-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
Allow timestamping gnmi notifications locally #8420
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please also add a description of the newly added option to the README.md
file and to the sampleConfig
variable.
No worries. Looks quite good already. :-) |
ok, I updated the docs, I'll let you know when I have an update on the CCLA. That will probably be next week. |
Code looks good. Waiting for the administrative requirements... :-) |
Sometimes it can be useful to use a local, on receive timestamp for gnmi notifications. This is the case for sample subscriptions. The gnmi spec requires that the update timestamps are the time when the value from the underlying data source (e.g. counter hardware) changed. This value might not change for a long time, resulting in a timestamp way back in the past. For such situations, it can be useful to use the current time on the server, turning the semantics of the timestamp into "This was the value on the device at time T according to the collector" from "This was when the value last changed on the device." Fixes influxdata#8411
the CCLA from Arista and my personal CCL are now all submitted, I gave the changes a rebase + conflict resolution just now to the latest telegraph master |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
gentle bump? |
I'm wondering if this should just be a processor plugin. This comes up many times across a lot of different plugins. |
@rski you've not been forgotten. :-) The guys are about to release 1.17 and PRs merges are held back until the release is done AFAIK. |
@srebhan hello, several of us are looking forward for this merge :-) |
If anyone is looking for this feature on gnmi specifically, pleas use the builds from above. I would like to close this for now. If anyone would like to work on #8689 for local timestamping to be used across plugins more generally we would gladly welcome a PR. |
Sometimes it can be useful to use a local, on receive timestamp for
gnmi notifications. This is the case for sample subscriptions. The
gnmi spec requires that the update timestamps are the time when the
value from the underlying data source (e.g. counter hardware) changed.
This value might not change for a long time, resulting in a timestamp
way back in the past. For such situations, it can be useful to use the
current time on the server, turning the semantics of the timestamp
into "This was the value on the device at time T according to the
collector" from "This was when the value last changed on the device."
Fixes #8411
Required for all PRs: