Hi @a4xrbj1, before I ask a question here let me say very clearly: I really love datadog and at Meteor we use their services to monitor many of our components, mostly our Go components that provide Proxies, Schedulers, Image builders, Automatic Certificates and everything in our infrastructure.
Now my honest question, what exactly are you tracking with dd-trace that you are not able to track with APM? This is a very honest question from someone that already scaled many Meteor apps in productions and I never used dd-trace, probably I’m missing something.
In my optimizations and monitoring cases Meteor APM + Memory Profiler package + CPU Profiler package where enough to me but I would like to understand more the usage of dd-trace with Meteor apps, I’m sure they are offering something that is great for Node.js apps in general
We describe a little bit on how to understand problems with your container in this package of Galaxy (cloud) Guide Container environment | Galaxy Docs
Specifically in these paragraphs:
One important tool to identify bottlenecks is the Meteor APM as it shows to you the Methods and Publications running. Specially in cases where you have spikes in CPU usage keep an eye as well in background jobs, maybe they are consuming all your CPU and then your container becomes unhealthy. Node.js is single threaded so is very important to be aware of heavy CPU operations in your app, mainly if you run background job tasks in the same app your users use the UI.
You can also profile your CPU as you would in any Node.js project, this package can help you to generate a profile and send it to S3. If your problem is related with memory you could use this package to get heap dumps from your container.
Again, I’m not advising against datadog, I just want to understand more what they are offering to you and Meteor users in general. I really love their services