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

1 year uptime badge #714

Open
vasili439 opened this issue Mar 23, 2024 · 4 comments
Open

1 year uptime badge #714

vasili439 opened this issue Mar 23, 2024 · 4 comments

Comments

@vasili439
Copy link

Describe the feature request

It's nice to have 1 year uptime badge with 6-7 nines accuracy

Why do you personally want this feature to be implemented?

Reports for CTO and other managers

How long have you been using this project?

2+ years

Additional information

No response

@TwiN
Copy link
Owner

TwiN commented Mar 23, 2024

It's not that I'm against the idea, but with the way uptime retention is currently implemented, this would imply having to store 8760 rows per endpoint instead of 240.

For 50 endpoints, that'd be a total of 438k rows, which I don't think is acceptable, so persistence for uptime would have to be redesigned.

@vasili439
Copy link
Author

is it just matter of DB and PV size? May it could be implemented as an option?

@TwiN
Copy link
Owner

TwiN commented Mar 23, 2024

It's also a matter of performance.

There are some users configuring a single Gatus instance with as much as 3500 endpoints - that'd amount to 3500 x 24 x 365 = 30,660,000 rows with the current implementation, which would be insanely slow for DBs. Not that I think Gatus should be used with 3500 endpoints configured, but even as little as 20 endpoints is 175k rows.

The way it works right now is that there is one row for each hour, and each row has endpoint_id, hour_unix_timestamp, total_executions, successful_executions and total_response_time.

This was acceptable for persistence of 1h, 24h and 7d, but anything further than that would require a more efficient design.

@vasili439
Copy link
Author

may be DB rows could be aggregated after 1 month of detailed stat?

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

2 participants