Gözlemlenebilirlik kümesi CPU’yu sürekli %100’e yakın kullanıyorsa, Kibana’da Explore yavaşlar, panolar gecikir ve her incident’te ilk şüphe yine arama katmanı olur. Budget Thuis için—Nuts Groep çatısı altında enerji, internet ve mobil markalarını bir araya getiren Hollandalı operatör—Elastic Cloud üzerindeki APM, log ve metrik yükü, depolama ağırlıklı (dense) donanım profilinde işlemci darboğazına kilitlenmişti.
Benim tarafımdan yapılan çalışma, semptomları tek tek “ince ayar”lamak yerine donanım profili, veri katmanları ve indeks yaşam döngüsü (ILM) üçlüsünü gözlemlenebilirlik verisinin gerçekten nasıl yaşlandığına göre hizalamaktı. Sonuç net: CPU baskısı yaklaşık %100’den ~%20’ye indi, log saklama süresi 10 günden 90 güne çıktı ve proje notlarındaki referans saatlik maliyetlerle birlikte yaklaşık $2.15/saat’ten yaklaşık $1.80/saat’e düşüş mümkün oldu—frozen katmanı eklendikten ve ILM oturduktan sonra hot tarafı doğru boyuta çekince.
Sorun
Budget Thuis’in Elasticsearch tarafı APM, log ve metrik için merkezi: ekipler Kibana üzerinden servis envanteri, log explorer ve izlenebilirlik görünümlerini kullanıyor. Elastic Agent ve Fleet ile uçtan uca toplanan telemetri, tek bir üretim kümesinde toplanıyor; bu da yüksek ingest ile sorgu ve pano yükünü aynı anda getiriyor. Ingest hacmi yüksek olduğundan küme operasyon olarak tekrar tekrar zorlanıyordu; kökte yüksek CPU kullanımı ve ingest baskısı vardı.
Hot veri katmanında düğümler depolama odaklı (storage-optimized, dense) profildeydi: disk başına maliyet iyi görünür ama indeksleme, merge ve sorgu fan-out CPU istediğinde sonuç %97–100 CPU olur. Ekipler çoğu zaman son 7 güne bakmak istiyor; altyapı ise “soğuk veriyi bile sıcak gibi taşımanın” maliyetini ödüyordu.
Öte yandan iş tarafı 10 günden uzun geçmişi görmek istiyordu; “her şeyi hot’ta tutarak” bunu çözmek ise doğrusal maliyet artışı demekti.
Teşhis
İki ana problem öne çıktı.
Donanım–iş yükü uyumsuzluğu. Dense profil, gözlemlenebilirlikte sık sık CPU sınırına çarpar. CPU uzun süre tavan yaptığında pano ve sorgu performansı belirsiz hale gelir; sorun yalnızca “yavaş dashboard” değil, operasyonel risktir.
Katmanlama ve ILM boşluğu. Uzun saklama, veriyi sonsuza dek sıcak tutmak değil; rollover, katmanlar arası taşıma ve silme politikası ile yasal/iş gereksinimini karşılamaktır. Ekibin ihtiyacı: hot’ta yakın dönem, frozen’da daha eski ama gerekli veri, disiplinli bir üst zaman sınırı.
Keşif notlarında ayrıca Spaces ve yetkilendirmenin ekiplere göre daha net ayrıştırılabileceği, ILM’de rollover tercihi ve takılı yaşam döngüsü hatalarının giderilmesi gerektiği görülüyordu. Ancak platformu ayağa kaldıran başlıca mesele CPU + saklama ekonomisiydi.
Çözüm
Elastic Cloud üzerinde ardışık, kontrollü bir dizi değişiklik uyguladık.
1) Hot katmanı CPU odaklı ARM düğümlere taşımak. Hot tarafı depolama ağırlıklı dense profilden CPU odaklı (ARM tabanlı) düğümlere geçirdik; hot’ta gereksiz disk fazlalığını, gerçek darboğaz olan vCPU için kullanılabilir hale getirdik. Bu geçişle CPU baskısı ~%100’den ~%20’ye indi; bu, hem ingest hem sorgu için nefer sayısı gibi düşünülebilecek bir başlıdır.
2) Frozen veri katmanı eklemek. Daha eski veriyi sıcak düğümlerde tutmak yerine frozen kapasiteyle düşük işlem gücü, yüksek depolama modeline taşıdık. Uzun saklama, hot’un faturasını şişirmeden mümkün olur.
3) ILM’i verinin yaşlanmasına göre güncellemek. Hot tarafında boyut ve süre eşikleriyle rollover, veri 7 günden eskiyse frozen’a taşınsın, 90 günden eskiyse silinsin gibi bir çerçeveyle politikayı netleştirdik. Böylece log saklama 10 günden 90 güne çıktı; ekipler “bu hafta / geçen çeyrek” karşılaştırmasını platform içinde yapabilir hale geldi.
4) ILM oturduktan sonra hot’u küçültmek. Veri katmanlar arası düzgün aktığında hot düğümlerde fazla kapasiteyi kırptık; proje notlarında saatlik maliyetin yaklaşık $3.05’ten yaklaşık $1.80’e indiği bir aşama var. Başlangıçtaki yaklaşık $2.15 referansına göre de nihai durum maliyet iyileştirmesi ile birlikte geldi.
Paylaşılabilir içerik için cluster adı, iç indeks adları veya altyapıya özgü kimlikler yerine mimari örüntü anlatıldı; müşteri ortamına özel tanımlayıcılar case study metnine taşınmadı.
Keşif aşamasında ayrıca bazı Windows tabanlı log entegrasyonlarında yol ve izin kaynaklı toplama hataları olduğu not edilmişti; bu tür sorunlar ingest’in düşmesine ve panolarda yanlış boşluk hissine yol açabilir. Platform tarafını CPU ve ILM ile sağlamlaştırmak bir yana, entegrasyon sağlığı da gözlemlenebilirlik güvenilirliği için ayrı bir hatırlatıcıdır.
Sonuçlar
| Metrik | Önce | Sonra |
|---|---|---|
| Hot CPU baskısı | ~%100 | ~%20 |
| Log saklama (politika sonucu) | 10 gün | 90 gün |
| Saatlik maliyet (notlardaki referans noktaları) | ~$2.15/saat (başlangıç dense) | ~$1.80/saat (nihai küçültme sonrası) |
Araya giren CPU ve frozen ekleme aşamalarında saatlik maliyetin geçici olarak arttığı normaldir; asıl kıyas, ILM ve katmanlama oturduktan sonra hot’u doğru boyuta çekmiş son durumdur.
Öğrendiklerimiz
- Darboğaz CPU ise donanım profili “dense” olmamalı. Gözlemlenebilirlik yükünde ARM tabanlı CPU odaklı hot çoğu zaman doğru varsayılandır.
- Uzun saklama = katmanlama. Frozen, 90 günlük veriyi hot fiyatına yazdırmanın alternatifidir.
- Sıra önemli: önce frozen + ILM, sonra hot küçültme—aksi halde veri taşınmadan kapasiteyi kesmek risklidir.
- Kibana performansı, CPU müsaitliği ile başlar. Sorgu optimizasyonuna gitmeden önce doymuş CPU var mı bakın.
Elasticsearch veya OpenSearch cluster'ınızla ilgili yardım almak için searchali.com’u ziyaret edin. Uzun saklama ve veri katmanları için Elastic’in ILM dokümantasyonuna bakın.