Server monitoring: Grafana, logs and alerts — control over your infrastructure

Your server is running, your application works — and then it goes quiet. Until the moment a customer calls you because the site has been down for twenty minutes. Sound familiar? Server monitoring is the difference between reacting to problems and preventing them. In this article, you'll learn how to set up a solid monitoring stack with Grafana, how to manage logs effectively, and how to configure alerts that are actually useful — without your inbox drowning in false positives.

We focus on practical implementation. No theory for show, but concrete steps you can apply today to your VPS, dedicated server, or on-premises infrastructure.

Why server monitoring is not an option, but a requirement

A server without monitoring is like driving without a dashboard. You might drive fine, but you only see the fuel is empty when the engine stops. Server monitoring gives you insight into CPU usage, memory, disk space, network traffic, and application behavior — real-time and historical.

The most common problems that monitoring brings to light:

• Memory leaks that slowly but surely suffocate your server
• Disks filling up due to logs or backups that go nowhere
• CPU spikes from runaway processes or suddenly increased traffic
• Failed services that restart themselves without you noticing
• Network issues such as packet loss or latency that make applications slow

With good server monitoring, you tackle these problems before users are affected by them. That is the promise — and it is fully achievable with the right toolstack.

The monitoring stack: Prometheus, Grafana, and exporters

The de facto standard for open-source server monitoring combines Prometheus as the metrics collector with Grafana as the visualization layer. Prometheus scrapes metrics from your servers and applications via so-called exporters. Grafana turns that raw data into understandable dashboards and manages your alerting rules.

Step 1: Install Prometheus and Node Exporter

The node_exporter is your first point of contact for system metrics. Install it on every server you want to monitor:

wget https://github.com/prometheus/node_exporter/releases/download/v1.8.1/node_exporter-1.8.1.linux-amd64.tar.gz
tar xvfz node_exporter-1.8.1.linux-amd64.tar.gz
sudo mv node_exporter-1.8.1.linux-amd64/node_exporter /usr/local/bin/
sudo useradd -rs /bin/false node_exporter

Then create a systemd service so the exporter starts automatically:

[Unit]
Description=Node Exporter
After=network.target

[Service]
User=node_exporter
ExecStart=/usr/local/bin/node_exporter

[Install]
WantedBy=multi-user.target

After systemctl enable --now node_exporter, your system metrics are available on port 9100. Prometheus fetches them there according to the interval you configure — by default every 15 seconds.

Step 2: Install Grafana and connect it

The easiest way to install Grafana is via the official apt repository:

sudo apt-get install -y apt-transport-https software-properties-common
wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add -
echo "deb https://packages.grafana.com/oss/deb stable main" | sudo tee /etc/apt/sources.list.d/grafana.list
sudo apt-get update && sudo apt-get install grafana
sudo systemctl enable --now grafana-server

Grafana now runs on port 3000. Log in with admin/admin and change the password immediately. Add Prometheus as a data source via Configuration → Data Sources → Add data source, fill in the URL of your Prometheus instance, and click Save & Test.

For a complete starter set of dashboards, import dashboard ID 1860 — the Node Exporter Full dashboard. This gives you at a glance an overview of CPU, RAM, disk I/O, network, and more, fully formatted and ready for use.

Centralizing logs: from chaos to insight

Metrics tell you what is happening; logs tell you why. A good server monitoring strategy always includes both. The problem with logs is that they are scattered: /var/log/syslog, application logs, Nginx logs, Docker container logs — all in different places and different formats.

The solution is log aggregation. The most commonly used stack for this within the Grafana ecosystem is Loki combined with Promtail as the log shipper.

Setting up Loki and Promtail

Loki stores your logs in an optimized format that you can query directly from Grafana. Promtail reads your log files and sends them to Loki. A minimal Promtail configuration for Nginx logs looks like this:

scrape_configs:
  - job_name: nginx
    static_configs:
      - targets: [localhost]
        labels:
          job: nginx
          __path__: /var/log/nginx/*.log

Once active, add Loki as a second data source in Grafana. After that, you can run queries directly on your logs in the Explore screen using LogQL — the query language of Loki that closely resembles PromQL.

A practical query to find all Nginx 500 errors:

{job="nginx"} |= "HTTP/1.1\" 5"

Combine this with a Prometheus metric that tracks the number of requests, and you have both the quantitative picture (how many errors) and the qualitative picture (which requests fail and why) in a single dashboard.

Configuring alerts your team will actually take seriously

Server monitoring is only effective if you are warned in a timely manner. Grafana has a built-in alerting engine that lets you define rules based on both Prometheus metrics and Loki logs. The big danger with alerting is alert fatigue: too many notifications that mean too little, causing people to systematically ignore them—and then you miss the alert that truly matters.

Basic rules for effective alerts

• Alert on symptoms, not causes. "Website is not responding" is more relevant than "CPU is at 95%". CPU spikes can be legitimate; an unreachable site is always a problem.
• Use thresholds with margin. Set an alert for memory usage above 85% for at least 5 minutes, not for a brief spike to 90%.
• Distinguish severity levels. Use warning for situations that need attention and critical for situations that require immediate action. Send them through different channels—Slack for warnings, PagerDuty or SMS for critical.
• Actively test your alerts. An alert you have never seen fire probably does not work.

Creating a practical Grafana Alert Rule

In Grafana, go to Alerting → Alert Rules → New alert rule. Choose your Prometheus datasource and enter as the query:

(node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100 < 15

This triggers an alert when less than 15% disk space is available on the root partition. Set the evaluation interval to 1m and the pending period to 5m—this prevents a brief anomaly from immediately causing an alarm. Link a contact point to the rule, configure your Slack webhook or email address, and your first serious alert is live.

Additional tools: Netdata and Glances for real-time insight

In addition to the Prometheus/Grafana stack, two tools are worth mentioning for specific use cases.

Netdata offers real-time server monitoring with a surprisingly low installation footprint. With one command you have a full dashboard:

wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh && sh /tmp/netdata-kickstart.sh

Netdata is ideal for quick diagnostics and smaller environments. The downside is that historical data is limited by default—for long-term trends, Prometheus/Grafana remains the better choice.

Glances is a command-line tool that gives you a direct overview of all system resources in one screen. If you start it with glances -w, it runs as a web server and you can also access it via the browser. Ideal for situations where you want to check something quickly without opening a full dashboard.

Conclusion: server monitoring as a foundation, not an afterthought

Effective server monitoring is built in layers. Grafana and Prometheus form the foundation for metrics and alerts. Loki and Promtail give you control over your logs. Tools like Netdata and Glances fill the gaps for real-time diagnostics and quick checks.

The key takeaways:

• Start with Node Exporter + Prometheus + Grafana—this trio covers 80% of your monitoring needs
• Add Loki once you want to correlate logs with metrics
• Configure alerts on symptoms, not raw resource metrics
• Use severity levels and send them through the right channels
• Test your alerts regularly—a silent alert is a useless alert

Server monitoring is not a one-time project but a living system. Add new exporters when you deploy new services, refine your alert thresholds based on actual patterns, and review your dashboards periodically. This is how you build infrastructure that does not surprise you—but informs you.