Alert sistemini standartlaştırmak ve IaC ile işletmek
(engineering.ab180.co)Giriş
Hizmet büyüdükçe, operasyon sırasında izlenmesi gereken sinyaller de birlikte arttı. Bu yazıda Alert’leri kodla yönetme ve Slack ile PagerDuty’ye uzanan müdahale akışını standartlaştırma sürecini anlatıyoruz.
İlk hedef basitti. Alert’leri daha kolay oluşturmak, daha okunaklı göndermek ve kimin bakması gerektiğini netleştirmek. Sonrasında operasyonu sürdürürken grouped Alert, tekrar eden tanımlar, müdahale otomasyonu ve izleme sisteminin kararlılığı gibi konuları da birlikte iyileştirdik.
Motivasyon
Hizmetin erişilebilirliğini artırıp kullanıcı etkisini azaltmanın birçok yolu vardır.
Bu çalışmada odak, bunların arasında Alert sistemini iyileştirmek oldu.
Alert, arıza önleme ile arıza müdahalesi arasında köprü kuran bir operasyon arayüzüne daha yakındır. Risk sinyalleri daha erken fark edilirse gerçek bir arızaya dönüşmeden önce aksiyon alınabilir; arıza meydana geldikten sonra da sorumlu kişiler durumu daha hızlı fark edip müdahaleye başlayabilir.
O dönemde iyileştirmek istediğimiz yön de açıktı. Risk sinyallerini daha iyi yakalamak, sorumluların daha hızlı fark etmesini sağlamak, inceleme ve müdahaleye doğrudan bağlamak ve tekrarlanan müdahale akışlarını azaltmak istiyorduk.
Her şeye en baştan nicel ölçümlerle başlamamış olsak da, Alert’in yalnızca bir bildirim değil, arızaları önleyen ve müdahaleye bağlanan bir operasyon sistemi olması gerektiği yönündeki problem tanımı nettı.
Alert’in rolü
Kararlı bir hizmet için arızaları önlemek önemli olduğu gibi, çalışan hizmetteki anormallik işaretlerini hızlı tespit etmek de önemlidir.
Alert bu noktada iki rol üstlenir. Arıza meydana gelmeden önce risk sinyallerini hızlı fark etmeye ve gerçek bir arızaya dönüşmeden önlem almaya yardımcı olur; arıza meydana geldikten sonra ise sorumlu kişilere problemi bildirir ve durumu anlamak için gerekli context ile Runbook, Dashboard, Log, Silence gibi sonraki aksiyonlara bağlar.
Yani Alert, sadece "bir sorun oluştu" diyen bir bildirim değil, arıza önleme ile müdahaleyi birbirine bağlayan bir operasyon arayüzüne daha yakındır.
Mevcut Alert’lerde eksik kalan noktalar
Mevcut Alert’lerde öne çıkan üç temel eksik vardı. Oluşturmak zordu, gelse bile hemen anlamak zordu ve kimin müdahale edip yöneteceği net değildi.
Alert oluşturmak zor
O dönemde Alert oluşturma ve iletme sürecinde Grafana, Slack, PagerDuty, CloudWatch, EventBridge, Lambda gibi birçok sistem iç içeydi; veri kaynakları da NewRelic, VictoriaMetrics, Steampipe, OpenSearch, Druid, MySQL gibi oldukça çeşitlilik gösteriyordu.
Her Alert için çalışma yöntemi de farklıydı. Bazı Alert’ler Grafana’dan doğrudan Slack’e gidiyordu, bazıları CloudWatch Alarm arkasına Lambda bağlıyordu, bazıları AWS kaynak durumunu Steampipe ile sorgulayıp karar veriyordu; PagerDuty entegrasyonu gereken durumlarda ise ayrıca yapılandırma düşünmek gerekiyordu.
Sorun, organizasyon genelinde yeterli konvansiyonun olmamasıydı. Hangi Alert’in nerede yönetileceği, yalnızca Slack’e mi gönderileceği yoksa PagerDuty’ye de mi bağlanacağı, mesajda hangi açıklama ve bağlantıların yer alacağı, sorumlu ekip ile iletim yolunun nerede yönetileceği gibi konular yeterince net değildi.
Sonuç olarak Alert’ler ihtiyaç oldukça oluşturuldu, ancak zaman geçtikçe oluşturma ve yönetim biçimleri giderek daha da parçalı hale geldi.
Alert’leri okumak zor
Bir Alert oluşturulmuş olması, gerçek Slack mesajının her zaman iyi görünen bir biçimde geleceği anlamına gelmiyordu. Mesaj formatı ve bilgi kalitesi, onu oluşturan kişiye ve sisteme göre değişiyordu; bazı Alert’lerde başlık uzun ve karmaşıktı, Value ya da Labels gibi iç değerler olduğu gibi görünüyordu.
Bağlantı olsa bile önce neye bakılması gerektiğinin net olmadığı durumlar vardı; Dashboard ya da Log düğmeleri olsa da gerçekte entegrasyon çalışmayan örnekler de oluyordu. Ayrıca Alert’in context’i yetersiz olduğundan, sorumlu kişinin hizmeti, cluster’ı, kaynağı ve zaman aralığını yeniden araması gereken durumlar da sık yaşanıyordu.
Arıza anlarında birkaç dakikalık fark bile çok büyük hissedilir. Bu yüzden Alert gelir gelmez bunun ne tür bir problem olduğu, ne kadar önemli olduğu, hangi hizmet ve kaynağı etkilediği, önce nereye bakılması gerektiği ve bir sonraki aksiyonun ne olduğu hemen anlaşılabilmeliydi.
Alert için müdahale sorumluluğunu yönetmek zor
Bir Alert çaldığında kimin kontrol edip müdahale etmesi gerektiği de bazen belirsizdi. Sorumlu ekip ya da kişi görünür değilse, Alert’i gören kişi önce "Buna benim mi bakmam gerekiyor?", "Kime sormalıyım?" diye karar vermek zorunda kalıyor; arıza anlarında bu kısa karar süresi bile müdahaleyi geciktirebiliyordu.
Ayrıca yalnızca Alert çaldıktan sonraki müdahale sorumluluğu değil, Alert’in kendisinin sahibi ve yöneticisinin kim olduğu da önemliydi. Hangi ekibin hizmetiyle ilgili olduğu, koşulları kimin değiştirebileceği, mesaj ve eşiklerin nasıl gözden geçirileceği, eski Alert’leri kimin temizleyeceği gibi konuların da görünür olması gerekiyordu.
Özetle iyileştirmek istediğimiz durum şuydu:
- Alert oluşturma ve yönetme biçimi parçalıydı
- Alert gelse bile ne anlama geldiğini bir bakışta anlamak zordu
- Alert çaldığında kimin kontrol edip müdahale edeceği belirsizdi
- Alert’in kendisine hangi ekibin sahip olup yöneteceği de net değildi
Neyi nasıl iyileştirdik?
İyileştirme yönü üç başlıktaydı. Alert oluşturma biçimini standartlaştırmak, Slack mesajlarında gerekli bilgiyi tutarlı bir yapıyla sunmak ve her Alert’te sorumlu kişi ile iletim yolunun görünür olacağı bir yapı kurmak.
Alert oluşturma ve yönetim biçimini standartlaştırmak
Önce Alert oluşturma ve yönetim yöntemini tek bir yapıda topladık. Alert rule değerlendirme ve yürütmeyi Grafana’da birleştirdik; Grafana, Slack ve PagerDuty arasındaki entegrasyonu Terraform Module ile soyutladık; tüm Alert tanımlarını da şirket içi alerts reposundaki alerts/ dizini altında IaC olarak yönetilir hale getirdik. Slack kanal bağlantısı, PagerDuty entegrasyonu, mesaj formatı ve ortak düğmelerin oluşturulması da ortak modül tarafından ele alınacak şekilde düzenlendi.
Böylece Alert yazan kişiler, tüm Alert pipeline’ını baştan sona anlamaya çalışmak yerine hangi koşulu algılamak istediklerine, Alert’in ne kadar kritik olduğuna, kimin kontrol etmesi gerektiğine ve müdahale için hangi bilgilerin gerektiğine daha fazla odaklanabilir hale geldi.
Repo içinde yazım biçimi, dizin yapısı, gerekli alanlar ve önerilen konvansiyonlar da birlikte yönetildi; Alert’leri kod olarak yönetince review ve değişiklik geçmişi de PR ve commit bazında kaydedilmeye başladı.
Alert dizin yapısı
Tüm Alert’ler {main-category}/{sub-category}/{severity}/{alert-name}.yml yapısını izleyecek şekilde düzenlendi.
Örneğin:
infra/kubernetes/critical/pod-unhealthy.ymldata/airflow/warning/task-failed.ymlfinops/aws/warning/cost-increase.yml
Bu yapı sayesinde yalnızca dosya konumuna bakarak bile hangi alana ait bir Alert olduğu ve hangi ciddiyet seviyesinde ele alındığı anlaşılabiliyordu; ayrıca belirli bir alandaki Alert’leri topluca görmek, yinelenen ya da eski Alert’leri gözden geçirmek ve Slack kanalı, PagerDuty Service, CODEOWNERS bağlantılarını kurmak için de kullanılabiliyordu.
Alert tanımlama biçimi
Her Alert dosyasına datasource, query, threshold, condition, message gibi bilgiler birlikte eklendi.
Ayrı bir DSL tasarlamadık. Yapı, Grafana Alert’in JSON olarak serileştirilmiş içeriğinin YAML ile ifade edilmesine yakındı; bu sayede Grafana’da tanımlanabilen çoğu Alert, benzer bir yapıyla IaC haline getirilebildi.
Son dönemde LLM de kullanıyoruz. Kişi doğal dille "hangi koşulda nasıl bir mesajla Alert almak istediğini" anlattığında, LLM mevcut örnekleri ve konvansiyonları referans alarak YAML biçiminde bir Alert tanımı taslağı oluşturuyor. Böylece Alert yazan kişiler, karmaşık serileştirme biçimlerinden çok neyi algılamak istediklerine ve bunun neden gerekli olduğuna odaklanabiliyor.
Alert mesajlarını hemen anlayıp müdahale edilebilir hale getirmek
Alert mesajını da bir arayüz olarak gördük. Arıza anlarında mesajı yavaş yavaş çözümlemeye pek vakit olmadığından, hangi Alert gelirse gelsin aynı konumlarda aynı tür bilgilerin görülebilmesi gerekiyordu.
Bu yüzden Slack mesajı yapısını tutarlı olacak şekilde düzenledik. Başlığa Alert adı, durumu ve önem derecesini koyduk; gövdeye ise insanların hemen anlayabileceği açıklamayı, sorumlu kişiyi, ekibi, servisi, region’ı, kaynak adını ve temel label’ları ekledik. Butonları da ortak butonlar ve seçmeli butonlar olarak ayırdık; varsayılan olarak IaC, PagerDuty, Silence sunup yalnızca gerektiğinde Runbook, Dashboard, Log göstermesini sağladık
Ortak butonlar sistem tarafından otomatik oluşturulup bağlanacak şekilde yaptık ve Alert durum değişikliklerinin tamamının Slack thread’ine kaydedilmesini sağladık. Kimin Acknowledge ettiğinden, işlemin Slack’ten mi PagerDuty’den mi yapıldığına, ne zaman Resolve edildiğine ve müdahale sırasında hangi notların bırakıldığına kadar her şeyi tek bir akışta görebilir hale getirdik
Sonuç olarak kim hangi Alert’ı oluşturursa oluştursun Slack’te görünen biçim benzer hale geldi ve ekip üyeleri nereye bakmaları gerektiğine daha hızlı karar verebilir oldu
Alert sorumluluk yapısını netleştirmek
Bir Alert’ı görür görmez anlayabilmek kadar önemli olan bir diğer şey de, o Alert’ı kimin sahiplenip kontrol etmesi gerektiğinin görünür olmasıydı
Bu yüzden kaynakların tag ve label bilgilerini müdahale akışında kullandık. Her Alert için sorumlu ekip ya da kişiyi doğrudan belirtmek yerine, servis, ekip, kaynak ve ortam gibi metadata’yı kullanarak Slack mesajında uygun sorumlu ekip ve kişinin otomatik olarak mention edilmesini sağladık
Yönlendirme yolunu da aynı kurallar içinde düzenledik. Alert sınıflandırması ve severity temelinde Slack kanalı, PagerDuty Service ve Escalation Policy’nin otomatik bağlanmasını sağladık; Warning seviyesindeki Alert’ları yalnızca Slack kanalına iletirken, kullanıcı etkisi veya arıza ihtimali yüksek olan Critical Alert’ların PagerDuty Incident da oluşturmasını sağladık
CODEOWNERS’ı da birlikte kullandık. Alert dosyalarını kategori ve servis alanına göre dizinlere ayırdık, her yol için sorumlu ekipleri CODEOWNERS içinde tanımlayarak hangi ekibin hangi Alert alanına sahip olduğunu repo içinde görünür hale getirdik
Sonuçta Alert sorumluluğu iki noktada yönetilir hale geldi. Alert gerçekten tetiklendiğinde tag ve label tabanlı olarak sorumlu ekip ve kişi mention ediliyor, Alert tanımı değiştirilirken ise dizin yapısı ve CODEOWNERS temelinde bunun hangi ekibin alanı olduğu doğrulanıyor
Alert proxy’nin rolü
Bu yapının gerçekten çalışabilmesi için ortada Alert’ı yorumlayıp ileten bir katmana ihtiyaç vardı. Bu nedenle Grafana ile Slack ve PagerDuty arasına AWS Lambda tabanlı bir proxy koyduk
Grafana Alert rule’ları değerlendirip webhook gönderiyor. Proxy bu webhook’u alıp category, severity, label, annotation ve fingerprint gibi Alert context’ini yorumluyor; hangi Slack kanalına gönderileceğine, hangi PagerDuty Incident’ın oluşturulacağına, kimin mention edileceğine, hangi butonların ekleneceğine, mevcut Slack thread’inin nasıl güncelleneceğine ve Ack/Resolve lifecycle’ının nasıl yönetileceğine karar veriyor
Yani Terraform module ve dizin yapısı "Alert nasıl tanımlanacak" kısmını standartlaştırdıysa, proxy de bu tanımın gerçek operasyon akışında aynı şekilde görünmesini ve çalışmasını sağlayan bağlantı rolünü üstlenmiş oldu
Proxy sayesinde Slack mesaj formatı, sorumlu mention’ları, PagerDuty entegrasyonu, Slack thread güncellemeleri ve Ack/Resolve etkileşimleri tek bir yerde tutarlı biçimde yönetilebildi; sonrasında grouped Alert, custom action button, yapay zeka ajanı entegrasyonu ve ortak Alert model gibi iyileştirmeleri de daha kolay genişletebildik
Başka neler eksik kalmıştı?
İlk iyileştirmenin ardından Alert tanımları IaC ile yönetilir hale geldi, Slack mesajları ve iletim yolları da tutarlı kurallar altında çalışmaya başladı. Ancak Alert sistemi bir kez kurup biten bir araç değildi. Yaklaşık 1 yıl işletince, Alert sayısı arttıkça aynı Alert içindeki birden fazla instance’ın nasıl gösterileceği, tekrarlayan Alert tanımlarının nasıl yönetileceği, insanların Alert’ı gördükten sonra gerçekte ne yapabilir hale getirileceği ve Alert sisteminin kendi kararlılığının nasıl güvenceye alınıp doğrulanacağı gibi yeni sorunlar görünmeye başladı
Aynı Alert birden fazla hedefte aynı anda tetiklenince görmek zorlaşıyor
Alert oluşturmak kolaylaştıkça Alert sayısı da doğal olarak arttı. Bu sırada özellikle rahatsız eden şeylerden biri, tek bir Alert rule’un birden fazla hedef için aynı anda tetiklenmesiydi
Grafana’da aynı rule olsa bile region, name, node, pod, app gibi label değerleri farklıysa bunların her biri ayrı bir Alert instance olarak görülür. Örneğin bir Pod unhealthy Alert’ı varsa, birden fazla pod aynı anda unhealthy duruma geçtiğinde her pod için bir Alert instance oluşur
Grafana’da zaten Alert Grouping özelliği vardı ama sadece group halinde toplamak yeterli değildi. Önemli olan, gruplanmış Alert’ların durumunu operatörün kolayca anlayabileceği şekilde göstermekti; group içinde hangi hedeflerin bulunduğu, hangilerinin hâlâ firing olduğu, hangilerinin az önce resolve edildiği, yeni eklenen hedef olup olmadığı ve aynı group’un durum değişimlerinin tek bir akış olarak devam edip etmediği önemliydi
Tekrarlayan Alert tanımları artıyor
Alert tanımları arttıkça YAML’ı kopyalayıp küçük değişiklikler yapma yöntemi de sınırlarına ulaştı. SQS lag, CloudWatch error log, Pod OOM, ALB 5xx, Lambda error/throttle gibi Alert’lar tekrar tekrar oluşturuluyordu; başta mevcut dosyayı kopyalayıp ad, query, threshold ve label’ı değiştirmek yeterliydi
Ama dosya sayısı arttıkça ortak davranışları düzeltmek zorlaştı ve aynı amacı taşıyan Alert’larda bile dashboard linki, labels yapısı ve threshold ifadesi küçük küçük farklılaşmaya başladı. Bu yüzden tekrarlayan kalıpların yeniden kullanılabileceği bir yapıya ihtiyaç vardı
Alert’ı gördükten sonra bile bir sonraki adıma mesafe var
Slack mesajlarına Runbook, Dashboard, IaC ve PagerDuty butonları eklemek yardımcı oldu ama gerçek arıza müdahalesinde yalnızca linkler çoğu zaman yeterli değildi. Özellikle Runbook’un faydası açıktı, ancak her Alert’a iyi bir Runbook bağlamak ve bunu sürekli güncel tutmak kolay değildi
Ayrıca gerçek müdahalede Kubernetes log kontrolü, pod durumu kontrolü, rollout history kontrolü, SQS ve Lambda metriklerinin incelenmesi, error log kontrolü gibi benzer araştırma işleri sürekli tekrarlanıyordu. Bu işlemlerin çoğu Slack mesajının dışında yapılıyordu; sorumlu kişi Alert içindeki label ve value’ları okuyup başka araçlara gidiyor, değerleri taşıyor ve sonra sonucu yeniden Slack thread’inde paylaşıyordu
Sonuçta ilk iyileştirme sayesinde Alert’ları daha iyi okunur hale getirdik, ama inceleme ve müdahale hâlâ büyük ölçüde Alert mesajının dışında kalıyordu
İzleme sisteminde SPOF sayısı artıyor
Alert sistemini düzenlerken SPOF olabilecek noktaların sayısı da arttı. Alert rule tanımı ve dağıtımı alerts reposu ile Terraform’da toplandı, Alert rule değerlendirmesini Grafana üstlendi, Slack mesajları, PagerDuty Incident’ları ve Ack/Resolve lifecycle’ı ise proxy yönetmeye başladı
Rollerin netleşmesi olumlu bir değişimdi ama bu noktalar başarısız olduğunda tüm Alert akışının etkilenme ihtimali de büyüdü. Daha zor olan ise bu tür başarısızlıkların dışarıdan kolay fark edilmeyebilmesiydi. Başka sistemlerdeki anormallikleri bildirmesi gereken yol sessizce durursa, gerçek bir arıza yaşansa bile kimse fark etmeyebilirdi
Sonuçta bu durum "İzleme sistemini kim izleyecek?" sorusuna çıkıyordu
İkinci iyileştirme
İlk iyileştirmeyle Alert sisteminin temel iskeleti kurulmuştu, ancak Alert oluşturup göndermek kolaylaştıkça işletim sırasında bakılması gereken sorunlar da değişti
İkinci iyileştirmede dört noktaya odaklandık. Aynı Alert rule’dan birden fazla hedef aynı anda tetiklendiğinde durum değişikliklerini tek bir yerde toplayıp bir bakışta göstermek, tekrarlayan Alert tanımlarını ortak kalıplar olarak yeniden kullanılabilir hale getirmek, Runbook’u tamamlayıp tekrarlayan inceleme işleriyle sınırlı hafifletme işlemlerini Slack butonlarına bağlamak ve SPOF olabilecek Alert tanımı, değerlendirme ve iletim yollarının kararlılığını ölçüp doğrulamak
Grouped Alert’ı doğru şekilde ele almak
Önce grouped Alert’in ifade biçimi iyileştirildi. Aynı Alert rule içinde birden fazla instance aynı anda tetiklendiğinde her birini bağımsız mesaj olarak göndermek Slack kanalını karmaşıklaştırıyor, tersine yalnızca tek bir group altında toplandığında ise gerçekte hangi kaynağın sorunlu olduğu kolayca gözden kaçabiliyor.
Buradaki kilit nokta gruplamak ama grup içindeki durumu kaybetmemek oldu. Slack’te grouped Alert tek bir temsilci mesaj olarak gösterilirken o anda etkilenen hedefler de birlikte gösterilecek şekilde düzenlendi; yeni bir hedef eklendiğinde veya mevcut bir hedef düzeldiğinde bu değişiklikler aynı thread içinde bırakılacak şekilde kurgulandı. Aynı anda çok sayıda durum değişikliği olduğunda, birden fazla değişiklik batch halinde gösterilecek şekilde yapıldı; PagerDuty tarafı da Slack’te görülen grouped Alert ile aynı sorunu işaret edecek biçimde uyarlandı.
Bunun sonucunda, aynı kök nedenden çıkan birden fazla Alert Slack’te tek bir akış olarak görülebilir hale geldi.
Tekrarlanan Alert tanımlarını azaltmak
Kopyalayıp küçük değişiklikler yapma yöntemi, Alert sayısı arttıkça bakım maliyetini ve hata olasılığını büyütüyor. Bunu azaltmak için global/templates ve matrix eklendi.
global/templates, tekrarlanan Alert yapısını ortak bir template olarak tanımlama işlevi; matrix ise aynı Alert’i birden fazla region, queue, datasource ve service kombinasyonuna açarak birden çok Alert üretme işlevi görüyor.
SQS queue lag, CloudWatch error log, birden çok cluster’daki Pod OOM, ALB 5xx, Lambda error/throttle, ECS memory/CPU/max-capacity gibi tekrar eden desenler template haline getirildi; queue adı, region, cluster, threshold ve dashboard değişkenleri gibi farklılaşan değerlerin ise yalnızca matrix’e girilmesi sağlandı.
Böylece ortak mesaj yapısı, butonlar, Runbook/dashboard linklerinin işlenişi ve datasource işleme yöntemi tek bir yerden düzeltilebilir hale geldi; Alert sayısı arttıkça ortaya çıkan tutarsızlıklar ve bakım maliyeti de azaltılmış oldu.
Slack mesajından doğrudan müdahaleye başlamak
Bir sonraki adım, Slack mesajı içinden yapılabilecek işleri artırmak oldu. Runbook ve dashboard bağlantıları hâlâ önemli, ancak her seferinde benzer biçimde tekrarlanan sorguları veya sınırlı hafifletme işlemlerini Slack mesajının içinden azaltmak istendi.
Bu yüzden mevcut butonlara ek olarak custom action button eklendi. Alert YAML içindeki message.actions alanında komut tanımlanırsa, bunlar Slack mesajında buton olarak gösteriliyor; butona basıldığında proxy komutu ayrı bir Lambda invocation ile çalıştırıyor, ardından kimin hangi butona bastığını ve çalıştırma sonucunu aynı Slack thread’ine yorum olarak bırakıyor.
Bu butonlar sayesinde log sorgulama, Kubernetes rollout durumunu kontrol etme, sınırlı durumlarda rollout restart, tek komut çalıştırma ve birden fazla komutu sıralı şekilde yürütme gibi işler sunulabilir hale geldi.
En çok önem verilen kısım güvenlik oldu. Buton adı ! ile bitiyorsa Slack confirm dialog gösteriliyor; ${labels.namespace}, ${labels.pod} gibi label değerleri komuta yerleştirilirken shell quoting uygulanarak command injection engelleniyor; ek yetki gereken işler için de actionRole üzerinden IAM role assume edilmesi sağlanıyor. İzin verilmeyen role kullanımı fail-closed olarak işleniyor; webhook ve Slack etkileşimleri de sırasıyla Bearer token, HMAC-SHA256 imzası ve replay protection ile doğrulanıyor.
Yapay zeka ajanıyla entegre etmek
Alert geldikten sonra gerekli bilgileri toplama sürecini de azaltmak istendi. Bu nedenle kurum içi yapay zeka ajanı abot, Alert akışına bağlandı.
Slack mesajındaki abot butonuna basıldığında proxy; Alert adı, açıklama, labels, values, IaC bağlantısı ve kullanıcının modal içinde ek olarak girdiği context bilgisini toplayıp analiz isteği gönderiyor. abot’un, butona basan kişinin OAuth tabanlı kimliğiyle çalışması sağlandı; böylece Grafana, AWS ve Kubernetes gibi sistemlerden gerekli bilgileri sorgulasa bile bunları yalnızca kullanıcının gerçekten görebileceği kapsam içinde getiriyor.
Analiz sonucu aynı Slack thread’ine yorum olarak bırakılıyor. Hangi metrik ve logların kontrol edildiği, önce hangi olasılıkların şüpheli görülebileceği ve RCA’da derlenmeye değer hangi ipuçlarının bulunduğu da birlikte yazılıyor; bu sayede farklı sistemleri açıp bilgiyi yeniden toplamak için harcanan zaman azaltılabildi.
İzleme sistemini izlemek
İkinci iyileştirmede, Alert’i tanımlama, değerlendirme ve iletme sürecinin kendisi de gözlem kapsamına alındı.
Önce proxy’nin operasyonel metrikleri toplandı. Ack’e kadar geçen süre, Resolve’a kadar geçen süre, şu anda açık olan Alert sayısı, Alert’lerin ne kadar süredir açık kaldığı ve aynı Alert’in kaç kez yeniden çaldığı gibi metrikler toplandı; Lambda timeout’a yaklaşırsa bunu algılayan bir watchdog da eklendi. proxy işlem sırasında başarısız olursa, full stack trace ve orijinal event payload birlikte kaydedilecek şekilde düzenlendi.
Ancak proxy’nin doğrudan bildirim yapma yönteminin sınırları vardı. Çünkü proxy bu bildirimi bile göndermeden önce ölürse, gönderilmesi gereken Alert olduğu gibi atlanabilir.
Bu yüzden proxy’nin dışında, farklı sistemlere dayanan algılama mekanizmaları kondu. Bunlardan biri Grafana oldu; proxy’nin gönderdiği metric’ler, monitoring domain’indeki Alert’lerle değerlendirilerek anormalliklerin görünür olması sağlandı. Ancak Grafana ve VictoriaMetrics aynı EKS üzerinde bulunduğu için, EKS veya Grafana tamamen çökerse bunu algılamak mümkün değil.
Diğeri ise deadman switch oldu. Grafana normal çalışırken /api/health endpoint’ini heartbeat olarak gönderiyor ve bu heartbeat’i EKS’ten bağımsız CloudWatch alıyor. CloudWatch alarm, heartbeat kesildiğinde veya missing olduğunda bunu arıza olarak değerlendiriyor; bu durumda Grafana ya da proxy üzerinden geçmeden doğrudan PagerDuty ve Slack’e bildirim gönderiyor.
Böylece algılayan taraf ile algılanan taraf farklı altyapılara yerleştirilmiş oldu ve bunun sayesinde EKS ile CloudWatch aynı anda çökmediği sürece izleme sisteminin devre dışı kaldığı anlaşılabilir hale geldi.
Sonraki iyileştirme konuları
İkinci iyileştirme tamamlandı, ancak hâlâ geliştirilmesi gereken noktalar var.
Toplanan operasyonel metrikleri doğru kullanmak
proxy Alert operasyonel metriklerini toplarken, hangi kanalda hangi Alert’in ne kadar sık çaldığı, belirli bir sorumluya ya da ekibe Alert’lerin aşırı yüklenip yüklenmediği ve hiçbir etkileşim olmadan yalnızca firing ile auto resolve’un tekrarlandığı Alert’ler olup olmadığı gibi sorular artık veriye dayalı olarak yanıtlanabilir hale geldi.
Ancak veriyi görebilmekle, buna dayanarak gerçek Alert iyileştirmesi yapmak ayrı şeyler. Şimdilik threshold ayarı, benzer Alert’leri gruplama, gereksiz Alert’leri kaldırma, noisy alert’leri azaltma ve fark etme süresiyle çözüm süresini gerçekten düşürmeye yönelik iyileştirmeler ciddi biçimde ele alınabilmiş değil.
Alert IaC iyileştirmesi
Şu anda Alert tanımları alerts deposundan CI/CD ile dağıtılıyor, ancak hâlâ Grafana Terraform provider içindeki grafana_rule_group kaynağına bağımlı. Sorun şu ki yalnızca tek bir rule değişse bile PR’da sanki rule group’un tamamı değişmiş gibi görünüyor ve diff’i okumak zorlaşıyor; ayrıca interval_seconds rule group düzeyinde olduğu için her Alert’e farklı değerlendirme aralığı vermek adına group’ları çok küçük parçalara bölmek gerekiyor.
Yakın zamanda Grafana’ya, Alert rule’ları Kubernetes kaynakları gibi ele alan yeni bir alerting API eklendi ve Terraform provider’a da grafana_apps_rules_alertrule_v0alpha1 kaynağı geldi. Henüz alpha olduğu için hemen devreye alınmıyor, ancak stable hale geldiğinde mevcut grafana_rule_group yerine buna geçilmesi değerlendirilecek.
Beklenen kazanımlar net: rule group ile rule’u ayrı ayrı tanımlamak, yalnızca tek bir rule değiştiğinde diff’te sadece o değişikliği temiz biçimde görmek, rule bazında değerlendirme aralığını ayrıntılı şekilde ayarlamak ve izleme kaynaklarını daha verimli kullanmak.
Kapanış
İlk hedef basitti: Alert’leri daha kolay oluşturmak, alındığında tek bakışta anlaşılır hale getirmek ve sorumluluğun kimde olduğunu netleştirmek.
İlk iyileştirme kapsamında Alert tanımları IaC olarak bir araya getirildi, Slack mesajları ve iletim yolu standartlaştırıldı, sorumlu mention’ları ile CODEOWNERS bağlantısı kuruldu ve proxy üzerinden Slack/PagerDuty lifecycle yönetimi düzenlendi.
Operasyon sürerken ortaya çıkan sorunlar ikinci iyileştirme aşamasında ele alındı. Aynı rule'dan yağan Alert'leri tek bir grupta gösterecek, tekrar eden tanımları template ve matrix ile azaltacak, Slack mesajı içinden inceleme ve hafifletme sürecini başlatmayı mümkün kılacak düzenlemeler yapıldı; ayrıca izleme sistemi kendisi durduğunda bunu fark edecek bir mekanizma da hazırlandı.
Bunun sayesinde Alert oluşturma, gönderme ve müdahale etme işleri eskisine göre daha kolay hale geldi.
Ancak verileri görünür kılmakla, o verilere dayanarak gerçek operasyonu iyileştirmek ayrı şeyler. Şimdiye kadar yapılan iş Alert sistemini standartlaştırmak ve ölçülebilir hale getirmek idiyse, bundan sonra geriye bu metriklere bakıp gerçekten azaltma ve iyileştirme yapmak kalıyor.
Bu yazıda hacim nedeniyle yer verilemeyen içerikler var. Daha ayrıntılı bilgi almak isteyenlere orijinal yazıyı da birlikte okumalarını öneririz.
Henüz yorum yok.