Utilizing New Relic APM inside of a Meteor application

This is a running log of information I plan to use to help me research, understand, implement and communicate why and how to utilize New Relic's APM suite inside of a Meteor application.

Why?

Meteor's rise to prominence (currently 30th ranked project on GitHub) has brought challenges for developers that choose to utilize the framework in a production environment. One of those challenges is application monitoring. With the downfall of Kadira, Meteor's defacto go to application monitoring service, developers have been relegated primarily to self hosting Kadira, or jumping into the larger Galaxy platform for insights.

Enter New Relic and it's industry leading APM suite.

The current state of New Relic and Meteor

As Meteor matures and the Meteor community scrambles to find a robust solution to monitoring their applications, many have turned to New Relic. Atmosphere (Meteor's package management system) has seen a few plugins turn up that attempt to hook New Relic's supported node agent into Meteor, however, from my experience these packages do not unlock the full potential of New Relic. Not for lack of effort or attention; the porting of New Relic's node agent into Meteor is a complicated process.

Challenges

---

One of the simpler, yet persistent, challenges is managing edits to New Relic's config.default.js and/or the newrelic.js files. Meteor literally removes these config files altogether during the build if they have been edited. Meteor package APIs do not allow for changing of internal configs for packages. One solution to this challenge is exporting the needed environment variables like so:

NEW_RELIC_NO_CONFIG_FILE    TRUE
NEW_RELIC_LICENSE_KEY       YOURKEYID
NEW_RELIC_APP_NAME          YOURAPPNAME
NEW_RELIC_LOG_LEVEL         ONE OF error, warn, info, debug, or trace

If you're using meteor-up you can achieve this rather easily by setting these variables in the mup.js file like so:

...
meteor: {
    ...
    env: {
      ...
      NEW_RELIC_NO_CONFIG_FILE:    'TRUE',
      NEW_RELIC_LICENSE_KEY:       'YOUR_LICENSE_KEY',
      NEW_RELIC_APP_NAME:          'YOUR_APP_NAME',
      NEW_RELIC_LOG_LEVEL:         'debug',
      ...
    },
    ...
 },
 ...

Once you get passed this challenge, you application will successfully complete the 'handshake' with the New Relic montiring suite, however your New Relic dashboard will remain empty. Note: You can always use New Relic's browser tools by simply adding their supplied js scripts to your page header(s)

---

Disclaimer: The challenges and solutions in this section are still a work in progress and have not been isolated from eachother. The challenges, and therefore solutions, are still somewhat unclear to me at this point.

1. Another hurdle in instrumenting Meteor apps is due to Meteor's use of websockets. The New Relic node agent works by monitoring HTTP transactions that respond to the request/response cycle (transactions with a defined start and end). Since Meteor uses websockets this presents a challenge.

2. The New Relic node agent is also designed for monitoring server side applications. Because Meteor is isomorphic in nature, this presents another hurdle.

3. Other desired Meteor specific metrics may include pub/sub response time and method response time. Those could probably combine somehow to an Apdex score for Meteor apps when you also factor in MongoDB response time.

One github user in particular has been especially helpful in exploring possible solutions to some of these challenges - and has seemingly solved many of these issues for a private client. You can view the github issue thread here, but the most important information supplied by @FGM can be seen below:

@RyanThomasMusser I just finished by adding custom code to the standard NewRelic package. Regrettably, the customer did not agree to open source it for now. In short, what I did create is:

* a NrMethod class and NrMethods instance monkey-patching Meteor.methods as a side effect of importing our package

* a createTracer() function allowing the capture of background transactions

* a NrBackgroundTask to allow a simple way to create background transactions

Native metrics, Connect, Express, MongoDB, are captured normally with that setup, using the newrelic and native-metrics packages. We still have the warning on top of the NewRelic screens, but the metrics are there, including those at the "node vm" level.

---

As mentioned, the last section of this write up is still incomplete and a work in progress. More information on solutions and diagnosis of the issue to come soon! If you have any questions, concerns or suggestions please don't hesitate to reach out to me at ryanthomasmusser[at]gmail.com