Comments (6)
This has been on my list as well.
I've also entertained the idea of having another in-memory map that stored the last N outages for each services and dynamically generated a timeline instead of trying to persist the entire history, i.e.
Service A Outages
- From YYYY-MM-DD hh:mm:ss to YYYY-MM-DD hh:mm:ss
Though this wouldn't survive application restarts.
But yeah, thanks for opening this issue.
from gatus.
Just a side note: Having a separate persistence layer (not in-memory) would be a step towards running Gatus in a high-availability setup to ensure monitoring works even when a host is down. In this case the state of performed requests of all instances would be shared and the dashboard could show them all.
Syncing execution of requests and sending of alerts would still be an open topic though 🙃
from gatus.
As discussed in #66 (comment), the first step towards this will be introducing file-based persistence.
Later, other storage means can be introduced if required (e.g databases).
from gatus.
I am taking a look at this with @cjheppell this afternoon
from gatus.
Posting part of the comment I posted in #69 here for traceability:
I've been working on persistence, and I've tried and compared several different options:
- memory-only (current implementation)
- file-only (with bolt)
- gocache (memory + file, but persistence is achieved through autosave)
The file-only option was pretty terrible in term of performance, granted it may have been because the implementation itself was a little lazy.
memory-only was used more as a baseline to compare performance, but since the purpose was to achieve performance, it's a no-go.
Finally, gocache gave such good results. It's essentially on-par with memory while providing the persistence required, but well, that's why I suggested using it in the first place.
To continue on that comment, the implementation I went for does not persist the data immediately. It dumps the data to a file every 7 minutes. I had initially tried to implement it through bolt only, but I was very unsatisfied with the performance of using file-only, so I decided to use a hybrid: in memory + occasional persistence.
I've renamed this issue to focus purely on persisting data to survive restarts, thus allowing the data generated by Gatus to survive restarts which in turns makes services with longer interval more viable than before.
The ability to view older history is definitely also on my agenda, but since the former is more important right now, I decided to focus only developing that feature.
The ability to go back in history will be added in the future, but I don't have a specific date yet.
P.S. For those of you who want the ability to view older history over a long period right now as opposed to just persistence, it's not ideal, but you can probably leverage the /metrics
endpoint and persist it through Prometheus. I didn't give an insane amount of love to the metrics, but if it's requested enough, I can work on improving the metrics exposed (unless somebody else wants to do it in my stead 🤷♂️)
from gatus.
Released in v2.1.0
from gatus.
Related Issues (20)
- Provide Backend Error messages via Gatus frontend
- x509: certificate signed by unknown authority HOT 2
- Ping not working in neither docker nor k3s HOT 4
- Details page is empty when CJK chars is used in endpoint name HOT 2
- Badges for groups
- Domain expiration not updating HOT 4
- Expose Raw Uptime Data via the API
- Please add additional Endpoint
- Nginx service health check
- Monitor Unix domain sockets
- Ability to send http headers
- Allow setting a priority on resolved Pushover notifications HOT 4
- Default alert settings not used for external endpoint HOT 3
- [Question] How monitoring docker container? HOT 1
- Case change in config file not effective
- Add support for DNS over TLS and DNS over HTTPS HOT 1
- A delay in sending email alerts blocks endpoint healthchecks from being run
- Add condition result to pushover alerts
- Alert send to Zulip
- MQTT Monitoring HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gatus.