Küçük Bir VPS'i Prometheus ve Grafana'yla Monitor Etmek

Monitoring genelde ertelenir çünkü farklı bir scale'in operasyonu gibi geliyor, bir düzine server, dedicated bir ops team, bir NOC'taki dashboard'lar. Bir client'ın application'ını çalıştıran tek bir küçük VPS için, bu çerçeve "monitoring kur"u, bir şey yavaş hissettirdiğinde sadece SSH'layıp htop çalıştırmaya kıyasla overkill gibi hissettiriyor. Ama tek bir server için asıl setup küçük, ve "bir şey yavaş hissettirdiğinde SSH'la" ile "son haftanın bir graph'ına bak" arasındaki fark, setup effort'unun ima ettiğinden daha büyük.

Tek bir server için parçalar

node_exporter, server'ın kendisinde çalışıyor ve sistem metric'lerini, CPU, memory, disk, network, Prometheus'un anladığı bir formatta expose ediyor:

wget https://github.com/prometheus/node_exporter/releases/download/v1.8.0/node_exporter-1.8.0.linux-amd64.tar.gz
tar xzf node_exporter-*.tar.gz
sudo mv node_exporter-*/node_exporter /usr/local/bin/

Küçük bir systemd unit'i onu çalışır halde tutuyor:

# /etc/systemd/system/node_exporter.service
[Unit]
Description=Node Exporter
After=network.target

[Service]
ExecStart=/usr/local/bin/node_exporter
Restart=always

[Install]
WantedBy=multi-user.target

Prometheus'un kendisi, single-server bir setup için aynı VPS'te çalışabilir, ya da watch ettiği server'ın kötü bir günü olmasından sağ çıkmasını tercih ediyorsanız ayrı bir küçük monitoring VPS'inde. Her iki durumda da config kısa:

# prometheus.yml
scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']

Grafana, Prometheus'a bir data source olarak bağlanıyor ve bu metric'leri dashboard'lara çeviriyor, node_exporter için community dashboard'ı (yıllardır stable olan, well-known bir dashboard ID'si) sıfırdan bir şey build etmeden CPU, memory, disk, ve network graph'ları veriyor.

Bu gerçekte size ne kazandırıyor

Açık cevap graph'lar, ama daha kullanışlı cevap history. "Server bugün yavaş hissettiriyor", "memory usage geçen iki hafta boyunca istikrarlı şekilde tırmandı ve şimdi limit'e yakın" oluyor, ki bu tamamen farklı, ve çok daha actionable, bir statement. Bir memory leak, yavaşça dolan bir disk, traffic büyürken load average'da sürünen bir artış, bunların hepsi tek bir htop snapshot'ında invisible ve haftalık bir graph'ta obvious.

Alerting: minimal olarak bile yapmaya değer kısım

Dashboard'lar, birinin onlara bakmasını gerektiriyor. Alerting, server'ın bir şey yanlış olduğunda size söylemesi demek. Minimal bir Alertmanager setup'ı bile, iki ya da üç rule, küçük bir VPS için gerçekten önemli olan durumları kapsıyor:

# alert.rules.yml
groups:
  - name: basic
    rules:
      - alert: DiskSpaceLow
        expr: node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} < 0.10
        for: 30m
        annotations:
          summary: "Disk space below 10% on {{ $labels.instance }}"

      - alert: HighMemoryUsage
        expr: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) > 0.90
        for: 15m
        annotations:
          summary: "Memory usage above 90% on {{ $labels.instance }}"

Bu iki rule tek başına en yaygın iki "server yavaşça bozuluyordu ve kimse fark etmedi" senaryosunu yakalıyor, ve Alertmanager sonucu, attention'ın zaten gittiği her neredeyse, email'e, Slack'e, ya da bir webhook'a gönderebiliyor.

Sonradan scale etmek ekstra hiçbir şeye mal olmuyor

Bunun tek bir server için bile setup etmeye değmesinin sebebi, ikinci bir server ortaya çıktığında setup'ın değişmemesi, sadece bir scrape_configs entry'si ve bir node_exporter install'ı daha alıyor. Sonra başlatılacak bir "monitoring projesi" yok, "monitoring yok"tan "monitoring var"a bir migration yok, sadece zaten orada olan bir config dosyasında bir target daha. Bir server'la başlamak, ikinci, üçüncü, ve onuncu server'ın baskı altında bir şey build etmenin tetikleyicisi olmak yerine, zaten çalışan bir sisteme katılması demek.