-
Notifications
You must be signed in to change notification settings - Fork 460
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
[azure_metrics] Duplicated metrics/metrics are not groupped #7621
Comments
Case 2 may be a side-effect of how the Azure Metrics metricset works, like at #7162 (comment). I'll try to reproduce these issues. Is there a metricset where this always happens? |
I could always reproduce it for |
@tetianakravchenko, we are changing the interval and the grouping logic for the metricset. I pushed a custom build of the agent with these changes. Would you mind to give it a try on your local stack with the Compute VM metrics? The agent version is 8.12.0-SNAPSHOT and the docker image id is zmoog/public-notes#35 (comment) I pushed the |
@zmoog thanks! I will give it a try and come back to you today-tomorrow |
We made a few additional changes to the interval and added a I'm building a new image, updates soon! |
Here's the latest custom agent build info:
Changes:
|
I am currently focusing the testing on |
@tetianakravchenko, did you get a chance to run some tests using the custom agent build? |
Here's the latest custom agent build info:
Changes:
|
@zmoog could you please build and share
I am getting warning above. thought I can run the container, for some reason I do not see the azure metrics |
Which metrics are you testing? |
Yep! I'll rebuilt it for linux/amd64. |
@tetianakravchenko, here's the latest custom agent build info for the
Same changes:
Footnotes
|
found some errors in logs:
|
Here's the latest custom agent build info:
Changes:
|
@tetianakravchenko, I am running the agent build |
Thanks for testing all these metricsets! I believe I found the root cause for the I'm building a new custom agent image to fix this error for all metrics. |
Here's the latest custom agent build info:
Changes:
|
Test results:
doc1
doc2
since there is used @zmoog if you think that the last point should be addressed by the elastic/beats#36778, I think we are good to open elastic/beats#36823 |
529 is an unofficial HTTP status code that Azure sometimes uses. It seems to be a transient error due to too many requests hitting the servers on the Azure side. The duplication is probably happening because the metricset didn't complete processing, and the event lacks some dimensions. |
\o/
Okay, so it looks fine and we only need to add a missing dimension definition here? |
yes, some number of duplicated documents are related to the fact that Other duplication group I believe could be related to the different |
Yeah, I see this metric example you reported has a This integration has PT5M and PT1H time grains and a 5m collection period. The metricset collects the same PT1H data point multiple times. This duplication is not a blocker for TSDB because it improves the situation by dropping the extra documents. However, we can try to integrate the work @tdancheva did to solve this problem for TSDB and non-TSDB data streams. |
opened #8319, testing if with this change I don't see any overlapping docs (beside the docs with |
The only overlapping documents are the one with |
I am testing a build that handles data streams with mixed time grains scenario, like a metricset with a 5 min collection period with metrics with I'll ship a custom agent build a little later this morning with this change. |
are you testing the build that includes elastic/beats#36778 ? |
Yep, parts of it. I had to make additional changes because some metrics configurations (for example, the first configuration in the database account) do not specify a time grain value. If we don't have time grain in the config, we can't calculate the intervals before sending the requests. |
Here's the latest custom agent build info:
Changes:
|
I've tested this image for all datastreams - no duplications (except one pair of |
Hi! We just realized that we haven't looked into this issue in a while. We're sorry! We're labeling this issue as |
Closing this as we have no reports of grouping issues anymore. Feel free to reopen if new data becomes available. |
Case 1. Duplicated documents. Comparing the documents below - the only difference is document id,
event.duration
andevent.ingested
It seems to be fine to drop 1 document (it will happen when enabled tsdb), since the list of metrics and the values are the same (at least for this example provided below)
document 1
document 2
Case 2. List of metrics in documents is different, and the values for the same metric name are different. In such case it seems to be some mistake.
Another strange thing: one document has
"ingested": "2023-08-30T15:36:46Z"
, another"ingested": "2023-08-30T15:41:49Z"
, so 5 min apart, but they are published under the same timestamp"@timestamp": "2023-08-30T15:31:00.000Z"
document 1
document 2
Note: this behavior I could see for both
compute_vm
andcompute_vm_scaleset
,monitor
cc @zmoog @tommyers-elastic
The text was updated successfully, but these errors were encountered: