Как бихте настроили мониторинг за 200 сървъра? Какви…

За мониторинг на 200 сървъра бих разработил мащабируема и надеждна система, която включва събиране, съхранение, анализ и визуализация на метрики и логове.

Подходи:

Agent-based срещу Agentless: Използвал бих комбинация. Agent-based за дълбоко събиране на системни метрики (CPU, RAM, диск, мрежа), agentless за проверка на достъпността на услуги и портове (ping, curl).
Централизирано мониторинг: Всички данни се събират и обработват в централизирана система.
Автоматизация: Използвал бих инструменти за автоматизация за разгръщане на агенти, настройка на конфигурации и създаване на табла.
Стратегия за известяване: Настроил бих система за известия с ясни правила, ескалация и интеграция с инструменти за уведомяване (Slack, PagerDuty).
Логване: Централизирано събиране на логове за анализ и отстраняване на грешки.
Визуализация: Информативни табла за бърз преглед на състоянието на системата.

Инструменти:

Събиране на метрики: Prometheus (с exporters: node_exporter за хостове, blackbox_exporter за проверка на достъпността).
Съхранение на метрики: Prometheus (локално) и Thanos или VictoriaMetrics за дългосрочно съхранение и мащабиране.
Събиране на логове: Fluentd или Filebeat за събиране, Kafka или RabbitMQ (по избор) за буфериране.
Съхранение на логове: Elasticsearch.
Визуализация: Grafana за метрики и логове.
Известия: Alertmanager (интегриран с Prometheus), интегриран със Slack, PagerDuty.
Автоматизация: Ansible или Puppet за разгръщане на агенти и настройка.
Оркестрация (по желание, но препоръчително): Kubernetes за разгръщане на мониторинговия стек.

Проектиране на система за мониторинг:

Архитектура:
- Множество екземпляри node_exporter на сървърите.
- Един или повече репликирани сървъри Prometheus (чрез Thanos Receiver или VictoriaMetrics VMAgent) за събиране на данни.
- Thanos / VictoriaMetrics за агрегиране, дългосрочно съхранение и заявки върху Prometheus.
- Единен кластер Elasticsearch за съхранение на логове.
- Кластер Grafana за визуализация.
- Един или повече екземпляра Alertmanager.
- Fluentd / Filebeat агенти на сървърите за събиране на логове.
```
graph TD
    A[200 сървъра] -- node_exporter --> B(Prometheus сървър)
    A -- Fluentd/Filebeat --> C(Kafka/RabbitMQ - по желание)
    C -- Fluentd/Logstash --> D(Elasticsearch клъстер)
    B -- Remote Write --> E(Thanos/VictoriaMetrics)
    E -- Query --> F(Grafana)
    D -- Query --> F
    B -- Alert --> G(Alertmanager)
    G -- Notify --> H(Slack/PagerDuty)
```
Конфигурация за събиране на метрики (Prometheus):
- Динамично откриване на цели (сървъри) чрез service discovery (напр. с Consul или Kubernetes) или статични конфигурации (управлявани чрез Ansible).
- Настройка на интервалите за събиране (scrape_interval).
- Прилагане на правила за запис (recording rules) за агрегиране на често изисквани метрики.
```
# Пример за scrape конфигурация за Prometheus
scrape_configs:
  - job_name: 'node_exporter'
    # Динамично откриване или static_configs
    static_configs:
      - targets: ['server1:9100', 'server2:9100', ...]
    # metrics_path: /metrics # по подразбиране
```
Конфигурация за събиране на логове:
- Настройка на агенти (Fluentd/Filebeat) за мониторинг на лог файлове и изпращането им към централния възел.
- Парсиране на логове на ниво агент или преди изпращане към Elasticsearch за структуриране на данните.
```
# Пример за конфигурация на Filebeat (filebeat.yml)
filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/*.log
    - /var/log/syslog
#-------------------------- Изход към Elasticsearch ---------------------------
output.elasticsearch:
  hosts: ["elasticsearch:9200"]
```
Настройка на Grafana:
- Добавяне на източници на данни (Prometheus, Elasticsearch).
- Създаване на табла:
  - Обзорни табла (Health Overview).
  - Табла по категории (CPU, памет, диск, мрежа).
  - Табла за конкретни услуги/приложения.
  - Табла за логове.
- Използване на шаблонни променливи за динамичен избор на сървъри/услуги.

Настройка на известия:

Определяне на прагови стойности въз основа на метрики.
Създаване на правила за известия в Prometheus (или Alertmanager).
Конфигуриране на получатели в Alertmanager (интеграции).
Определяне на политики за ескалация (например, първо известяване в Slack, после обаждане чрез PagerDuty).

# Пример за правило за запис и известяване в Prometheus (rules.yml)
# Правило за запис: процент на CPU натоварване за 5 минути
- record: instance:node_cpu_user_percent:rate5m
  expr: 100 - avg without (cpu)(rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)

# Правило за известяване: Високо CPU натоварване (> 80%)
- alert: HighCPULoad
  expr: instance:node_cpu_user_percent:rate5m > 80
  for: 5m # Изчакване 5 минути преди активиране
  labels:
    severity: warning
  annotations:
    summary: "Високо CPU натоварване на {{ $labels.instance }}"
    description: "CPU натоварването на {{ $labels.instance }} е {{ $value }}%."

Автоматизация:
- Използване на Ansible playbook-и за:
  - Инсталиране и настройка на node_exporter, Fluentd/Filebeat.
  - Разгръщане на stack-а Prometheus/Alertmanager/Grafana/Elasticsearch.
  - Управление на конфигурационните файлове (scrape configs, rules, dashboards).

Това би бил комплексен, мащабируем и гъвкав подход към мониторинга на голям брой сървъри.

Как бихте настроили мониторинг за 200 сървъра? Какви подходи и инструменти бихте използвали и как бихте проектирали системата за мониторинг?