Kubernetes (K8s) ortamlar\u0131n\u0131z\u0131n sa\u011fl\u0131\u011f\u0131n\u0131 ve performans\u0131n\u0131 etkili bir \u015fekilde nas\u0131l izleyece\u011finizi \u00f6\u011frenin. Temel kavramlardan ileri d\u00fczey ara\u00e7lara kadar kapsaml\u0131 bir rehber.<\/p>\n
Modern yaz\u0131l\u0131m geli\u015ftirme yakla\u015f\u0131mlar\u0131n\u0131n temelini olu\u015fturan mikroservis mimarileri ve da\u011f\u0131t\u0131k sistemler, Kubernetes gibi konteyner orkestrasyon ara\u00e7lar\u0131yla hayat bulur. Ancak bu dinamik ve s\u00fcrekli de\u011fi\u015fen yap\u0131, beraberinde ciddi izleme zorluklar\u0131 getirir. K8s ortamlar\u0131, binlerce pod, servis ve d\u00fc\u011f\u00fcmden olu\u015fabilen karma\u015f\u0131k ekosistemlerdir. Bu karma\u015f\u0131kl\u0131k, sistemdeki anormallikleri, performans d\u00fc\u015f\u00fc\u015flerini veya potansiyel hatalar\u0131 manuel olarak tespit etmeyi neredeyse imkans\u0131z hale getirir. \u0130\u015fte tam da bu noktada, etkili bir K8s izleme stratejisi hayati bir \u00f6nem kazan\u0131r.<\/p>\n
Peki, Kubernetes ortamlar\u0131n\u0131z\u0131 neden bu kadar titizlikle izlemelisiniz? En ba\u015fta, kesintisiz hizmet sunumu ve kullan\u0131c\u0131 deneyiminin kalitesini sa\u011flamak i\u00e7in izleme vazge\u00e7ilmezdir. Bir uygulaman\u0131n yava\u015flamas\u0131 veya tamamen eri\u015filemez hale gelmesi, do\u011frudan m\u00fc\u015fteri memnuniyetsizli\u011fine ve ticari kay\u0131plara yol a\u00e7abilir. \u0130zleme, bu t\u00fcr sorunlar\u0131 ortaya \u00e7\u0131kmadan \u00f6nce veya ilk belirtilerinde tespit etmenize olanak tan\u0131r. \u00d6rne\u011fin, bir podun kaynak t\u00fcketiminin aniden artmas\u0131, potansiyel bir bellek s\u0131z\u0131nt\u0131s\u0131n\u0131n veya hatal\u0131 bir uygulaman\u0131n i\u015fareti olabilir. Erken te\u015fhis, b\u00fcy\u00fck bir krize d\u00f6n\u00fc\u015fmeden \u00f6nce sorunu \u00e7\u00f6zmek i\u00e7in size zaman kazand\u0131r\u0131r.<\/p>\n
\u0130kinci olarak, operasyonel maliyetleri optimize etmek ve kaynaklar\u0131 verimli kullanmak i\u00e7in izleme kritik bir rol oynar. K8s k\u00fcmelerinde kaynak israf\u0131, gereksiz y\u00fcksek bulut faturalar\u0131na yol a\u00e7abilir. \u0130zleme ara\u00e7lar\u0131 sayesinde CPU, bellek, disk ve a\u011f kullan\u0131m\u0131 gibi metrikleri s\u00fcrekli takip edebilir, hangi kaynaklar\u0131n a\u015f\u0131r\u0131 tahsis edildi\u011fini veya yetersiz kald\u0131\u011f\u0131n\u0131 belirleyebilirsiniz. Bu sayede, kaynaklar\u0131 daha dengeli da\u011f\u0131tarak hem performans\u0131 art\u0131rabilir hem de gereksiz harcamalardan ka\u00e7\u0131nabilirsiniz. \u00d6rne\u011fin, s\u00fcrekli d\u00fc\u015f\u00fck kaynak kullan\u0131m\u0131 g\u00f6steren bir servisin replika say\u0131s\u0131n\u0131 azaltarak maliyet tasarrufu sa\u011flayabilirsiniz.<\/p>\n
\u00dc\u00e7\u00fcnc\u00fc bir \u00f6nemli neden ise hata ay\u0131klama (debugging) ve sorun giderme s\u00fcre\u00e7lerini h\u0131zland\u0131rmakt\u0131r. Da\u011f\u0131t\u0131k bir sistemde bir hatan\u0131n k\u00f6k nedenini bulmak, i\u011fneyi samanl\u0131kta aramaya benzer. Metrikler, loglar ve da\u011f\u0131t\u0131k izleme (tracing) verileri, bu s\u00fcre\u00e7te size yol g\u00f6sterir. Bir hata meydana geldi\u011finde, ilgili podun loglar\u0131na bakarak, o podun kaynak t\u00fcketimini inceleyerek veya bir mikroservis \u00e7a\u011fr\u0131s\u0131n\u0131n nerede tak\u0131ld\u0131\u011f\u0131n\u0131 trace verileriyle takip ederek sorunun kayna\u011f\u0131na \u00e7ok daha h\u0131zl\u0131 ula\u015fabilirsiniz. Bu da ar\u0131za s\u00fcresini (MTTR – Mean Time To Recovery) \u00f6nemli \u00f6l\u00e7\u00fcde k\u0131salt\u0131r.<\/p>\n
Son olarak, g\u00fcvenlik ve uyumluluk a\u00e7\u0131s\u0131ndan da izleme b\u00fcy\u00fck \u00f6nem ta\u015f\u0131r. K8s k\u00fcmelerinde anormal a\u011f trafi\u011fi, yetkisiz eri\u015fim denemeleri veya beklenmedik sistem davran\u0131\u015flar\u0131 gibi durumlar, g\u00fcvenlik a\u00e7\u0131\u011f\u0131na i\u015faret edebilir. \u0130zleme sistemleri, bu t\u00fcr anormallikleri tespit ederek sizi uyarabilir ve proaktif g\u00fcvenlik \u00f6nlemleri alman\u0131z\u0131 sa\u011flayabilir. T\u00fcm bu nedenler g\u00f6z \u00f6n\u00fcne al\u0131nd\u0131\u011f\u0131nda, K8s ortamlar\u0131n\u0131n karma\u015f\u0131kl\u0131\u011f\u0131na ra\u011fmen veya bu karma\u015f\u0131kl\u0131k nedeniyle, kapsaml\u0131 ve etkili bir izleme stratejisi, ba\u015far\u0131l\u0131 bir operasyonel y\u00f6netim i\u00e7in adeta bir temel direk niteli\u011findedir. \u0130zleme, sadece sorunlar\u0131 tespit etmekle kalmaz, ayn\u0131 zamanda sistemlerinizin evrimle\u015fmesine ve geli\u015fmesine de rehberlik eder.<\/p>\n
Kubernetes ortamlar\u0131n\u0131 etkin bir \u015fekilde izlemek i\u00e7in \u00fc\u00e7 temel veri t\u00fcr\u00fcne odaklanmak gerekir: Metrikler, loglar ve da\u011f\u0131t\u0131k trace’ler. Bu \u00fc\u00e7l\u00fc, sisteminizin sa\u011fl\u0131\u011f\u0131, performans\u0131 ve davran\u0131\u015flar\u0131 hakk\u0131nda farkl\u0131 ama birbirini tamamlayan bak\u0131\u015f a\u00e7\u0131lar\u0131 sunar. Bu verileri do\u011fru bir \u015fekilde toplay\u0131p analiz etmek, sorunlar\u0131 anlamak ve \u00e7\u00f6zmek i\u00e7in hayati \u00f6neme sahiptir.<\/p>\n
Metrikler, sistemin belirli bir zamandaki durumu hakk\u0131nda nicel verilerdir. Genellikle zaman serisi format\u0131nda toplan\u0131r ve CPU kullan\u0131m\u0131, bellek t\u00fcketimi, a\u011f trafi\u011fi, disk I\/O, istek say\u0131s\u0131, hata oranlar\u0131 gibi verileri i\u00e7erir. K8s ba\u011flam\u0131nda metrikler, d\u00fc\u011f\u00fcm (node), pod, konteyner ve hatta uygulama seviyesinde toplanabilir. \u00d6rne\u011fin, bir podun belirli bir anda ne kadar CPU kulland\u0131\u011f\u0131n\u0131 g\u00f6steren bir metrik, uygulaman\u0131n performans\u0131n\u0131 do\u011frudan etkileyen bir kaynak k\u0131s\u0131tlamas\u0131n\u0131n varl\u0131\u011f\u0131n\u0131 i\u015faret edebilir. Benzer \u015fekilde, bir HTTP servisi i\u00e7in saniyede i\u015flenen istek say\u0131s\u0131 (RPS – Requests Per Second) veya ortalama yan\u0131t s\u00fcresi (latency), kullan\u0131c\u0131 deneyiminin kalitesi hakk\u0131nda \u00f6nemli bilgiler sunar.<\/p>\n
Metrikler genellikle say\u0131sal de\u011ferler oldu\u011fundan, zaman i\u00e7inde de\u011fi\u015fimlerini grafikler ve g\u00f6sterge tablolar\u0131 (dashboards) arac\u0131l\u0131\u011f\u0131yla g\u00f6rselle\u015ftirmek kolayd\u0131r. Bu g\u00f6rselle\u015ftirmeler, trendleri, ani y\u00fckseli\u015fleri (spikes) veya d\u00fc\u015f\u00fc\u015fleri h\u0131zl\u0131ca fark etmenizi sa\u011flar. Kubernetes kendi i\u00e7inde cAdvisor gibi ara\u00e7larla temel konteyner metriklerini toplar ve bu verilere Loglar, bir uygulaman\u0131n veya sistemin belirli bir zamanda ger\u00e7ekle\u015ftirdi\u011fi olaylar\u0131n metin tabanl\u0131 kay\u0131tlar\u0131d\u0131r. Hata mesajlar\u0131, uyar\u0131lar, bilgi notlar\u0131, kullan\u0131c\u0131 giri\u015fleri, veritaban\u0131 i\u015flemleri gibi pek \u00e7ok farkl\u0131 olay\u0131 kaydederler. K8s ortamlar\u0131nda her pod, konteyner ve d\u00fc\u011f\u00fcm kendi loglar\u0131n\u0131 \u00fcretir. Ancak bu loglar\u0131n tek tek incelenmesi veya toplanmas\u0131, \u00f6zellikle y\u00fczlerce podun \u00e7al\u0131\u015ft\u0131\u011f\u0131 b\u00fcy\u00fck k\u00fcmelerde pratik de\u011fildir. Bu nedenle merkezi log y\u00f6netimi \u00e7\u00f6z\u00fcmleri hayati \u00f6nem ta\u015f\u0131r.<\/p>\n Loglar, bir sorunun nedenini anlamak i\u00e7in metriklerden daha detayl\u0131 bilgi sunar. \u00d6rne\u011fin, bir metrik CPU kullan\u0131m\u0131n\u0131n y\u00fcksek oldu\u011funu g\u00f6sterirken, ilgili podun loglar\u0131 hangi i\u015flemin CPU’yu a\u015f\u0131r\u0131 y\u00fckledi\u011fini veya hangi hatan\u0131n bu duruma yol a\u00e7t\u0131\u011f\u0131n\u0131 a\u00e7\u0131klayabilir. Loglar\u0131n yap\u0131s\u0131 genellikle “serbest bi\u00e7imli” metin gibi g\u00f6r\u00fcnse de, g\u00fcn\u00fcm\u00fczde yap\u0131land\u0131r\u0131lm\u0131\u015f loglama (structured logging) giderek daha pop\u00fcler hale gelmektedir. JSON gibi formatlarda loglamak, log verilerini daha kolay sorgulanabilir, filtrelenebilir ve analiz edilebilir hale getirir. Fluent Bit veya Fluentd gibi log toplay\u0131c\u0131lar, K8s k\u00fcmelerinden loglar\u0131 toplay\u0131p Elasticsearch gibi merkezi bir loglama sistemine y\u00f6nlendirmek i\u00e7in yayg\u0131n olarak kullan\u0131l\u0131r. Loglar, hata ay\u0131klama s\u00fcre\u00e7lerinin bel kemi\u011fidir ve bir sistemdeki gizli sorunlar\u0131 ortaya \u00e7\u0131karmada e\u015fsiz bir rol oynar.<\/p>\n Da\u011f\u0131t\u0131k trace’ler (distributed traces), \u00f6zellikle mikroservis mimarilerinde ortaya \u00e7\u0131kan karma\u015f\u0131k istek ak\u0131\u015flar\u0131n\u0131 anlamak i\u00e7in tasarlanm\u0131\u015f veri k\u00fcmeleridir. Bir kullan\u0131c\u0131 iste\u011fi, birden fazla mikroservis \u00fczerinden ge\u00e7erek i\u015flenebilir ve her bir serviste farkl\u0131 gecikmeler ya\u015fanabilir. Trace’ler, bu yolculu\u011fun her ad\u0131m\u0131n\u0131 (span) kaydeder ve iste\u011fin ba\u015flang\u0131c\u0131ndan sonuna kadar ge\u00e7ti\u011fi t\u00fcm servisleri, harcad\u0131\u011f\u0131 s\u00fcreleri ve olas\u0131 hatalar\u0131 g\u00f6rselle\u015ftirmemizi sa\u011flar. B\u00f6ylece, iste\u011fin toplam gecikmesinin hangi servisten kaynakland\u0131\u011f\u0131n\u0131 net bir \u015fekilde g\u00f6rebiliriz.<\/p>\n \u00d6rne\u011fin, bir e-ticaret uygulamas\u0131nda “sipari\u015f olu\u015fturma” i\u015flemi, kullan\u0131c\u0131 aray\u00fcz\u00fc, \u00fcr\u00fcn servisi, envanter servisi, \u00f6deme servisi ve bildirim servisi gibi pek \u00e7ok mikroservisi tetikleyebilir. E\u011fer bu i\u015flem beklenenden yava\u015fsa, bir trace, gecikmenin hangi servis \u00e7a\u011fr\u0131s\u0131nda ya\u015fand\u0131\u011f\u0131n\u0131 (\u00f6rne\u011fin, envanter servisinin veritaban\u0131 sorgusunda tak\u0131lmas\u0131) kolayca belirlemenize yard\u0131mc\u0131 olur. Bu, metriklerin veya loglar\u0131n tek ba\u015f\u0131na sa\u011flayamayaca\u011f\u0131 b\u00fct\u00fcnsel bir bak\u0131\u015f a\u00e7\u0131s\u0131 sunar. OpenTelemetry gibi standartlar, uygulamalar\u0131n izleme verilerini (metrik, log ve trace) ba\u011f\u0131ms\u0131z bir \u015fekilde \u00fcretmesini ve \u00e7e\u015fitli izleme backend’lerine g\u00f6ndermesini kolayla\u015ft\u0131r\u0131r. Jaeger veya Zipkin gibi da\u011f\u0131t\u0131k izleme sistemleri ise bu trace verilerini toplar, saklar ve g\u00f6rselle\u015ftirir. Mikroservislerin sa\u011flad\u0131\u011f\u0131 \u00e7evikli\u011fi tam olarak kullanabilmek i\u00e7in da\u011f\u0131t\u0131k izleme, sistemin her bir par\u00e7as\u0131n\u0131n bir b\u00fct\u00fcn olarak nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 anlamak ad\u0131na vazge\u00e7ilmez bir ara\u00e7t\u0131r.<\/p>\n Kubernetes izlemenin kalbinde, a\u00e7\u0131k kaynak d\u00fcnyas\u0131n\u0131n en pop\u00fcler iki arac\u0131 olan Prometheus ve Grafana bulunur. Prometheus, metrik toplama ve depolama konusunda standart haline gelmi\u015fken, Grafana bu metrikleri g\u00f6rselle\u015ftirmek ve anlaml\u0131 g\u00f6sterge tablolar\u0131 (dashboards) olu\u015fturmak i\u00e7in e\u015fsiz bir platform sunar. Bu b\u00f6l\u00fcmde, bu g\u00fc\u00e7l\u00fc ikiliyi K8s ortam\u0131n\u0131zda nas\u0131l yap\u0131land\u0131rabilece\u011finizi ve uygulayabilece\u011finizi ad\u0131m ad\u0131m inceleyece\u011fiz.<\/p>\n Prometheus, cloud-native ortamlar i\u00e7in \u00f6zel olarak tasarlanm\u0131\u015f, zaman serisi veritaban\u0131na sahip bir izleme sistemidir. Temel \u00e7al\u0131\u015fma prensibi “pull” modeline dayan\u0131r; yani, hedeflenen servislerden veya uygulamalardan belirli aral\u0131klarla metrikleri \u00e7eker (scrape eder). Kubernetes ortam\u0131nda Prometheus’u kurmak ve yap\u0131land\u0131rmak i\u00e7in genellikle Prometheus’un K8s ortam\u0131ndaki g\u00fcc\u00fc, dinamik servis ke\u015ffi (service discovery) yetene\u011finden gelir. Kubernetes API’sini kullanarak otomatik olarak izlenecek servisleri, podlar\u0131 veya d\u00fc\u011f\u00fcmleri ke\u015ffedebilir. Bu, her yeni birim devreye al\u0131nd\u0131\u011f\u0131nda manuel yap\u0131land\u0131rmaya gerek kalmamas\u0131 anlam\u0131na gelir. Metrikleri toplamak i\u00e7in Prometheus, genellikle \u00f6zel bir metrik endpoint’i (\u00f6rne\u011fin, A\u015fa\u011f\u0131da, \u00f6rnek bir <\/code><\/p>\n Bu Grafana, Prometheus taraf\u0131ndan toplanan ham metrik verilerini anlaml\u0131 g\u00f6sterge tablolar\u0131na d\u00f6n\u00fc\u015ft\u00fcrmek i\u00e7in kullan\u0131lan a\u00e7\u0131k kaynakl\u0131 bir g\u00f6rselle\u015ftirme arac\u0131d\u0131r. Grafana'y\u0131 K8s \u00fczerinde kurduktan sonra, Prometheus'u bir veri kayna\u011f\u0131 olarak eklemeniz gerekir. Bu entegrasyon sayesinde, Grafana'n\u0131n g\u00fc\u00e7l\u00fc sorgulama ve g\u00f6rselle\u015ftirme yeteneklerini kullanarak sisteminizin genel sa\u011fl\u0131\u011f\u0131n\u0131 ve performans\u0131n\u0131 anl\u0131k olarak takip edebilirsiniz.<\/p>\n Grafana'da dashboard'lar olu\u015ftururken, farkl\u0131 paneller (panels) kullanarak \u00e7e\u015fitli metrikleri g\u00f6rselle\u015ftirebilirsiniz. \u00d6rne\u011fin, bir panelde pod'lar\u0131n CPU kullan\u0131m\u0131n\u0131, di\u011ferinde bellek t\u00fcketimini, bir di\u011ferinde ise a\u011f trafi\u011fini g\u00f6sterebilirsiniz. Grafana'n\u0131n zengin k\u00fct\u00fcphanesinde, K8s i\u00e7in \u00f6nceden haz\u0131rlanm\u0131\u015f bir\u00e7ok dashboard \u015fablonu (\u00f6rne\u011fin, \"Kubernetes \/ Compute Resources \/ Cluster\" veya \"Kubernetes \/ Kubelet\") bulunur. Bu \u015fablonlar\u0131 i\u00e7e aktararak h\u0131zla izlemeye ba\u015flayabilir ve kendi ihtiya\u00e7lar\u0131n\u0131za g\u00f6re \u00f6zelle\u015ftirebilirsiniz.<\/p>\n Bir e-ticaret platformunun K8s k\u00fcmesinde \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 d\u00fc\u015f\u00fcnelim. Cuma ak\u015fam\u0131, ani bir sat\u0131\u015f kampanyas\u0131yla birlikte uygulaman\u0131n yan\u0131t s\u00fcrelerinde belirgin bir art\u0131\u015f ya\u015fanmaya ba\u015flar. Kullan\u0131c\u0131lar, \u00fcr\u00fcn sayfalar\u0131n\u0131n yava\u015f y\u00fcklendi\u011finden \u015fikayet\u00e7idir. Operasyon ekibi Grafana dashboard'lar\u0131na bakt\u0131\u011f\u0131nda, Prometheus ve Grafana altyap\u0131 ve sistem metriklerinde m\u00fckemmel olsa da, uygulama i\u00e7erisindeki i\u015f mant\u0131\u011f\u0131 ve mikroservisler aras\u0131 ileti\u015fimdeki sorunlar\u0131 daha derinlemesine anlamak i\u00e7in ek ara\u00e7lara ihtiya\u00e7 duyar\u0131z. Burada devreye OpenTelemetry ve Jaeger gibi da\u011f\u0131t\u0131k izleme (distributed tracing) \u00e7\u00f6z\u00fcmleri girer. OpenTelemetry, metrik, log ve trace verilerini toplamak i\u00e7in tek bir a\u00e7\u0131k kaynak standart seti sunar. Uygulama kodunuzu enstr\u00fcmante ederek (instrumenting), yani \u00f6zel k\u00fct\u00fcphaneler ekleyerek, uygulaman\u0131z\u0131n her bir fonksiyon \u00e7a\u011fr\u0131s\u0131n\u0131n veya harici servis iste\u011finin bir \"span\" olarak kaydedilmesini sa\u011flars\u0131n\u0131z.<\/p>\n Bu span'lar, bir iste\u011fin mikroservisler aras\u0131nda nas\u0131l gezindi\u011fini g\u00f6steren bir \"trace\" olu\u015fturur. Trace'ler, bir iste\u011fin ba\u015flang\u0131c\u0131ndan sonuna kadar t\u00fcm yolculu\u011funu, hangi serviste ne kadar zaman harcad\u0131\u011f\u0131n\u0131 ve hangi hatalarla kar\u015f\u0131la\u015ft\u0131\u011f\u0131n\u0131 g\u00f6rselle\u015ftirmenize olanak tan\u0131r. Jaeger gibi ara\u00e7lar, bu trace verilerini toplar, depolar ve bir kullan\u0131c\u0131 aray\u00fcz\u00fc \u00fczerinden g\u00f6rselle\u015ftirir. Bu sayede, \"performans darbo\u011faz\u0131 nerede?\" veya \"bu hata zincirleme olarak hangi servisten kaynakland\u0131?\" gibi sorulara kesin yan\u0131tlar bulabilirsiniz.<\/p>\n Yine ayn\u0131 e-ticaret platformunda, kullan\u0131c\u0131lar sepetlerine \u00fcr\u00fcn eklerken zaman zaman uzun gecikmeler ya\u015fad\u0131klar\u0131n\u0131 rapor ederler. Prometheus metrikleri genel olarak sistemin iyi durumda oldu\u011funu g\u00f6sterir; CPU ve bellek kullan\u0131m\u0131 normaldir. Ancak da\u011f\u0131t\u0131k izleme sistemi Jaeger incelendi\u011finde, sepet servisine gelen isteklerin Kubernetes ortamlar\u0131nda sadece metrikleri toplamak yeterli de\u011fildir; sistemin ve uygulamalar\u0131n \u00fcretti\u011fi loglar\u0131 etkin bir \u015fekilde y\u00f6netmek ve anlamland\u0131rmak da kritik \u00f6neme sahiptir. Ayr\u0131ca, tespit edilen anormallikler ve e\u015fikler a\u015f\u0131ld\u0131\u011f\u0131nda otomatik olarak uyar\u0131lar g\u00f6ndererek proaktif m\u00fcdahale sa\u011flamak, sistemin dayan\u0131kl\u0131l\u0131\u011f\u0131n\u0131 art\u0131r\u0131r. Bu b\u00f6l\u00fcmde, merkezi log y\u00f6netimi \u00e7\u00f6z\u00fcmlerini ve g\u00fc\u00e7l\u00fc uyar\u0131 mekanizmalar\u0131n\u0131 inceleyece\u011fiz.<\/p>\n K8s k\u00fcmeleri, her biri ayr\u0131 log ak\u0131\u015flar\u0131 \u00fcreten y\u00fczlerce pod ve konteyner bar\u0131nd\u0131rabilir. Bu loglar\u0131n tek tek incelenmesi pratik de\u011fildir. Bu nedenle, merkezi bir log y\u00f6netim sistemine sahip olmak elzemdir. Merkezi loglama, t\u00fcm loglar\u0131n tek bir yerden toplanmas\u0131n\u0131, depolanmas\u0131n\u0131, filtrelenmesini, aranmas\u0131n\u0131 ve analiz edilmesini sa\u011flar.<\/p>\n A\u00e7\u0131k kaynak d\u00fcnyas\u0131nda en pop\u00fcler merkezi log y\u00f6netim \u00e7\u00f6z\u00fcm\u00fc, Elasticsearch, Logstash ve Kibana'dan olu\u015fan ELK Stack'tir. Bu \u00fc\u00e7 bile\u015fen bir araya geldi\u011finde g\u00fc\u00e7l\u00fc bir log analizi platformu olu\u015fturur:<\/p>\n Kubernetes ortam\u0131nda loglar\u0131 ELK Stack'e ta\u015f\u0131mak i\u00e7in genellikle Fluent Bit<\/a> veya Fluentd<\/a> gibi log toplay\u0131c\u0131lar kullan\u0131l\u0131r. Bu ara\u00e7lar, her K8s d\u00fc\u011f\u00fcm\u00fcnde bir DaemonSet olarak \u00e7al\u0131\u015f\u0131r ve o d\u00fc\u011f\u00fcmdeki t\u00fcm konteynerlerin loglar\u0131n\u0131 toplar. Ard\u0131ndan, bu loglar\u0131 i\u015fleyip (iste\u011fe ba\u011fl\u0131 olarak) Logstash'e veya do\u011frudan Elasticsearch'e g\u00f6nderir. Fluent Bit, daha hafif yap\u0131s\u0131yla K8s ortamlar\u0131 i\u00e7in genellikle tercih edilir.<\/p>\n Kibana'da, loglar\u0131 zaman damgas\u0131na g\u00f6re s\u0131ralayabilir, belirli anahtar kelimelere g\u00f6re arayabilir, hata seviyesine g\u00f6re filtreleyebilir veya \u00f6zel dashboard'lar olu\u015fturarak log trendlerini izleyebilirsiniz. \u00d6rne\u011fin, bir uygulaman\u0131n hata oran\u0131n\u0131n aniden y\u00fckseldi\u011fini veya belirli bir hata mesaj\u0131n\u0131n s\u0131kl\u0131\u011f\u0131n\u0131n artt\u0131\u011f\u0131n\u0131 h\u0131zl\u0131ca g\u00f6rebilirsiniz. ELK Stack'in alternatifi olarak, Grafana ekosisteminde pop\u00fclerle\u015fen Loki<\/a> (Prometheus gibi etiket tabanl\u0131 log indeksleme) veya ticari \u00e7\u00f6z\u00fcmler olan Splunk, Datadog gibi platformlar da bulunmaktad\u0131r. Hangi \u00e7\u00f6z\u00fcm\u00fcn se\u00e7ilece\u011fi, projenin b\u00fcy\u00fckl\u00fc\u011f\u00fcne, b\u00fct\u00e7esine ve ekipteki mevcut bilgi birikimine g\u00f6re de\u011fi\u015fir.<\/p>\n \u0130zleme sistemlerinizin toplad\u0131\u011f\u0131 metrikler ve loglar ne kadar zengin olursa olsun, e\u011fer \u00f6nemli bir sorun olu\u015ftu\u011funda kimseyi uyaram\u0131yorsa, de\u011feri s\u0131n\u0131rl\u0131d\u0131r. Etkin uyar\u0131 sistemleri, belirli e\u015fikler a\u015f\u0131ld\u0131\u011f\u0131nda veya anormal durumlar tespit edildi\u011finde ilgili ekipleri otomatik olarak bilgilendirerek proaktif m\u00fcdahaleyi m\u00fcmk\u00fcn k\u0131lar. Prometheus ekosisteminde bu g\u00f6revi Alertmanager<\/a> \u00fcstlenir.<\/p>\n Alertmanager, Prometheus'tan gelen uyar\u0131lar\u0131 al\u0131r, bunlar\u0131 gruplar (b\u00f6ylece ayn\u0131 sorundan kaynaklanan birden fazla uyar\u0131 tek bir bildirim olarak g\u00f6nderilir) ve \u00e7e\u015fitli bildirim kanallar\u0131na (Slack, email, PagerDuty, Opsgenie vb.) y\u00f6nlendirir. Uyar\u0131 kurallar\u0131, Prometheus yap\u0131land\u0131rmas\u0131nda \u00d6rnek bir <\/code><\/p>\n Bu kurallar, pod'un CPU kullan\u0131m\u0131n\u0131n %80'i a\u015fmas\u0131 veya bir pod'un s\u00fcrekli yeniden ba\u015flamas\u0131 durumunda uyar\u0131 tetikler. Uyar\u0131lar, belirlenen kanallara g\u00f6nderilerek ilgili ekibin h\u0131zla m\u00fcdahale etmesini sa\u011flar.<\/p>\n Bir medya \u015firketinin K8s \u00fczerindeki canl\u0131 yay\u0131n platformu, b\u00fcy\u00fck bir etkinlik s\u0131ras\u0131nda beklenmedik bir trafik art\u0131\u015f\u0131 ya\u015far. Prometheus, Geli\u015fmi\u015f senaryolarda, Kubernetes'in Vertical Pod Autoscaler (VPA) veya Cluster Autoscaler gibi ara\u00e7lar\u0131 da izleme verileriyle entegre edilerek kaynak optimizasyonu ve maliyet y\u00f6netimi sa\u011flanabilir. VPA, pod'lar\u0131n kaynak (CPU, bellek) isteklerini ve limitlerini otomatik olarak ayarken, Cluster Autoscaler, k\u00fcmenin kaynak talebine g\u00f6re d\u00fc\u011f\u00fcm say\u0131s\u0131n\u0131 art\u0131r\u0131p azalt\u0131r. Bu otomasyon yetenekleri, K8s izlemenin sa\u011flad\u0131\u011f\u0131 istihbarat\u0131n ger\u00e7ek d\u00fcnya de\u011ferini en \u00fcst d\u00fczeye \u00e7\u0131kar\u0131r.<\/p>\n Mobil uyumlu HTML'den bahsetmi\u015fken, bu genellikle CSS ile sa\u011flan\u0131r. Ancak konsepti g\u00f6stermek ad\u0131na, K8s dashboard'lar\u0131n\u0131n mobil cihazlarda da kullan\u0131labilir olmas\u0131 i\u00e7in responsive tasar\u0131mlar \u00f6nemlidir. \u00d6rne\u011fin, basit bir mobil g\u00f6r\u00fcn\u00fcm i\u00e7in a\u015fa\u011f\u0131daki gibi bir CSS prensibini uygulayabiliriz (bu bir HTML i\u00e7eri\u011fi oldu\u011fu i\u00e7in yaln\u0131zca bir \u00f6rnek olarak belirtilmi\u015ftir):<\/p>\nkubectl top<\/code> komutuyla eri\u015filebilir. Ancak daha kapsaml\u0131 ve \u00f6zelle\u015ftirilmi\u015f izleme i\u00e7in Prometheus gibi \u00f6zel metrik toplama sistemleri kullan\u0131l\u0131r. Uygulama geli\u015ftiricileri de kendi uygulamalar\u0131na \u00f6zel metrikler (\u00f6rne\u011fin, sepetinize eklenen \u00fcr\u00fcn say\u0131s\u0131, veritaban\u0131 sorgu s\u00fcreleri) ekleyerek, uygulaman\u0131n i\u00e7 i\u015fleyi\u015fi hakk\u0131nda de\u011ferli bilgiler sa\u011flayabilirler. Bu t\u00fcr \u00f6zel metrikler, i\u015f metrikleri olarak da adland\u0131r\u0131l\u0131r ve operasyonel verilerle birle\u015ftirildi\u011finde daha b\u00fct\u00fcnsel bir g\u00f6r\u00fcn\u00fcm sunar.<\/p>\nLoglar: Sistem Olaylar\u0131n\u0131n G\u00fcnl\u00fckleri<\/h3>\n
Da\u011f\u0131t\u0131k Trace’ler: Mikroservisler Aras\u0131 Yolculuklar\u0131n Haritas\u0131<\/h3>\n
K8s \u0130zleme Ara\u00e7lar\u0131n\u0131 Uygulamaya Koymak: Prometheus ve Grafana ile Pratik Ad\u0131mlar<\/h2>\n
Prometheus: Metrik Toplaman\u0131n Kalbi<\/h3>\n
kube-prometheus-stack<\/code> gibi Helm chart’lar\u0131 kullan\u0131l\u0131r. Bu chart, Prometheus’un yan\u0131 s\u0131ra Grafana, Alertmanager ve \u00e7e\u015fitli K8s bile\u015fenlerini de kurarak kapsaml\u0131 bir izleme \u00e7\u00f6z\u00fcm\u00fc sunar.<\/p>\n\/metrics<\/code>) sunan uygulamalara HTTP \u00e7a\u011fr\u0131lar\u0131 yapar. Bu endpoint’ler, Prometheus taraf\u0131ndan okunabilir formatta (Prometheus text exposition format) metrikleri d\u0131\u015fa aktar\u0131r. K8s servislerini izlemek i\u00e7in ServiceMonitor<\/code> veya PodMonitor<\/code> gibi Custom Resource Definition (CRD) kaynaklar\u0131 kullan\u0131l\u0131r. Bu CRD’ler, Prometheus’a hangi servisleri veya podlar\u0131 hangi portlardan ve hangi yollardan scrape edece\u011fini bildirir.<\/p>\nretention<\/code> ve retention.size<\/code> ayarlar\u0131n\u0131 yapman\u0131z \u00f6nemlidir.\n<\/div>\nServiceMonitor<\/code> tan\u0131m\u0131 g\u00f6sterilmi\u015ftir. Bu tan\u0131m, my-app<\/code> etiketine sahip bir servisi ve http<\/code> portundan metriklerini \u00e7ekece\u011fini belirtir:<\/p>\n\napiVersion: monitoring.coreos.com\/v1\nkind: ServiceMonitor\nmetadata:\n name: my-app-service-monitor\n labels:\n app: my-app\nspec:\n selector:\n matchLabels:\n app: my-app\n endpoints:\n - port: http\n path: \/metrics\n interval: 30s\n namespaceSelector:\n matchNames:\n - default\n<\/pre>\nServiceMonitor<\/code> kayna\u011f\u0131, Prometheus operat\u00f6r\u00fcn\u00fcn belirli servisleri otomatik olarak ke\u015ffetmesini ve yap\u0131land\u0131rmas\u0131n\u0131 sa\u011flar. Prometheus, bu sayede uygulaman\u0131z\u0131n performans verilerini d\u00fczenli olarak toplamaya ba\u015flar.<\/p>\nGrafana: Metrikleri Anlaml\u0131 Hale Getirmek<\/h3>\n
Vaka Analizi 1: E-ticaret Uygulamas\u0131ndaki Performans D\u00fc\u015f\u00fc\u015f\u00fc<\/h4>\n
checkout-service<\/code> pod'lar\u0131n\u0131n CPU kullan\u0131m\u0131n\u0131n %90'\u0131n \u00fczerine \u00e7\u0131kt\u0131\u011f\u0131n\u0131 ve bellek limitlerine yakla\u015ft\u0131\u011f\u0131n\u0131 g\u00f6r\u00fcr. Ayn\u0131 zamanda, kube_pod_container_resource_limits_cpu_cores<\/code> metrikleri incelendi\u011finde, bu pod'lara tahsis edilen CPU limitlerinin mevcut y\u00fck\u00fc kar\u015f\u0131lamakta yetersiz kald\u0131\u011f\u0131 anla\u015f\u0131l\u0131r. Grafana'daki apiserver_request_total<\/code> ve kube_deployment_status_replicas_unavailable<\/code> metriklerinin g\u00f6sterdi\u011fi art\u0131\u015f, API sunucusuna gelen isteklerin artt\u0131\u011f\u0131n\u0131 ve baz\u0131 replikalar\u0131n sa\u011fl\u0131ks\u0131z oldu\u011funu do\u011frular. Ekip, h\u0131zla checkout-service<\/code>'in replika say\u0131s\u0131n\u0131 art\u0131rmak i\u00e7in Horizontal Pod Autoscaler (HPA) limitlerini g\u00fcnceller ve ge\u00e7ici olarak CPU limitlerini y\u00fckseltir. Birka\u00e7 dakika i\u00e7inde, CPU kullan\u0131m\u0131 normal seviyelere d\u00f6ner ve yan\u0131t s\u00fcreleri iyile\u015fir. Bu senaryo, Prometheus ve Grafana'n\u0131n anl\u0131k metriklerle sorunlar\u0131 nas\u0131l h\u0131zl\u0131ca tespit edip m\u00fcdahale edilmesine olanak sa\u011flad\u0131\u011f\u0131n\u0131 a\u00e7\u0131k\u00e7a g\u00f6stermektedir.<\/p>\nUygulama \u0130\u00e7i \u0130zleme ve Da\u011f\u0131t\u0131k \u0130zleme: OpenTelemetry ve Jaeger'\u0131n G\u00fcc\u00fc<\/h3>\n
Vaka Analizi 2: Mikroservisler Aras\u0131 \u0130leti\u015fimdeki Gecikmenin Tespiti<\/h4>\n
product-catalog-service<\/code>'e yapt\u0131\u011f\u0131 \u00e7a\u011fr\u0131larda rastgele ama belirgin bir gecikme ya\u015fand\u0131\u011f\u0131 fark edilir. Jaeger aray\u00fcz\u00fcnde, gecikmeli trace'lerin product-catalog-service<\/code>'in veritaban\u0131 sorgular\u0131n\u0131n oldu\u011fu span'larda yo\u011funla\u015ft\u0131\u011f\u0131 g\u00f6r\u00fcl\u00fcr. Daha derinlemesine inceleme sonucunda, product-catalog-service<\/code>'in kritik bir veritaban\u0131 indeksinin eksik oldu\u011fu veya veritaban\u0131 ba\u011flant\u0131 havuzunun yetersiz oldu\u011fu tespit edilir. Bu sorun, sadece trace verileri sayesinde kolayca belirlenebilmi\u015f ve do\u011fru \u00e7\u00f6z\u00fcme h\u0131zl\u0131ca ula\u015f\u0131lm\u0131\u015ft\u0131r. OpenTelemetry ve Jaeger, metriklerin ve loglar\u0131n sa\u011flayamayaca\u011f\u0131 d\u00fczeyde bir g\u00f6r\u00fcn\u00fcrl\u00fck sunarak, \u00f6zellikle karma\u015f\u0131k mikroservis mimarilerinde hata ay\u0131klama s\u00fcre\u00e7lerini radikal bir \u015fekilde h\u0131zland\u0131r\u0131r.<\/p>\nK8s Log Y\u00f6netimi ve Uyar\u0131 Mekanizmalar\u0131: Geli\u015fmi\u015f Stratejiler<\/h2>\n
Merkezi Log Y\u00f6netimi: ELK Stack ve Alternatifler<\/h3>\n
\n
Etkin Uyar\u0131 Sistemleri ve Otomatik M\u00fcdahale<\/h3>\n
alert.rules<\/code> dosyalar\u0131nda tan\u0131mlan\u0131r. Bu kurallar, PromQL (Prometheus Query Language) kullan\u0131larak yaz\u0131l\u0131r ve belirli bir metrik belirli bir s\u00fcre boyunca bir e\u015fi\u011fi a\u015ft\u0131\u011f\u0131nda veya bir durum olu\u015ftu\u011funda uyar\u0131 tetikler.<\/p>\nalert.rules<\/code> dosyas\u0131 a\u015fa\u011f\u0131daki gibi g\u00f6r\u00fcnebilir:<\/p>\n\ngroups:\n- name: application-alerts\n rules:\n - alert: HighCPUUsage\n expr: sum(rate(container_cpu_usage_seconds_total{image!=\"\"}[5m])) by (pod, namespace) \/ sum(container_spec_cpu_quota{image!=\"\"}) * 100 > 80\n for: 5m\n labels:\n severity: warning\n annotations:\n summary: \"Pod {{ $labels.pod }} CPU kullan\u0131m\u0131 y\u00fcksek\"\n description: \"Pod {{ $labels.pod }} (Namespace: {{ $labels.namespace }}) CPU kullan\u0131m\u0131 5 dakikadan uzun s\u00fcredir %80'in \u00fczerinde.\"\n - alert: PodCrashLooping\n expr: sum(kube_pod_container_status_restarts_total) by (pod, namespace) > 0 and on(pod, namespace) kube_pod_container_status_restarts_total offset 5m < sum(kube_pod_container_status_restarts_total) by (pod, namespace)\n for: 1m\n labels:\n severity: critical\n annotations:\n summary: \"Pod {{ $labels.pod }} \u00e7\u00f6kme d\u00f6ng\u00fcs\u00fcnde\"\n description: \"Pod {{ $labels.pod }} (Namespace: {{ $labels.namespace }}) son 5 dakikada yeniden ba\u015flat\u0131ld\u0131. L\u00fctfen loglar\u0131 kontrol edin.\"\n<\/pre>\nVaka Analizi 3: Y\u00fcksek Trafik An\u0131nda Otomatik \u00d6l\u00e7ekleme ile Hizmet Kesintisi \u00d6nleme<\/h4>\n
streaming-service<\/code> pod'lar\u0131n\u0131n CPU kullan\u0131m\u0131n\u0131n h\u0131zla artmaya ba\u015flad\u0131\u011f\u0131n\u0131 ve %70 e\u015fi\u011fini ge\u00e7ti\u011fini tespit eder. Bu durum, \u00f6nceden tan\u0131mlanm\u0131\u015f bir uyar\u0131 kural\u0131n\u0131 tetikler. Ancak bu noktada manuel bir m\u00fcdahaleye gerek kalmaz. \u00c7\u00fcnk\u00fc K8s'in Horizontal Pod Autoscaler (HPA)<\/a> \u00f6zelli\u011fi devreye girer. HPA, CPU kullan\u0131m\u0131 %60'\u0131 a\u015ft\u0131\u011f\u0131nda streaming-service<\/code> pod'lar\u0131n\u0131n replika say\u0131s\u0131n\u0131 otomatik olarak art\u0131racak \u015fekilde yap\u0131land\u0131r\u0131lm\u0131\u015ft\u0131r. HPA, Prometheus metriklerini kullanarak pod say\u0131s\u0131n\u0131 otomatik olarak 5'ten 10'a \u00e7\u0131kar\u0131r. Yeni pod'lar devreye girdik\u00e7e, y\u00fck da\u011f\u0131t\u0131l\u0131r, CPU kullan\u0131m\u0131 d\u00fc\u015fer ve hizmet kesintiye u\u011framadan, manuel m\u00fcdahaleye gerek kalmadan y\u00fcksek trafi\u011fi sorunsuz bir \u015fekilde kar\u015f\u0131lar. Bu senaryo, izleme verilerinin sadece uyar\u0131 vermekle kalmay\u0131p, otomatik \u00f6l\u00e7ekleme gibi proaktif m\u00fcdahalelerle sistemin dayan\u0131kl\u0131l\u0131\u011f\u0131n\u0131 nas\u0131l art\u0131rd\u0131\u011f\u0131n\u0131 g\u00f6sterir.<\/p>\n\n\n