Skip to content
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

Duration graph legend shows inaccurate value when duration is greater than 1 second #1215

Open
jvv-trackunit opened this issue Jul 11, 2024 · 0 comments

Comments

@jvv-trackunit
Copy link

Hi devs.

Cool project! I ran into an issue.

I have defined the following SLO

apiVersion: pyrra.dev/v1alpha1
kind: ServiceLevelObjective
metadata:
  labels:
    prometheus: k8s
    pyrra.dev/application: my-api
    role: alert-rules
  name: my-api-latency-95
  namespace: default
spec:
  alerting:
    absent: false
    burnrates: true
  description: my-api API response latency over time grouped by route.
  indicator:
    latency:
      grouping:
      - uri
      success:
        metric: http_server_requests_seconds_bucket{error="none",job="my-api",le="1.0"}
      total:
        metric: http_server_requests_seconds_count{error="none",job="my-api"}
  target: "95"
  window: 2w
status:
  type: PrometheusRule

At some point my service was slower than the p95 SLO allowed. I checked the duration in the Pyrra UI.
When looking at the graph, the p95 is a lot higher than the target. When hovering over the values, the legend shows that the target was 1s and that p95 is also 1s.

image

It looks like the legend is applying some sort of rounding to the p95 value that makes it seem equal to the target. Can the graph show a more accurate p95 value? I want to know the p95 latency, but using the graph, I can't see whether it is 1.4, 1.6 or 1.8 seconds.

Versions used

Pyrra image ghcr.io/pyrra-dev/pyrra:v0.7.7
Firefox 128.0
MacOS 14.5

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant