Tek sunucu için AI nöbetçi: Grafana AI'ya neyi emanet ederdim, neyi kendim kontrol ediyorum

Grafana bir hafta içinde servisi izleyen ve olayları araştıran ajanları, bir de ajanın kodda düzeltme hazırladığı bir sandbox'ı çıkardı. CNCF, ajana bağlam verildiğinde nedeni ne kadar daha hızlı bulduğunu ölçtü. Percona, “perşembe günü ne olmuştu” sorusuna yanıt veren bir araç yayınladı. İşletme sahibi için bunların hepsi tek bir soru: sunucunuzun başında gece kim nöbet tutuyor ve siz olmadan ne yapmaya yetkili.

Ne çıktı

Grafana Labs 20 Ekim'de Grafana Assistant'ın üç parçasını duyurdu. Watchers, kalıcı ajanlar: serviste sizi neyin kaygılandırdığını kendi sözlerinizle anlatıyorsunuz, Assistant telemetri geçmişinden bir taban çizgisi seçiyor ve sonra sinyalleri düzenli aralıklarla kontrol ediyor. Kritik bir şey bulursa metrikler ve loglar üzerinden araştırma yapan ajan Investigations'ı kendisi başlatıyor. Managed Sandboxes, şimdilik public preview'da: ajan repodaki kodu ve canlı telemetriyi ayrı bir bulut ortamında alıyor, neyin neden değiştiğini ve hangi kontrollerden geçtiğini anlatan bir pull request hazırlıyor. Grafana'nın altını çizdiği nokta: prod'daki kurtarmayı onaylamak ve neyin yayınlanacağına karar vermek ekipte kalıyor.

CNCF 21 Ekim'de bir ölçüm yayınladı; bütün duyurulardan çok bu hoşuma gitti. Aynı ajan, aynı modelde Claude Code, açık SREGym benchmark'ındaki 50 bozuk Kubernetes kümesinden iki kez geçti. İlkinde sıradan kabuk ve kubectl ile, ikincisinde güncel arıza listesini, değişiklik geçmişini ve hatalı logları doğrudan veren salt okunur araçlarla. Doğruluk neredeyse değişmedi: 45 doğru teşhise karşı 46. Değişen şey süre: ortalama 191 saniyeye karşı 64, iki dakika içinde doğru yanıt oranı %60'a karşı %86. Yazarlar araçların kendi araçları olduğunu ve iki varyantın da aynı üç arızada yanıldığını yazıyor.

Grafana Labs 14 Ekim'de Grafana Cloud IRM'de bir olayın yolunu anlattı: çağrı sayfası servisi ve tetiklenme geçmişini gösteriyor, Slack'ten Assistant'a başka neyin yandığını sorabiliyorsunuz, Assistant Workspace'teki araştırmayı ise elle düzenleyebiliyorsunuz: hipotez eklemek, çürütüleni işaretlemek, kaynaklara bakmak.

Percona 16 Ekim'de Apache 2.0 lisanslı açık araç mongo-health'i gösterdi. Her mongod saniyede bir kendi metriklerini diagnostic.data'ya yazıyor, ama Atlas M10'da canlı yük altında bu dosyalar iki ila beş gün yaşıyor. mongo-health onları üç ay saklıyor, saatte bir 68 kontrol çalıştırıyor ve küme için tek bir karar veriyor. Örneklerden biri: indeksi olmayan bir sorgu, döndürdüğü her belge için yaklaşık 10 milyon belge okuyordu. Percona bunun izlemenin yerini tutmadığını kendisi yazıyor: saatte bir okuyor ve kimseyi uyandırmıyor.

Grafana Labs 19 Ekim'de Assistant'ın kendisini nasıl iyileştirdiğini raporladı: yaklaşık 10 haftada dashboard modundaki hata oranı %2,47'den %0,65'e düştü, 95. yüzdelikteki gecikme 63 saniyeden 28,8 saniyeye, istek başına maliyet %18 azaldı.

