-
Notifications
You must be signed in to change notification settings - Fork 469
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
[AWS Usage] Overlapping documents when enabling TSDB - no more dimensions available #6783
Comments
been running the usage integration all day at 1hr collection periods and also not seen any dups. under what circumstances have you all seen this happen? i'm conflicted about what to do about this, because if we decide to go ahead with TSDB for these datasets, it would be very unlikely we would see this issue again (the issue is masked). but i have a feeling that for the cases we have seen here, the duplicate values are acting like cumulative counters over the collection period - i.e. the newer value is the one we should take, and the opposite happens with TSDB (the first value is the one we take). i think figuring out how to repro this, and determining if the above theory is correct regarding cumulative values should be the next step. although it doesn't seem like a particularly impactful issue, metric accuracy is important for us, and we should do what we can to figure it out. |
I honestly have no idea. I left AWS Usage running and it just appeared after some time with documents overlapping. I had many, many documents at that time. Sometimes I run the TSDB test for 40k documents and I do not see any overlap, so I have no idea what could be causing this. How are you checking if you can reproduce this @tommyers-elastic ? My suggestion would be to leave AWS Usage for 1 day and test on all documents, I am sure you would end up seeing the overlap. |
It seems there are few (potential) issues: How to reproduce
@constanca-m can you please check if you can reproduce it with usage data_stream? for this case it is not clear why the documents are added with the same timestamp? second use case - the one when |
I don't think it is necessary to go that far. I was testing using Elastic Cloud and the documents I had on aws.usage data stream. I checked the overwritten documents, and indeed, some of them only have those fields as a difference: And another example in the same data stream: So the document is the same, but it is weird that some metric changes sometimes: I believe this last case is even harder to find. From the set of 10 documents, I think only one had a change of value on a metric. I think these documents are all the same, which in that case, it is exactly what TSDB is for: discard the same document to save storage space. |
with tsdb enabled those duplicated documents will be silently dropped, but still generated, processed on the beats side and sent to elasticsearch, that is not optimal. |
One thing we can try is to calculate a document ID based on the unique identifiers of that document. Right now we don't specify the ID so when metricbeat/agent restarts, two documents will be sent to ES with diff ID but same metrics. |
Hi! We just realized that we haven't looked into this issue in a while. We're sorry! We're labeling this issue as |
Currently there is no way to distinguish between some documents from AWS Usage. If we enable TSDB with the dimensions set as of now, they will not be enough and we will end up losing data. However, there are no keyword fields available to differentiate between the these set of documents. Example:
Document 1
Document 2
This issue might be hard to reproduce. When testing, I got the output:
Out of 40000 documents from the index .ds-metrics-aws.usage-default-2023.06.29-000001, 429 of them were discarded.
, which means that this is happening with just 1% of the documents.The text was updated successfully, but these errors were encountered: