[checkpoint] Change fingerprint creation - #16918
Conversation
The fields originally chosen for fingerprinting do not create a unique fingerprint. The new fields create a more unique fingerprint.
just reordering for possible better reading
Updated PR number
|
Hi! We just realized that we haven't looked into this PR in a while. We're sorry! We're labeling this issue as |
|
Pinging @elastic/integration-experience (Team:Integration-Experience) |
|
Hey @efd6, @gogochan — this PR changes the checkpoint fingerprint fields used for document @efd6 — you built the original fingerprint logic in #6483 to handle loguid collisions. Would you mind weighing in on whether dropping @gogochan — you added 🤖 Generated by Claude Code/Opus 4.6 |
|
@ilyannn The change will not reintroduce the issue I fixed. However The description text in the changelog could be improved. Suggest something like "Fix document fingerprint to prevent rejection of Check Point update events. Previously, fingerprints lacked fields that would distinguish update events from their originals." The integration should probably add a latest transform as well, but that is future work. |
|
HI @efd6 , as I have used the described fingerprint forsome time and have not observed drops, do you remember why segment_time is important? It's perfectly possible that your combination is only observed in certain circumstances, we all only see what the installations before us produce after all. You mentiond an issue, do you have a link? P.S. I don't mean to haggle over this, I am just genuinely curious, especially if you have any documentation I could use to develop my understanding further. |
|
@ash-darin Thank you for your work. Can you please resolve the conflicts? I'm running the checks in the meanwhile. |
@ilyannn I have corrected the conflicts. Didn't notice them, probably a problem with my notifications. |
|
/test |
🚀 Benchmarks reportPackage
|
| Data stream | Previous EPS | New EPS | Diff (%) | Result |
|---|---|---|---|---|
firewall |
1182.03 | 938.09 | -243.94 (-20.64%) | 💔 |
To see the full report comment with /test benchmark fullreport
|
/test |
|
/test |
💚 Build Succeeded
History
|
|
Package checkpoint - 1.46.0 containing this change is available at https://epr.elastic.co/package/checkpoint/1.46.0/ |
The fields originally chosen for fingerprinting do not create a unique fingerprint. The new fields create a more unique fingerprint. --------- Co-authored-by: Ilya Nikokoshev <ilya.nikokoshev@elastic.co>
The fields originally chosen for fingerprinting do not create a unique fingerprint. The new fields create a more unique fingerprint. --------- Co-authored-by: Ilya Nikokoshev <ilya.nikokoshev@elastic.co>
Enhancement
Proposed commit message
This changes the fields used to create a unique fingerprint for the event. The currently selected fields are lacking in achieving this as rejects have been observed. Checkpoint apparently often generate events that are "updates" to previous events. These events have the timestamp of the original event but incorporate a "lastupdatetime" timestamp and an update_count. Fingerprint creation therefore creates duplicates.
Checklist
changelog.ymlfile.How to test this PR locally
Check your logs/indices if any messages are rejected. Apply fix and check whether numbers go down..