On 2021-03-22 11:47, Harkishen Singh wrote:
Thank you everyone for the suggestions!
I agree with the age-based solutions, but such a solution is useful to
particularly those systems that have a limitation on time. Many don't
have that. But seeing the scenario, can we have both, so if users have
a remote-storage system that respects time, then they can use the
time-based dropping logic. If the user has a remote-storage that can
accept a sample with any timestamp (past or future), he can use the
retries count method. This will avoid recurring errors, like the null
byte.
We can have something like LIMITRETRYPOLICY as TIME or RETRIES. If its
TIME, we choose the max time (taken as input). If the policy is
RETRIES, then a count would be the input for the maximum retries. That
way, we solve both the problems and leave it up to the user to
consider it, based on the storage system he is using.
Does that look good to go, or we do just the age-based way?
The time based isn't just about handling remote write receivers than can
only ingest samples up to a certain age, but also to encapsulate policy
about what still matters.
Even if my receiver can ingest metrics from any time it is quite
possible that I don't care about data older than a certain period. For
example I might be doing something ML related that can be used for
autoremediation, so I want all the data but after 30 minutes it becomes
irrelivant. So even though it might accept older data I can set the
limit to 30 mins so Prometheus just drops it instead of trying to resend
(possibly unblocking more recent data in the process).
--
Stuart Clark
--
You received this message because you are subscribed to the Google Groups
"Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/prometheus-developers/97a200f341be01d0200477f726d4eab7%40Jahingo.com.
