Grafana != Monitoring
Grafana'da paneller dönüyor, her şey yeşil. Sorun çıkınca aynı panellere bakıp "ee şimdi?" diyorsun. Kullanıcı etkileniyor mu, hangi bileşen yüzünden, neyi değiştirmeliyim? Bunlar boşta kalıyor. Ekranda grafik olması sistemi anladığın anlamına gelmiyor.
Monitoring'i "ne kadar çok metrik o kadar iyi" diye düşünmek buraya götürüyor. Ev sunucusu, birkaç servis, az kullanıcı için iş daha basit: bir şey bozulunca fark et, nereden geldiğini anla, ne yapacağını bil. Ölçümü de o yüzden araç merakından değil, karar vermen gereken yerden başlatmak lazım.
Bir sunucuda Tailscale, AdGuard Home ve küçük bir API çalışıyor diyelim. Tailscale uzaktan erişim, AdGuard DNS, API kişisel bir uygulama. Bu setup'ta yüzlerce metrik üretebilirsin. İlk sorular yine basit: DNS cevap veriyor mu? API dışarıdan erişiliyor mu? Sunucu bunları taşıyacak kadar ayakta mı?
Araçlar
Metrik tarafında Prometheus ya da VictoriaMetrics yeterli. İkisi de servislerden ve sunucudan zaman serisi toplayıp saklıyor. Prometheus'un ekosistemi geniş, çekme modeli tanıdık; cardinality büyüdükçe işletmesi ağırlaşıyor. VictoriaMetrics daha az kaynakla uzun saklama için rahat ama yine ayrı bir bileşen, yedek ve sürüm takibi demek. İkisini birden kurmak çoğu zaman iki ayrı bakım işi.
Grafana bu veriyi panellere çeviriyor. İşe yaradığı yer, bir soruyu hızlı cevaplamak: son bir saatte DNS gecikmesi mi yükseldi, yoksa tek bir istemci mi bozuldu? Panel çoğaldıkça sahipsiz dashboard'lar, aynı metrik için üç farklı sorgu, hiç bakılmayan paneller birikiyor.
Alertmanager, Prometheus kurallarından gelen alarmı insana ulaştırıyor. Gruplama, susturma, doğru kanala yönlendirme kuralları olmadan gece bildirim yağdırır. Yanında ne yapacağını bilmiyorsan o alarmı kaldır veya yeniden yaz.
Uptime Kuma dışarıdan HTTP, DNS veya TCP kontrolü yapıyor. Uygulamanın health endpoint'inin "ben iyiyim" demesi ile senin seçtiğin noktadan erişebilmek farklı şeyler. Kontrolü aynı sunucudan yaparsan internet veya Tailscale istemci sorununu kaçırabilirsin. Çok sık kontrol de geçici ağ dalgalanmasını gürültüye çevirir.
Merkezi log toplamayı ilk günden şart görmüyorum. Metrikler genelde ne zaman ve ne kadar olduğunu gösterir, loglar neden tarafına yardım eder. Hepsi bu kadar net de değil; bir log erişim hatasını gösterebilir, bir metrik de olası nedeni daraltabilir. Tüm logları merkezileştirmek depolama, saklama politikası, erişim kontrolü ve arama maliyeti demek. Hata araştırırken düzenli olarak makine makine dosya geziyorsan o zaman merkezi log işe yarıyor. Ek olarak merkezi log çözümleri genelde çok kaynak gerektirir.
Erişilebilirlik
systemd active görünüyor diye iş bitmiyor. Port dinlemiyor olabilir, reverse proxy yanlış yönleniyor olabilir, DNS upstream cevap vermiyor olabilir. Bakman gereken şey istemcinin kullandığı yoldan işin yapılıp yapılmadığı.
DNS için Uptime Kuma ile AdGuard Home'a gerçek bir DNS sorgusu yaptırmak mantıklı. :53 TCP açık diye sevinme; bilinen bir alan adını çözümleyen kontrol daha işe yarar. Kontrol kırmızıysa önce şunu ayır: AdGuard'a Tailscale üzerinden mi ulaşamıyorum, yoksa servis yerelde de mi ölü? Birincisi Tailscale, ACL veya ağ yolu. İkincisi AdGuard, port çakışması veya upstream.
API için dışarıdan HTTP kontrolü koy, sağlık endpoint'inden beklenen status code'u al. API sadece tailnet'ten erişiliyorsa kontrolü de oradan yap; herkese açık bir check zaten ulaşamayacağı servisi sürekli kırmızı gösterir. API düştüğünde tüm istemcilerde mi yoksa tek bir ağ yolunda mı bak. Sonra süreç, port, reverse proxy, Tailscale.
Sunucuya SSH atabilmek DNS ve API'nin çalıştığını kanıtlamaz.
Gecikme
Bazen cevap geliyor ama geç geliyor. Ortalama tek başına zayıf; birkaç hızlı istek yavaşları gizler. Trafik varsa p95 / p99 daha anlamlı. Trafik azsa yüzdelikler kararsız olur, o durumda en yavaş istekler, eşik üstü istek sayısı ve örnek timestamp'ler daha okunaklı.
AdGuard tarafında sorgu süresi yükseliyorsa suç hemen yerel resolver olmayabilir. Upstream, ağ yolu veya sunucu kaynak baskısı da işin içinde olabilir. Yerel ad çözümü de mi yavaş, yoksa sadece dış adlar mı? Aynı anda CPU, disk bekleme ve ağ hatalarına bak. Tek başına gecikme grafiği "sunucuyu restart et" kararı verdirmez.
API'de HTTP yanıt süresi, health check yeşilken deneyimin bozulduğunu gösterir. Gecikme artıp hata oranı henüz artmıyorsa bağlantı havuzu, uzak bağımlılık veya kaynak doygunluğuna bak. Birkaç dakikalık sıçrama ile kalıcı eğilimi aynı alarm seviyesinde tutma. Kısa dalgalanma için panel yeter; kullanıcıyı etkilemeye devam ediyorsa bildirim lazım.
Hata Oranı
Servis cevap veriyor ama yanlış veya başarısız sonuç üretiyor olabilir. HTTP'de 5xx, timeout, başarısız istek oranı. DNS'te SERVFAIL, timeout ve beklenmeyen NXDOMAIN artışı bağlama göre anlamlı. Her NXDOMAIN hata değil; kullanıcı var olmayan adı sormuş olabilir. DNS alarmını istek hacmi ve bildiğin beklentilerle birlikte tanımla.
AdGuard DNS kontrolü düşüyor ama Tailscale node ayaktaysa DNS servisi veya upstream etkilenmiş olabilir. Birden fazla istemciden timeout geliyorsa bu ihtimal güçlenir. AdGuard loglarında upstream hata / timeout bak, sonra upstream listesi ve ağ erişimi. Tek istemcinin hatasıyla bütün resolver'ı restart etme.
API'de 5xx yükselirken HTTP check ara sıra yeşil kalabilir. "API erişilebilir" sonucu burada yetmez. Hangi endpoint, hangi hata sınıfı, hangi deploy veya kaynak değişimiyle aynı zamana denk geldi? Birden fazla API örneği veya kısa ömürlü container varsa merkezi log araştırmayı hızlandırır. Tek API, az trafik için yerel loglar başlangıçta yeter.
Kaynak Doygunluğu
CPU %80 diye paniklemene gerek yok; gecikme artmıyorsa acil müdahale şart olmayabilir. Disk dolmak üzereyken veya bellek baskısı altında süreçler ölürken ortalama CPU düşük görünebilir.
Sunucuda bakılacaklar: kullanılabilir disk, bellek baskısı / OOM, CPU bekleme-yoğunluk eğilimi, disk I/O beklemesi. Beş saniyelik CPU sıçraması ile yirmi dakika süren disk beklemesi aynı şey değil. Disk alanının düzenli azalması, "disk doldu" alarmından önce fark edilir.
API gecikmesi yükseldi, AdGuard sorguları timeout'a yaklaştı, sunucuda disk beklemesi arttıysa kaynak doygunluğu olabilir. Kim I/O yapıyor, disk / inode tükeniyor mu, OOM kaydı var mı? Log retention kısaltmak, ağır DB işini ayırmak, kaynak sınırı koymak veya daha güçlü makineye geçmek seçenek. Rastgele container restart etmek baskıyı kısa süre erteler.
Başlangıç Listesi
Tek sunuculu küçük sistem için:
- DNS için gerçek sorgu yapan bir dış kontrol koy. Düşerse önce Tailscale yolu ile AdGuard / upstream ayrımını yap.
- API için kullanıcının eriştiği ağdan HTTP kontrolü koy. Status code, timeout, temel yanıt süresini izle.
- API 5xx ve timeout artışını istek hacmiyle birlikte değerlendir. Tekil hatayı genel kesinti gibi alarmlama.
- Sunucuda disk alanı, bellek baskısı / OOM ve uzun süren CPU veya disk bekleme eğilimlerini izle.
- Her bildirime bir müdahale adımı yaz. Yazamıyorsan alarmı kaldır veya daha dar koşulla yeniden yaz.
- Sorun araştırmaları düzenli olarak yerel loglarda zaman yiyorsa merkezi log ekle. Sırf mümkün diye ekleme.
Saded
Grafana'da dashboard yaratmak monitoring değil. Hangi sinyalin hangi kararını değiştirdiğini söyleyemiyorsan o dashboard'u kurmana gerek yok.