ElastAlert2 Kurulumu: Rule, E-posta Alert, systemd

Bir container süreci exit code 137 ile ölüyor. Kullanıcı şikayet edene kadar kimse fark etmiyor. Oysa log baştan beri Elasticsearch'teydi—logstash-* index'inde info.exitCode: "137" olarak duruyordu, okuyan yoktu. ElastAlert2 tam bu boşluğu kapatıyor: Elasticsearch'ü periyodik sorgular, eşleşme çıktığı anda alert gönderir.

Bu rehber gerçek bir projeden geliyor: öldürülen süreçleri yakalayan bir frequency rule, insan okusun diye yazılmış bir e-posta template'i ve reboot'a dayanıklı bir systemd unit'i kurduk. Aşağıdaki her şey sanitize edildi (placeholder e-posta ve host'lar), ama config'ler pseudocode değil, çalışan yapının kendisi.

Kısa cevap: ElastAlert2, Elasticsearch için açık kaynak bir alerting daemon'ıdır. Her rule dört ana bloktan oluşan bir YAML dosyasıdır: type (ne zaman tetiklenir, ör. frequency), index (nerede arar), filter (query DSL eşleşmesi) ve alert (email, Slack ve onlarcası). alert_subject ve alert_text + _args ham dokümanı okunabilir bildirime çevirir. systemd servisi olarak koşturun (WorkingDirectory=/opt/elastalert, ExecStart=/usr/bin/elastalert) ki 7/24 sorgulasın. Lisanssız, her Elasticsearch dağıtımında çalışan alerting istiyorsanız ElastAlert2; lisanslı Elastic Stack'te her şeyi UI'da isteyenler için Kibana alerting.

ElastAlert2 vs Kibana alerting: hangisi nerede

Kibana'nın kendi alerting framework'ü var; lisanslı bir Elastic Stack kullanıyorsanız makul varsayılan budur: rule'lar UI'da yaşar, connector'lar yönetilir, her şey stack ile birlikte upgrade olur. Ama bazı connector tipleri ücretli tier'ların arkasında ve bazı ekipler Kibana alerting'in hiç seçenek olmadığı dağıtımlar çalıştırıyor.

ElastAlert2, Yelp'in ElastAlert'inin topluluk tarafından sürdürülen devamı. Bağımsız bir Python daemon'ı: cluster'ın dışında koşar, belirli aralıklarla sorgu çalıştırır, kendi state'ini writeback index'lerinde tutar ve düz HTTP üzerinden Elasticsearch ile konuşur. Uçtan uca açık kaynak Elasticsearch alerting isteyenler için cazibesi burada—e-posta veya Slack için lisans kapısı yok, rule'lar git'te code review'dan geçen YAML dosyaları, ortada tamamen sizin kontrolünüzde tek bir süreç var. Bedeli: kendiniz koşturmanız, izlemeniz ve upgrade etmeniz gereken bir servis daha. Bu rehber tam da o operasyonel kısmı anlatıyor.

ElastAlert2 rule anatomisi

Projedeki rule'un sanitize edilmiş hali aşağıda. İş hedefi: herhangi bir workbench süreci exit code 137 ile öldürüldüğünde (SIGKILL—container ortamlarında neredeyse her zaman OOM kill) ekibe bir saat içinde e-posta gitsin.

# rules/workbench-exitcode-137.yaml

# (Zorunlu) Rule adı, unique olmalı
name: workbench-exitcode-137

# (Zorunlu) Rule type: frequency, timeframe içinde
# num_events eşleşme olursa tetiklenir
type: frequency

# (Zorunlu) Aranacak index, wildcard destekler
index: logstash-*

# (frequency'ye özgü) pencere içindeki ilk eşleşmede tetikle
num_events: 1
timeframe:
  hours: 1

# (Zorunlu) Elasticsearch filtreleri, AND ile birleşir
filter:
- match:
    info.exitCode: "137"

# (Zorunlu) Eşleşmede ne yapılacağı
alert:
- "email"

alert_subject: "Alert: workbench exitCode 137"

alert_text_type: alert_text_only
alert_text: "
  Bu e-posta hata detayı içerir, lütfen yanıtlamayın \n
timestamp: {0}\n
machineInfo.user: {1}\n
info.command: {2}\n
info.exitCode: {4}\n
event.original: {3}"
alert_text_args:
- timestamp
- machineInfo.user
- info.command
- event.original
- info.exitCode

email:
- "alerts@example.com"
from_addr: "noreply@example.com"

type ve index

type, rule'un ne zaman tetikleneceğini belirler. frequency + num_events: 1 + bir saatlik timeframe, "kayan bir saat içindeki ilk eşleşmede alarm" demek—pencereli bir any-match tetikleyicisi. Diğer type'lar eşikleri (num_events: 50), spike (oran ikiye katlandı), flatline (veri kesildi—her ops ekibinin eninde sonunda ihtiyaç duyduğu yokluk alert'i) ve fazlasını kapsar; tam liste ElastAlert2 rule types dokümantasyonunda. index wildcard kabul eder; logstash-* günlük index'leri bakım gerektirmeden tarar.

filter

filter, AND ile birleşen Elasticsearch query DSL parçalarının listesi. Burada info.exitCode üzerinde tek bir match yetiyor. Query DSL ile ifade edebildiğiniz her şey çalışır—term, range, query_string. Yani sorguyu önce Kibana Dev Tools'ta prototipleyip doğru dokümanları döndürdüğünde rule'a yapıştırabilirsiniz.

alert

alert bir liste; tek rule birden fazla kanala bildirim atabilir. E-posta klasik; Slack iki satırlık değişiklik:

alert:
  - slack
slack_webhook_url: "<webhook_url>"

Alert text şablonları: subject, from, to

ElastAlert2 varsayılan olarak e-posta gövdesini rule_name + [alert_text] + ruletype_text + {top_counts} + {field_values} şeklinde kurar—eksiksiz ama gürültülü. Üç ayar bunu evcilleştirir:

• alert_text + alert_text_args: doküman alanlarından doldurulan {0}, {1}, ... placeholder'lı template. Yukarıdaki rule'da args sırası ile placeholder sırası farklı ({4} = info.exitCode)—index, alert_text_args içindeki pozisyonu gösterir; eşlemeyi dürüst tutun.
• alert_text_type: alert_text_only otomatik üretilen kuyruğu atar; alıcı yalnızca sizin template'inizi görür. exclude_fields orta yol: count'ları tutar, ham alan dökümünü atar.
• alert_subject + alert_subject_args konu satırını aynı mantıkla şablonlar, ör. alert_subject: "High response time at {0}" + - "@timestamp".

Gönderim ayarları rule içinde veya global config.yaml'da durabilir:

email:
- "alerts@example.com"
- "oncall@example.com"
from_addr: "noreply@example.com"
smtp_host: "smtp.example.com"
smtp_port: 25
smtp_ssl: true
smtp_auth_file: "/opt/elastalert/smtp_auth_file.yaml"

SMTP kimlik bilgilerini rule dosyasına değil smtp_auth_file'a koyun—rule'lar git'e girer, credential girmez.

ElastAlert2'yi systemd servisi olarak çalıştırmak

elastalert'i tmux'ta koşturmak, alerting'in bir sonraki reboot'ta sessizce ölmesinin en garantili yolu. Çözüm minimal bir systemd unit—birebir kullandığımız şekil:

# /lib/systemd/system/elastalert.service
[Unit]
Description=elastalert
After=multi-user.target

[Service]
Type=simple
WorkingDirectory=/opt/elastalert
ExecStart=/usr/bin/elastalert

[Install]
WantedBy=multi-user.target

Sonra link, reload, enable, start:

ln -s /lib/systemd/system/elastalert.service /etc/systemd/system/elastalert.service
systemctl daemon-reload
systemctl enable elastalert.service
systemctl start elastalert.service
systemctl status elastalert.service

WorkingDirectory kritik: ElastAlert2, config.yaml ve rules/ klasörünü ona göre çözer. ExecStart'ı kendi kurulum yolunuza uyarlayın (virtualenv binary'si veya python -m elastalert.elastalert) ve daemon çökerse kendi kendine kalksın diye Restart=on-failure eklemeyi düşünün. O noktadan sonra alerting log'unuz journalctl -u elastalert -f olur.

Alert'ten önce: alanın var olduğundan emin olun

ElastAlert2 filtresi yalnızca var olan alanları eşleştirebilir. info.exitCode sorgulanabilirdi çünkü ingest aşaması onu ham satırdan önceden parse etmişti. Loglarınız hâlâ tek parça bir message string'i ise önce onu düzeltin—Kibana Dev Tools'taki Grok Debugger tam bunun için var: örnek satırı yapıştırın, %{COMMONAPACHELOG} gibi bir pattern deneyin ve satırın response, clientip, verb, timestamp alanlarına ayrıldığını görün. Önce yapılandırılmış alanlar, sonra alert'ler. Cluster'ınızın alerting yükü altında ne yaptığından emin değilseniz, sürekli monitoring bunu kullanıcılarınızdan önce söyler.

Öğrendiklerimiz

1. Rule başına dört blok: type, index, filter, alert. Bunları oturtunca her ElastAlert2 rule'u aynı şekilde okunur.
2. frequency + num_events: 1 en basit işe yarar tetikleyici—pencere içindeki ilk eşleşmede alarm.
3. alert_text_type: alert_text_only + alert_text_args, ham JSON'u insanın aksiyon alacağı e-postaya çevirir.
4. Placeholder sırası ≠ args sırası. {4}, alert_text_args'ın beşinci elemanını gösterir—eşlemeyi iki kez kontrol edin.
5. tmux değil systemd. 12 satırlık unit + systemctl enable, alerting ile temenni arasındaki fark.
6. Önce parse, sonra alert. Alanları Grok Debugger ile doğrulayın; olmayan alana yazılmış filter sessizce hiç tetiklenmez.

Yukarıda performans veya hacim metriği yok, çünkü kaynak pakette yok—bu rehber uydurma yüzdeler değil, config iddia eder.

Müşteri fark etmeden önce birilerini uyandıran alerting mi lazım? → searchali.com

Sık Sorulan Sorular

ElastAlert2 ücretsiz mi?

Evet. ElastAlert2 açık kaynaktır (Apache-2.0) ve her Elasticsearch veya OpenSearch cluster'ına karşı çalışır. E-posta, Slack ve diğer alerter'lar lisans ücreti taşımaz—bazı Kibana tier'larındaki lisans kapılı connector'lara karşı ana avantajı budur.

ElastAlert2 sorgularını ne sıklıkla çalıştırır?

config.yaml'daki global run_every ayarı sorgulama aralığını, buffer_time her sorgunun ne kadar geriye bakacağını belirler. frequency gibi rule type'ları dönen event'lerin üstüne kendi timeframe pencerelerini uygular.

Tek rule hem e-posta hem Slack'e gönderebilir mi?

Evet. alert bir liste—aynı rule'a email ve slack'i birlikte koyun; her biri kendi ayarlarını taşır (email/from_addr/smtp_host ve slack_webhook_url). Şablonlanan alert_subject ve alert_text alerter'lar arasında ortak kullanılır.

Rule Kibana'da eşleşiyor ama alert gelmiyor, neden?

Sırasıyla klasik şüpheliler: alan index'e filtrenin beklediği şekilde parse edilmemiş (Discover'a değil, Dev Tools sorgusuna güvenin), timeframe/run_every kombinasyonu henüz dolmadı, ya da önceki eşleşme realert bastırması içinde. --verbose ve elastalert_status writeback index'i her koşunun gerçekte neyi sorgulayıp neyi eşleştirdiğini gösterir.