როგორ დააყენებდით 200 სერვერის მონიტორინგს? რა მიდგომებს და ინსტრუმენტებს გამოიყენებდით, და როგორ დაგეგმავდით მონიტორინგის სისტემას?

200 სერვერის მონიტორინგისთვის მე შემუშავებდი მასშტაბურ და საიმედო სისტემას, რომელიც მოიცავს მეტრიკებისა და ლოგების შეგროვებას, შენახვას, ანალიზსა და ვიზუალიზაციას:

მოწყობილობები:

1. აგენტი-ბაზირებული და აგენტი-გაუქმებელი: მე გამოიყენებდი კომბინაციას. აგენტი-ბაზირებული — სისტემური მეტრიკების სიღრმისეულ შეგროვებისთვის (CPU, RAM, დისკი, ქსელი), აგენტი-გაუქმებელი — სერვისებისა და პორტების ხელმისაწვდომობის შემოწმებისთვის (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 დატვირთვა (> 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 }}%.
   

" ```

6. ავტომატიზაცია:
   • გამოყენება მაქვს Ansible-ის პლეიბუკებით —
     • node_exporter, Fluentd/Filebeat ინსტალაცია და კონფიგურაცია:
     • Prometheus/Alertmanager/Grafana/Elasticsearch სტეკის განთავსება:
     • კონფიგურაციის ფაილების მართვა (scrape configs, rules, dashboards):

ეს იქნებოდა კომპლექსური, მასშტაბური და მოქნილი მონიტორინგის მიდგომა დიდი რაოდენობის სერვერებისთვის।