Getting Started Quickly with Meteor Logging
Tags: logging, programming, software
Published: 2019-10-22 15:29:31

We’ve covered a lot of bases in our "getting started quickly" posts. In addition to <a href="https://www.scalyr.com/blog/get-started-quickly-with-javascript-logging/">JavaScript</a> and <a href="https://www.scalyr.com/blog/getting-started-quickly-with-node-js-logging/">Node.js</a>, we’ve created guides for&nbsp;<a href="https://www.scalyr.com/blog/get-started-quickly-csharp-logging/">C#</a>,&nbsp;<a href="https://www.scalyr.com/blog/get-started-quickly-java-logging/">Java</a>,&nbsp;<a href="https://www.scalyr.com/blog/get-started-quickly-with-python-logging/">Python</a>,&nbsp;and more. Today we’ll discuss logging from a Meteor point of view.

Now, since Meteor can follow the same premise as JavaScript and Node.js, we’re going to change things up a bit. Instead of an empty app, we're going to clone an existing sample app and add logging to it. But if this tutorial isn't quite what you were looking for, go check out the basic JavaScript and Node.js posts. They'll cover anything else you might need.

But don’t worry, we’ll still cover these topics:

• Meteor overview
• Basic logging
• Where to log
• What to log

Now let's get started.

<img class="wp-image-2967 aligncenter" src="https://library.scalyr.com/2019/02/15120426/Meteor_logging_image_with_scalyr_colors.png" alt="Meteor_logging_image_with_scalyr_colors" width="541" height="541">

<!--more-->
<h2>Meteor Overview</h2>
If you came to this blog post by searching for Meteor logging, you might not need this section. But I’d like to make sure we’re all starting from the same point, so here’s some quick Meteor info. Don’t worry, I’ll be brief.

<a href="https://www.meteor.com/">Meteor</a> provides a full-stack JavaScript platform for developing web and mobile apps. It includes a number of packages from Node.js and other JavaScript libraries. It focuses on and provides full stack reactivity so your UI acts seamlessly with your backend server. And as a bonus, it provides easy MongoDB integration right out of the box.
<h2>Basic Logging</h2>
As I mentioned above, instead of creating a bare application, we’re going to clone one of the existing sample applications that the folks over at Meteor have provided. Since we’re adding logging to an already existing app, we’ll be able to see different logs come through with minimal effort.
<h3>Setup</h3>
If you haven't used Meteor before, their basic setup is a breeze. First, you'll need to install both Node.js and npm. Also, if you're on a Mac, you'll need Xcode as well.

For step two, we'll install Meteor using either Chocolatey or a curl command, depending on your operating system.
<pre class="lang:default decode:true">curl https://install.meteor.com/ | sh

// OR...

choco install meteor</pre>
All set? Great. Next, let's clone the simple todo app from Meteor.
<pre class="lang:default decode:true">git clone https://github.com/meteor/simple-todos.git</pre>
Once you've got everything downloaded and installed, cd into the simple-todo directory and run the app using the Meteor command.

<img class="alignnone wp-image-2969 size-full" src="https://library.scalyr.com/2019/02/15124602/011.png" alt="" width="948" height="416">

Once the application has started, go to http://localhost:3000/. You should see a simple todo app there.

<img class="alignnone size-large wp-image-2970" src="https://library.scalyr.com/2019/02/15124645/021-1024x463.png" alt="" width="1024" height="463">

You should be able to add users, add items to the checklist, and so on. Go ahead and play around with it. I'll be waiting at the next section for you.
<h3>Console Logging</h3>
Now that you've had a chance to check out the application, let's get started. To demonstrate some simple logging, we're going to add some console logs to our application. This can be helpful for debugging issues on the client side while you're developing. But it won't do much for you once your application is being used by someone out in the real world—you won't have access to their console logs.

To start, let's add some code to the&nbsp;imports/api/tasks.js file. This file contains the JavaScript that's executed when we add or remove tasks from the list. In the "tasks.insert" method, add the log.console line shown in this image.

<img class="alignnone size-large wp-image-2971" src="https://library.scalyr.com/2019/02/15124721/031-1024x439.png" alt="" width="1024" height="439">

Next, after saving that file, head over to your browser window. It should have updated automatically, so you don't have to restart the app. When you add a new task, you should see the output in your browser console.

<img class="alignnone size-large wp-image-2972" src="https://library.scalyr.com/2019/02/15124750/041-1024x280.png" alt="" width="1024" height="280">

Looks great, right? What if we also want to add some user context? Modify the line in the "tasks.insert" method to also print out the userId object that this application has defined.
<div>
<pre class="lang:default decode:true">console.log('Task being added: ' + text + ' by ' + this.userId);</pre>
After that, you should see something like this.

<img class="alignnone size-large wp-image-2973" src="https://library.scalyr.com/2019/02/15124816/051-1024x221.png" alt="" width="1024" height="221">

Not super helpful, is it? Let's make it a little more useful by asking Meteor to find the username associated with this ID instead.
<div>
<div>
<div>
<pre class="lang:default decode:true">console.log('Task being added: ' + text + ' by ' + Meteor.users.findOne(this.userId).username);</pre>
</div>
</div>
</div>
</div>
Yes, that looks much better!

<img class="alignnone size-large wp-image-2974" src="https://library.scalyr.com/2019/02/15124841/06-1024x243.png" alt="" width="1024" height="243">

OK, now that we've done some simple console logging, we can move on to the next section. However, I have one thing I'd like you to do first.

Now that you have a Meteor application up and running, take some time to explore its various functionalities by adding your own console logging throughout the code. It really helps you understand the application by seeing data flow through the system as you use it. And though these may not be logs you want to keep around forever, they'll help you gain a sense of what goes into a good Meteor application.
<h2>Where to Log</h2>
Let's return to something I mentioned at the beginning of the console logging section: You won't be able to view your customer's console.log files. Let's discuss what you should do instead.
<h3>Send Logs to the Server</h3>
As discussed, if your application is being used by actual customers, you won't have access to their console logs. Sure, you could have them open their browser console and send you what's there every time there's an issue. But you're assuming that people will know how to do that. And even if they do know, it doesn't provide a great user experience for them.

So what can we do instead? Well, instead of just writing to a console, we could send logs back to the server. But then what?
<h3>Save Logs for Later Use</h3>
With Meteor, one option could be to set up a logging table in MongoDB. So instead of just inserting tasks as our example above shows, we could insert logging or error messages. However, storing logs in a database typically doesn't make sense. You want to store them somewhere easily accessible by tools like Scalyr so you can start harvesting some analytics.

Let's consider another option. How about taking a look at some of Scalyr's <a href="https://www.scalyr.com/help/api">APIs</a>? There are a lot of goodies there. And two of them let us add events to our Scalyr logs, either one at a time or by batch. So instead of logging to the console, or saving the logs to our database, we can send events that require logging right back to Scalyr.

In this situation, I would send the logs over to the server side of my Meteor application and then call the Scalyr APIs with the token tied to my account. Let's go over this in greater detail.

First, adding simple HTTP functionality to your Meteor app requires running the following command within your Meteor directory.
<pre class="lang:default decode:true">meteor add http</pre>
That will let you make HTTP calls to remote servers easily.

Then we can use the following syntax to send an event to Scalyr's addEvents API.
<pre class="lang:default decode:true">HTTP.call('POST', 'https://www.scalyr.com/addEvents', 
{
  "token": "YOUR_ACCESS_TOKEN",
  "session": "UNIQUE_SESSION_ID",
  "sessionInfo": {
    "serverType": "simple-todo",
    "serverId": "simple-todo-server-1"},
  "events": [
    {
      "thread": "1",
      "ts": "1332851837424000000",
      "type": 0,
      "sev": 3,
      "attrs": {
        "message": "Task being added: stuff",
        "recordId": 39217,
        "latency": 19.4,
        "username": "sylvia"
      }
    }
  ]
);</pre>
You may have noticed that I broke out the username from the message I sent. That's because breaking parts of the log into separate attributes will help with searching later.
<h2>What to Log</h2>
With great logging comes great responsibility. So what should we log in our applications?

Well, that depends—not only on what your application does, but also on whether you're logging on the client side or the server side. You also want to make sure that what you log adds value. Logging every little action is usually a bad idea.

In fact, the example above doesn't represent something I'd want to be logged in my system. I don't care what my customers add to their to-do lists. I care about metrics, performance, and errors. And I want specific information that can help debug issues.

So what sort of data can we log?
<ol>
 	<li>Errors—If something goes wrong, we want to know about it.</li>
 	<li>Usage—Let's see how often various parts of our application are used. If we have features no one uses, we can deprecate them or make them better.</li>
 	<li>Performance—We want to know what the customer experiences regarding latency. If the application slows down too much for them, we need to investigate.</li>
</ol>
<img class="size-full wp-image-2976 alignright" src="https://library.scalyr.com/2019/02/15125225/With-great-logging-comes-great-responsibility.png" alt="With great logging comes great responsibility" width="252" height="140">

Specifically for error logging, what information do we need?
<ol>
 	<li>Timestamps that tell exactly when an error occurred</li>
 	<li>User ID or context, so we know who was affected</li>
 	<li>Relevant parameters to help recreate the problem and find a solution</li>
 	<li>Unique and specific error messages to help pinpoint the problem</li>
</ol>
<h2>You're on Your Way</h2>
You're in a great place. You've got a sample Meteor app to experiment with, as well as some guidance on how to log information in it. Once you've logged data from your application, remember to review the logs from time to time. Iterate on what's being logged and the format until you have a useful set of data that will help you debug and optimize your application. And now you can rest easy knowing you'll be able to support your Meteor application in production.