Building an open source, self managed Meteor APM


#1

The Kadira client looks like it works great for collecting performance data from the Meteor applications.

However, once we get to the Kadira server, things get complicated. It was designed to be a SaaS product, and as a result, it has many features not related to performance management, it relies on many services, it has to support a lot of requests, and so on. Plus, it would be natural to think there are some issues and/or bugs present.

I’m wondering, why not repurpose Kadira Client to store all the data it collects into the application database (or a secondary database) and then build a simple interface to view all of it? Perhaps we can even cut out some non-key features to keep things really simple.

I would be happy to start some kind of group and build the interface part to run with-in a user’s app.


Running a own Kadira instance Update: now with a guide!
#2

I could help with that. don’t know about my time right now, but it sounds like a fun project :slight_smile:


#3

I’ve never used Kadira, do you know off hand what performance data it collects on the Client?

Also, how hard would it be to use the Kadira Client to collect this performance data, and just send it to another server’s REST endpoint periodically? Nothing fancy, just sending over the perf-data via REST to a remote DB for later analysis. I’d be interested in building something like this for my clients.


#4

By client I mean the APM package that sits in your app and pushes data to Kadira.

I imagine it wouldn’t be too difficult. The Meteor APM Agent could probably be used as well. Maybe we can have some kind of function that lets you decide what to do with the collected data, like send to a REST endpoint, push into something ElasticSearch, or just store in Mongo.

I haven’t used Kadira either - I mainly want this to see how my methods and pub/sub is performing. It looks like Kadira does support some client side tracking, but I think that can be gutted. What do you think?


#5

Kadira logs all client-side (and server) errors, and some of the response time measurements are probably also done on the client.

I think cutting out all the now unnecessary parts of Kadira and simplifying it would be good, maybe get it down to a single process instead of three as I think it is at the moment. It’d be cool if you could just run the Kadira server as a regular Meteor project (or even as just a package as you said). Kadira already has an excellent front-end and everything though, so I think you might as well use that instead of creating your own. Unless you think it’s really fun of course :smile: