-
Notifications
You must be signed in to change notification settings - Fork 25k
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
TSDB: Modeling of delta metrics in elasticsearch #98171
Comments
Pinging @elastic/es-analytics-geo (Team:Analytics) |
One area where it could be helpful to have knowledge about delta metrics is when building queries. Assuming we know a value is a delta and not a gauge value, we could recommend some aggregations vs others and explain to the user in the UI why one should be used vs the other. |
The thing is that a lot of protocols don't have the distinction between gauge vs delta. For example, in OTLP, there's only the |
@felixbarny If I understand your comment correctly, then a delta gauge isn't really needed now? So we can close this issue? |
I think what I said back then wasn't entirely correct. In OpenTelemetry, there's the concept of temporality that describes whether a counter is I agree with Ruflin that you'd perform different default aggregations depending on whether something is a delta counter vs a gauge. Therefore, I think we shouldn't close this issue and instead work on properly supporting metric temporalities. Having said that, I don't feel like this is very urgent. |
Pinging @elastic/es-storage-engine (Team:StorageEngine) |
Delta metrics are emitted by GCP and needs to be stored in elastic TSDS. The definition of delta metric is "The change in a value during a time interval"
The current proposal is to model the delta metrics as gauge, in the GCP integration metrics.
Suggestion by Felix: I think we should just map GCP DELTA metrics to gauges. I wouldn’t consider this a hack or a short-term solution as I don’t expect this have any negative impact.
Maybe the reason they have different types for delta vs gauge is that the consumers can differ between the two so that they can convert delta metrics into cumulative counters if they need to. But ES has excellent support for both deltas and counters so I don’t think that’s necessary.
Keeping this issue open to track any comments/suggestions for the same and potential future requirements to support delta metrics natively as a time_series_metric directly.
CC: @constanca-m @mlunadia @felixbarny
The text was updated successfully, but these errors were encountered: