I think lots of people still use it but maybe they are fragmented now between the MDG fork, the MontiAPM fork and all the others. The only person I know actively developing it is @zodern who runs MontiAPM . We use that and would love to see the improvements you mention. Particularly number 3 and having some tracking of webhook entry points would be great.
Is the MontiAPM fork opensource and available on github? Or only provided as online services?
#1 and #3 I am planning to add to Monti APM. Someone else wanted something similar to #2, and I am considering it.
It currently is not open source, though this could change.
2 Likes
I got most of the features I wanted to working (webhooks are working, but I need to test more and cover some edge cases I know of).
Whats working:
- Force kadira to save a trace
- Logging within a Meteor.defer call (specifically on the server)
- Logging async traces
- Logging of functional contexts
2 Likes
I’ve checked the changes mentioned in the readme and they look very useful for daily monitoring. Hopefully these changes reach all the different Kadira implementations out there 
1 Like
One thing I’d love to get working (again) is notifications, via email, or slack. For example when an error is found for the first time (or if it was marked as resolved), I’d want to be pinged somehow by kadira.
Similarly for other triggers, like if the app is down, or if CPU usage is very high.
Awesome work @znewsham
I think notifications are working in Monti APM, I’m getting notifications on Slack.
1 Like
Yep, saw that Though we’re self hosted…
@florianbienefelt - we’re self hosted and have notifications working too. If you want email, you need to configure your own SMTP connection, but for slack it worked pretty much immediately - you need to run the alerts AND API services in addition to the RMA, engine and UI. We made a few small changes to the alerts manager to get it working with rocket chat too
You need to already have been using a Kadira environment - it is no longer a paid service. If you dont already have that setup, Monti is probably a better option for you.
I used to use Kadira before.
But I don’t understand how to setup.
Have any video tutorial?
No, the Kadira UI was sold to MDG and open-sourced. So you can build your own environment following the instructions found here: https://github.com/kadira-open/kadira-server But it isn’t simple. You’d need to do this whichever kadira derivative you used, unless they have opted to build a paid service around it, as MontiAPM did. However, its unlikely that my package will work with their paid service, though if asked they may integrate some of the features.
Thanks again, Now I tried Monti APM with standard plan.
1 Like
You should try this version of the APM, which is dockerized for an easy deployment : https://github.com/lmachens/meteor-apm-server I got it working quite easily with notifications.
I will look @znewsham version which has some improvements to the original version.
Just for cross reference … could we get this apm package extended so it provides a common way of gathering the data and an interface for the individual monitoring tools?
I saw this idea previously on a post about meteor-elastic-apm … See: The new APM for Meteor is coming soon!
Just a heads up that I have a PR open towards monti to remove underscore from the client side ( https://github.com/monti-apm/monti-apm-agent/pull/7 ), but I also am working on a larger refactoring, bringing it to modern ES standards. I work on it every now and then when I have a little time to spare, so it might form a good basis for further extensions.
2 Likes
From my side - with many APM packages and UI’s in existance, I’d like to see us move toward an API specification. To decouple the package from the server. Specifically, I’d like to see three things:
- the ability to define arbitrary types, with custom UI without modifying the package, either by sending a configuration message to the server, or by allowing arbitrary styling information to be sent with each event (easier, but would cause dramatic overhead).
- the ability to define arbitrary groupings, not just methods, pub/sub, but potentially methods, pub/sub, defers, page views, anything else I want, e.g., tracking self-defined methods separately from package-defined methods.
These two things would mean that in the future package authors could extend their preferred APM package with other actions they would like to log, without having to modify a server they potentially dont control.
Yes, you are completely right. I am planning to do this when I complete my current apm package. It will be something that will collect events with time logs, then you decide what to do with this data, save it to db or send to elastic, kadira or something else.
1 Like
I have been working with the kadira-open/kadira-server code and have the UI upgraded from Meteor 1.4.3.2 to Meteor 1.8.3. The APM engine is running in-house in a local environment running on RedHat Enterprise Linux 7. A limited staff of in-house Meteor software developers is currently using our local fork of the Kadira APM.
I have provided one branch v1.0.0 that makes the original code serviceable. A second branch v2.0.0 will soon be posted that supports Meteor 1.8.3. I am currently working on an update to support the toolchain compatible with Meteor 1.11.1. These updates are based on Meteor and the packaged npm compatible tools.
Since Kadira is an implied trademark owned by the developer, and a recommendation has been made to rename the forks of the package, I am still trying to determine a proper name for my fork of the code.
The github repository is shathaway/kadira-server. I do not have a good name at this time for my fork of kadira-server.
Our work makes significant patches to:
- kadira-engine
- kadira-rma
- kadira-ui
Another upgrade will support RedHat Enterprise Linux 8.
4 Likes