Selçuk Şan
Selçuk Şan
Platform Mühendisi

Prometheus ve Alertmanager ile Alarm Yönetimi

Prometheus ve Alertmanager ile Alarm Yönetimi

İçindekiler

  1. Prometheus ile Alarm Yönetimi
  2. Alertmanager Yapılandırması ve Routing
    1. Routing (Yönlendirme)
    2. Matchers (Eşleştiriciler)
    3. Subroutes (Alt Rotalar)
    4. Continue (Devam et)
  3. Alarm Gruplama
  4. Time Intervals (Zaman Aralıkları)
  5. Receivers (Alıcılar)
  6. Inhibition Rules (Engelleme Kuralları)
  7. Alarm Yorgunluğu
  8. Sonuç
  9. Kaynakça

Prometheus ile Alarm Yönetimi

Sistemlerin sorunsuz çalışıp çalışmadığından ve kullanıcılar için beklenen hizmetin sağlandığından emin olmak için sürekli olarak manuel kontrol yapmak gerekiyorsa, bu hem yorucu hem de riskli olabilir. Bu tür senaryolar için, sistemlerin durumunu değerlendiren, doğru çalışmadıklarında uyarılar gönderen ve arka planda çalışan bir sisteme ihtiyaç vardır.

Bu blog yazısında, Prometheus’un Alerting Rule (Uyarma Kuralı) ve Alertmanager bileşeni aracılığıyla bunu nasıl başardığını ele alacağız.

Prometheus’u lokal bilgisayarınıza kurmak, yapılandırmak ve mimarisi hakkında daha detaylı bilgiler almak isterseniz sizi yazarımız Alptekin Yanık’ın konuyla ilgili yazısına yönlendirebilirim: Prometheus İzleme Aracı

Alertmanager Yapılandırması ve Routing

Prometheus’u ilk defa kullanmaya başlayan kullanıcılar arasında yaygın bir yanılgı, alarmların Slack, PagerDuty, Teams vb. platformlar gibi hedeflere ulaştırılmasından Prometheus’un sorumlu olduğu yanılgısıdır.

İkisi arasındaki ayrım biraz kafa karıştırıcı olabilir. Basitçe açıklarsak; Prometheus rule’ları sürekli bir döngü içinde değerlendirir ve bu rule’lar belirli bir süre boyunca (for) karşılandığında bunları bir veya birden fazla Alertmanager instance’ına gönderir. Bu aşamadan sonra, Alertmanager alarm bilgisinin nereye gönderileceğine (Slack, PagerDuty, Teams vb.) karar verir.

Alertmanager bunu nasıl başarıyor bakalım.

Routing (Yönlendirme)

Routing, Alertmanager’ın yaptığı işin özüdür diyebiliriz.

Bir alarmı işlerken, alarmın hangi receiver’lara (alıcı) gönderileceğini belirlemek için bir route tree yapısı takip edilir.

  • Doğru bir Alertmanager yapılandırma dosyası için gerekli olan tek şey bir route ve bir receiver’dır; diğer her şey isteğe bağlıdır.

  • Bir route, en basit haliyle, bir receiver ve bir veya daha fazla matcher’dan oluşur.

Basit ve doğru bir route örneği verecek olursak:

1
2
3
4

route:
  receiver: "default"
  matchers:
    - environment = "production"

Receiver’dan daha sonra bahsedeceğiz, şimdilik matchers’a bir bakalım.

Matchers (Eşleştiriciler)

Alertmanager’da matcher, bir alarmın label’larına (etiket) bakarak belirli koşulları kontrol eden ifadelerdir. Bir matcher, bir label’ın belirli bir değere sahip olup olmadığını ya da belirli bir koşulu sağlıyor olup olmadığını kontrol eder.

  • Matcher, gelen alarmları filtrelemek ve yönlendirmek için kullanılır.

Örneğin, belirli bir label’ın değerine göre alarmları farklı receiver’lara yönlendirebiliriz:

1
2
3
4
5
6
7
8
9

route:
  receiver: "fallthrough"
  routes:
    - receiver: "slack-devops"
      matchers:
        - team = "devops"
    - receiver: "slack-sre"
      matchers:
        - team = "sre"

Burada bir alarmın team label’ı devops ise, bu alarm “slack-devops” receiver’ına, sre ise “slack-sre” receiver’ına gönderilir. Belirlenen label’a uymayan alarmlar da “fallthrough” receiver’ına yönlendirilir.

Subroutes (Alt Rotalar)

Alertmanager, gelen tüm alarmları eşleştiren tek bir top-level route içerir (bu route bir matchers bölümüne sahip olamaz ve olmamalıdır). Diğer tüm route’lar, bu top-level route’un Subroute’dur.

Aşağıdaki örnekte top-level route ve subroutes arasındaki ilişkiyi açıklayalım:

1
2
3
4
5
6
7
8

route:
  receiver: "fallthrough"
  routes:
    - receiver: "operation"
      matchers:
        - environment = "production"
        - namespace != "default"
        - team =~ "(devops|sre)"

Top-Level Route:

Route key’inin altındaki bu bölüm top-level route’dur. Bu route, gelen tüm alarmları karşılar ve matchers bölümü içermez. Burada receiver “fallthrough” olarak tanımlanmış. Bu, top-level route’un, herhangi bir subroute’a uymayan alarmları nereye yönlendireceğini belirtir.

Subroute

Routes, top-level route’un altındaki subroute’ları tanımlar.

Bu örnekte, receiver: operation olarak verilmiştir ve çeşitli matcher’lar içerir. Bu subroute, alarmları belirli kriterlere göre yönlendirecek şekilde yapılandırılmıştır:

  • environment = “production”: Alarm “production” ortamında olmalı.

  • namespace != “default”: Alarm “default” namespace’inde olmamalı.

  • team =~ “(devops sre)”: Alarm “devops” veya “sre” takımına ait olmalı.

Bu yapı, top-level route’un tüm alarmları alıp, belirli koşulları karşılayanları subroute’a yönlendirdiği bir yapılandırma örneğidir.

Alertmanager’da her bir subroute’un kendi subroute’u olabilir; bu durum routing (yönlendirme) mantığını biraz karmaşıklaştırıyor.

Alertmanager, hangi receiver’ı kullanacağına karar verirken en spesifik route’u eşleştirmeye çalışır. Eğer bir parent route ile eşleşir ancak subroute’lardan hiçbiri ile eşleşmezse, parent route’un receiver’ını kullanmaya geri döner.

Bu durumu daha iyi anlamak için bir örnek yapalım:

1
2
3
4
5
6
7
8
9
10
11
12
13

route:
  receiver: "fallthrough"
  routes:
    - receiver: "slack-devops"
      matchers:
        - team = "devops"
      routes:
        - receiver: "pagerduty-devops"
          matchers:
            - environment = "production"
        - receiver: "teams-devops"
          matchers:
            - environment = "staging"

Top-Level Route Kontrolü:

  • Alarm önce top-level route ile kontrol edilir. Bu route receiver: “fallthrough” olarak yapılandırılmıştır, yani tüm alarmlar için geçerli olan bir fallback receiver’ıdır.

İlk Subroute:

  • Eğer alarm team = “devops” kriterini sağlıyorsa, receiver: “slack-devops” olarak belirlenir ancak bu route altında daha spesifik bir subroute daha var…

En Spesifik Subroute Kontrolü:

  • Eğer alarm team = “devops” ile eşleşiyorsa, bu route’un altındaki subroute’lar da kontrol edilir.

  • Alarm environment = “production” match kriterini sağlıyorsa, en spesifik match olarak receiver: “pagerduty-devops” kullanılır.

  • Alarm environment = “staging” match kriterini sağlıyorsa da en spesifik match olarak receiver: “teams-devops” kullanılır.

  • Alarm team = “devops” ile eşleşiyor ancak, bu route’un altındaki subroute’lar ile eşleşmiyorsa receiver parent receiver, yani “slack-devops” olarak belirlenir.

Fallback Durumu:

  • Eğer alarm team = “devops” ile eşleşmiyorsa, top-level route’un receiver’ı olan “fallthrough” kullanılır.
1
2
3
4
5
6
7
8
9
10
11
12
13

route:
  receiver: "fallthrough"
  routes:
    - receiver: "slack-devops"
      matchers:
        - team = "devops"
      routes:
        - receiver: "pagerduty-devops"
          matchers:
            - environment = "production"
        - receiver: "teams-devops"
          matchers:
            - environment = "staging"

Aşağıdaki alarmları yukarıdaki route tree’ye göre sınıflandıralım:

{environment=”production”, team=”devops”}

  • Alarm pagerduty-devops receiver’ına gönderilir çünkü hem team = “devops” hem de environment = “production” kriterlerine uyar.

{environment=”testing”, team=”devops”}

  • Alarm “slack-devops” receiver’ına gönderilir çünkü team = “devops” ile eşleşmesine rağmen daha spesifik subroute ile eşleşmez.

{environment=”production”, team=”sre”}

  • Alarm fallthrough receiver’ına gönderilir çünkü team = “devops” kriterini sağlayan subroute ile eşleşmez.

Son örneği routing tree editor ile görselleştirelim. Prometheus’un Routing Tree Editor aracı, Alertmanager yapılandırmalarını görsel olarak düzenlemenizi sağlar. Bu araç, alarm routing yapılandırmalarınızı daha kolay bir şekilde oluşturmanıza ve anlamanıza yardımcı olur.

Şekil 1’de görüldüğü üzere Routing Tree ve Match Label Set bilgilerini dolduruyoruz.


Şekil 1. Alertmanager Yapılandırma Aracı

Şekil 2'de görüldüğü üzere alarm slack-devops receiver’ına gönderilir çünkü team = devops ile eşleşmesine rağmen daha spesifik subroute ile eşleşmez.


Şekil 2. Routing Tree

Continue (Devam et)

Alertmanager’da continue: true özelliği etkinleştirildiğinde, bir alarm en spesifik subroute’u bulduktan sonra bile diğer aynı seviyedeki sibling (kardeş) route’lara da yönlendirilir.

  • Bu, alarmın birden fazla route tarafından işlenebileceği anlamına gelir.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

route:
  receiver: "fallthrough"
  routes:
    - receiver: "slack-devops"
      continue: true
      matchers:
        - team = "devops"
      routes:
        - receiver: "pagerduty-devops"
          matchers:
            - environment = "production"
    - receiver: "default"
      matchers:
        - environment = "production"
        - namespace != "default"
        - team =~ "(devops|sre)"

Alarm ve Top-Level Route:

  • Alarm önce top-level route ile kontrol edilir. Eğer bu route’un altındaki subroute’lar ile eşleşmezse, receiver: “fallthrough” kullanılır.

İlk Subroute Kontrolü:

  • Alarm team = devops ile eşleşiyorsa, bu route’un altındaki subroute’lar da kontrol edilir. Eğer environment = “production” ile de eşleşirse, alarm pagerduty-devops receiver’ına iletilir. environment = “production” ile eşleşmezse receiver: slack-devops devreye girer.

İkinci Subroute Kontrolü:

  • İlk Subroute kriterleri karşılarsa ve alarm bir receiver’a iletilirse dahi continue: true ayarı dolayısıyla diğer sibling route (default) devreye girecektir.

  • default route, belirli match kriterlerine göre alarmları yönlendirir. Eşleşme olmazsa alarm fallthrough receiverına gönderilecektir.

Örneklerle açıklayalım;

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

route:
  receiver: "fallthrough"
  routes:
    - receiver: "slack-devops"
      continue: true
      matchers:
        - team = "devops"
      routes:
        - receiver: "pagerduty-devops"
          matchers:
            - environment = "production"
    - receiver: "default"
      matchers:
        - environment = "production"
        - namespace != "default"
        - team =~ "(devops|sre)"

{environment=”production”, team=”devops”}

  • Alarm hem team = devops hem de environment = production kriterlerine uyduğu için pagerduty-devops receiver’ına gönderilir. Ek olarak continue: true olarak ayarlandığı için default subroute’u da değerlendirilir. Burada hem team = “devops” hem de environment = “production” kriterleri sağlandığı için alarm default receiverına da gönderilir.

{environment=”testing”, team=”devops”}

  • Alarm team = “devops” ile eşleşir ancak environment = “testing” kriteri karşılanmaz ve slack-devops receiver’ına (parent) gönderilir. Alarm, continue: true ayarına rağmen, default subroute’u ile eşleşmez, çünkü “environment = testing” kriterini sağlamaz. Sonuç olarak, sadece slack-devops receiver’ı alarmı alır.

{environment=”production”, team=”sre”}

  • Alarm team = “devops” kriterini karşılamaz ve diğer sibling rubroute’a(default) geçilir. Alarm burada default route’un kriterlerine uyar ve default receiver’ına atanır.


Genel olarak, continue:true ayarını kullanmak, bildirimlerin birden fazla yere gönderilmesi gereken durumlarda (örneğin, hem bir Slack mesajı hem de bir e-posta göndermek) son derece faydalı olabilir.

Alarm Gruplama

Alertmanager’ın temel özelliklerinden biri de alarmları gruplama yeteneğidir. Kimse, aynı konuya dair 100 alarmın birden gelmesini istemez. Alertmanager bu aşamada devreye girerek benzer alarmları label temelinde gruplamanızı sağlar.

Alarm gruplama, routing tree’nin herhangi bir seviyesinde gerçekleşebilir ve her bir route için farklı olabilir.

Genellikle, top-level route’da bazı varsayılan gruplamaları yapılandırmak istersiniz. Kendi group_by ayarını tanımlamayan subroute, en yakın parent’ın gruplama ayarlarını kullanacaktır.

kube-prometheus-stack ile bir Alertmanager instance’ı ayağa kaldırırsanız, varsayılan gruplamanın yalnızca namespace label’ı kullanılarak gerçekleştirildiğini görebilirsiniz. Ancak, genellikle top-level gruplamanın alert name, service ve environment gibi başka label’larla de yapılması yaygın bir kullanımdır (örneğin, “production”).

1
2
3

route:
  receiver: "fallthrough"
  group_by: ["alertname", "service", "environment"]

Bu yapılandırma ile, belirtilen üç label için aynı değerlere sahip olan alarmlar bir araya getirilecek. Ancak bu gruplamanın nasıl gerçekleştiği bazen kafa karıştırıcı olabilir, bu yüzden detaylı bir açıklama yapalım.

group_by key’ine ek olarak, her bir route içinde group_interval ve group_wait ayarları da bulunmakta.

  • group_wait: Alertmanager’ın bir alarmı receiver’a göndermeden önce ne kadar bekleyeceğini belirler. Bu bekleme süresi, ek alarmların da gruba eklenebilmesi ve nihayetinde gönderilen alarm sayısının azaltılabilmesi için zaman tanır. Varsayılan olarak, bu süre 30 saniyedir. group_wait zamanlayıcısı, bir gruptaki ilk alarm alındığında başlar ve gruba yeni bir alarm eklendiğinde sıfırlanmaz. Zamanlayıcı dolduktan sonra, alarm receiver’a gönderilir ve yeni alarmlar bir sonraki group_interval süresi dolana kadar bekletilir.

  • group_interval: Bir alarm grubuna dair güncellemelerin ne sıklıkla gönderileceğini kontrol eder. Bu, hem yeni tetiklenen hem de çözülmüş (resolved) alarmları içerir. Varsayılan olarak bu süre 5 dakikadır. Yukarıdaki group_by ayarımızla birlikte varsayılan değerlerle pratikte nasıl göründüğüne dair bir örnek olarak Tablo 1’e göz atalım:


Tablo 1. Alarm Örnekleri

Gruptaki 3. alarm, ilk alarmdan biraz daha geç, yani 35 saniye sonrasında geliyor. Bu nedenle, ilk group_wait süresini kaçırıyor ve gönderilebilmesi için ilk alarmın alındığı andan itibaren 5 dakikanın dolmasını beklemesi gerekiyor.

group_interval yalnızca grubun güncellemelerinin ne sıklıkla gönderileceğini kontrol eder ve bu, alarmları takip eden kişilere yeniden bildirim gönderilmesini sağlar. Peki, gruba yeni alarmlar eklenmediği veya alarmlar kaldırılmadığı, ancak alarmların hâlâ çözülmediği durumlarda ne olur?

Bunun için Alertmanager’da repeat_interval adında bir ayar bulunur. repeat_interval, bir alarm grubunun receiver’a ne sıklıkla yeniden gönderileceğini tanımlar ve varsayılan olarak 4 saattir. Uygulama durumlarına ve ihtiyaçlara göre bu süre biraz fazla sık olabilir ve ekiplerde alarm yorgunluğuna (Alert Fatigue) yol açabilir. Bu nedenle, bu süre esnetilebilir (Örneğin, 24 saat). Yine de bu ayarın etkin kalması önemlidir, çünkü alarmların gözden kaçmamasını ve kaybolmamasını sağlar.

Bir örnek üzerinden bu konuyu detaylandıracak olursak;

Bir e-ticaret web servisini izlediğinizi düşünelim. Hedefimiz, aynı türdeki alarmları gruplamak ve anlamlı bildirimler göndermek. Konfigürasyonumuz şu şekilde:

1
2
3
4
5
6
7
8
9
10

receivers:
- name: 'email-receiver'
  email_configs:
  - to: 'admin@example.com'
route:
  group_by: ['alertname', 'service', 'environment']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 1h
  receiver: 'email-receiver'

group_by: [‘alertname’, ‘service’, ‘environment’]

  • Bu konfigürasyon, aynı alertname, service, ve environment değerlerine sahip alarmları bir grup altında toplar. Örneğin, High HTTP Error Rate adlı alarm hem payment-service hem de production ortamında tetikleniyorsa, bu alarmlar bir grup olarak ele alınır.

group_wait: 30s

  • Alarmlar toplandıktan sonra, 30 saniye beklenir. Bu süre zarfında yeni alarmlar aynı gruba eklenir. Eğer yeni alarmlar gelmezse, grup bildirimi gönderilir.

group_interval: 5m

  • Bir grup alarm bildirildikten sonra, aynı grup için tekrar bildirim göndermeden önce 5 dakika beklenir. Örneğin, ilk alarm bildirildikten sonra, aynı grup için yeni bir bildirim 5 dakika boyunca gönderilmez.

repeat_interval: 1h

  • Aynı grup için bir bildirim gönderildikten sonra, aynı grup alarmlarının tekrar bildirileceği zaman dilimini belirtir. Örneğin, bir grup alarmı 1 saat içinde çözülmezse, bu grup tekrar bildirilir.

  • Saat 12:00 — High HTTP Error Rate alarmı payment-service ve production ortamında tetiklenir.

  • Saat 12:00:30 — 30 saniye içerisinde alınan alarmlarla ilk bildirim gönderilir, çünkü group_wait süresi tamamlanmıştır.

  • Saat 12:05 — Eğer yeni alarmlar gelirse, 5 dakika boyunca aynı gruba dahil edilir. Ancak, group_interval nedeniyle bu grup için yeni bir bildirim gönderilmez.

  • Saat 13:00 — Eğer alarmlar hala aktifse (çözümlenmemişse) ve repeat_interval süresi dolmuşsa, alarm grubu tekrar bildirilecektir.

Time Intervals (Zaman Aralıkları)

