Trendyol’da Load Balancer Altyapımızı Nasıl Monitor Ediyoruz?

Selamlar, bu medium yazısında Trendyol’da load balancer altyapımızı nasıl monitör ettiğimizden bahsedeceğiz, ancak öncesinde nasıl bir LB altyapımız olduğundan bahsetmekte fayda var.

2019 yılının sonlarına doğru, event dönemlerinde karşıladığımız anlık trafiğin 550 bin seviyelerini aşması ile birlikte kullandığımız kutu çözümler ihtiyaçlarımıza cevap vermekte yetersiz kalmaya başladı. (Bahsi geçen kutu çözümlerden burada söz etmiştik.) Bu doğrultuda yeni çözümler aramaya başladık, birçok uygulama test ettik, ve eldeki seçenekler arasında ihtiyaçlarımıza en uygun olanın tengine olduğuna karar verdik.

Tengine Nedir?

Ne Şekilde Kullanıyoruz?

Bunun dışında kalan trafiğimiz ise birbirine bağımlılığı olan (api to api) uygulamalarımızın iç iletişiminden oluşuyor. Aynı datacenter içerisinde veya DC to DC iletişimleri internal olarak gruplandırdığımız load balancer’lar üzerinden yönlendiriyoruz.

Trendyol Multi-DC Traffic Flow

Load balancer altyapımızın teknik detaylarından, yaptığımız konfigürasyonlardan ve otomasyon sistemlerimizden detaylı bahsedeceğiz ancak bu başka bir yazının konusu.

Nasıl Monitör Ediyoruz?

1-) Metric’leri Export Etmek

Bu aşamada şuan için 3 adet exporter kullanıyoruz.

Node exporter ile instance’ların cpu utilization, memory usage, network throughput gibi performans ve hardware metriclerini,

VTS exporter ile Tengine üzerinden anlık request miktarı, response süreleri, hata oranları gibi tengine metriclerini,

Bird exporter ile BGP komşuluklarını kurduğumuz bird’ün metriclerini toplayabiliyoruz.

Bu exporter’ları deployment esnasında, tüm load balancerlarımıza kuruyoruz. Kurulum sonrası exporter servisi running olduğunda data toplamaya hazır hale geliyor.

2-) Metric’leri Toplamak

Sıra geldi export ettiğimiz metricleri toplamaya. Bunun için her datacenter’da load balancer fabric’ini oluştururken bir tane de monitor node oluşturuyoruz.

Oluşturduğumuz monitor node üzerinde temelde 3 adet uygulama çalışıyor.

Prometheus, bizim için belirttiğimiz target’lar üzerinde seçtiğimiz metric’leri topluyor.

Aynı zamanda Prometheus konfigürasyonu içerisinde alerts klasörü altına, her exporterdan oluşturacağımız alarmları tanımlıyoruz. Örneğin aşağıda node_reboot_required değeri 1'in üzerine çıktığında alarm üretecek olan kuralı görüyorsunuz.

Ürettiğimiz bu alarmlardan bildirimler yaratabilmek için, Prometheus’un Alertmanager’a göndermesini sağlıyoruz.

Prometheus konfigürasyonu içerisinde Alertmanager tanımı

Monitor node üzerinde kullandığımız bir diğer uygulama ise Grafana.

Grafana — Data Source Alanı

Örneğin aşağıda VTS Exporter üzerinden aldığımız HTTP Status code’ların grafiğini ve bu grafik için gerekli regex’i görebilirsiniz.

3-) Alarm Üretmek

Alertmanager’ı kurduğumuz monitor node’un 9093 portuna gittiğimizde yukarıda örnek verdiğimiz alarmın buraya düştüğünü görebiliriz.

Şimdi ise bu alarmın bize SMS / Telefon / Mail olarak gelmesini sağlayacağız. Bu aşamada ise imdadımıza, dışarıdan satın aldığımız bir hizmet olan PagerDuty yetişiyor.

Bunun için PagerDuty’de bir service directory yaratıp service key oluşturuyoruz. Bu service key ile Alertmanager üzerinde entegrasyon için gerekli konfigürasyonu yapıyoruz.

Bu aşamadan sonra Prometheus’un Alertmanager’a ilettiği alarmlar, PagerDuty’e düşüyor. PagerDuty, service directory altında belirttiğimiz nöbet listelerine göre o günün nöbetçisini, ulaşamaz ise yedek nöbetçiyi arıyor.

Soru : Peki ya monitor node’umuzda bir sorun olursa nasıl alarm üreteceğiz?

Alertmanager üzerinde de görebildiğimiz bu Watchdog alarmı, 5 dakikalık aralıklarla Deadmansnitch’e gidiyor.

15 dakika içerisinde bu watchdog alarmı Deadmansnitch’e hiç gelmez ise, Deadmansnitch alarm üretiyor.

Başka konularda görüşmek üzere! Teşekkürler.

System Administrator @Trendyol.com

System Administrator @Trendyol.com