-
Notifications
You must be signed in to change notification settings - Fork 597
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
Host metrics instrumentation #231
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome! I'm excited to use this 😄
Thanks for changing the runtime.Start
as well 🎉
It turns out that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
This instrumentation module implements metrics that the OTel Collector would also generate via its "hostmetrics" receiver. This covers only a minimum amount of information that is generally useful for monitoring, and leaves open questions about how to handle OS-specific metrics (esp. memory) and whether to encode per-CPU and per-NIC measurements for CPU and Network. See the new TODOs.
While working on this I filed several related specification questions:
open-telemetry/opentelemetry-specification#818
open-telemetry/opentelemetry-specification#819
This raises a very serious potential to share code with the OTel Collector's hostmetrics receiver, as that code is more thorough and handles OS-specific fields (with mock tests). On the other hand, factoring out that code module would be easier if we could migrate to using the real OTel-Go Metric SDK to generate these measurements. This is not out of the question, but too much work for this little PR, so I'll suggest that we start small with just a few metrics and evaluate this possibility later.