Prometheus Alertmanager Yapılandırması
Prometheus, metrik toplama konusunda mükemmel bir iş çıkarır ancak ham metrik eşiklerinin doğrudan aksiyonlu olaylara dönüşmesi nadirdir. Bir uyarı yönetim katmanı olmadan, ekipleriniz duplicate uyarılardan, flapping threshold'lardan ve kritik olmayan uyarılardan 3 AM'de on-call mühendisleri sayfalayarak notification fatigue yaşaması kaçınılmazdır. Prometheus Alertmanager, algılamayı bildirimden ayırarak, gürültülü sinyalleri yönetilebilir olaylara dönüştürmek için gereken grouping, inhibition ve routing mantığını sağlar.
Bu makalede, Alertmanager'ın temel mimarisinden başlayarak, production ortamları için optimize edilmiş routing ağaçları, grouping stratejileri, inhibition kuralları ve yüksek erişilebilirlik yapılandırmaları detaylı olarak ele alınacaktır.
Alertmanager Mimarisi
Temel Kavramlar
Alertmanager, Prometheus ecosystem'ünün kritik bir bileşenidir ve üç temel işlevi yerine getirir: bildirim yönetimi, uyarı gruplama ve sessize alma (silence) mekanizması. Prometheus, metrikleri toplar ve alerting kurallarını değerlendirir; bir kural koşulu karşılandığında ve for süresi geçtiğinde, uyarı Alertmanager'a HTTP üzerinden gönderilir. Alertmanager ise gelen uyarıları işleyerek tanımlanmış routing kurallarına göre uygun alıcılara yönlendirir.
Bu mimari, Prometheus'un kendisini sadece algılama ile sınırlandırırken, bildirim mantığının tamamını Alertmanager'a bırakır. Bu ayrım, karmaşık bildirim senaryolarını Prometheus tarafında kodlamadan yönetmeyi mümkün kılar. Örneğin, bir uyarının nereye gideceği, hangi koşullarda gruplanacağı ve hangi durumlarda bastırılacağı tamamen Alertmanager yapılandırmasında tanımlanır.
Kurulum ve Temel Yapılandırma
Alertmanager, genellikle Prometheus ile birlikte deploy edilir; Kubernetes ortamında sidecar olarak veya systemd ile yönetilen bir servis olarak çalışabilir. Bu makalede, çalışan bir Prometheus kurulumunuzun olduğu varsayılmaktadır ve eklenen şey düzgün yapılandırılmış bir Alertmanager örneğidir.
Varsayılan yapılandırma dosyası /etc/alertmanager/alertmanager.yml konumunda bulunur. Kubernetes ortamında kube-prometheus-stack Helm chart kullanılıyorsa, bu dosya bir ConfigMap üzerinden yönetilir, ancak YAML yapısı identik kalır.
Yapılandırmaya başlamadan önce, amtool kurulumunu yapmanız önerilir. Amtool, Alertmanager ile birlikte gelir ve yapılandırma doğrulama ile silence yönetimi için vazgeçilmez bir araçtır:
``bash
amtool --alertmanager.url=http://localhost:9093 config show
amtool check-config /etc/alertmanager/alertmanager.yml
`
Bu doğrulama adımını alışkanlık haline getirmek önemlidir. Hatalı bir YAML dosyası, Alertmanager'ın reload'u reddetmesine ve önceki yapılandırmayı çalıştırmaya devam etmesine neden olur. Operatör perspektifinden bu sessizce gerçekleşir; reload endpoint'inin yanıt kodunu izlemezseniz sorunu fark etmeyebilirsiniz.
Routing Ağacı Tasarımı
Temel Routing Yapısı
Routing ağacı, her uyarının hangi alıcı tarafından işleneceğini belirleyen Alertmanager yapılandırmasının kalbidir. Her uyarı root route'dan girer ve en spesifik eşleşen route'a kadar ağacı遍历 eder. Bu yapı, uyarıları etiketlerine (labels) göre yönlendirmeyi sağlar.
`yaml
route:
receiver: 'default-receiver'
group_by: ['alertname', 'cluster', 'service']
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
routes:
- receiver: 'critical-alerts'
matchers:
- severity = 'critical'
continue: true
- receiver: 'backend-alerts'
matchers:
- team = 'backend'
routes:
- receiver: 'backend-pagerduty'
matchers:
- severity = 'critical'
continue: true
- receiver: 'backend-slack'
matchers:
- severity = 'warning'
- receiver: 'database-alerts'
matchers:
- service = 'database'
- receiver: 'low-priority'
matchers:
- severity = 'info'
`
Bu yapılandırmada, root receiver olarak bir default alıcı tanımlanmıştır. Ardından, spesifik eşleşmeler için alt route'lar eklenmiştir. continue: true parametresi, uyarının sonraki route'larla da eşleşmesini sağlar; bu, kritik uyarıların hem PagerDuty'ye hem de Slack'e gönderilmesi gibi senaryolarda kullanışlıdır.
Routing Sıralama Mantığı
Routing ağacı tasarımında en önemli nokta, sıralama mantığını doğru kurgulamaktır. Alertmanager, uyarıları ağaçta yukarıdan aşağıya doğru değerlendirir ve ilk eşleşen route'ı kullanır. Bu nedenle, en spesifik kriterler en üstte, en genel kriterler en altta yer almalıdır.
Kritik uyarılar için ayrı bir dal oluşturmak, üretkenlik ve alarm yorgunluğu arasındaki dengeyi kurmanın en etkili yoludur. Bir Slack alıcısı ile grouping veya inhibition olmadan tek başına naive yapılandırma, bir hafta içinde göz ardı edilen bir kanal oluşturur. Routing ağacı, her dal eklenen kriter olmadan teknik borç olacak şekilde tasarlanmalıdır.
Doğru anatomide, sağlıklı bir yapılandırma birlikte çalışan altı element üzerine kuruludur: routing ağacı hangi alıcının her uyarıyı işleyeceğini belirler, gruplama ilgili uyarıları tek bir bildirimde birleştirir, inhibition kuralları kök nedeni etkilerden ayırt eder, silence'lar tek seferlik bakım pencereleri için gürültüyü engeller, severity kanalları uykuyu kesen ile mesai saatlerine kadar bekleyeni ayırır, ve on-call rotasyonu bildirimin doğru kişiye ulaşmasını garanti eder.
Grouping Stratejileri
Grouping Nedir ve Neden Önemli
Grouping, aynı etiket kümesine sahip uyarıları tek bir bildirimde birleştirir. Bu mekanizma, birden fazla sunucuda aynı tipte uyarı oluştuğunda (örneğin 10 sunucuda yüksek CPU kullanımı), Alertmanager'ın bunları tek bir sayfada paketleyebilmesini sağlar. Grouping olmadan, büyük bir olay yönetilemez bir uyarı seline dönüşebilir.
Timing parametreleri, gürültü azaltma ve hız arasındaki dengeyi kontrol eder. group_wait (30 saniye ile 1 dakika arası), yeni bir grup için ilk bildirim gönderilmeden önce ne kadar bekleneceğini belirler. Bu pencere, milisaniyeler arayla gelen ilgili uyarıların birlikte toplanmasını sağlar.
Grouping Parametreleri
`yaml
route:
group_by: ['alertname', 'cluster', 'service']
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
`
group_interval parametresi, ilk bildirimden sonra aynı gruba eklenen yeni uyarılar hakkında güncellemeler gönderilmeden önce ne kadar bekleneceğini tanımlar. repeat_interval ise aynı uyarının tekrar gönderilmesi arasındaki süreyi belirler; bu, uzun süren olaylar için periyodik hatırlatmalar sağlar.
Pratik bir örnek olarak, group_by: ['alertname', 'cluster', 'service'] değerini ele alalım. Eğer HighCpuUsage uyarısı iki farklı sunucuda tetiklenirse ancak bu sunucular farklı cluster veya service etiketlerine sahipse, bunlar ayrı bildirimler olacaktır. Aynı cluster ve service içindeyseler, tek bir bildirimde birleştirileceklerdir. Bu yaklaşım, yeterli bağlam sağlarken aynı mesajın içinde farklı sorunları gizlemeyecek kadar granülerlik korur.
Daha uzun bir group_wait değeri (örneğin 1 veya 2 dakika), daha fazla ilgili uyarının tek bir bildirimde birleşmesini sağlar. Öte yandan, daha kısa bir değer (10-15 saniye), uyarıların daha hızlı iletilmesini sağlar ancak bildirim sayısını artırabilir. Production ortamları için genellikle 30 saniye ile 1 dakika arası değerler idealdir.
Inhibition Kuralları
Inhibition Nedir
Inhibition, bir uyarı aktifken diğer uyarıları bastırma mekanizmasıdır. Bu özellik, kök nedeni etkilerden ayırt etmek için kritik öneme sahiptir. Örneğin, cluster master node'u düştüğünde, o node üzerinde çalışan her pod için sayfa almaya gerek yoktur. Inhibition kuralları, bir kaynak uyarı aktif olduğunda hedef uyarıları otomatik olarak sessize alır.
Inhibition kuralları, en az kullanılan ve aynı zamanda bölgesel olaylar sırasında en yüksek etkiye sahip araçtır. Kritik bir uyarı, birisini uyandırmayı hak eden uyarıdır; bu açık tanımı zorlamak, ekip davranışını değiştirir.
Inhibition Yapılandırması
`yaml
inhibit_rules:
# Cluster düştüğünde instance düzeyindeki uyarıları bastır
- source_matchers:
- 'alertname = "ClusterDown"'
- 'severity = "critical"'
target_matchers:
- 'severity =~ "warning|info"'
equal:
- 'cluster'
- 'namespace'
# Kritik bir uyarı varsa aynı servis için warning uyarılarını bastır
- source_matchers:
- 'severity = "critical"'
target_matchers:
- 'severity = "warning"'
equal:
- 'job'
- 'instance'
# Database erişilemez olduğunda tüm database bağlantılı uyarıları bastır
- source_matchers:
- 'alertname = "DatabaseUnreachable"'
target_matchers:
- 'alertname =~ "Database.*"'
equal:
- 'database'
`
Bu inhibition kurallarında, source_matchers bastırma kaynağını, target_matchers bastırılacak hedef uyarıları, ve equal hangi etiketlerin eşleşmesi gerektiğini tanımlar. Bastırma sadece tüm equal etiketleri eşleştiğinde gerçekleşir.
Inhibition kurallarını ifade etmenin faydalı mental modeli, cause (neden) uyarılarını effect (sonuç) uyarılarından ayırmaktır. Cause, node'un düştüğü, network link'in koptuğu, veritabanının bağlantıları kabul etmeyi bıraktığı durumlardır. Effect ise pod'ların başlayamadığı, isteklerin başarısız olduğu, job'ların bağlanamadığı durumlardır. Büyük bir olay sırasında, on-call olan kişi nedenleri, etkilerin elli kalemlik bir listesini değil, görmeye ihtiyaç duyar.
Alıcı Yapılandırması
Slack Entegrasyonu
`yaml
receivers:
- name: 'default-receiver'
slack_configs:
- channel: '#alerts'
send_resolved: true
title: '{{ range .Alerts }}{{ .Annotations.summary }}{{ end }}'
text: '{{ range .Alerts }}Alert: {{ .Labels.alertname }}
Severity: {{ .Labels.severity }}
Cluster: {{ .Labels.cluster }}
Description: {{ .Annotations.description }}
{{ end }}'
footer: 'Alertmanager'
color: '{{ if eq .Labels.severity "critical" }}danger{{ else }}warning{{ end }}'
- name: 'critical-alerts'
slack_configs:
- channel: '#oncall-critical'
send_resolved: true
title: '🚨 CRITICAL: {{ range .Alerts }}{{ .Annotations.summary }}{{ end }}'
- name: 'pagerduty-critical'
pagerduty_configs:
- service_key: 'YOUR_PAGERDUTY_SERVICE_KEY'
severity: critical
description: '{{ range .Alerts }}{{ .Annotations.summary }}{{ end }}'
`
PagerDuty Entegrasyonu
PagerDuty, kritik uyarıların anında müdahale gerektiren durumlarda kullanılır. PagerDuty yapılandırması, service key ve severity mapping içerir. Kritik uyarılar otomatik olarak PagerDuty üzerinden on-call ekibini bilgilendirirken, düşük öncelikli uyarılar e-posta veya Slack üzerinden iletilebilir.
Silence Yönetimi
Amtool ile Silence Oluşturma
Silence, tek seferlik bakım pencereleri veya bilinen sorunlar için uyarıları geçici olarak susturmak için kullanılır:
`bash
amtool silence add --alertname="HighMemoryUsage" --duration="2h" --author="admin" --comment="Bakım penceresi"
amtool silence list
amtool silence expire SILENCE_ID
`
Yüksek Erişilebilirlik
Alertmanager Clustering
Production ortamlarında, Alertmanager'ın yüksek erişilebilirliği için birden fazla instance çalıştırılmalıdır. Bu, hem yük dengeleme hem de failover sağlar:
`yaml
global:
resolve_timeout: 5m
route:
receiver: 'default-receiver'
group_by: ['alertname', 'cluster']
group_wait: 30s
group_interval: 5m
mesh_peers:
- alertmanager-1.example.com:6783
- alertmanager-2.example.com:6783
- alertmanager-3.example.com:6783
``
Bu yapılandırma, üç Alertmanager instance'ının bir mesh ağı oluşturmasını sağlar. Uyarılar tüm instance'lara gönderilir ve herhangi bir instance başarısız olursa, diğerleri bildirimlere devam eder.
En İyi Uygulamalar
Alarm Yorgunluğunu Önleme
Alarm yorgunluğunun belirtileri tanıdıktır: on-call rotasyonu Slack bildirimlerini alışkanlıkla filtrelemeye başlar, PagerDuty onay süreleri uzar ve post-mortem'ler bazen kritik bir uyarının ateşlendiğini ancak rutin olarak göz ardı edildiğini ortaya koyar. Bunlar süreç hataları değil, yapılandırma hatalarıdır.
Çözüm için dört temel unsur birlikte çalışmalıdır: grouping, inhibition, tiered routing ve uygun severity tanımları. Grouping, aynı etiket kümesine sahip uyarıları tek bir bildirimde birleştirir. Inhibition, kök neden uyarıları aktifken etki uyarılarını bastırır. Tiered routing, severity ve team etiketlerine göre farklı kanallara yönlendirme yapar. Son olarak, kritik uyarıların net bir tanımı, ne zaman birisinin uyandırılması gerektiğini belirler.
İzlenecek Adımlar
İlk olarak, mevcut tüm uyarılarınızı gözden geçirin ve her biri için şu soruları yanıtlayın: Bu uyarı için birisini 3 AM'de uyandırmalı mıyım? Yanıt hayırsa, severity etiketini warning veya info olarak değiştirin ve Slack gibi düşük öncelikli kanallara yönlendirin.
İkinci olarak, inhibition kurallarınızı tanımlayın. Hangi uyarılar diğerlerinin nedeni olabilir? Bu soruyu yanıtlamak, inhibition kurallarının temelini oluşturur.
Üçüncü olarak, grouping parametrelerinizi ayarlayın. Çok fazla gruplama, sorunları gizler; çok az gruplama, bildirim seline neden olur. İdeal denge, uygulama karakteristiklerinize bağlıdır ve zamanla ince ayar yapmayı gerektirir.
Son olarak, amtool ve Alertmanager metric'lerini kullanarak yapılandırmanızı izleyin. Beklenmedik bildirim sayısı veya gruplama davranışı, yapılandırma sorunlarının erken göstergeleridir.
Sonuç
Prometheus Alertmanager, etkili bir şekilde yapılandırıldığında, izleme altyapınızın kritik bir bileşenidir. Bu makalede ele alınan routing ağaçları, grouping stratejileri, inhibition kuralları ve yüksek erişilebilirlik yapılandırması, production ortamları için sağlam bir temel oluşturur.
Unutmayın: Alertmanager yapılandırması bir seferlik bir görev değildir. Ekip geri bildirimleri, olay analizleri ve iş yükü değişiklikleri düzenli olarak yapılandırmanın gözden geçirilmesini gerektirir. İyi yapılandırılmış bir Alertmanager, doğru kişilere, doğru zamanda, doğru bilgiyle ulaşan uyarılar sağlar ve bu da müdahale süresini kısaltır, ekip tükenmişliğini azaltır.