Tek sunuculu işletmeye bu neden gerekli

Bir araç kiralama şirketi düşünelim. Perşembe akşamı rezervasyon sitesi yavaşladı, birkaç müşteri beklemedi, yönetici ancak pazartesi bir şikâyet üzerine fark etti. Alarm çalmadı, çünkü site yanıt veriyordu, on saniyede de olsa. Perşembenin loglarının üzerine sunucu çoktan yazdı, yük grafiği düz bir çizgi gösteriyor.

Sonuç aynı: geçmişi, ona bakmaya niyetleneceğinizden daha uzun saklamak gerekiyor ve ilk soru “bundan önce ne değişti” olacak. Araştırmacı ajana sizinle aynı kayıtlar gerekli; onlar olmadan o da bir şey bulamaz.

Bende nasıl kurulu

ABD'deki PDR şirketinde 2021'den beri teknik ortağım ve altyapıyı kendim izliyorum: Google Cloud'da Debian sunucu, MariaDB, VPN, kendi PBX'imiz üzerinde telefon sistemi. 2022'de kendi sunucumuz kurulduğundan beri kurtarma gerektiren ciddi bir arıza olmadı.

2023'ten beri çalıştığım hidroponik çiftlikte tek bir ağda 2 sahaya dağılmış 25 kontrolcü, Google Cloud'da Debian sunucu ve MariaDB veritabanı var. Şu anda benim tarafımdan aktif geliştirme yok, destek ise oldukça aktif: güncellemeler, hata ayıklama, sorunlar ortaya çıkınca inceleme. Gece bağlamı toplayacak nöbetçi bana işte burada lazım.

AI bana test ve hata ayıklamada yardım ediyor, sonucu ben kontrol ediyorum. Managed Sandboxes tarzı otomatik “önerilen düzeltmeyi” ancak kanıtla kabul ederdim: hangi metrikler bunu gösteriyor ve arızadan önce ne değişti. Bir de veto hakkıyla: değişiklik sunucuya, diğer her değişiklikle aynı kontrol sırasından geçerek giriyor.

Ben ne yapardım

Geçmişi varsayılanlardan uzun saklamak. Birkaç haftalık metrik ve log.

Değişiklik günlüğü tutmak: ne zaman ne yayınlandı, hangi config değişti. CNCF ölçümünde değişiklik geçmişi, 50 arızanın 35'inde ajanın ikinci isteğiydi. O olmadan insan da ajan da zamanı yeniden kurgulamaya harcıyor.

Tek bir servisle ve salt okunur erişimle başlamak. Ajana metrikleri, logları ve değişiklik günlüğünü vermek, geçmiş bir olayın nedenini bulmasını istemek ve sizin bulduğunuzla karşılaştırmak.

Önerilen düzeltmeyi kanıtlı bir pull request olarak kabul etmek, yayını ise elle, olağan kontrollerden geçirerek yapmak.

Yedeklerin geri yüklenebildiğini kontrol etmek. Yalnızca teşhis koyabilen bir nöbetçi kurtarmanın yerini tutmaz.

İlgili içerikler

Sistemin merkezi olarak sunucuyu Sunucu: veri, erişim ve sürecin yürütülmesi yazısında anlattım. Alan: yayınlanabilen ve kurtarılabilen altyapı. Vakalar: 2021'den beri PDR şirketinin teknik ortağı ve 25 kontrolcülü hidroponik çiftlik. Diğer incelemelerden: tek sunuculu sisteme ne kadar gözlemlenebilirlik gerekir, kimsenin geri yüklemediği yedek ve canlı sunucuda AI ajanına neye izin veriyorum. Daha önce gözlemlenebilirlik grafiği ve doğrulanabilir hipotezler hakkında yazmıştım. Gece kimsenin izlemediği bir sunucunuz varsa, üzerinde ne çalıştığını ve sorunları şu anda nasıl öğrendiğinizi anlatın. Görevi konuşalım.