Ինչպե՞ս կկազմեք 200 սերվերների մոնիտորինգը: Ի՞նչ մոտեցումներ և գործիքներ կօգտագործեք, և ինչպես կպроектեք մոնիտորինգի համակարգը։

Ստուգման համար 200 սերվերների համար ես մշակել մի մասշտաբային և հուսալի համակարգ, որը ներառում է մետրիկների և լոգների հավաքում, պահպանում, վերլուծում և վիզուալիզացիա:

Մոտեցումներ:

1. Ագենտային և առանցագենտային: Կիրառել եմ համակցություն: Ագենտային՝ համակարգային մետրիկների խորքային հավաքման համար (CPU, RAM, disk, network), առանցագենտային՝ ծառայությունների և պորտերի հասանելիության ստուգման համար (ping, curl):
2. Կենտրոնական մոնիտորինգ: Բոլոր տվյալները հավաքվում և մշակվում են կենտրոնական համակարգում:
3. Ավтоматացում: Օգտագործել եմ ավտոմատացման գործիքներ՝ գործակալների տեղադրման, կոնֆիգուրացիայի կարգավորումների և դաշբորդների ստեղծման համար:
4. Էլեկտրական ռազմավարություն: Կարգավորել եմ ծանուցման համակարգ՝ հստակ կանոններով, էսկալացիայով և ծանուցման գործիքների (Slack, PagerDuty) ինտեգրմամբ:
5. Լոգավորում: Կենտրոնական լոգների հավաքում՝ վերլուծության և խնդիրների լուծման համար:
6. Վիզուալիզացիա: Ինֆորմատիվ դաշբորդներ՝ արագ համակարգի վիճակի դիտարկման համար:

Գործիքներ:

• Մետրիկների հավաքում: Prometheus (exporters-ով՝ node_exporter՝ հոստերի համար, blackbox_exporter՝ հասանելիության ստուգման համար):
• Մետրիկների պահպանում: Prometheus (տեղական) և Thanos կամ VictoriaMetrics՝ երկարաժամկետ պահպանում և մասշտաբայնություն:
• Լոգների հավաքում: Fluentd կամ Filebeat՝ հավաքման համար, Kafka կամ RabbitMQ (ընտրովի)՝ բուֆերացման համար:
• Լոգների պահպանում: Elasticsearch:
• Վիզուալիզացիա: Grafana՝ մետրիկների և լոգների համար:
• Ծանուցումներ: Alertmanager (Prometheus-ով ինտեգրված), Slack, PagerDuty:
• Ավтоматացում: Ansible կամ Puppet՝ գործակալների տեղադրման և կարգավորումների համար:
• Օրգանիզացիա (ընտրովի, բայց խորհուրդ է տրվում): Kubernetes՝ մոնիտորինգի ստեկի տեղադրման համար:

Մոնիտորինգի համակարգի նախագծում:

1. Արքիտեկտուրա:

   • 200 սերվերների վրա node_exporter օրինակներ:
   • Մի կամ մի քանի կրկնվող Prometheus սերվերներ (օգտագործելով Thanos Receiver կամ VictoriaMetrics VMAgent) տվյալների հավաքման համար:
   • Thanos / VictoriaMetrics՝ հավաքագրման, երկարաժամկետ պահպանում և հարցումների համար:
   • Միացյալ 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 -- Արտաքին գրառում --> E(Thanos/VictoriaMetrics)
       E -- Հարցում --> F(Grafana)
       D -- Հարցում --> F
       B -- Ծանուցում --> G(Alertmanager)
       G -- Ծանուցում --> H(Slack/PagerDuty)
   

2. Մետրիկների հավաքման կոնֆիգուրացիա (Prometheus):

   • Դինամիկ նպատակների հայտնաբերում (սերվերներ)՝ ծառայության հայտնաբերման միջոցով (օրինակ՝ Consul կամ Kubernetes) կամ ստատիկ կոնֆիգուրացիաներով (կառավարում Ansible-ով):
   • Հավաքման ինտերվալների կարգավորում (scrape_interval):
   • Հաճախակի մետրիկների համար գրառման կանոնների կիրառում (recording rules):

   # Prometheus-ի օրինակային scrape կոնֆիգուրացիա
   scrape_configs:
     - job_name: 'node_exporter'
       # Դինամիկ հայտնաբերում կամ static_configs
       static_configs:
         - targets: ['server1:9100', 'server2:9100', ...]
       # metrics_path: /metrics # Դեֆոլտ արժեք
   

3. Լոգների հավաքման կոնֆիգուրացիա:

   • Գործակալների (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"]
   

4. Grafana-ի կարգավորումներ:

   • Դատարկելու տվյալների աղբյուրներ (Prometheus, Elasticsearch):
   • Դաշբորդների ստեղծում:
     • Հետազոտական դաշբորդներ (Health Overview):
     • Կատեգորիաներով դաշբորդներ (CPU, Memory, Disk, Network):
     • կոնկրետ ծառայությունների/հավելվածների դաշբորդներ:
     • Լոգների դաշբորդներ:
   • Շաբլոնների օգտագործում՝ դինամիկ ընտրության համար սերվերների/ծառայությունների:

5. Ծանուցման կարգավորումներ:

   • Պարամետրային սահմանումների որոշում մետրիկների հիման վրա:
   • Ծանուցման կանոնների ստեղծում 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 բեռ
   - 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 }}%։"
   

6. Ավтоматացում:

   • Օգտագործել եմ Ansible պլեյբուքեր՝
     • node_exporter, Fluentd/Filebeat տեղադրելու և կարգավորելու համար:
     • Prometheus/Alertmanager/Grafana/Elasticsearch ստեկի տեղադրման համար:
     • Կոնֆիգուրացիոն ֆայլերի կառավարում (scrape configs, rules, dashboards):

Սա կլիներ համալիր, մասշտաբային և ճկուն մոնիտորինգի մոտեցում մեծ քանակությամբ սերվերների համար։