-
Notifications
You must be signed in to change notification settings - Fork 487
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
spanmetrics: wire in new metrics_flush_interval field #4614
Comments
This issue has been automatically marked as stale because it has not had any activity in the past 30 days. The issue will not be closed automatically, but a label will be added to it for tracking purposes. If the opened issue is a bug, check if newer releases have fixed the issue. If the issue is no longer relevant, please feel free to close it. |
Is this for both Flow mode and static mode? |
@rfratto I believe this is just for static mode if I recall correctly. I am not sure about flow mode, but if you make any changes to the static agent, please keep me updated. |
Hey @rfratto @shelbyatgrafana . I'm the one who raised this. We use static mode, currently. |
For development context, anything added to static mode must also be brought into flow mode, since we're actively working on giving flow mode parity with static mode. Since the request is for static mode, then the implementation must make sure that both static mode and flow mode are covered. |
I think this was added here 7357b37#diff-e2e63ff69ed7490ea189f8053e03be8b6d74504e8b1f8ec5b4c516e07b9daf28R50 ? (in 0.36.1) Edit: Looks like maybe this only exists in flow mode, not static mode |
Flow mode already supports During the last time we upgraded our Otel dependencies, I made a conscious decision to refrain from adding new config parameters to Otel components used in Static mode. This was based on the assumption that the components would keep working as they have in the past, and any new parameters would be set to default values by Otel so that components keep working as before. To be honest this assumption is hard to verify, given that #5271 is causing inconvenience for users I will look into adding the |
Request
Since we've updated our OpenTelemetry Collector dependency, we can now wire in a new field available in the spanmetrics processor,
metrics_flush_interval
.Use case
This would help with limiting the rate of metrics generation, from every time a trace was received to a preset interval and help users manage their data throughput.
The text was updated successfully, but these errors were encountered: