mixin: Use sidecar's metric timestamp for healthcheck #3204
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hwoarang
force-pushed
the
add-2m-delay-sidecar
branch
2 times, most recently
from
8f7b458
to
e097018
Compare
kakkoyun
reviewed
Sep 22, 2020
hwoarang
force-pushed
the
add-2m-delay-sidecar
branch
from
e097018
to
47cb8d8
Compare
hwoarang
changed the title
hwoarang
force-pushed
the
add-2m-delay-sidecar
branch
from
47cb8d8
to
50f8f99
Compare
|
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
hwoarang
force-pushed
the
add-2m-delay-sidecar
branch
from
50f8f99
to
88b2e6e
Compare
|
Update PR to match latest master branch @kakkoyun any thoughts here? |
|
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
hwoarang
force-pushed
the
add-2m-delay-sidecar
branch
from
88b2e6e
to
7313f0a
Compare
|
@hwoarang This looks good to me in principle, however, you need to generate docs and make sure this fulfils the expected behaviour with tests. CI already points out where it falls short. You can find all necessary task as Make actions. |
kakkoyun
requested changes
Feb 1, 2021
hwoarang
force-pushed
the
add-2m-delay-sidecar
branch
3 times, most recently
from
7dba321
to
4568191
Compare
@kakkoyun thank you for your input and apologies for taking a while to address your concerns. Tests are passing now as I had to refactor tests a little bit as we are now effectively testing for a different kind of alert. Please let me know your thoughts. Thank you |
|
The only tests that seems to fail in circle CI is |
|
Hey @hwoarang, enabled the auto-merge and approved. Please fix the conflicts for the Changelog. |
kakkoyun
approved these changes
Mar 1, 2021
hwoarang
force-pushed
the
add-2m-delay-sidecar
branch
from
4568191
to
b4bf820
Compare
During prometheus updates the alert was firing because the metric was initialized with a value of '0' before the first heartbeat was sent. As such, the evaluation of the alert results into actually taking just the value of time() into consideration which led to misleading information about the health of the sidecar. As the thanos_sidecar_last_heartbeat_success_time_seconds metric is effectively just a timestamp that resets on new deployments, we can simply wrap it around the timestamp() function which should return almost the same value of the metric itself with the added benefit that heartbeat resets will be ignored. This also refactors the relevant tests and drops the timeout to 4 minutes in order to ensure that we do not get hit by stale data if the sidecar takes longer to start. Signed-off-by: Markos Chandras <markos@chandras.me>
hwoarang
force-pushed
the
add-2m-delay-sidecar
branch
from
b4bf820
to
95b2fe9
Compare
|
@hwoarang This PR has introduced regressions around the pod to instance label renamings. It's my bad to mark as auto-merge. I didn't anticipate this. I'll send a consecutive PR to fix the issues. |
|
@kakkoyun really sorry that I missed that locally. I assumed the green CI was a good indication :) |
andrejbranch
pushed a commit
to andrejbranch/thanos
that referenced
this pull request
Mar 11, 2021
During prometheus updates the alert was firing because the metric was initialized with a value of '0' before the first heartbeat was sent. As such, the evaluation of the alert results into actually taking just the value of time() into consideration which led to misleading information about the health of the sidecar. As the thanos_sidecar_last_heartbeat_success_time_seconds metric is effectively just a timestamp that resets on new deployments, we can simply wrap it around the timestamp() function which should return almost the same value of the metric itself with the added benefit that heartbeat resets will be ignored. This also refactors the relevant tests and drops the timeout to 4 minutes in order to ensure that we do not get hit by stale data if the sidecar takes longer to start. Signed-off-by: Markos Chandras <markos@chandras.me>
Merged
2 tasks
dgrisonnet
pushed a commit
to dgrisonnet/thanos
that referenced
this pull request
Mar 26, 2021
During prometheus updates the alert was firing because the metric was initialized with a value of '0' before the first heartbeat was sent. As such, the evaluation of the alert results into actually taking just the value of time() into consideration which led to misleading information about the health of the sidecar. As the thanos_sidecar_last_heartbeat_success_time_seconds metric is effectively just a timestamp that resets on new deployments, we can simply wrap it around the timestamp() function which should return almost the same value of the metric itself with the added benefit that heartbeat resets will be ignored. This also refactors the relevant tests and drops the timeout to 4 minutes in order to ensure that we do not get hit by stale data if the sidecar takes longer to start. Signed-off-by: Markos Chandras <markos@chandras.me>
dgrisonnet
pushed a commit
to dgrisonnet/thanos
that referenced
this pull request
Mar 26, 2021
During prometheus updates the alert was firing because the metric was initialized with a value of '0' before the first heartbeat was sent. As such, the evaluation of the alert results into actually taking just the value of time() into consideration which led to misleading information about the health of the sidecar. As the thanos_sidecar_last_heartbeat_success_time_seconds metric is effectively just a timestamp that resets on new deployments, we can simply wrap it around the timestamp() function which should return almost the same value of the metric itself with the added benefit that heartbeat resets will be ignored. This also refactors the relevant tests and drops the timeout to 4 minutes in order to ensure that we do not get hit by stale data if the sidecar takes longer to start. Signed-off-by: Markos Chandras <markos@chandras.me>
2 tasks
dgrisonnet
pushed a commit
to dgrisonnet/thanos
that referenced
this pull request
Mar 26, 2021
During prometheus updates the alert was firing because the metric was initialized with a value of '0' before the first heartbeat was sent. As such, the evaluation of the alert results into actually taking just the value of time() into consideration which led to misleading information about the health of the sidecar. As the thanos_sidecar_last_heartbeat_success_time_seconds metric is effectively just a timestamp that resets on new deployments, we can simply wrap it around the timestamp() function which should return almost the same value of the metric itself with the added benefit that heartbeat resets will be ignored. This also refactors the relevant tests and drops the timeout to 4 minutes in order to ensure that we do not get hit by stale data if the sidecar takes longer to start. Signed-off-by: Markos Chandras <markos@chandras.me> Signed-off-by: Damien Grisonnet <dgrisonn@redhat.com>
kakkoyun
pushed a commit
that referenced
this pull request
Mar 26, 2021
During prometheus updates the alert was firing because the metric was initialized with a value of '0' before the first heartbeat was sent. As such, the evaluation of the alert results into actually taking just the value of time() into consideration which led to misleading information about the health of the sidecar. As the thanos_sidecar_last_heartbeat_success_time_seconds metric is effectively just a timestamp that resets on new deployments, we can simply wrap it around the timestamp() function which should return almost the same value of the metric itself with the added benefit that heartbeat resets will be ignored. This also refactors the relevant tests and drops the timeout to 4 minutes in order to ensure that we do not get hit by stale data if the sidecar takes longer to start. Signed-off-by: Markos Chandras <markos@chandras.me> Signed-off-by: Damien Grisonnet <dgrisonn@redhat.com> Co-authored-by: Markos Chandras <hwoarang@users.noreply.github.com>
onprem
pushed a commit
that referenced
this pull request
Jun 23, 2021
…er healthy (#4342) * Revert "mixin: Use sidecar's metric timestamp for healthcheck (#3204) (#3979)" This reverts commit 5139e33. Signed-off-by: Arunprasad Rajkumar <arajkuma@redhat.com> * fix(mixin): ThanosSidecarUnhealthy doesn't fire if the sidecar is never healthy Signed-off-by: Arunprasad Rajkumar <arajkuma@redhat.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
During prometheus updates the alert was firing because the metric was
initialized with a value of '0' before the first heartbeat was sent. As
such, the evaluation of the alert results into actually taking just the
value of time() into consideration which led to misleading information
about the health of the sidecar.
As the thanos_sidecar_last_heartbeat_success_time_seconds metric is
effectively just a timestamp that resets on new deployments, we can
simply wrap it around the timestamp() function which should return
almost the same value of the metric itself with the added benefit that
heartbeat resets will be ignored.
Signed-off-by: Markos Chandras markos@chandras.me
Changes
Verification