Quiet services and NaN about sloth HOT 8 CLOSED

Hi @simonjefford

You are right this is not a good outcome, however, is how prometheus works,NaN != Null != 0. What you can do to fix this situation, is only create metrics when you know that the metrics will be valid, this is when the total events are >0.

So, having this SLI:

    sli:
      events:
        error_query: sum(rate(http_request_duration_seconds_count{job="myservice",code=~"(5..|429)"}[{{.window}}]))
        total_query: sum(rate(http_request_duration_seconds_count{job="myservice"}[{{.window}}]))

Only get SLIs when we can have them:

    sli:
      events:
        error_query: sum(rate(http_request_duration_seconds_count{job="myservice",code=~"(5..|429)"}[{{.window}}]))
        total_query: sum(rate(http_request_duration_seconds_count{job="myservice"}[{{.window}}])) > 0

This way, the total SLI query will return Null (no metrics) when there are no total metric datapoints and there will not be NaNs that will corrupt the rules that are created from these SLI metrics.

To test this you could deploy a new SLO with this change along with your current SLO and check if its its working for you while you see both in action.

This is the simplest thing I think it would work, let me know if this works for your use case. If not we can think of a better query using raw SLI type (I did this in the past and worked, however is a bit more complex).

If it works with this simple change, I'm wondering if Sloth could do this by default or let the user do this and add to the F.A.Q, not strong opinion at this moment.

from sloth.

Thanks for the informations. I will give it a try.

I also found this interesting video from SLOconf which might solve some of the issues; not 100% sure if its related but I think it is. I wouldn't have a clue how to express it in PromQL. First feeling is it might need some recording rule
https://www.youtube.com/watch?v=R4nCsgt1qEU

from sloth.

Thanks @weyert!

The video is very interesting when the services have few metrics!

from sloth.

@simonjefford Any news on this one? AFAIK @weyert has tested this and seems that worked for Weyert's use case.

from sloth.

Apologies - I haven't had a chance to give this a go yet. Hoping to do so this afternoon. Thank you for your response!

from sloth.

Hey @slok,

Just throwing my two cents here - we had similar problem on low traffic endpoints and '>0' for total_query seems to resolve the issue.

from sloth.

Hi @mrtworo!

Thanks for the information! is very valuable!

Due to the inactivity of @simonjefford and your answer that seems to solve the problem I'll assume the problem is solved.

@simonjefford if you continue with the problem, please reopen the issue :)

Thanks to all of you that contributed to this issue!

from sloth.

from sloth.