Log mu metrik mi: tek sunucudaki sisteme ne kadar gözlemlenebilirlik gerekir

Grafana Workflows'u çıkardı ve Adaptive Telemetry'yi genişletti, Sentry log ile metrik arasındaki farkı açıkladı, OpenTelemetry güvenlik için sürüm kurallarını değiştirdi, CNCF blogunda ise koddaki yapay zeka asistanının telemetrisinin nasıl kırpılacağı gösterildi. Bunların hepsi onlarca servisi olan ekipler için yazılmış. “Neyi loga yazmalı, neyi saymalı” sorusu tek sunucudaki sistemin de önünde duruyor ve işletme sahibinin izlemede neye para ödediğini bilmesi işine yarar.

Neler yayımlandı

Grafana Labs 21 Ekim'de herkese açık preview olarak Grafana Workflows'u tanıttı: ekibin süreci otomatik adımlara dönüşüyor. major incident kickoff şablonu Slack'te kanal açıyor, takvimden nöbetçi olay komutanını buluyor, runbook'u sabitliyor ve olayın zaman çizelgesine yazıyor. ask Assistant adımı, kendi modellerinden olay özeti çıkarmasını ve gözlemleri hipotezlerden ayırmasını istiyor. on-call handoff report şablonu nöbet değişiminde haftanın olay raporunu topluyor.

Bir gün önce, 20 Ekim'de, Grafana Adaptive Telemetry'nin faturayı veri hacminden nasıl ayırdığını anlattı. Trace'ler için: volumetric sampling örnekleme bütçesini servisler arasında bölüyor ve testlerine göre aynı hacimdeki rastgele örneklemeden yaklaşık %25 daha fazla işe yarar bilgi veriyor; atılan trace'lere 24 saat boyunca ID ile ulaşılabiliyor. Loglar için: atma kuralları doğrudan collector'larda uygulanıyor, kaybetmeye kıyamadığınız veri ise geri alınabilir şekilde sizin ucuz nesne depolamanıza gidiyor.

Sentry 22 Ekim'de ne zaman log, ne zaman metrik gerektiği sorusunu yanıtladı. Formülleri kısa: loglar hata ayıklama için, metrikler analiz için. Log, olay anında neyin doğru olduğunu kaydeder ki sonra tablo yeniden kurulabilsin; metrik, her şey yolundayken bile zaman içinde izlenen bir sayının olduğu yerde gerekir. Trace'ler örnekleniyor, loglar ve metrikler örneklenmiyor.

OpenTelemetry 22 Ekim'de sürüm politikasını güncelledi: kararlı SDK'lar ve Contrib bileşenleri artık minor ve patch sürümlerde güvenlik için davranış değiştirebiliyor, herkese açık API'ye dokunulmuyor ve release notes'un yapılandırmada neyin değişeceğini açıklaması zorunlu.

Haftanın en pratik yazısı: CNCF 22 Ekim'de koddaki yapay zeka asistanının telemetrisinin OpenTelemetry Collector ile nasıl filtreleneceğini gösterdi. Claude Code için küçük bir görev 181 kayıt ve 289 KB JSON üretmiş. Yazar altı soru yazmış: modellere göre maliyet, token'lar, hangi araçlar düşüyor, gecikme nerede, ne bozuldu. Hepsine sayaçlar ve kısa öznitelikler cevap veriyor; dosya gövdeleri ve prompt'lar yalnızca yer kaplıyor. Sonra collector yapılandırması: api_request olayını atmak, bu kayıtların yaklaşık dörtte biri; altı özniteliği silmek; kimlikleri hash'leyip hash'i 16 karaktere kısaltmak, çünkü tam SHA256 UUID'den uzun ve ilk denemeden sonra log hacmi büyümüş.

İşletme için ne anlama geliyor

