Meteor logging quickstart

Every few years, it’s useful to survey the package ecosystem and figure out the state of DevOps logging. Logging in and of itself isn’t particularly challenging; the industry has been doing it for 50 years. It’s mostly just a matter of updating documentation for new operating systems, new businesses, maybe a new protocol or file format. Typically, it’s not something that needs to be done more than once every two years, and this is probably the third time I’ve done it for the Meteor ecosystem.

Since the last round of articles were written for logging, Meteor has seen a lot of changes—the most notable being the new ES2015 syntax and Meteor 1.3 introducing full support of NPM packages via import statements. This means a lot of the old packages break with current Meteor apps and old tutorials are outdated. So, it’s time to do a survey and figure out where things currently stand!

Methodology

After talking with Meteor devs, reading tutorials, and searching the Meteor forums, we narrowed the current Meteor logging landscape to the following seven packages: three NPM packages and five Atmosphere packages.

NPM packages

“loggly”: “^1.1.1”
“winston”: “^2.3.1”
“winston-loggly-bulk”: “^1.4.2”

Atmosphere packages

miktam:loggly
infinitedg:winston-loggly
infinitedg:winston
brentjanderson:winston-browser-logging
clinical:winston-browser-logging

Like a test kitchen, we went through and implemented each recipe to figure out how well it worked. It was simply a matter of following tutorials and READMEs, creating some demos, and figuring out which ones still worked and were up-to-date. You can find our reference demos of the above packages here:

https://github.com/awatson1978/meteor-loggly-demos

There were three main questions that needed to be resolved: NPM or Atmosphere? And should we just install Loggly or should the entire Winston logging layer be included? And can we retain an isomorphic API across both server and client?

The reasoning behind selecting and recommending the following quickstart goes like this: A number of the packages were outdated and hadn’t seen any maintenance in three or four years, which ruled them out. Also, the Meteor Development Group has announced a long-term goal of moving away from Atmosphere to NPM, which gave us a clear preference for NPM packages.

Since Loggly recommends the winston-loggly-bulk NPM package as a best practice and it works seamlessly with Meteor, it was a great foundation. The benefit of Atmosphere, however, is client-side packages and isomorphic APIs, which the brentjanderson:meteor-winston-client package nearly provided, but had some errors in. So, we forked and published the clinical:winston-browser-logging package to get the isomorphic client-side API. And thus, we get best practices, isomorphic API, and updated packages that are currently supported and maintained.

Quickstart

To begin this walkthrough, we want to emphasize that Meteor is fundamentally just a flavor of Node. It has an extended build pipeline and some best practices regarding folder structures, code styles, importing modules, and the like. But at the end of the day, it’s simply Node.js.

1. Install NPM packages

We begin by simply installing the winston and winston-loggly-bulk packages using the meteor npm command. Just like the Node.js tutorial. You can also add NPM packages directly to the packages.json file, and Atmosphere packages to .meteor/packages.

This requires Meteor v1.3 or later.

# first we install our npm packages for the server
meteor npm install --save winston winston-loggly-bulk

# then we install atmosphere packages for the client
meteor add clinical:winston-browser-logging

2. Configure loggly-winston-bulk

With the loggly-winston-bulk package, we configure the Winston logging subsystem direction in our application. This has long-term support from MDG, is aligned with best practices, and shouldn’t be going anywhere.

// server/main.js  
var winston  = require('winston');
require('winston-loggly-bulk');
 
winston.add(winston.transports.Loggly, {
  inputToken: "TOKEN",
  subdomain: "SUBDOMAIN",
  tags: ["meteor", "winston"],
  json:true
});

3. Set up client- and server-side logging

Now it’s time to start logging!

// the code in this block can also be put into client/main.js
if(Meteor.isClient){

  // starting from Meteor 1.3, it's best to explicitly declare your imports 
  import { Meteor } from 'meteor/meteor';
  import { winston } from 'meteor/clinical:winston-browser-logging';

  Meteor.startup(function(){
    // You should see a message on both the browser console and Loggly.com
    winston.info("winston-client has started on the client!");
  });  
  
}

// the code in this block can also be put into server/main.js
if(Meteor.isServer){  
  // starting from Meteor 1.3, it's best to explicitly declare your imports 
  import { Meteor } from 'meteor/meteor';
  
  // note that we're importing winston from a different package!
  // (this is totally a feature, not a flaw)
  import winston from 'winston';

  Meteor.startup(function(){
    winston.log('info', "Hello World from Node.js!  winston-loggly-bulk-demo has started!");
  });
}

Advanced architectures checklist

Sometimes you have more complicated logging requirements. Our survey of the current state of logging also led to the following checklist for more complex Meteor apps. Do you:

• Have a legacy Meteor app? Or are you using ‘Meteor Classic’?
• Need to use a packages-only architecture?
• Use a local copy of the Fastosphere package manager?

Use the older infinitedg:winston-loggly and infinitedg:winston packages. Of the four reference demos, meteor-winston is a classic, but it’s also falling behind as the rest of the technology ecosystem changes.

---

• Need SNMP-like functionality on a cluster of servers
• Need quiet statistics reporting from desktop electron apps
• Have a strict NPM-only policy
• Have an express or apollo configuration
• Aren’t using minimongo or DDP

Use the loggly NPM package, which provides a behind-the-scenes reporting tool. Of the four reference demos, loggly-demo will quietly report to the Loggly service with no hassles.

---

• Need the quickest and easiest way to start logging with Loggly
• Don’t need a logging transport layer
• Need an isomorphic API
• Want the simplicity of Atmosphere packages
• Don’t mind self-hosting the package if Atmosphere is decommissioned

Use the miktam:loggly Atmosphere package, which provides a dead-simple isomorphic API to get data from your app to Loggly.

Unless any of the above items applies to your project, you should be good to go with the quickstart. To learn more about Meteor application monitoring use cases, read this post by Michael Ghobrial.

References

And there you have it. A nice roundup of the state of logging for Meteor apps. For more information, see these links. And happy coding!
https://www-staging.loggly.com/blog/managing-a-meteor-application-in-production-three-real-log-management-use-cases/
https://www-staging.loggly.com/blog/pii-logs-managing-log-data-loggly-fluentd/
https://www-staging.loggly.com/docs/node-js-logs/
https://www.east5th.co/blog/2016/07/04/winston-and-meteor-13/

The Loggly and SolarWinds trademarks, service marks, and logos are the exclusive property of SolarWinds Worldwide, LLC or its affiliates. All other trademarks are the property of their respective owners.