Kaip sukonfigūruotumėte stebėseną 200 serverių? Kokius požiūrius ir įrankius naudotumėte, ir kaip suprojektuotumėte stebėjimo sistemą?

200 serverių stebėjimui aš sukurtų mastelį ir patikimą sistemą, apimančią metrinių duomenų ir žurnalų surinkimą, saugojimą, analizę ir vizualizaciją:

Požiūriai:

1. Agentų pagrindu ir be agentų: Naudotųsi kombinacija. Agentų pagrindu — giluminis sisteminių metrinių duomenų surinkimas (CPU, RAM, diskas, tinklas), be agentų — paslaugų ir prievadų prieinamumo patikrinimas (ping, curl).
2. Centralizuotas stebėjimas: Visų duomenų surinkimas ir apdorojimas centrinėje sistemoje.
3. Automatizacija: Naudotųsi automatizavimo įrankiais agentų diegimui, konfigūracijų nustatymui ir dashboardų kūrimui.
4. Įspėjimo strategija: Nustatyti aiškius taisykles, eskalaciją ir įspėjimo įrankių (Slack, PagerDuty) integraciją.
5. Žurnalų surinkimas: Centralizuotas žurnalų surinkimas analizei ir problemų sprendimui.
6. Vizualizacija: Informatyvūs dashboardai greitam sistemos būklės apžvalgai.

Įrankiai:

• Metrinių duomenų surinkimas: Prometheus (eksporterių pagalba: node_exporter — hostams, blackbox_exporter — prieinamumo patikrinimui).
• Metrinių duomenų saugojimas: Prometheus (vietinis) ir Thanos arba VictoriaMetrics — ilgalaikis saugojimas ir mastelio keitimas.
• Žurnalų surinkimas: Fluentd arba Filebeat — surinkimui, Kafka arba RabbitMQ (pasirinktinai) — buferizacijai.
• Žurnalų saugojimas: Elasticsearch.
• Vizualizacija: Grafana — metrinių duomenų ir žurnalų vizualizacijai.
• Įspėjimai: Alertmanager (integruotas su Prometheus), Slack, PagerDuty.
• Automatizacija: Ansible arba Puppet — agentų diegimui ir konfigūracijų nustatymui.
• Orkestracija (pasirinktinai, bet rekomenduojama): Kubernetes — stebėjimo stako diegimui.

Stebėjimo sistemos projektavimas:

1. Architektūra:

   • Daug pavyzdžių node_exporter serveriuose.
   • Vienas arba keli replikiniai Prometheus serveriai (naudojant Thanos Receiver arba VictoriaMetrics VMAgent) duomenų surinkimui.
   • Thanos / VictoriaMetrics — agregacijai, ilgalaikiam saugojimui ir užklausoms.
   • Vieningas Elasticsearch klasteris žurnalams.
   • Dashboardų klasteris vizualizacijai.
   • Vienas arba keli Alertmanager pavyzdžiai.
   • Fluentd / Filebeat agentai serveriuose žurnalų surinkimui.

   graph TD
       A[200 Serverių] -- node_exporter --> B(Prometheus Serveris)
       A -- Fluentd/Filebeat --> C(Kafka/RabbitMQ - Pasirinktinai)
       C -- Fluentd/Logstash --> D(Elasticsearch Klasteris)
       B -- Nuotolinis Rašymas --> E(Thanos/VictoriaMetrics)
       E -- Užklausos --> F(Grafana)
       D -- Užklausos --> F
       B -- Įspėjimas --> G(Alertmanager)
       G -- Pranešimas --> H(Slack/PagerDuty)
   

2. Metrinių duomenų surinkimo konfigūracija (Prometheus):

   • Dinamiškas tikslų aptikimas (serveriai) — naudojant paslaugų atradimą (pvz., Consul arba Kubernetes) arba statinę konfigūraciją (valdymas per Ansible).
   • Surinkimo intervalų nustatymas (scrape_interval).
   • Dažnai užklausiamų metrinių duomenų taisyklių taikymas (recording rules).

   # Prometheus pavyzdinis scrape konfigūracija
   scrape_configs:
     - job_name: 'node_exporter'
       # Dinamiškas aptikimas arba static_configs
       static_configs:
         - targets: ['server1:9100', 'server2:9100', ...]
       # metrics_path: /metrics # Numatytoji reikšmė
   

3. Žurnalų surinkimo konfigūracija:

   • Agentų (Fluentd arba Filebeat) konfigūracijos — žurnalo failų stebėjimas ir siuntimas į centrą.
   • Žurnalų analizė agentų lygyje arba siuntimo prieš Elasticsearch — duomenų struktūrizavimas.

   # Filebeat konfigūracijos pavyzdys (filebeat.yml)
   filebeat.inputs:
   - type: log
     enabled: true
     paths:
       - /var/log/*.log
       - /var/log/syslog
   #-------------------------- Elasticsearch išėjimas ---------------------------
   output.elasticsearch:
     hosts: ["elasticsearch:9200"]
   

4. Grafana nustatymai:

   • Duomenų šaltinių pridėjimas (Prometheus, Elasticsearch).
   • Dashboardų kūrimas:
     • Apžvalgos dashboardai (Health Overview).
     • Kategorijų dashboardai (CPU, Memory, Disk, Network).
     • Konkretūs paslaugų/taikymų dashboardai.
     • Žurnalų dashboardai.
   • Naudoti kintamųjų šablonus — dinamiškas serverių/paslaugų pasirinkimas.

5. Įspėjimo nustatymai:

   • Riba parametrų nustatymas pagal metrinius duomenis.
   • Įspėjimų taisyklių kūrimas Prometheus (arba Alertmanager) sistemoje.
   • Gavimo priemonių konfigūracija — Alertmanager (integracijos).
   • Eskalacijos politikos nustatymas (pavyzdžiui, pirmiausia į Slack, po to skambutis PagerDuty).

   # Prometheus taisyklių ir įspėjimų pavyzdys (rules.yml)
   # CPU apkrovos procentinė reikšmė — 5 minutės
   - record: instance:node_cpu_user_percent:rate5m
     expr: 100 - avg without (cpu)(rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)
   
   # Įspėjimo taisyklė: aukšta CPU apkrova (> 80%)
   - alert: HighCPULoad
     expr: instance:node_cpu_user_percent:rate5m > 80
     for: 5m # Laukti 5 minutes
     labels:
       severity: warning
     annotations:
       summary: "CPU apkrova aukšta {{ $labels.instance }}"
       description: "CPU apkrova {{ $labels.instance }} — {{ $value }}%."
   

6. Automatizacija:

   • Naudojant Ansible playbook'us —
     • node_exporter, Fluentd/Filebeat diegimas ir konfigūracija.
     • Prometheus/Alertmanager/Grafana/Elasticsearch stako diegimas.
     • Konfigūracijų failų valdymas (scrape configs, rules, dashboards).

Tai būtų kompleksinis, mastelinis ir lankstus stebėjimo požiūris dideliam serverių skaičiui.