Pompaları ve sulamayı kontrolörlerin yönettiği bir serayı ele alalım. Her sensörün her ölçümünü metin olarak loga yazabilirsiniz. Altı ay sonra log gigabaytlarca yer tutar, ama “dün gece üçte pompa neden çalışmadı” sorusunun cevabı içinde yoktur: pompa satırı sıcaklık ölçümlerinin arasında kaybolmuştur. Doğrusu tersi: su seviyesi ve sıcaklık metriktir, onlardan grafik ve bildirim eşiği kurulur; pompanın komut alıp yanıt vermediği an ise nedeniyle birlikte logdur.

Sonuç: gözlemlenebilirlik, cevaplanabilen soru sayısıyla ölçülür. Hiçbir grafik ve hiçbir bildirim bir alanı okumuyorsa onu saklamaya boşuna para ödüyorsunuz.

Bende nasıl çalışıyor

ABD'deki PDR şirketiyle 2021'den beri çalışıyorum ve altyapıyı kendim izliyorum: Google Cloud'da Debian sunucu, VPN, ağ donanımı ve telefon sistemi. Grafana Workflows orada gerekmiyor; nöbetçi tek kişi ve o da benim. Buna karşılık 2025'te şirketteki 4 televizyona TV panosu çıkardım, her birinde ayrı pano: sahibi için, siparişlere göre üretim için, ön büro için ve satışçılar için. İşletme için bunlar, mühendisin dashboard'da baktığı metriklerin aynısı. Leaderboard çalışanları 15 göstergeye göre sayıyor. Her aramanın kaydı ve kimin neden aradığının yapay zeka analizi ise Sentry'nin terimleriyle log: belirli bir müşteride ne olduğu ondan yeniden kuruluyor.

2023'ten beri sunucusundan, ağından ve kontrolör bağlantısından sorumlu olduğum hidroponik çiftlikte iki sahadaki 25 kontrolörün verisi sunucudaki tek bir MariaDB veritabanına geliyor. Neyin geçmiş olarak saklanacağına, neyin özet olarak sayılacağına otomasyon mantığını ve arayüzü yapan başka bir ekip karar veriyor. Benim kısmım: verinin ulaşması.

Kodda yapay zeka asistanım bende de var; rutin işleri, testleri ve hata ayıklamayı alıyor. Telemetrisini collector'a bağlamadım, ama CNCF yazısındaki sıra doğru: önce sorular, sonra alanlar.

Ben ne yapardım

Sistemin cevaplaması gereken beş soruyu yazın. Örneğin: bugün kaç talep geldi, kontrolör en son ne zaman yanıt verdi, günlük yapay zeka analizi kaça mal oluyor.

Her soru için karar verin: bu zaman içinde bir sayı mı, yoksa bağlamı olan bir olay mı. Sayı, eşiği olan metrik olur. Olay, kendisini bulduracak alanları olan log olur: talep ID'si, müşteri, neden.

Gerisini toplamayın: belge gövdeleri ve modellerin tam yanıtları loglarda gerekmez, uzunlukları ve durumları yeter.

Üç ayda bir hangi alanları kimsenin okumadığına bakın ve onları kaldırın ya da Grafana'nın önerdiği gibi ucuz depolamaya koyun.

Logların en çok gerektiği arka plan görevleri ve yeniden denemeler hakkında Worker'lar: arka plan görevleri ve yeniden denemeler yazısında yazdım. Hizmet alanları: yayınlanabilen ve geri yüklenebilen altyapı ve ekipman izleme ve bildirimler. Projeler: PDR şirketinin teknik ortağı ve 25 kontrolörlü hidroponik çiftlik. Aynı konuda: tek sunucuda yapay zeka nöbetçiye ne bırakırdım ve hangi metrikler ekibe kötü kararlar öğretiyor. Daha önce gözlemlenebilirliğin ekibin vermesi gereken kararla başladığını yazmıştım. İzlemede neye para ödediğinizi anlamıyorsanız şu an neyin toplandığını gösterin: Görevi konuşalım.