Kā jūs iestatītu uzraudzību 200 serveriem? Kādas…

Lai uzraudzītu 200 serverus, es izstrādātu mērogojamu un uzticamu sistēmu, kas ietver metriku un žurnālu apkopošanu, glabāšanu, analīzi un vizualizāciju:

Pieejas:

Aģentu balstīts un bez aģentiem: Es izmantotu kombināciju. Aģentu balstīts — dziļa sistēmas metriku apkopošana (CPU, RAM, disks, tīkls), bez aģentiem — pakalpojumu un portu pieejamības pārbaude (ping, curl).
Centralizēta uzraudzība: Visu datu apkopošana un apstrāde centrālajā sistēmā.
Automatizācija: Es izmantotu automatizācijas rīkus aģentu izvietošanai, konfigurāciju iestatīšanai un panelu izveidei.
Brīdinājumu stratēģija: Es konfigurētu skaidras noteikumus, eskalāciju un brīdinājumu rīku (Slack, PagerDuty) integrāciju.
Žurnālu apkopošana: Centralizēta žurnālu apkopošana analīzei un problēmu risināšanai.
Vizuālizācija: Informatīvi paneli ātrai sistēmas stāvokļa pārskatīšanai.

Instrumenti:

Metriku apkopošana: Prometheus (eksportētāji: node_exporter — resursiem, blackbox_exporter — pieejamības pārbaudei).
Metriku glabāšana: Prometheus (lokāli) un Thanos vai VictoriaMetrics — ilgtermiņa glabāšana un mērogošana.
Žurnālu apkopošana: Fluentd vai Filebeat — apkopošanai, Kafka vai RabbitMQ (pēc izvēles) — buferizācijai.
Žurnālu glabāšana: Elasticsearch.
Vizuālizācija: Grafana — metriku un žurnālu vizualizācijai.
Brīdinājumi: Alertmanager (integrēts ar Prometheus), Slack, PagerDuty.
Automatizācija: Ansible vai Puppet — aģentu izvietošanai un konfigurāciju iestatīšanai.
Orkestrācija (pēc izvēles, bet ieteicama): Kubernetes — uzraudzības staka izvietošanai.

Sistēmas projektēšana:

Arhitektūra:
- Daudzas node_exporter instances serveros.
- Viens vai vairāki replikēti Prometheus serveri (ar Thanos Receiver vai VictoriaMetrics VMAgent) datu apkopošanai.
- Thanos / VictoriaMetrics — apkopojumam, ilgtermiņa glabāšanai un vaicājumiem.
- Vienots Elasticsearch klasteris žurnāliem.
- Panelu klasteris vizualizācijai.
- Viens vai vairāki Alertmanager piemēri.
- Fluentd / Filebeat agenti serveros žurnālu apkopošanai.
```
graph TD
    A[200 Serveri] -- node_exporter --> B(Prometheus Serveris)
    A -- Fluentd/Filebeat --> C(Kafka/RabbitMQ - Pēc izvēles)
    C -- Fluentd/Logstash --> D(Elasticsearch klasteris)
    B -- Attālināts rakstīšana --> E(Thanos/VictoriaMetrics)
    E -- Vaicājumi --> F(Grafana)
    D -- Vaicājumi --> F
    B -- Brīdinājums --> G(Alertmanager)
    G -- Paziņojums --> H(Slack/PagerDuty)
```
Metriku apkopošanas konfigurācija (Prometheus):
- Dinamisks mērķu atklāšana (serveri) — izmantojot pakalpojumu atklāšanu (piemēram, Consul vai Kubernetes) vai statisku konfigurāciju (ar Ansible pārvaldību):
- Apkopošanas intervālu iestatīšana (scrape_interval).
- Bieži pieprasītu metriku noteikumu piemērošana (recording rules).
```
# Prometheus piemēra scrape konfigurācija
scrape_configs:
  - job_name: 'node_exporter'
    # Dinamisks atklājums vai static_configs
    static_configs:
      - targets: ['server1:9100', 'server2:9100', ...]
    # metrics_path: /metrics # Noklusējuma vērtība
```

Žurnālu apkopošanas konfigurācija:

Agentu (Fluentd vai Filebeat) konfigurācijas — žurnālfailu uzraudzība un sūtīšana uz centru.
Žurnālu analīze agentu līmenī vai sūtīšana uz Elasticsearch — datu strukturēšana.

# Filebeat konfigurācijas piemērs (filebeat.yml)
filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/*.log
    - /var/log/syslog
#-------------------------- Elasticsearch izvade ---------------------------
output.elasticsearch:
  hosts: ["elasticsearch:9200"]

Grafana konfigurācija:
- Datu avotu pievienošana (Prometheus, Elasticsearch).
- Panelu izveide:
  - Vispārējs pārskats (Health Overview).
  - Kategorijām pēc (CPU, Memory, Disk, Network).
  - Konkrētu pakalpojumu/lietojumu paneli.
  - Žurnālu paneli.
- Mainīgo šablonu izmantošana — dinamiska serveru/pakalpojumu izvēle.

Brīdinājumu konfigurācija:

Parametru robežu noteikšana pēc metriku datiem.
Brīdinājumu noteikumu izveide Prometheus (vai Alertmanager) sistēmā.
Saņēmēju konfigurācija — Alertmanager (integrācijas).
Eskalācijas politikas noteikšana (piemēram, pirmā paziņojums Slack, pēc tam zvans PagerDuty).

# Prometheus noteikumu un brīdinājumu piemērs (rules.yml)
# CPU slodzes procentuālais rādītājs — 5 minūtes
- record: instance:node_cpu_user_percent:rate5m
  expr: 100 - avg without (cpu)(rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)

# Brīdinājuma noteikums: Augsta CPU slodze (> 80%)
- alert: HighCPULoad
  expr: instance:node_cpu_user_percent:rate5m > 80
  for: 5m # gaidīt 5 minūtes
  labels:
    severity: warning
  annotations:
    summary: "CPU slodze ir augsta {{ $labels.instance }}"
    description: "CPU slodze {{ $labels.instance }} — {{ $value }}%."

Automatizācija:
- Izmantojot Ansible plēibukus —
  - node_exporter, Fluentd/Filebeat uzstādīšana un konfigurēšana.
  - Prometheus/Alertmanager/Grafana/Elasticsearch staka izvietošana.
  - Konfigurācijas failu pārvaldība (scrape configs, rules, dashboards).

Tas būtu sarežģīts, mērogojams un elastīgs uzraudzības pieejas veids lielam serveru skaitam.

Kā jūs iestatītu uzraudzību 200 serveriem? Kādas pieejas un rīkus izmantotu, un kā projektētu uzraudzības sistēmu?