Alertmanager’a nispeten yakın bir zamanda eklenen isteğe bağlı bir özelliktir ve belirli bir route’tan hangi zaman dilimlerinde alarm almak istediğinizi tanımlamamıza olanak tanır.

Örneğin, iş saatleri içinde yalnızca warning seviyesinde alarmlar almak istiyoruz ve gece yarısı bu düzeydeki alarmlar için nöbetçi mühendisi uyandırmak istemiyoruz. Alertmanager’ın Time Intervals özellikleri ile bunu yapabiliriz.

Bunu kontrol eden iki ayar mute_time_intervals ve active_time_intervals’dır. Bu 2 ayar mutually exclusive değildir yani birlikte kullanılabilir, ancak genellikle bir route için sadece biri kullanılır. Ayrıca, Alertmanager yapılandırmasında top-level route üzerinde ayarlanamazlar.

Biri alarmları hangi zaman aralıklarında sessize alacağınızı tanımlar, diğeri ise hangi zaman aralıklarında göndereceğimizi belirler.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

route:
  receiver: "fallthrough"
  routes:
    - receiver: "slack-devops"
      continue: true
      matchers:
        - team = "devops"
        - severity = "warning"
      active_time_intervals:
        - mesai-saati
time_intervals:
  - name: mesai-saati
    time_intervals:
      - weekdays: ["Monday:Friday"]
        times:
          - start_time: 08:00
            end_time: 17:00
  • Böyle bir yapılandırma, gece saatlerinde veya tatil günlerinde gelen warning seviyesinde alarmların dikkate alınmamasını sağlar, böylece gereksiz bildirimler azaltılır ve dikkat dağılmasının önüne geçilir.

Her zaman aralığı, çeşitli ayarlar kullanarak bir veya daha fazla zaman aralığı içerebilir. Bu ayarlar arasında hafta içi günler (weekdays), ayın günleri (days_of_month), aylar (months), yıllar (years) ve günün saat/dakikaları (times) bulunur.

Tüm bu ayarlar liste şeklindedir ve önceki weekdays örneğinde olduğu gibi aralıkları belirtmek için “:” karakteri kullanılır.

1
2
3
4
5
6
7
8
9
10

time_intervals:
  - name: example
    time_intervals:
      - weekdays: ["monday:thursday", "friday"]
        days_of_month: ["1:31"]
        months: ["1:6", "july:october"]
        years: ["2024:2026", "2030"]
        times:
          - start_time: 08:00
            end_time: 17:00

Receivers (Alıcılar)

Alertmanager konfigürasyonunun en kritik kısmı routing olsa da receivers aslında Alertmanager’ın amacını gerçekleştirdiği yerdir. Sonuçta, Alertmanager’ın tüm amacı alarmları bir veya daha fazla hedefe iletmektir ve receivers tam olarak bunu yapar.

Alertmanager’da çok sayıda farklı receiver vardır ve kullanma tercihi büyük ölçüde kişisel ihtiyaçlarınıza ve/veya şirketin mevcut teknolojilerine bağlıdır. Ancak, her receiver’ın yapılandırmasının ilgili teknolojiye göre farklılık göstereceğini söylemek yeterli olacaktır. Örneğin, Slack ile Pagerduty için konfigürasyon ayarlarında çok fazla örtüşme olmayacaktır.

Tüm receiver’lar bir name ve Slack, Pagerduty ve e-posta gibi notifier’lar (bildiriciler) için bir veya daha fazla konfigürasyon alır. Bir receiver, alarm bildirimleri gönderdiği birden fazla notifier’a sahip olabilir.

Örneğin, Slack ve Pagerduty:

1
2
3
4
5
6
7
8
9

receivers:
  - name: "devops"
    slack_configs:
      - channel: "#alerts"
        api_url: "https://hooks.slack.com/services/ZZZZZZZZZZZZZZZ"
        send_resolved: true
    pagerduty_configs:
      - routing_key: "XXXXXXXXXXXXXXX"
        send_resolved: true

