Metrics collection
Prometheus with the right exporters, such as node_exporter, mysqld_exporter and cAdvisor, or kube-prometheus-stack on Kubernetes.
DevOps
Monitoring and centralized logging with Grafana, Prometheus and ELK
When a service slows down, you need to see quickly whether the cause is the database, the network or the last release. We set up Grafana and Prometheus, bring your logs into one place, and give you that view across servers, containers and applications.
Tools & technology
observability
- Prometheus
- Grafana
- Alertmanager
- Grafana Loki
- Elasticsearch
- Kibana
- Logstash
- OpenTelemetry
- node_exporter
5work areas
4deliverables
4steps
What is Observability & Logging?
Grafana and Prometheus setup is the work of collecting metrics from servers, containers and applications, showing them on dashboards and alerting on real problems, usually alongside centralized logging with ELK or Grafana Loki. It helps teams that SSH into several servers and grep logs to find an error, lose logs after a few days, or hear about a slow site from users first. PikoSystem installs Prometheus with exporters such as node_exporter and cAdvisor, builds Grafana dashboards for server resources, databases, latency and error rate, collects logs with Loki and Promtail or Elasticsearch, Logstash and Kibana, and writes Alertmanager rules for symptoms like filling disks or rising 5xx errors. Noisy alerts are removed during an agreed tuning period. You receive dashboards stored in Git, an alert list with the action for each and documented log retention.
When you need Observability & Logging
- To find an error we SSH into several servers and grep through logs.
- We run Prometheus, but there are so many alerts that nobody reads them.
- Users notice the site is slow before we do.
- Logs are gone after a few days, so there's nothing left to investigate after an incident.
What Observability & Logging includes
Grafana dashboards
Dashboards for server resources, databases and application metrics like latency and error rate, with separate access per team.
Centralized logging
Log collection with Grafana Loki and Promtail, or Elasticsearch, Logstash and Kibana, with retention policies sized to your storage.
Alerting rules
Alertmanager rules based on real symptoms such as disks filling up, rising 5xx errors or slow responses, routed to email, SMS or your team chat.
Distributed tracing
Where it helps, OpenTelemetry with Tempo or Jaeger to follow a single request across services.
What you get from Observability & Logging
- Grafana dashboards, exported and stored in Git
- A list of alert rules with the expected action for each
- A centralized logging stack with a documented retention policy
- A guide for adding new servers or services to monitoring
Observability & Logging: a practical guide
Grafana Loki with Promtail or Grafana Alloy?
Most Grafana Loki tutorials still ship logs with Promtail, but Grafana has deprecated Promtail and named Grafana Alloy as its replacement. Alloy collects logs and can also forward metrics and traces, so we use it on new installs and migrate existing Promtail agents on a schedule.
Labels matter more than the agent. Loki indexes logs by label, and putting high-variety values such as user IDs, client IPs or request IDs into labels multiplies the number of streams and slows Loki down. Those values belong in the log line, filtered at query time with LogQL.
Is Grafana Loki on Docker Compose enough to start?
For low to moderate log volume, Loki in monolithic mode, with every component in one process, runs well next to Grafana and Prometheus in a single Docker Compose file. Two conditions apply: data must sit on a persistent volume, and retention has to be enabled in the compactor. Otherwise logs are never deleted and the disk fills.
Once daily volume grows or you need high availability, we move Loki to S3-compatible object storage such as MinIO and run it distributed on Kubernetes. The data model is the same in both modes, so starting with Compose doesn't box you in.
Monitoring dashboard and alerting mistakes
Alerting on causes instead of symptoms is the most common one. CPU at 90 percent isn't a problem by itself; rising latency or a climbing 5xx rate is. Rules without a for clause fire on every brief spike and train the team to ignore alerts.
In Prometheus, high-cardinality labels eat memory fast, and the default 15-day retention is too short for month-over-month comparisons. Dashboards imported from grafana.com and never tuned tend to carry dozens of irrelevant panels. Finally, a monitoring server on the host it watches goes down with it; an always-firing Watchdog alert that raises the alarm when it stops arriving covers that gap.
What drives the resources for ELK and monitoring?
Daily log volume and retention period decide disk size. Elasticsearch also wants plenty of memory: heap is usually set to about half of system RAM and kept below roughly 31 GB, with the rest left for filesystem cache. That is why ELK needs more hardware than Loki for the same log volume.
On the metrics side, the number of active time series is what counts, driven by servers, exporters and labels. Other factors include high availability for the monitoring stack itself, tracing with OpenTelemetry, and how many teams need separate access and dashboards.
How Observability & Logging works
-
01
Understand your services
We identify which services matter most to the business and which numbers define healthy for each.
-
02
Install and collect
We install Prometheus, exporters and the logging stack, and start collecting data from servers and containers.
-
03
Dashboards and alerts
We build the dashboards and alert rules and tune thresholds against real data.
-
04
Tune and hand over
Over an agreed period we follow the alerts with your team, remove the noisy ones and deliver the documentation.
Observability & Logging: frequently asked questions
How is this different from Zabbix monitoring?
Zabbix is a good fit for availability monitoring of servers and network devices, and we offer it under our support contracts. This service is for teams that want application metrics, containers and logs side by side. Many organisations run both.
Should we use ELK or Loki?
ELK is strong for full-text search across logs but needs more memory and disk. Grafana Loki is lighter and sits right next to your Grafana dashboards. We recommend one based on your daily log volume and how you search.
How long are logs kept?
We agree the retention period with you and size storage accordingly. Security logs are usually kept longer and on separate storage, so they are available when investigating an incident.
Related searches
- Grafana monitoring
- Prometheus
- ELK stack setup
- centralized log management
- Grafana Loki
- monitoring dashboard
- Elasticsearch
Related services
Quote
Tell us what you need, we'll come back with a plan and a price
A few lines on where things stand and what you want is enough. An engineer calls you back, not a sales rep.
- 01We read your request and call if anything is unclear.
- 02If needed, we do a quick remote review or a site visit.
- 03You get a written proposal with scope, timeline and cost.