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

Better latency, error analysis navigation/overview #735

Open
tarasglek opened this issue Apr 2, 2024 · 5 comments
Open

Better latency, error analysis navigation/overview #735

tarasglek opened this issue Apr 2, 2024 · 5 comments
Assignees

Comments

@tarasglek
Copy link

Description

I signed up for openstatus primarily for cool analytics capabilities per recent blog posts. Would love some improvements in this area.

  1. I find it impossible to go from seeing red to finding response logs for red/failed responses.
image

I think it would be intuitive to be able to click on failing indicators on main any dash that shows red and have those go to response view filtered specifically for failures.

  1. Likewise, it would be helpful to filter by p99, etc. Would love to see logs just for the fast/slow responses.

  2. It would be helpful to adjust timeframe on /monitors page for 1 day, 7 days, month, etc.

  3. Would be handy to download the database to do my own analytics

@mxkaske
Copy link
Member

mxkaske commented Apr 2, 2024

Hey @tarasglek, thanks a lot for the request!

A few thoughts before we start working on it (and we will!):

  1. We will add a value filter value within the Response Logs to be able to filter by 'failed request' (true/false). That will provide an easy way to find the failed once. We are not using search params yet for the filters within a /monitor/[id]/data page but that might be the right time for doing it. That way, you can click on the failed requests and get forwarded to the correct filter option.
  2. How do you want to filter by P99 exactly? The Response Logs are the 'raw' requests and so no aggregation has been done on it. Would you like to only see the requests that are faster/slower than a specific threshold (or latency)? That's a more global approach where you define the max/min latency of your filter option.
  3. You can adjust the timeframe on your monitor page (select option on top of the uptime card). That filter might not be obvious at all. It goes until 14d, but we'll provide more options. To avoid overloading the graph, we might restrict the 'Interval' to 1d for a month and higher. That's on the todo now!
  4. Yes! We can provide you with a download button for the last X days. Is a csv file good?

Thanks for your time and making OpenStatus a better monitoring tool! ❤️

@tarasglek
Copy link
Author

tarasglek commented Apr 4, 2024

  1. That's exactly what I want
  2. Will check it out
  3. Would prefer api access, eg if it could be exposed along with public status page that would be fine. This way you can skip auth. csv download would work for now

@thibaultleouay
Copy link
Member

Hey @tarasglek

for 4 do you want a Prometheus endpoint?

@mxkaske
Copy link
Member

mxkaske commented Apr 4, 2024

I fully agree on (4): an API endpoint would be easier as you can access and process the data immediately, and always have up to date data.

@tarasglek
Copy link
Author

tarasglek commented Apr 5, 2024

@thibaultleouay i think both have usecases. For analytics a csv endpoint would be nice that i can plug into duckdb or something. For alerting and integrating into own infra prom endpoint would be better.

Actually do you mean endpoint that provides metrics or endpoint that I can query? I think both are useful :)

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

3 participants