200 sunucu için izleme nasıl yapılandırırdınız? Hangi…

200 sunucuyu izlemek için, metriklerin ve günlüklerin toplanmasını, depolanmasını, analiz edilmesini ve görselleştirilmesini içeren ölçeklenebilir ve güvenilir bir sistem geliştirirdim.

Yaklaşımlar:

Ajan tabanlı mı yoksa ajan tabansız mı: Bir kombinasyon kullanırdım. Derin sistem metriği toplama için ajan tabanlı (CPU, RAM, disk, ağ), hizmetlerin ve portların kullanılabilirliğini kontrol etmek için ajan tabansız (ping, curl).
Merkezi İzleme: Tüm veriler merkezi bir sistemde toplanır ve işlenir.
Otomasyon: Ajanların dağıtılması, yapılandırmanın ayarlanması ve panoların oluşturulması için otomasyon araçları kullanırdım.
Uyarı Stratejisi: Açık kurallarla, eskalasyonla ve bildirim araçlarıyla (Slack, PagerDuty) entegrasyonla uyarı sistemi kurardım.
Günlük Kaydı: Analiz ve sorun giderme için merkezi günlük toplama.
Görselleştirme: Sistem durumunun hızlıca gözden geçirilmesi için bilgilendirici panolar.

Araçlar:

Metrik toplama: Prometheus (exporterlar ile: node_exporter ana makineler için, blackbox_exporter kullanılabilirlik kontrolü için).
Metrik depolama: Prometheus (yerel) ve Thanos veya VictoriaMetrics uzun vadeli depolama ve ölçeklenebilirlik için.
Günlük toplama: Fluentd veya Filebeat, Kafka veya RabbitMQ (isteğe bağlı) tamponlama için.
Günlük depolama: Elasticsearch.
Görselleştirme: Grafana, metrikler ve günlükler için.
Uyarılar: Alertmanager (Prometheus ile entegre), Slack, PagerDuty ile entegrasyon.
Otomasyon: Ansible veya Puppet, ajanların dağıtımı ve yapılandırması için.
Orkestrasyon (isteğe bağlı ama önerilen): Kubernetes, izleme yığını dağıtımı için.

Sistem Tasarımı:

Mimari:
- Sunucularda çok sayıda node_exporter örneği.
- Veri toplaması için çoğaltılmış Prometheus sunucuları (Thanos Receiver veya VictoriaMetrics VMAgent kullanılarak).
- Thanos / VictoriaMetrics, toplama, uzun vadeli depolama ve sorgular için.
- Günlüklerin depolanması için tek Elasticsearch kümesi.
- Görselleştirme için Grafana kümesi.
- Bir veya daha fazla Alertmanager örneği.
- Sunucularda günlükleri toplamak için Fluentd / Filebeat ajanları.
```
graph TD
    A[200 Sunucu] -- node_exporter --> B(Prometheus Sunucusu)
    A -- Fluentd/Filebeat --> C(Kafka/RabbitMQ - İsteğe bağlı)
    C -- Fluentd/Logstash --> D(Elasticsearch Kümesi)
    B -- Uzaktan Yazma --> E(Thanos/VictoriaMetrics)
    E -- Sorgu --> F(Grafana)
    D -- Sorgu --> F
    B -- Uyarı --> G(Alertmanager)
    G -- Bildirim --> H(Slack/PagerDuty)
```
Metrik toplama yapılandırması (Prometheus):
- Hedeflerin dinamik keşfi (konsul veya Kubernetes gibi altyapılar varsa) veya statik yapılandırmalar (Ansible ile yönetim).
- Toplama aralıklarının yapılandırılması (scrape_interval).
- Sıkça istenen metriklerin toplanması için kayıt kuralları (recording rules) kullanımı.
```
# Prometheus için scrape yapılandırması örneği
scrape_configs:
  - job_name: 'node_exporter'
    # Dinamik keşif veya static_configs
    static_configs:
      - targets: ['server1:9100', 'server2:9100', ...]
    # metrics_path: /metrics # Varsayılan değer
```

Günlük toplama yapılandırması:

Günlükleri izlemek ve merkezi bir düğüme göndermek için ajanların (Fluentd/Filebeat) yapılandırılması.
Günlüklerin ajan seviyesinde veya Elasticsearch’a göndermeden önce yapılandırılması.

# Filebeat yapılandırması örneği (filebeat.yml)
filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/*.log
    - /var/log/syslog
#-------------------------- Elasticsearch çıkışı ---------------------------
output.elasticsearch:
  hosts: ["elasticsearch:9200"]

Grafana yapılandırması:
- Veri kaynaklarının eklenmesi (Prometheus, Elasticsearch).
- Panoların oluşturulması:
  - Genel bakış panoları (Health Overview).
  - Kategorilere göre panolar (CPU, Bellek, Disk, Ağ).
  - Belirli hizmetler/uygulamalar için panolar.
  - Günlükler için panolar.
- Dinamik sunucu/hizmet seçimi için değişken şablonlarının kullanılması.

Uyarı ayarları:

Metriklere dayalı eşiklerin belirlenmesi.
Prometheus (veya Alertmanager) üzerinde uyarı kurallarının oluşturulması.
Alertmanager’daki alıcıların yapılandırılması (entegrasyonlar).
Eskalasyon politikalarının belirlenmesi (örneğin, önce Slack bildirimi, sonra PagerDuty araması).

# Prometheus (rules.yml) içinde kayıt ve uyarı kuralı örneği
# Kayıt kuralı: 5 dakika içindeki CPU kullanıcı yük yüzdesi
- record: instance:node_cpu_user_percent:rate5m
  expr: 100 - avg without (cpu)(rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)

# Uyarı kuralı: Yüksek CPU kullanımı (> 80%)
- alert: HighCPULoad
  expr: instance:node_cpu_user_percent:rate5m > 80
  for: 5m # 5 dakika bekle
  labels:
    severity: warning
  annotations:
    summary: "Yüksek CPU yükü {{ $labels.instance }} üzerinde"
    description: "CPU yükü {{ $labels.instance }} üzerinde {{ $value }}%"

Otomasyon:
- Ansible playbook’ları kullanımı:
  - node_exporter, Fluentd/Filebeat’in kurulumu ve yapılandırması.
  - Prometheus/Alertmanager/Grafana/Elasticsearch yığını dağıtımı.
  - Yapılandırma dosyalarının yönetimi (scrape configs, kurallar, panolar).

Bu, büyük sayıda sunucuyu izlemek için kapsamlı, ölçeklenebilir ve esnek bir yaklaşım olurdu.

200 sunucu için izleme nasıl yapılandırırdınız? Hangi yaklaşımları ve araçları kullanırdınız ve izleme sistemini nasıl tasarlardınız?