Skip to content
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

Include internal trace context with internal metrics #2660

Closed
binarylogic opened this issue May 21, 2020 · 10 comments · Fixed by #3888
Closed

Include internal trace context with internal metrics #2660

binarylogic opened this issue May 21, 2020 · 10 comments · Fixed by #3888
Assignees
Labels
domain: data model Anything related to Vector's internal data model domain: metrics Anything related to Vector's metrics events have: must We must have this feature, it is critical to the project's success. It is high priority. needs: requirements Needs a a list of requirements before work can be begin type: enhancement A value-adding code change that enhances its existing functionality.

Comments

@binarylogic
Copy link
Contributor

#1953 introduced a new internal_metrics source for Vector's internal metrics. Metrics are defined within events, you can see an example here. A caveat noted in #1953 is the ability to carry over the internal tracing context:

A big benefit of tracing is its ability to propagate contextual information about where you are in the system. We use this extensively for our logging to tell you what type and the name of the current component without having to manually pass that data around everywhere just for log messages. This same functionality would be very beneficial for naming and tagging metric data, so a tracing based solution is what we started with and what I spent quite a bit of time exploring.

Unfortunately, the state of using tracing to collect metrics is extremely early right now. What we want to do is definitely possible, but both the exact implementation and the public API are still undergoing a lot of experimentation. This seems like an area we could jump in and help advance the state of the art, but my current read is that we need a metrics system sooner than that work will be ready, even with our help.

This issue represents the work to solve this.

@binarylogic binarylogic added type: enhancement A value-adding code change that enhances its existing functionality. event type: metric needs: requirements Needs a a list of requirements before work can be begin have: should We should have this feature, but is not required. It is medium priority. labels May 21, 2020
@binarylogic
Copy link
Contributor Author

@lukesteensen is this something @ktff could work on? This would require upstream work but I think it might be worth it.

@lukesteensen
Copy link
Member

I've chimed in on metrics-rs/metrics#70 to see if there's anything we can help with.

@binarylogic binarylogic added domain: data model Anything related to Vector's internal data model domain: metrics Anything related to Vector's metrics events have: must We must have this feature, it is critical to the project's success. It is high priority. and removed event type: metric have: should We should have this feature, but is not required. It is medium priority. labels Aug 6, 2020
@binarylogic
Copy link
Contributor Author

@MOZGIII as discussed, I think this is the highest priority change outside of any remaining k8s works. I've added this to your sprint. It might be worth chiming in on metrics-rs/metrics#70 to ensure your approach will be accepted.

@binarylogic
Copy link
Contributor Author

@MOZGIII how's this coming? Just noting this is priority after the source-level line merging.

@MOZGIII
Copy link
Contributor

MOZGIII commented Sep 2, 2020

I've started with the implementation.

@lukesteensen
Copy link
Member

@MOZGIII Could you explain a bit about what your rough plan is here? I'd like to do as much of this work as possible in the open so that we can make sure we're aligned with the upstream projects.

@binarylogic
Copy link
Contributor Author

To add more context here. We chatted with the maintainer of metrics-rs in an email thread which then moved to a Discord channel. Mike has been chatting with him there about the direction. But I agree, I would like to hear a rough plan, and also double verify that his plan is blessed by the maintainer.

@lukesteensen
Copy link
Member

Ah, gotcha. I can follow along in Discord.

@MOZGIII
Copy link
Contributor

MOZGIII commented Sep 2, 2020

Yep, here's what we're planning to do:

  • we'll add a Layer for metrics crate that would inject labels;
  • this, in turn, would require two things:
    • in metrics crate ecosystem:
      • either disabling the static labels optimization, or
      • changing the APIs to decouple the static and dynamic label sets (we're leaning to this option currently);
    • in tracing ecosystem:
      • as I discovered today, we'll need to add a way to enumerate all fields a Scope has (no such API currently).

That's about it, roughly. I hope it goes smoothly and without any more surprises.

@MOZGIII MOZGIII removed this from the 2020-08-31 - Digitization Laser milestone Sep 9, 2020
@MOZGIII MOZGIII added this to the 2020-09-14 - The Grid milestone Sep 9, 2020
@MOZGIII
Copy link
Contributor

MOZGIII commented Sep 9, 2020

A tiny status update:

  • turns out no changes are required in tracing crate - there's a (non-trivial) way to do what we need with the current API;
  • there's work ongoing on the API changes to allow dynamic labels passing; the macros might change a bit too.

For further progress, check out the metrics-rs/metrics#87.
We're also discussing the progress in chat at https://discord.gg/RqTk6bq - feel free to join if you're interested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain: data model Anything related to Vector's internal data model domain: metrics Anything related to Vector's metrics events have: must We must have this feature, it is critical to the project's success. It is high priority. needs: requirements Needs a a list of requirements before work can be begin type: enhancement A value-adding code change that enhances its existing functionality.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants