Server monitoring with Grafana: setting up logs, metrics, and alerts

Your server is running, your application is live, and everything seems fine. Until the moment a customer calls you because the site has been down for twenty minutes—and you are the last to know. Does that sound familiar? Then it is time to take server monitoring seriously. With the right tools, you can see problems coming before they grow into incidents, and you will know exactly what is happening on your infrastructure.

In this article, we dive into a practical monitoring stack with Grafana as the heart of your dashboards and alerting, complemented by the right log aggregation and real-time metrics. Whether you manage a single VPS or run a cluster of dozens of servers—the principles are the same.

Why server monitoring is not optional

Many developers and system administrators monitor reactively: only when something breaks do they start looking. That is understandable when you are busy, but it is also unnecessarily expensive. Downtime costs money, reputation, and nerves. Good server monitoring revolves around three pillars:

• Metrics: numerical data about CPU, memory, disk usage, network, and application performance
• Logs: textual events from your system, application, and services
• Alerts: automatic notifications when something falls outside expected parameters

Without metrics, you do not know how healthy your server is. Without logs, you do not know why something went wrong. Without alerts, you do not know when it went wrong. The three work together, and Grafana is the platform that merges them into a coherent whole.

The monitoring stack: Grafana, Prometheus, and Loki

Grafana is by itself a visualization tool and alerting platform—it needs a data source. The most common combination for server monitoring looks like this:

• Prometheus — scrapes metrics from your servers and applications and stores them as time series
• Node Exporter — runs on each server and exports system metrics to Prometheus
• Loki — log aggregation system from Grafana Labs, optimized for use with Grafana
• Promtail — collects logs from your system and sends them to Loki
• Grafana — visualizes everything and sends alerts

This stack is fully open source, lightweight, and well documented. You can run it via Docker Compose, which significantly simplifies installation.

Quick installation with Docker Compose

Create a file named docker-compose.yml with the following basic structure:

version: '3.8'
services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    ports:
      - "9090:9090"
  node-exporter:
    image: prom/node-exporter:latest
    ports:
      - "9100:9100"
  loki:
    image: grafana/loki:latest
    ports:
      - "3100:3100"
  promtail:
    image: grafana/promtail:latest
    volumes:
      - /var/log:/var/log
      - ./promtail-config.yml:/etc/promtail/config.yml
  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=yourpassword

Start the stack with docker compose up -d and open Grafana on port 3000. Add Prometheus and Loki as data sources via Configuration → Data Sources, and you are ready to build your first dashboard.

Visualizing metrics in Grafana

Once the stack is running, it is time for the fun part: building dashboards. Grafana has an extensive library of ready-made dashboards on grafana.com/grafana/dashboards. For Node Exporter, dashboard ID 1860 is the standard—import it with one click and you immediately get insight into CPU usage, load average, memory, disk I/O, and network traffic.

If you want to add your own panels, you write a PromQL query. A few useful examples:

• CPU usage in percent: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
• Free memory: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100
• Disk usage: (node_filesystem_size_bytes - node_filesystem_free_bytes) / node_filesystem_size_bytes * 100

PromQL is powerful but has a learning curve. Start simple, use the autocomplete in the Grafana query editor, and build from there.

Alternative: Netdata for real-time monitoring

If you want something working immediately without setting up the full stack, then Netdata is an excellent alternative. Netdata installs with one command:

bash <(curl -Ss https://my-netdata.io/kickstart.sh)

You immediately get a rich dashboard with thousands of metrics, automatic anomaly detection, and built-in alerts. Netdata is ideal for quick insights or as a supplement to your Grafana stack. It can also serve as a data source for Grafana via the Netdata Cloud integration.

Collecting and making logs searchable

Metrics tell you that something is wrong. Logs tell you what and why. A good server monitoring setup without log aggregation is like a car without a rearview mirror: you only see what is in front of you.

With Loki and Promtail, you collect logs from /var/log/syslog, your Nginx or Apache access logs, application logs, and system services. Promtail automatically labels the logs based on the source location, so you can filter them in Grafana by server, service, or log level.

In Grafana, you use LogQL to search logs. Examples:

• All Nginx errors: {job="nginx"} |= "error"
• SSH login attempts: {job="syslog"} |= "Failed password"
• Logs from the last five minutes with a specific string: {job="app"} |~ "timeout" [5m]

Link a log panel to your metrics dashboard so that during a CPU spike you immediately see the corresponding application logs. That's where Grafana's real power comes into play: correlation between metrics and logs in one interface.

Setting up alerts: notifications before it's too late

The most underestimated feature of server monitoring is a well-configured alerting system. Grafana has a built-in alerting engine that evaluates queries on a schedule and sends notifications when deviations occur.

Set up alerts via Alerting → Alert Rules. A typical rule looks like this:

• Condition: CPU usage higher than 85% for 5 minutes
• Pending period: 2 minutes (prevents false alerts during short spikes)
• Notification channel: Slack, email, PagerDuty, or webhook

Configure notification channels via Alerting → Contact Points. Grafana supports dozens of integrations. For a Dutch hosting environment, Slack or email is often sufficient; larger teams choose PagerDuty or OpsGenie for on-call rotations.

Practical alert thresholds for servers

Use these threshold values as a starting point and adjust them to your workload:

• CPU: warning at >75%, critical at >90% for 5 minutes
• Memory: warning at >80%, critical at >95%
• Disk: warning at >75%, critical at >90%
• Load average: critical when sustained load exceeds 2× the number of CPU cores
• Service down: immediately critical — use a blackbox exporter or uptime check

Avoid alert fatigue: if you set too many alerts that trigger too quickly, you'll start ignoring them. Start conservatively and tighten the thresholds based on your baseline data after a week or two.

Practical tips for a solid monitoring setup

Finally, a number of concrete recommendations from practice:

• Monitor the monitoring itself. Set an alert if Prometheus or Grafana becomes unreachable. A monitoring system that stays silent during an outage is worthless.
• Use a retention policy for metrics. Prometheus stores 15 days of data by default. Consider longer retention with Thanos or Cortex for trend analysis.
• Don't lock your dashboards away from the team. Make Grafana accessible to developers — visibility into production increases the quality of releases.
• Document your alerts. Add a runbook link to each alert rule. Then the on-call administrator knows exactly what to do at three in the morning.
• Test your alerts periodically. An alert that never fires may be broken. Deliberately simulate a situation that should trigger the alert.

Conclusion

Server monitoring with Grafana, Prometheus, Loki, and Node Exporter gives you full observability over your infrastructure: from real-time system metrics to searchable logs and proactive alerts. The stack is open source, scalable, and well integrated.

Start small: install the stack on one server, import an existing dashboard, and set up three alerts. Build from there. The investment of an afternoon of setup work pays off in the form of nights you actually sleep through — because you know Grafana will wake you when necessary.

The key is not the perfect stack, but a working stack that you actually use and maintain.