Monitoring and alerting: know what is happening on your servers
A service that stops at night is often noticed only when the first customer calls. Sortia Labs sets up monitoring that checks servers, applications, databases and backups, shows measurements over time and alerts the right people when something is really wrong. The goal: little noise and clear hints on what to do.
- Server monitoring
- Prometheus and Grafana
- Uptime monitoring
- Alerting
- Logs with Loki
- Observability
- ServicesWebsites, APIs, databases
- ChecksAt regular intervals
- AlertE-mail with a link
- IncidentsWho, what, how long
- ReportTrends over weeks
What we monitor and how
Checks from outside
Availability, response time and content of your websites and APIs, measured the way visitors experience them. Plus the validity of TLS certificates, with a warning in good time before they expire.
Metrics with Prometheus and Grafana
CPU, memory and disk usage, requests, error rates and response times in clear dashboards. Trends over several weeks show when a server is reaching its limits.
Central logs with Loki
The logs of all services end up in one place and can be searched by time, service and error. During an incident you can quickly trace what happened just before.
Alerts with a sense of proportion
Not every failed check is an emergency. We set thresholds and repetitions so that an alert has a real reason, and send it by e-mail or through the channel your team already uses.
Databases and backups in view
Replication, slow queries, connections and disk space of the databases, plus the age of the latest backup. A backup that has been failing for days should stand out before anyone needs it.
Incident list and follow-up
Every confirmed incident is listed with start, end and timeline. You see which problems recur and can fix the cause instead of only the symptom.
How your monitoring comes together
- 1
What is critical?
We clarify with you which services are business-critical, who should be informed about an incident and at what times. Checks and alert routes follow from that.
- 2
Setup
Exporters, checks, dashboards and alert rules are created as code in the repository. New servers and services can then be added to monitoring without manual work.
- 3
Fine-tuning
In the first weeks we review every alert: was it justified, did it arrive in time, was it clear what to do? Unnecessary alerts go, missing ones are added.
- 4
Operations
We respond to alerts within an agreed scope or hand monitoring over to your team, with runbooks for typical incidents and a short briefing.
Software we build and run ourselves.
Questions about Monitoring
Which tools do you use for monitoring?
Usually Prometheus for metrics, Grafana for dashboards, Loki for logs, plus checks from outside. These tools are open source and run on your servers or in your cloud. We integrate existing solutions instead of replacing them without good reason.
Who responds when an alert comes in at night?
We agree that together: either your team with clear runbooks, or us within an agreed scope. What matters is that at night only alerts arrive that cannot wait until morning. Everything else appears as a warning in the report.
How do we avoid too many false alarms?
With thresholds that match normal load, repetitions before an alert fires and a clear line between warning and incident. After the first weeks we look together at which alerts were useful and adjust the rules.
How does monitoring differ from observability?
Monitoring checks known values: is the service reachable, is the disk filling up? Observability connects metrics, logs and traces so that even unexpected errors can be traced to their cause. For mid-sized companies, solid monitoring is usually the sensible first step.
Read on.
Do you know when your services last had a problem?
If that is hard to answer, monitoring is a good next step. Tell us which systems you run, and we will suggest what should be monitored first.