-
-
Notifications
You must be signed in to change notification settings - Fork 7.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
First class support for popular instrumentation technologies #4007
Comments
Thanks for your extensive issue - though we track it here #967. |
I know you're trying to purge duplicates and keep your issues groomed, but the scope of this issue is different. This feature request is asking for metrics and open tracing to be added to official nest modules. It's a call to action to consider prioritizing telemetry and observability as a whole. The linked issue is specifically regarding a community Prometheus library, it's stale and without any action in over a year. @BrunnerLivio please consider re-opening the issue, I think this is important for nest going forward. I'm here for constructive reasons. As per Nests motto, how can you deliver your promise to "build scalable server-side applications" without the above? |
@tl-jarvis-prestidge Please note that Nest is compatible with every existing Node.js library and creating official wrappers for all of them is simply impossible for us to handle. For instance, you can easily use Nest with sequelize, knex, typegoose, even though the "official modules" for these packages don't exist. If you look at the official repositories such as
Delivering a framework that helps developers and teams to create highly testable, scalable, loosely coupled, and easily maintainable applications doesn't mean "create a wrapper for every single, popular Node.js library that has been built over the last 9 years". If you look into our documentation, you'll see this:
Our goal from the very early beginning was to provide an opinionated, testable architecture which makes Node.js projects easier to maintain & scale. As long as devs learn how to leverage this architecture (and we show how beneficial it is with several "official" modules), they should be able to wrap and use anything with Nest. PS.
Modules that wrap the official packages don't really have to be updated unless breaking API change was introduced in the underlying library. Typically, wrappers are very thin and expose a simple interface to interact with other packages (which usually are maintained by larger organizations). I've personally used "nestjs-prom" library and it worked quite well. |
Feature Request
Nest covers integration with so many interesting frameworks and libraries and is encouraging microservices architectures, but completely lacks guidance and integrations with core technologies useful in helping observability. Things like Prometheus metrics, and (name your vendor) open tracing. Which really matters when taking your project to production.
Is your feature request related to a problem? Please describe.
Things like metrics, tracing, logging, health checks etc. are all core concepts in cloud native applications, but the tracing and metrics side of things feels like it's been neglected in nestjs. There's no clear way to add these to our applications and realistically they should be togglable and auto instrumented similar to other frameworks trying to do the same thing as nest. i.e. moleculer seem to be on top of this.
Describe the solution you'd like
Bring in popular prometheus / jaeger / zipkin integrations to give the community some guidance and confidence in the ability to instrument a nestjs application with industry-standard metrics and tracing tech.
Teachability, Documentation, Adoption, Migration Strategy
What is the motivation / use case for changing the behavior?
I'd like to integrate Prometheus and Jaeger in my cluster with some nestjs applications and although there's are numerous npm packages to do so, I feel as though this should be a concern at least partial solved with a reciepe for nest 🙏
The text was updated successfully, but these errors were encountered: