Is there any interest in a few tweaks to the old open-source kadira system? I’m still using it for APM and while it is excellent, find its lacking in three key areas:
anything that happens in a callback gets logged as async (even if it’s DB work)
no ability to track movement between functions in a complex server side method (helpful with debugging)
no tracking of non method/pubsub interactions (e.g., when using packages like meteor-files, or responding to webhooks).
(2) can be fixed with some jerry rigging of Kadira (manually tracking “db.enteredFunction foo”)
(1) and (3) can be semi-fixed with pure kadira package changes (tracking webapp requests as methods, and tracking calls nested inside an aysnc block, but reporting them flat).
However to do this properly would require hacking about in the kadira engine and UI projects - so I’m wondering if anyone has already done something like that, or if there is any interest in it?
Glad to hear it - I thought for a moment I was the only one still using it! Any other additions/changes you’d make to the list? I know that (1) will increase the workload a bit, depending on how often you have these nested contexts
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.
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
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.
@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.
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.
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?