send_resolved: Varsayılan olarak, çoğu receiver bir alarm tetiklendiğinde ve çözümlendiğinde bildirim gönderir. Bir şeyin olduğunu bilmek yeterli ise ve çözümlendiğine dair bildirime gerek yoksa send_resolved: false ayarı yapılarak gereksiz çözüm bildirimleri engellenebilir.

Inhibition Rules (Engelleme Kuralları)

Engelleme kuralları, belirli koşullar altında bildirimlerin gönderilmesini engellemek için gereklidir. Bu, alarm yorgunluğunu en aza indirmek için önemlidir.

Alarm Yorgunluğu

Kısaca, sürekli ve fazla miktarda alarm almak sonucunda kullanıcıların bu alarmları dikkate almama eğilimidir. Özellikle Sistem Yöneticileri ve DevOps Mühendisleri, sık sık gelen ve çoğu zaman önemsiz olan alarmlar yüzünden bu durumu yaşayabilir. Bu durum, kritik alarmların gözden kaçırılmasına ve sonuç olarak önemli sorunların zamanında tespit edilmemesine neden olabilir.

Diyelim ki bir veri merkezinde birçok cluster’ınız var ve bu veri merkezinde bir ağ kesintisi yaşanıyor. Ağ kesintisinin genel bir alarmını alıyorsunuz. Ancak, bu ağ kesintisi nedeniyle tüm sunucularda bağlantı sorunları da yaşanıyor. Bu durumda, ağ kesintisini gösteren bir kritik alarm aldığınızda, aynı anda her bir sunucu için ayrı ayrı bağlantı sorunlarıyla ilgili alarmlar almak, gereksiz ve kafa karıştırıcı olacaktır. Çünkü, ağ kesintisi nedeniyle zaten tüm sunucularda bağlantı sorunları yaşanıyor ve bu durum tek bir kritik alarmla zaten kapsamlı bir şekilde iletiliyor.

Inhibition Rules, diğer alarmların çalmasını engelleyerek çalışır. Yani temelde, “Eğer Alarm-A aktifse, bana Alarm-B’yi gönderme” şeklindedirler. Örneğin:

1
2
3
4
5
6
7
8

inhibit_rules:
  - source_matchers:
      - severity="critical"
    target_matchers:
      - severity=~"warning|info"
    equal:
      - namespace
      - alertname

Engelleme kurallarında, source mevcut bir alarmı, target ise gelen bir alarmı ifade eder. Bu nedenle, yukarıdaki örnekte,

{namespace=”default”, alertname=”HighCPU”, severity=”warning”}

label’larına sahip bir hedef alarm,

{namespace=”default”, alertname=”HighCPU”, severity=”critical”}

label’larına sahip bir başka alarm tarafından engellenir. Böylece, yalnızca critical label’ına sahip alarm receiver’a gönderilir; warning seviyesindeki alarm gönderilmez.

Sonuç

Bu yazıda Prometheus ve Alertmanager kullanarak etkili alarm yönetimi için gerekli temel kavramlar ve yapılandırma yöntemleri ele alınmıştır. Alarm yönlendirme, gruplama, zaman aralıkları, engelleme kuralları ve alarm yorgunluğu gibi kritik konular detaylı şekilde incelenmiştir. Bu bilgiler, sistem yöneticilerinin ve DevOps mühendislerinin karmaşık altyapılarda alarm yönetimini optimize etmelerine yardımcı olacak değerli bir rehber sunmaktadır.

Kaynakça

  1. Alertmanager https://prometheus.io/docs/alerting/latest/alertmanager/
  2. Prometheus https://prometheus.io/docs/alerting/latest/configuration//
  3. sysdig https://sysdig.com/blog/prometheus-alertmanager/
  4. SigNoz https://signoz.io/guides/how-do-i-add-alerts-to-prometheus/

Yazımızın teknik gözden geçirmesi için Zeynep Rümeysa Yorulmaz’a, editör desteği için ise Ayşegül Özkaya Eren ile Kübra Ertürk’e teşekkür ederiz.