Modern yaz\u0131l\u0131m geli\u015ftirme d\u00fcnyas\u0131nda Docker konteynerleri, uygulamalar\u0131 paketlemek, da\u011f\u0131tmak ve \u00e7al\u0131\u015ft\u0131rmak i\u00e7in vazge\u00e7ilmez bir ara\u00e7 haline geldi. Ancak, konteynerlerin esnekli\u011fi ve hafif yap\u0131s\u0131, beraberinde kaynak kullan\u0131m\u0131n\u0131n dikkatli bir \u015fekilde izlenmesi gereklili\u011fini getiriyor. Bir konteynerin CPU ve bellek t\u00fcketimini anlamak, uygulaman\u0131z\u0131n performans\u0131n\u0131 optimize etmek, olas\u0131 darbo\u011fazlar\u0131 \u00f6nceden tespit etmek ve altyap\u0131 maliyetlerini kontrol alt\u0131nda tutmak i\u00e7in kritik \u00f6neme sahiptir. Bu makale, Docker konteynerlerinizin kaynak kullan\u0131m\u0131n\u0131 nas\u0131l etkin bir \u015fekilde izleyece\u011finizi, dahili ara\u00e7lardan geli\u015fmi\u015f \u00e7\u00f6z\u00fcmlere kadar ad\u0131m ad\u0131m a\u00e7\u0131klayacakt\u0131r.<\/p>\n
G\u00fcn\u00fcm\u00fcz\u00fcn dinamik ve mikroservis tabanl\u0131 uygulama mimarilerinde, her bir bile\u015fenin bir konteyner i\u00e7inde \u00e7al\u0131\u015fmas\u0131 olduk\u00e7a yayg\u0131nd\u0131r. Bu durum, kaynak y\u00f6netimini ve performans izlemeyi daha karma\u015f\u0131k ancak bir o kadar da \u00f6nemli hale getirir. Konteynerlerin CPU ve bellek kullan\u0131m\u0131n\u0131 d\u00fczenli olarak takip etmek, sadece mevcut sorunlar\u0131 \u00e7\u00f6zmekle kalmaz, ayn\u0131 zamanda gelecekteki performans\u0131 ve maliyetleri proaktif bir \u015fekilde y\u00f6netmenizi sa\u011flar. Peki, bu izleme neden bu kadar kritik?<\/p>\n
\u00d6ncelikle, performans darbo\u011fazlar\u0131n\u0131 tespit etmek<\/strong> i\u00e7in izleme \u015fartt\u0131r. Bir uygulaman\u0131n yava\u015flamas\u0131 veya yan\u0131t vermemesi genellikle y\u00fcksek CPU kullan\u0131m\u0131, bellek s\u0131z\u0131nt\u0131lar\u0131 veya yetersiz kaynak tahsisi gibi sorunlardan kaynaklan\u0131r. Konteyner baz\u0131nda detayl\u0131 metrikler toplamak, sorunun tam olarak hangi servisten veya konteynerden kaynakland\u0131\u011f\u0131n\u0131 h\u0131zl\u0131ca belirlemenize olanak tan\u0131r. \u00d6rne\u011fin, bir e-ticaret sitesinde \u00f6deme i\u015flemleri s\u0131ras\u0131nda CPU kullan\u0131m\u0131n\u0131n aniden f\u0131rlad\u0131\u011f\u0131n\u0131 g\u00f6rmek, ilgili mikroserviste bir optimizasyon ihtiyac\u0131na i\u015faret edebilir. Bu t\u00fcr bir g\u00f6zlem olmadan, sorunun k\u00f6k nedenini bulmak “samanl\u0131kta i\u011fne aramak” gibi zorlay\u0131c\u0131 olabilir.<\/p>\n \u0130kinci olarak, maliyet optimizasyonu<\/strong> a\u00e7\u0131s\u0131ndan izleme b\u00fcy\u00fck fayda sa\u011flar. Bulut tabanl\u0131 altyap\u0131larda kaynaklar kulland\u0131k\u00e7a \u00f6de (pay-as-you-go) modeliyle faturaland\u0131r\u0131l\u0131r. E\u011fer konteynerleriniz gere\u011finden fazla CPU veya bellek kayna\u011f\u0131na sahipse, bu do\u011frudan gereksiz maliyetlere yol a\u00e7ar. Kaynak kullan\u0131m\u0131n\u0131 izleyerek, her bir konteynere veya servise ger\u00e7ekten ihtiya\u00e7 duydu\u011fu kadar kaynak atayabilir, b\u00f6ylece altyap\u0131 maliyetlerinizde \u00f6nemli tasarruflar sa\u011flayabilirsiniz. Bir ba\u015fka a\u00e7\u0131dan, yetersiz kaynak tahsisi de performans sorunlar\u0131na ve dolay\u0131s\u0131yla m\u00fc\u015fteri memnuniyetsizli\u011fine yol a\u00e7arak dolayl\u0131 maliyetler yaratabilir. Do\u011fru dengeyi bulmak, s\u00fcrekli izleme ile m\u00fcmk\u00fcnd\u00fcr.<\/p>\n \u00dc\u00e7\u00fcnc\u00fc olarak, uygulama kararl\u0131l\u0131\u011f\u0131 ve g\u00fcvenilirli\u011fi<\/strong> i\u00e7in izleme vazge\u00e7ilmezdir. Bir konteynerin a\u015f\u0131r\u0131 kaynak t\u00fcketimi, ayn\u0131 ana makine \u00fczerinde \u00e7al\u0131\u015fan di\u011fer konteynerleri de olumsuz etkileyebilir ve “kom\u015fu g\u00fcr\u00fclt\u00fcs\u00fc” (noisy neighbor) sorununa yol a\u00e7abilir. Bu durum, t\u00fcm sistemin karars\u0131zla\u015fmas\u0131na ve hatta \u00e7\u00f6kmesine neden olabilir. Erken uyar\u0131 sistemleri kurarak ve anormallikleri izleyerek, potansiyel sorunlar\u0131 b\u00fcy\u00fcmeden \u00f6nce tespit edip \u00e7\u00f6zebilirsiniz. Bu, \u00f6zellikle kritik i\u015f y\u00fckleri ve 7\/24 hizmet vermesi gereken uygulamalar i\u00e7in hayati \u00f6neme sahiptir.<\/p>\n Son olarak, kapasite planlamas\u0131<\/strong> i\u00e7in izleme verileri paha bi\u00e7ilmezdir. Uygulaman\u0131z\u0131n gelecekteki b\u00fcy\u00fcmesini ve artan y\u00fck\u00fc kar\u015f\u0131layabilmesi i\u00e7in ne kadar ek kayna\u011fa ihtiya\u00e7 duyaca\u011f\u0131n\u0131z\u0131 tahmin etmek, ge\u00e7mi\u015fe d\u00f6n\u00fck kaynak kullan\u0131m verileriyle \u00e7ok daha kolayd\u0131r. Belirli d\u00f6nemlerde (\u00f6rne\u011fin, \u00f6zel indirim g\u00fcnleri veya sezonluk yo\u011funluklar) kaynak t\u00fcketiminin nas\u0131l de\u011fi\u015fti\u011fini analiz ederek, altyap\u0131n\u0131z\u0131 buna g\u00f6re \u00f6l\u00e7eklendirebilir ve beklenmedik performans d\u00fc\u015f\u00fc\u015flerinin \u00f6n\u00fcne ge\u00e7ebilirsiniz. Bu, \u00f6zellikle s\u00fcrekli geni\u015fleyen ve kullan\u0131c\u0131 say\u0131s\u0131 artan platformlar i\u00e7in stratejik bir ad\u0131md\u0131r.<\/p>\n K\u0131sacas\u0131, Docker konteynerlerinin CPU ve bellek kullan\u0131m\u0131n\u0131 izlemek, modern DevOps pratiklerinin temel ta\u015flar\u0131ndan biridir. Bu, sadece teknik bir gereklilik de\u011fil, ayn\u0131 zamanda i\u015f s\u00fcreklili\u011fi, maliyet verimlili\u011fi ve m\u00fc\u015fteri memnuniyeti a\u00e7\u0131s\u0131ndan stratejik bir yat\u0131r\u0131md\u0131r. \u0130zleme sayesinde, konteynerize edilmi\u015f uygulamalar\u0131n\u0131z\u0131n her zaman en y\u00fcksek performansta ve en verimli \u015fekilde \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flayabilirsiniz.<\/p>\n Docker, konteynerlerin temel kaynak kullan\u0131m\u0131n\u0131 h\u0131zl\u0131 ve kolay bir \u015fekilde izlemek i\u00e7in birka\u00e7 dahili komut sat\u0131r\u0131 arac\u0131 sunar. Bu ara\u00e7lar, karma\u015f\u0131k bir izleme altyap\u0131s\u0131 kurmaya gerek kalmadan anl\u0131k durum tespiti yapmak i\u00e7in olduk\u00e7a kullan\u0131\u015fl\u0131d\u0131r. \u00d6zellikle geli\u015ftirme ortamlar\u0131nda veya h\u0131zl\u0131 sorun giderme senaryolar\u0131nda bu komutlar adeta bir cankurtaran g\u00f6revi g\u00f6r\u00fcr. \u015eimdi bu temel ara\u00e7lara ve kullan\u0131mlar\u0131na daha yak\u0131ndan bakal\u0131m.<\/p>\n Varsay\u0131lan olarak, \u00c7\u0131kt\u0131 genellikle a\u015fa\u011f\u0131daki gibi bir tablo format\u0131nda olacakt\u0131r:<\/p>\n Bu \u00e7\u0131kt\u0131da dikkat etmeniz gereken baz\u0131 \u00f6nemli s\u00fctunlar \u015funlard\u0131r:<\/p>\n Belirli bir konteyneri izlemek isterseniz, komutun sonuna konteyner ID’sini veya ad\u0131n\u0131 ekleyebilirsiniz:<\/p>\n Bir konteynerin neden y\u00fcksek CPU veya bellek kulland\u0131\u011f\u0131n\u0131 merak ediyorsan\u0131z, sorunun kayna\u011f\u0131n\u0131 bulmak i\u00e7in konteynerin i\u00e7indeki s\u00fcre\u00e7leri incelemek isteyebilirsiniz. Bu komutun \u00e7\u0131kt\u0131s\u0131, ana makinedeki Konteynerin mevcut kaynak kullan\u0131m\u0131n\u0131 g\u00f6rmek kadar, ona atanan kaynak limitlerini de bilmek \u00f6nemlidir. Bu komutun \u00e7\u0131kt\u0131s\u0131nda, Bu dahili Docker ara\u00e7lar\u0131, konteynerlerinizin kaynak kullan\u0131m\u0131n\u0131 h\u0131zl\u0131ca anlamak ve anl\u0131k sorunlar\u0131 gidermek i\u00e7in m\u00fckemmel bir ba\u015flang\u0131\u00e7 noktas\u0131d\u0131r. Ancak, b\u00fcy\u00fck \u00f6l\u00e7ekli \u00fcretim ortamlar\u0131nda veya uzun vadeli performans analizi gerektiren durumlarda, daha geli\u015fmi\u015f ve merkezi izleme \u00e7\u00f6z\u00fcmlerine ihtiya\u00e7 duyulur. Bu ara\u00e7lar, sadece “o an” ne oldu\u011funu g\u00f6sterir; “ge\u00e7mi\u015fte ne oldu” veya “gelecekte ne olabilir” gibi sorulara yan\u0131t veremezler. \u0130\u015fte bu noktada, Prometheus ve Grafana gibi harici \u00e7\u00f6z\u00fcmler devreye girer.<\/p>\n Docker’\u0131n dahili izleme ara\u00e7lar\u0131, anl\u0131k durum tespiti i\u00e7in kullan\u0131\u015fl\u0131 olsa da, b\u00fcy\u00fck \u00f6l\u00e7ekli ve dinamik konteyner ortamlar\u0131nda yetersiz kal\u0131r. Ger\u00e7ek zamanl\u0131 uyar\u0131lar, ge\u00e7mi\u015fe d\u00f6n\u00fck veri analizi, merkezi bir g\u00f6r\u00fcn\u00fcm ve \u00f6zelle\u015ftirilebilir g\u00f6sterge tablolar\u0131 gibi geli\u015fmi\u015f \u00f6zellikler i\u00e7in harici izleme \u00e7\u00f6z\u00fcmlerine ihtiya\u00e7 duyar\u0131z. Bu alanda en pop\u00fcler ve g\u00fc\u00e7l\u00fc kombinasyonlardan biri Prometheus ve Grafana’d\u0131r. Bu ikili, konteyner metriklerini toplamak, depolamak, g\u00f6rselle\u015ftirmek ve uyar\u0131lar olu\u015fturmak i\u00e7in kapsaml\u0131 bir \u00e7\u00f6z\u00fcm sunar.<\/p>\n Dahili ara\u00e7lar\u0131n aksine, harici \u00e7\u00f6z\u00fcmlerin sundu\u011fu avantajlar \u015funlard\u0131r:<\/p>\n Prometheus, CNCF (Cloud Native Computing Foundation) taraf\u0131ndan desteklenen a\u00e7\u0131k kaynakl\u0131 bir zaman serisi veritaban\u0131 ve izleme sistemidir. Temel \u00e7al\u0131\u015fma prensibi “\u00e7ekme” (pull) modelidir; yani izlenecek hedeflerden (uygulamalar, servisler, ana makineler) d\u00fczenli aral\u0131klarla metrikleri \u00e7eker ve kendi veritaban\u0131nda depolar. Prometheus, zengin bir sorgu dili olan PromQL’i kullanarak toplanan metrikler \u00fczerinde karma\u015f\u0131k analizler yap\u0131lmas\u0131na olanak tan\u0131r.<\/p>\n Docker konteynerlerinden metrik toplamak i\u00e7in genellikle cAdvisor<\/strong> (Container Advisor) ad\u0131 verilen bir ara\u00e7 kullan\u0131l\u0131r. cAdvisor, Google taraf\u0131ndan geli\u015ftirilmi\u015f ve Docker ile entegre olan, \u00e7al\u0131\u015fan konteynerlerin kaynak kullan\u0131m\u0131n\u0131 (CPU, bellek, a\u011f, disk I\/O) toplayan ve bu metrikleri Prometheus’un anlayabilece\u011fi formatta ( Bu komut, cAdvisor’\u0131 8080 portunda \u00e7al\u0131\u015ft\u0131r\u0131r ve Docker ana makinesinin \u00e7e\u015fitli dizinlerine salt okunur eri\u015fim sa\u011flayarak konteyner metriklerini toplamas\u0131na izin verir. cAdvisor \u00e7al\u0131\u015ft\u0131\u011f\u0131nda, Prometheus’un yap\u0131land\u0131rma dosyas\u0131nda ( Prometheus, bu yap\u0131land\u0131rma sayesinde Prometheus metrikleri depolasa da, bunlar\u0131 anlaml\u0131 bir \u015fekilde g\u00f6rselle\u015ftirmek ve izlemek i\u00e7in genellikle Grafana kullan\u0131l\u0131r. Grafana, a\u00e7\u0131k kaynakl\u0131 bir veri g\u00f6rselle\u015ftirme ve g\u00f6sterge paneli (dashboard) arac\u0131d\u0131r. Prometheus, Elasticsearch, Graphite, InfluxDB gibi bir\u00e7ok veri kayna\u011f\u0131n\u0131 destekler ve kullan\u0131c\u0131lar\u0131n bu verilerle etkile\u015fimli, \u00f6zelle\u015ftirilebilir panolar olu\u015fturmas\u0131na olanak tan\u0131r.<\/p>\n Grafana’y\u0131 da bir Docker konteyneri olarak \u00e7al\u0131\u015ft\u0131rmak olduk\u00e7a basittir:<\/p>\n Grafana \u00e7al\u0131\u015ft\u0131\u011f\u0131nda, web taray\u0131c\u0131n\u0131zdan Hayal edin ki, bir e-ticaret platformunuz var ve bu platform, bir Nginx web sunucusu, bir Node.js API servisi ve bir MongoDB veritaban\u0131 olmak \u00fczere \u00fc\u00e7 ana Docker konteynerinden olu\u015fuyor. Yo\u011fun sat\u0131\u015f d\u00f6nemlerinde (\u00f6rne\u011fin, “Kara Cuma” indirimleri) uygulaman\u0131z\u0131n performans\u0131nda d\u00fc\u015f\u00fc\u015fler ya\u015fan\u0131yor ve m\u00fc\u015fterilerden \u015fikayetler geliyor. Bu durumu \u00e7\u00f6zmek i\u00e7in Prometheus ve Grafana’y\u0131 devreye sokmaya karar verdiniz.<\/p>\n Bu vaka analizi, Prometheus ve Grafana’n\u0131n sadece anl\u0131k durumu g\u00f6stermekle kalmay\u0131p, ge\u00e7mi\u015f verileri analiz ederek sorunlar\u0131n k\u00f6k nedenlerini bulmada ve proaktif \u00e7\u00f6z\u00fcmler \u00fcretmede ne kadar g\u00fc\u00e7l\u00fc oldu\u011funu ortaya koymaktad\u0131r. Merkezi bir izleme platformu, karma\u015f\u0131k konteynerize edilmi\u015f uygulamalar\u0131n sa\u011fl\u0131\u011f\u0131n\u0131 ve performans\u0131n\u0131 y\u00f6netmek i\u00e7in vazge\u00e7ilmezdir.<\/p>\n Konteynerlerin CPU ve bellek kullan\u0131m\u0131n\u0131 izlemek, performans sorunlar\u0131n\u0131 tespit etmenin \u00f6nemli bir par\u00e7as\u0131d\u0131r. Ancak, bu metrikler tek ba\u015f\u0131na her zaman sorunun tam resmini vermeyebilir. Bir konteynerin neden aniden y\u00fcksek CPU kullanmaya ba\u015flad\u0131\u011f\u0131n\u0131 veya bellek s\u0131z\u0131nt\u0131s\u0131 ya\u015fad\u0131\u011f\u0131n\u0131 anlamak i\u00e7in, genellikle o konteynerin \u00fcretti\u011fi log (g\u00fcnl\u00fck) kay\u0131tlar\u0131na da bakmak gerekir. Loglar, uygulaman\u0131n i\u00e7 i\u015fleyi\u015fi, hata mesajlar\u0131, uyar\u0131lar ve kullan\u0131c\u0131 etkile\u015fimleri hakk\u0131nda de\u011ferli bilgiler sa\u011flar. Bu nedenle, merkezi loglama \u00e7\u00f6z\u00fcmleri, kaynak izleme ile birlikte kullan\u0131ld\u0131\u011f\u0131nda \u00e7ok daha g\u00fc\u00e7l\u00fc bir sorun giderme ve anomali tespit arac\u0131 haline gelir.<\/p>\n Bir konteynerin CPU veya bellek kullan\u0131m\u0131nda anormal bir art\u0131\u015f g\u00f6rd\u00fc\u011f\u00fcn\u00fczde, bu art\u0131\u015f\u0131n nedenini a\u00e7\u0131klayabilecek ipu\u00e7lar\u0131n\u0131 loglarda bulabilirsiniz. \u00d6rne\u011fin:<\/p>\n Bu t\u00fcr senaryolarda, sadece metrikleri de\u011fil, ayn\u0131 zamanda loglar\u0131 da merkezi bir yerde toplay\u0131p analiz etmek, sorunun k\u00f6k nedenini \u00e7ok daha h\u0131zl\u0131 ve do\u011fru bir \u015fekilde tespit etmenizi sa\u011flar.<\/p>\n Merkezi loglama i\u00e7in piyasada bir\u00e7ok g\u00fc\u00e7l\u00fc \u00e7\u00f6z\u00fcm bulunmaktad\u0131r. En pop\u00fcler a\u00e7\u0131k kaynakl\u0131 \u00e7\u00f6z\u00fcmlerden biri ELK Stack<\/strong>‘tir (\u015fimdi Elastic Stack olarak da bilinir). Bu y\u0131\u011f\u0131n \u00fc\u00e7 ana bile\u015fenden olu\u015fur:<\/p>\n Alternatif olarak, Splunk<\/strong> gibi ticari \u00e7\u00f6z\u00fcmler de benzer i\u015flevsellik sunar ve b\u00fcy\u00fck kurumsal ortamlarda yayg\u0131n olarak kullan\u0131l\u0131r. Splunk, log toplama, indeksleme, arama, raporlama ve uyar\u0131 mekanizmalar\u0131 konular\u0131nda kapsaml\u0131 yeteneklere sahiptir.<\/p>\n Docker konteynerlerinden log toplamak i\u00e7in genellikle Docker’\u0131n kendi loglama s\u00fcr\u00fcc\u00fcleri (\u00f6rne\u011fin, Loglar merkezi bir yerde topland\u0131\u011f\u0131nda, Kibana gibi ara\u00e7lar sayesinde CPU veya bellek metriklerinizdeki anormallikler ile loglardaki olaylar\u0131 korele edebilirsiniz. \u00d6rne\u011fin, Prometheus’tan gelen bir uyar\u0131 (Node.js konteyneri %90 CPU kullan\u0131yor) ile Kibana’da o konteynerin loglar\u0131n\u0131 filtreleyerek e\u015f zamanl\u0131 olarak hangi hata mesajlar\u0131n\u0131n veya yo\u011fun i\u015flemlerin ger\u00e7ekle\u015fti\u011fini g\u00f6rebilirsiniz. Bu sayede, “Ne oldu?” sorusunun cevab\u0131n\u0131 metriklerden al\u0131rken, “Neden oldu?” sorusunun cevab\u0131n\u0131 loglardan bulabilirsiniz.<\/p>\n Bir bankac\u0131l\u0131k uygulamas\u0131n\u0131n mikroservis mimarisinde \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 ve bu uygulaman\u0131n binlerce m\u00fc\u015fteriye hizmet verdi\u011fini d\u00fc\u015f\u00fcnelim. Bir sabah, Prometheus’tan “Hesap Bakiyesi Servisi” konteynerinin CPU kullan\u0131m\u0131n\u0131n normalin \u00e7ok \u00fczerinde seyretti\u011fi ve bellek t\u00fcketiminin de h\u0131zla artt\u0131\u011f\u0131na dair bir uyar\u0131 ald\u0131n\u0131z. Hemen Grafana panolar\u0131n\u0131za bakt\u0131n\u0131z ve bu durumu do\u011frulad\u0131n\u0131z.<\/p>\n \u015eimdi s\u0131ra loglarda. Kibana’ya girerek, ayn\u0131 zaman dilimi i\u00e7inde “Hesap Bakiyesi Servisi”ne ait loglar\u0131 filtrelediniz. Loglarda, beklenenden \u00e7ok daha fazla say\u0131da “Veritaban\u0131 ba\u011flant\u0131 hatas\u0131” ve “Tekrar deneme (retry)” mesajlar\u0131 oldu\u011funu fark ettiniz. Bu hatalar\u0131n, belirli bir veritaban\u0131 sunucusundan geldi\u011fini de g\u00f6rd\u00fcn\u00fcz. Ayr\u0131ca, her bir tekrar deneme i\u015fleminin yo\u011fun CPU ve bellek kayna\u011f\u0131 t\u00fcketti\u011fi anla\u015f\u0131ld\u0131.<\/p>\n Bu korelasyon sayesinde, sorunun do\u011frudan “Hesap Bakiyesi Servisi” uygulamas\u0131ndan veya Docker konteynerinden kaynaklanmad\u0131\u011f\u0131n\u0131, asl\u0131nda veritaban\u0131 ba\u011flant\u0131 sorunlar\u0131 nedeniyle uygulaman\u0131n s\u00fcrekli tekrar denemeler yaparak CPU ve belle\u011fi t\u00fcketti\u011fini tespit ettiniz. Veritaban\u0131 ekibiyle ileti\u015fime ge\u00e7ildi\u011finde, ilgili veritaban\u0131 sunucusunda bir bak\u0131m \u00e7al\u0131\u015fmas\u0131 yap\u0131ld\u0131\u011f\u0131 veya bir a\u011f kesintisi ya\u015fand\u0131\u011f\u0131 ortaya \u00e7\u0131kt\u0131. Sorunu veritaban\u0131 taraf\u0131nda \u00e7\u00f6zd\u00fckten sonra, “Hesap Bakiyesi Servisi” konteynerinin CPU ve bellek kullan\u0131m\u0131 normale d\u00f6nd\u00fc.<\/p>\n Bu \u00f6rnek, metrik izleme ve merkezi loglama aras\u0131ndaki sinerjinin ne kadar \u00f6nemli oldu\u011funu g\u00f6stermektedir. Birbirini tamamlayan bu iki yakla\u015f\u0131m, karma\u015f\u0131k konteyner ortamlar\u0131nda sorunlar\u0131 h\u0131zl\u0131ca te\u015fhis etmek ve \u00e7\u00f6zmek i\u00e7in g\u00fc\u00e7l\u00fc bir kombinasyon sunar. Sadece “ne” oldu\u011funu de\u011fil, ayn\u0131 zamanda “neden” oldu\u011funu da anlamak, sistemlerinizin istikrarl\u0131 ve g\u00fcvenilir \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flaman\u0131n anahtar\u0131d\u0131r.<\/p>\n Konteynerlerin CPU ve bellek kullan\u0131m\u0131n\u0131 izlemek, sadece sorunlar\u0131 tespit etmekle kalmaz, ayn\u0131 zamanda bu sorunlar\u0131 \u00f6nlemek ve kaynaklar\u0131 daha verimli kullanmak i\u00e7in de bir temel olu\u015fturur. \u0130zleme verilerini kullanarak, konteynerlerinize do\u011fru kaynak limitlerini atayabilir, sa\u011fl\u0131k kontrolleriyle uygulamalar\u0131n durumunu denetleyebilir ve de\u011fi\u015fen y\u00fcklere g\u00f6re otomatik \u00f6l\u00e7ekleme stratejileri geli\u015ftirebilirsiniz. Etkin kaynak y\u00f6netimi, hem uygulaman\u0131z\u0131n performans\u0131n\u0131 ve kararl\u0131l\u0131\u011f\u0131n\u0131 art\u0131r\u0131r hem de altyap\u0131 maliyetlerinizi optimize eder.<\/p>\n Docker, bir konteynerin kullanabilece\u011fi CPU ve bellek miktar\u0131n\u0131 s\u0131n\u0131rlaman\u0131za olanak tan\u0131r. Bu, \u00f6zellikle ayn\u0131 ana makine \u00fczerinde birden fazla konteyner \u00e7al\u0131\u015ft\u0131r\u0131rken “kom\u015fu g\u00fcr\u00fclt\u00fcs\u00fc” sorununu \u00f6nlemek ve her konteynere adil bir kaynak dilimi sa\u011flamak i\u00e7in kritik \u00f6neme sahiptir. \u0130ki ana kavram vard\u0131r:<\/p>\n Bu parametreleri Veya Docker Compose ile:<\/p>\n Do\u011fru limitleri belirlemek i\u00e7in, konteynerlerinizin ortalama ve tepe kaynak kullan\u0131m\u0131n\u0131 izleme verilerinizden (Prometheus\/Grafana) analiz etmeniz gerekir. A\u015f\u0131r\u0131 d\u00fc\u015f\u00fck limitler performans\u0131 d\u00fc\u015f\u00fcr\u00fcrken, a\u015f\u0131r\u0131 y\u00fcksek limitler kaynak israf\u0131na yol a\u00e7ar.<\/p>\n Bir konteynerin \u00e7al\u0131\u015f\u0131yor olmas\u0131, uygulaman\u0131n i\u00e7inde d\u00fczg\u00fcn \u00e7al\u0131\u015ft\u0131\u011f\u0131 anlam\u0131na gelmez. \u00d6rne\u011fin, bir web sunucusu konteyneri \u00e7al\u0131\u015f\u0131yor olabilir ancak i\u00e7erisindeki uygulama veritaban\u0131na ba\u011flanamad\u0131\u011f\u0131 i\u00e7in hata veriyor olabilir. Docker sa\u011fl\u0131k kontrolleri ( Bir Bu \u00f6rnekte, Nginx konteyneri her 5 saniyede bir De\u011fi\u015fken i\u015f y\u00fcklerine sahip uygulamalar i\u00e7in manuel kaynak y\u00f6netimi pratik de\u011fildir. Yo\u011funluk artt\u0131\u011f\u0131nda uygulaman\u0131n performans\u0131n\u0131n d\u00fc\u015fmesini engellemek ve gereksiz maliyetlerden ka\u00e7\u0131nmak i\u00e7in otomatik \u00f6l\u00e7ekleme (auto-scaling) mekanizmalar\u0131na ihtiya\u00e7 duyar\u0131z. Konteyner orkestrasyon platformlar\u0131, bu konuda g\u00fc\u00e7l\u00fc yetenekler sunar:<\/p>\n Otomatik \u00f6l\u00e7ekleme stratejileri, izleme verilerine dayan\u0131r. Prometheus gibi bir sistemden toplanan CPU ve bellek metrikleri, otomatik \u00f6l\u00e7ekleme kararlar\u0131n\u0131n tetikleyicisi olarak kullan\u0131l\u0131r. Bu sayede, uygulaman\u0131z her zaman en uygun kaynaklarla \u00e7al\u0131\u015f\u0131r, performans d\u00fc\u015f\u00fc\u015fleri ya\u015fanmaz ve maliyetler kontrol alt\u0131nda tutulur. Bu, modern bulut yerel (cloud-native) uygulamalar\u0131n esneklik ve dayan\u0131kl\u0131l\u0131k hedeflerine ula\u015fmas\u0131nda kilit bir rol oynar.<\/p>\n Sonu\u00e7 olarak, konteyner kaynaklar\u0131n\u0131 etkin bir \u015fekilde y\u00f6netmek, sadece anl\u0131k izleme yapmakla kalmaz, ayn\u0131 zamanda gelece\u011fe y\u00f6nelik planlama, proaktif sorun \u00f6nleme ve dinamik \u00f6l\u00e7eklendirme stratejilerini de i\u00e7erir. \u0130zleme verilerini kullanarak do\u011fru limitleri belirlemek, sa\u011fl\u0131k kontrolleriyle uygulaman\u0131n i\u00e7 durumunu anlamak ve otomatik \u00f6l\u00e7ekleme ile de\u011fi\u015fen y\u00fcklere adapte olmak, modern konteynerize edilmi\u015f uygulamalar\u0131n ba\u015far\u0131s\u0131 i\u00e7in vazge\u00e7ilmezdir.<\/p>\n En iyi y\u00f6ntem, ihtiya\u00e7lar\u0131n\u0131za ve altyap\u0131n\u0131z\u0131n karma\u015f\u0131kl\u0131\u011f\u0131na ba\u011fl\u0131d\u0131r. H\u0131zl\u0131 ve anl\u0131k durum tespiti i\u00e7in Kaynak limitleri (CPU, bellek), bir konteynerin kullanabilece\u011fi maksimum kaynak miktar\u0131n\u0131 k\u0131s\u0131tlar. Bu, ayn\u0131 ana makine \u00fczerinde \u00e7al\u0131\u015fan di\u011fer konteynerlerin performans\u0131n\u0131 korumak (“kom\u015fu g\u00fcr\u00fclt\u00fcs\u00fc” sorununu \u00f6nlemek) ve tek bir konteynerin t\u00fcm sistem kaynaklar\u0131n\u0131 t\u00fcketmesini engellemek i\u00e7in \u00f6nemlidir. Ayr\u0131ca, kaynak israf\u0131n\u0131 \u00f6nleyerek maliyet optimizasyonuna da yard\u0131mc\u0131 olur ve kapasite planlamas\u0131 i\u00e7in temel olu\u015fturur.<\/p>\n \u0130zleme ara\u00e7lar\u0131, metrik toplama i\u015flemleri nedeniyle \u00e7ok k\u00fc\u00e7\u00fck bir performans y\u00fck\u00fc olu\u015fturabilir. Ancak modern izleme sistemleri (Prometheus, cAdvisor gibi) genellikle olduk\u00e7a hafif olacak \u015fekilde tasarlanm\u0131\u015ft\u0131r ve bu y\u00fck genellikle ihmal edilebilir d\u00fczeydedir. Yine de, binlerce konteynerin oldu\u011fu \u00e7ok b\u00fcy\u00fck \u00f6l\u00e7ekli ortamlarda, izleme sisteminin kendi kaynak t\u00fcketimini de optimize etmek ve izlemek \u00f6nemlidir.<\/p>\n En \u00f6ncelikli metrikler \u015funlard\u0131r: CPU kullan\u0131m\u0131 (y\u00fczde veya \u00e7ekirdek baz\u0131nda), bellek kullan\u0131m\u0131 (mutlak de\u011fer ve y\u00fczde olarak), a\u011f G\/\u00c7 (g\u00f6nderilen\/al\u0131nan bayt) ve disk G\/\u00c7 (okunan\/yaz\u0131lan bayt). Bunlara ek olarak, uygulaman\u0131n kendi metrikleri (istek say\u0131s\u0131, hata oranlar\u0131, yan\u0131t s\u00fcreleri) ve sa\u011fl\u0131k durumu (sa\u011fl\u0131k kontrol\u00fc sonu\u00e7lar\u0131) da kritik \u00f6neme sahiptir. Bu metriklerin birle\u015fimi, uygulaman\u0131z\u0131n ve konteynerlerinizin genel sa\u011fl\u0131\u011f\u0131 hakk\u0131nda kapsaml\u0131 bir g\u00f6r\u00fcn\u00fcm sunar.<\/p>\n Docker konteynerlerinin CPU ve bellek kullan\u0131m\u0131n\u0131 izlemek, modern uygulama geli\u015ftirme ve operasyon s\u00fcre\u00e7lerinin ayr\u0131lmaz bir par\u00e7as\u0131d\u0131r. Geli\u015ftirme ortam\u0131ndan \u00fcretime kadar her a\u015famada, konteynerlerin kaynak t\u00fcketimini anlamak, uygulamalar\u0131n\u0131z\u0131n istikrarl\u0131, performansl\u0131 ve maliyet etkin bir \u015fekilde \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flaman\u0131n anahtar\u0131d\u0131r. Bu makalede ele ald\u0131\u011f\u0131m\u0131z gibi, Docker’\u0131n dahili Ayr\u0131ca, merkezi loglama \u00e7\u00f6z\u00fcmleri olan ELK Stack veya Splunk gibi ara\u00e7larla metrik izlemeyi birle\u015ftirmek, performans anormalliklerinin k\u00f6k nedenlerini tespit etmede paha bi\u00e7ilmez bir sinerji yarat\u0131r. \u0130zleme verileriyle desteklenen do\u011fru kaynak limitleri belirlemek, sa\u011fl\u0131k kontrolleriyle uygulaman\u0131n i\u00e7sel durumunu anlamak ve Kubernetes veya Docker Swarm gibi orkestrasyon ara\u00e7lar\u0131yla otomatik \u00f6l\u00e7ekleme stratejilerini uygulamak, konteynerize edilmi\u015f altyap\u0131lar\u0131n esnekli\u011fini ve dayan\u0131kl\u0131l\u0131\u011f\u0131n\u0131 maksimum seviyeye \u00e7\u0131kar\u0131r.<\/p>\n Unutmay\u0131n ki, izleme bir kerelik bir i\u015flem de\u011fildir; s\u00fcrekli bir s\u00fcre\u00e7tir. Uygulamalar\u0131n\u0131z geli\u015ftik\u00e7e, i\u015f y\u00fckleriniz de\u011fi\u015ftik\u00e7e ve altyap\u0131n\u0131z geni\u015fledik\u00e7e, izleme stratejilerinizi de d\u00fczenli olarak g\u00f6zden ge\u00e7irmeli ve g\u00fcncellemelisiniz. Bu sayede, Docker konteynerlerinizin potansiyelini tam olarak kullanabilir ve dijital hizmetlerinizin her zaman en iyi performansta \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flayabilirsiniz.<\/p>\n #Docker #Konteyner #\u0130zleme #Performans #DevOps #Prometheus #Grafana #ElasticStack<\/p>\nDocker’\u0131n Dahili \u0130zleme Ara\u00e7lar\u0131 Nelerdir ve Nas\u0131l Kullan\u0131l\u0131r?<\/h2>\n
docker stats<\/code> Komutu: Canl\u0131 Kaynak Kullan\u0131m\u0131na H\u0131zl\u0131 Bir Bak\u0131\u015f<\/h3>\ndocker stats<\/code> komutu, \u00e7al\u0131\u015fan konteynerlerin CPU, bellek, a\u011f G\/\u00c7 (I\/O) ve disk G\/\u00c7 gibi kaynak kullan\u0131m istatistiklerini ger\u00e7ek zamanl\u0131 olarak g\u00f6sterir. Bu komut, Unix sistemlerindeki top<\/code> komutuna benzer bir aray\u00fcz sunar ve her birka\u00e7 saniyede bir g\u00fcncellenen dinamik bir tablo g\u00f6r\u00fcnt\u00fcler. Bu sayede, hangi konteynerin ne kadar kaynak t\u00fcketti\u011fini anl\u0131k olarak takip edebilirsiniz.<\/p>\ndocker stats<\/code> komutunu parametresiz \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131n\u0131zda, \u00e7al\u0131\u015fan t\u00fcm konteynerlerin istatistiklerini g\u00f6r\u00fcrs\u00fcn\u00fcz:<\/p>\ndocker stats<\/code><\/pre>\n<\/p><\/div>\nCONTAINER ID NAME CPU % MEM USAGE \/ LIMIT MEM % NET I\/O BLOCK I\/O PIDS\na1b2c3d4e5f6 my-web-app 0.12% 12.3MiB \/ 1.952GiB 0.62% 7.81kB \/ 4.54kB 0B \/ 0B 7\nf7e6d5c4b3a2 my-db-server 0.05% 25.6MiB \/ 1.952GiB 1.28% 12.3kB \/ 8.76kB 0B \/ 0B 12<\/code><\/pre>\n<\/p><\/div>\n\n
CPU %<\/code>: Konteynerin CPU kullan\u0131m y\u00fczdesi. Y\u00fcksek de\u011ferler, konteynerin yo\u011fun i\u015flem yapt\u0131\u011f\u0131n\u0131 veya bir performans sorunu ya\u015fad\u0131\u011f\u0131n\u0131 g\u00f6sterebilir.<\/li>\nMEM USAGE \/ LIMIT<\/code>: Konteynerin anl\u0131k bellek kullan\u0131m\u0131 ve kendisine atanan bellek limiti. Bu limit, e\u011fer belirlenmi\u015fse, konteynerin ne kadar bellek kullanabilece\u011fini g\u00f6sterir.<\/li>\nMEM %<\/code>: Konteynerin atanan bellek limitine g\u00f6re bellek kullan\u0131m y\u00fczdesi. Bu de\u011fer %100’e yakla\u015ft\u0131\u011f\u0131nda veya a\u015ft\u0131\u011f\u0131nda, bellek yetersizli\u011fi sorunlar\u0131 ya\u015fanabilir.<\/li>\nNET I\/O<\/code>: Konteynerin a\u011f \u00fczerinden g\u00f6nderdi\u011fi ve ald\u0131\u011f\u0131 veri miktar\u0131.<\/li>\nBLOCK I\/O<\/code>: Konteynerin disk \u00fczerinde yapt\u0131\u011f\u0131 okuma ve yazma i\u015flemleri.<\/li>\n<\/ul>\ndocker stats my-web-app<\/code><\/pre>\n<\/p><\/div>\ndocker stats<\/code> komutu, anl\u0131k durum tespiti i\u00e7in harika olsa da, ge\u00e7mi\u015fe d\u00f6n\u00fck veri depolamaz veya geli\u015fmi\u015f uyar\u0131 mekanizmalar\u0131 sunmaz. Bu nedenle, daha kapsaml\u0131 izleme senaryolar\u0131 i\u00e7in yetersiz kalabilir.<\/p>\ndocker top<\/code> Komutu: Konteyner \u0130\u00e7indeki S\u00fcre\u00e7leri G\u00f6r\u00fcnt\u00fcleme<\/h3>\ndocker top<\/code> komutu tam olarak bu i\u015fe yarar. Belirli bir konteynerin i\u00e7inde \u00e7al\u0131\u015fan t\u00fcm s\u00fcre\u00e7leri, PID (Process ID), CPU kullan\u0131m y\u00fczdesi ve bellek kullan\u0131m\u0131 gibi detaylarla birlikte listeler.<\/p>\ndocker top my-web-app<\/code><\/pre>\n<\/p><\/div>\ntop<\/code> komutunun \u00e7\u0131kt\u0131s\u0131na benzerdir ve konteyner i\u00e7inde hangi s\u00fcrecin (\u00f6rne\u011fin, bir Python uygulamas\u0131, bir Nginx web sunucusu veya bir veritaban\u0131 motoru) en \u00e7ok kaynak t\u00fcketti\u011fini g\u00f6rmenizi sa\u011flar. Bu bilgi, bir performans sorununun do\u011frudan hangi uygulama bile\u015feninden kaynakland\u0131\u011f\u0131n\u0131 anlamak i\u00e7in \u00e7ok de\u011ferlidir.<\/p>\ndocker inspect<\/code> Komutu: Detayl\u0131 Konteyner Yap\u0131land\u0131rmas\u0131 ve Kaynak Limitleri<\/h3>\ndocker inspect<\/code> komutu, bir konteynerin veya Docker objesinin (imaj, a\u011f, hacim vb.) t\u00fcm detayl\u0131 yap\u0131land\u0131rma bilgilerini JSON format\u0131nda d\u00f6nd\u00fcr\u00fcr. Bu bilgiler aras\u0131nda, konteynere atanan CPU ve bellek limitleri de bulunur.<\/p>\ndocker inspect my-web-app<\/code><\/pre>\n<\/p><\/div>\n\"HostConfig\"<\/code> b\u00f6l\u00fcm\u00fc alt\u0131nda \"CpuShares\"<\/code>, \"Memory\"<\/code>, \"MemorySwap\"<\/code> gibi alanlar\u0131 arayarak konteynerin kaynak k\u0131s\u0131tlamalar\u0131n\u0131 g\u00f6rebilirsiniz. \u00d6rne\u011fin, e\u011fer bir konteynere --memory=512m<\/code> parametresiyle 512 MB bellek limiti atad\u0131ysan\u0131z, bu bilgiyi docker inspect<\/code> \u00e7\u0131kt\u0131s\u0131nda bulabilirsiniz. Bu, bir konteynerin neden bellek yetersizli\u011fi hatas\u0131 verdi\u011fini anlamak veya kaynak tahsisini do\u011frulamak i\u00e7in kritik bir bilgidir.<\/p>\nGeli\u015fmi\u015f \u0130zleme \u00c7\u00f6z\u00fcmleri: Prometheus ve Grafana Entegrasyonu ile Daha Derin Analizler<\/h2>\n
Neden Harici \u0130zleme Ara\u00e7lar\u0131na \u0130htiya\u00e7 Duyar\u0131z?<\/h3>\n
\n
Prometheus Nedir ve Metrikleri Nas\u0131l Toplar?<\/h3>\n
\/metrics<\/code> endpoint’i \u00fczerinden) sunan bir arac\u0131d\u0131r. cAdvisor’\u0131 bir Docker konteyneri olarak \u00e7al\u0131\u015ft\u0131rmak olduk\u00e7a kolayd\u0131r:<\/p>\ndocker run \\\n --volume=\/:\/rootfs:ro \\\n --volume=\/var\/run:\/var\/run:ro \\\n --volume=\/sys:\/sys:ro \\\n --volume=\/var\/lib\/docker\/:\/var\/lib\/docker:ro \\\n --volume=\/dev\/disk\/:\/dev\/disk:ro \\\n --publish=8080:8080 \\\n --detach=true \\\n --name=cadvisor \\\n google\/cadvisor:latest<\/code><\/pre>\n<\/p><\/div>\nprometheus.yml<\/code>) onu bir hedef olarak tan\u0131mlayabiliriz:<\/p>\n# prometheus.yml\nglobal:\n scrape_interval: 15s # Her 15 saniyede bir metrikleri \u00e7ek\n\nscrape_configs:\n - job_name: 'prometheus'\n static_configs:\n - targets: ['localhost:9090'] # Prometheus'un kendi metrikleri\n\n - job_name: 'cadvisor'\n static_configs:\n - targets: ['localhost:8080'] # cAdvisor'\u0131n metrikleri<\/code><\/pre>\n<\/p><\/div>\nlocalhost:8080<\/code> adresindeki cAdvisor’dan d\u00fczenli olarak metrikleri \u00e7eker ve depolar. Bu metrikler aras\u0131nda container_cpu_usage_seconds_total<\/code> ve container_memory_usage_bytes<\/code> gibi kritik veriler bulunur.<\/p>\nGrafana Nedir ve Metrikleri Nas\u0131l G\u00f6rselle\u015ftirir?<\/h3>\n
docker run -d -p 3000:3000 --name=grafana grafana\/grafana<\/code><\/pre>\n<\/p><\/div>\nhttp:\/\/localhost:3000<\/code> adresine giderek eri\u015febilirsiniz (varsay\u0131lan kullan\u0131c\u0131 ad\u0131\/\u015fifre: admin\/admin). Ard\u0131ndan, Prometheus’u bir veri kayna\u011f\u0131 olarak ekleyebilir ve cAdvisor’dan gelen Docker metriklerini kullanarak \u00e7e\u015fitli panolar olu\u015fturabilirsiniz. Grafana’n\u0131n zengin g\u00f6rselle\u015ftirme se\u00e7enekleri (\u00e7izgi grafikler, bar grafikler, tablolar vb.) sayesinde, konteynerlerinizin CPU ve bellek kullan\u0131m\u0131n\u0131 zaman i\u00e7inde kolayca takip edebilir, tepe noktalar\u0131n\u0131 ve d\u00fc\u015f\u00fc\u015fleri g\u00f6zlemleyebilirsiniz.<\/p>\nVaka Analizi: E-ticaret Uygulamas\u0131n\u0131n Kaynak \u0130zlemesi<\/h3>\n
\n
Merkezi Loglama ve Kaynak Kullan\u0131m Anormalliklerini Tespit Etme<\/h2>\n
Loglar\u0131n \u0130zleme ile \u0130li\u015fkisi<\/h3>\n
\n
ELK Stack (Elasticsearch, Logstash, Kibana) veya Splunk’\u0131n Rol\u00fc<\/h3>\n
\n
Konteyner Loglar\u0131n\u0131 Toplama ve Korelasyon<\/h3>\n
json-file<\/code>, syslog<\/code>, fluentd<\/code>, gelf<\/code>) kullan\u0131l\u0131r. \u00d6rne\u011fin, fluentd<\/code> veya gelf<\/code> s\u00fcr\u00fcc\u00fclerini kullanarak konteyner loglar\u0131n\u0131 do\u011frudan Logstash’e veya Elasticsearch’e g\u00f6nderebilirsiniz. Ya da her ana makinede \u00e7al\u0131\u015fan bir Filebeat<\/strong> (Elastic Stack’in bir par\u00e7as\u0131) veya Fluent Bit<\/strong> gibi hafif bir log toplay\u0131c\u0131, Docker log dosyalar\u0131n\u0131 okuyarak merkezi loglama sistemine iletebilir.<\/p>\nVaka Analizi: Mikroservis Ortam\u0131nda Kaynak Anormalli\u011fi Tespiti<\/h3>\n
Konteyner Kaynaklar\u0131n\u0131 Etkin Y\u00f6netme ve Otomatik \u00d6l\u00e7ekleme Stratejileri<\/h2>\n
Konteyner Kaynak Limitleri ve Rezervasyonlar\u0131<\/h3>\n
\n
--memory=512m<\/code> bir konteynerin 512 MB’tan fazla bellek kullanmas\u0131n\u0131 engeller. E\u011fer konteyner bu limiti a\u015farsa, Docker onu durdurabilir (OOM – Out Of Memory hatas\u0131). CPU i\u00e7in --cpus=0.5<\/code>, konteynerin tek bir CPU \u00e7ekirde\u011finin %50’sini kullanabilece\u011fi anlam\u0131na gelir.<\/li>\n--memory-reservation=256m<\/code>, konteynerin en az 256 MB belle\u011fe sahip olaca\u011f\u0131n\u0131 garanti eder. E\u011fer ana makinede bellek s\u0131k\u0131nt\u0131s\u0131 ya\u015fan\u0131rsa, di\u011fer konteynerler bu rezervasyonun alt\u0131na d\u00fc\u015febilirken, rezervasyonu olan konteynerin performans\u0131 korunmaya \u00e7al\u0131\u015f\u0131l\u0131r.<\/li>\n<\/ul>\ndocker run<\/code> komutuyla veya docker-compose.yml<\/code> dosyas\u0131nda belirleyebilirsiniz. \u00d6rne\u011fin:<\/p>\ndocker run -d \\\n --name my-limited-app \\\n --cpus=0.5 \\\n --memory=512m \\\n my-image:latest<\/code><\/pre>\n<\/p><\/div>\nversion: '3.8'\nservices:\n my-app:\n image: my-image:latest\n deploy:\n resources:\n limits:\n cpus: '0.5'\n memory: 512M\n reservations:\n cpus: '0.25'\n memory: 256M<\/code><\/pre>\n<\/p><\/div>\nKonteyner Sa\u011fl\u0131k Kontrolleri (Health Checks)<\/h3>\n
HEALTHCHECK<\/code>), bir konteynerin i\u00e7indeki uygulaman\u0131n ger\u00e7ekten sa\u011fl\u0131kl\u0131 ve hizmet vermeye haz\u0131r olup olmad\u0131\u011f\u0131n\u0131 periyodik olarak kontrol etmenizi sa\u011flar.<\/p>\nHEALTHCHECK<\/code>, Dockerfile i\u00e7inde tan\u0131mlan\u0131r ve belirli bir komutun (\u00f6rne\u011fin, bir HTTP endpoint’ine istek g\u00f6ndermek veya bir veritaban\u0131 ba\u011flant\u0131s\u0131n\u0131 test etmek) ba\u015far\u0131l\u0131 bir \u015fekilde \u00e7al\u0131\u015f\u0131p \u00e7al\u0131\u015fmad\u0131\u011f\u0131n\u0131 denetler. E\u011fer sa\u011fl\u0131k kontrol\u00fc belirli bir say\u0131da ba\u015far\u0131s\u0131z olursa, Docker konteyneri “sa\u011fl\u0131ks\u0131z” (unhealthy) olarak i\u015faretler. Bu bilgi, konteyner orkestrasyon ara\u00e7lar\u0131 (Docker Swarm, Kubernetes) taraf\u0131ndan kullan\u0131larak sa\u011fl\u0131ks\u0131z konteynerlerin otomatik olarak yeniden ba\u015flat\u0131lmas\u0131na veya trafikten \u00e7\u0131kar\u0131lmas\u0131na olanak tan\u0131r.<\/p>\n# Dockerfile\nFROM nginx:latest\nRUN apt-get update && apt-get install -y curl\nHEALTHCHECK --interval=5s --timeout=3s --retries=3 \\\n CMD curl --fail http:\/\/localhost || exit 1<\/code><\/pre>\n<\/p><\/div>\nhttp:\/\/localhost<\/code> adresine istek g\u00f6nderecek. E\u011fer 3 saniye i\u00e7inde yan\u0131t alamazsa veya ba\u015far\u0131s\u0131z olursa, bu 3 kez tekrarland\u0131ktan sonra konteyner sa\u011fl\u0131ks\u0131z kabul edilecektir. Sa\u011fl\u0131k kontrolleri, kaynak izleme ile birlikte kullan\u0131ld\u0131\u011f\u0131nda, bir konteynerin neden y\u00fcksek CPU kulland\u0131\u011f\u0131n\u0131 anlaman\u0131za yard\u0131mc\u0131 olabilir; \u00f6rne\u011fin, sa\u011fl\u0131ks\u0131z bir durumdayken s\u00fcrekli yeniden ba\u015flat\u0131lmaya \u00e7al\u0131\u015f\u0131lan bir uygulama d\u00f6ng\u00fcye girip CPU’yu t\u00fcketebilir.<\/p>\nOtomatik \u00d6l\u00e7ekleme Mekanizmalar\u0131<\/h3>\n
\n
S\u0131k\u00e7a Sorulan Sorular (SSS)<\/h2>\n
1. Docker konteyner izleme i\u00e7in en iyi y\u00f6ntem nedir?<\/h3>\n
docker stats<\/code> gibi dahili komutlar yeterli olabilir. Ancak \u00fcretim ortamlar\u0131 i\u00e7in Prometheus, Grafana ve cAdvisor kombinasyonu gibi geli\u015fmi\u015f, merkezi \u00e7\u00f6z\u00fcmler \u00f6nerilir. Bu \u00e7\u00f6z\u00fcmler, ge\u00e7mi\u015fe d\u00f6n\u00fck analiz, uyar\u0131 mekanizmalar\u0131 ve geli\u015fmi\u015f g\u00f6rselle\u015ftirme yetenekleri sunar. Loglama i\u00e7in ELK Stack veya Splunk gibi sistemlerle entegrasyon da sorun giderme yetene\u011fini art\u0131r\u0131r.<\/p>\n2. Kaynak limitleri belirlemek neden \u00f6nemlidir?<\/h3>\n
3.
docker stats<\/code> komutu neden bazen “0%” g\u00f6sterir?<\/h3>\ndocker stats<\/code> komutu, CPU kullan\u0131m\u0131n\u0131 genellikle son bir veya iki saniyelik aral\u0131kta hesaplar. E\u011fer konteyneriniz o an hi\u00e7bir i\u015flem yapm\u0131yorsa veya \u00e7ok d\u00fc\u015f\u00fck bir i\u015f y\u00fck\u00fcne sahipse, CPU kullan\u0131m\u0131 “0%” olarak g\u00f6r\u00fcnebilir. Bu genellikle bir sorun i\u015fareti de\u011fildir, ancak uygulaman\u0131z\u0131n aktif olmas\u0131 gerekti\u011fi halde s\u00fcrekli “0%” g\u00f6steriyorsa, uygulaman\u0131n durdu\u011funu veya bir sorun ya\u015fad\u0131\u011f\u0131n\u0131 kontrol etmeniz gerekebilir.<\/p>\n4. \u0130zleme ara\u00e7lar\u0131 konteyner performans\u0131n\u0131 nas\u0131l etkiler?<\/h3>\n
5. Hangi metrikler \u00f6ncelikli olarak izlenmelidir?<\/h3>\n
Sonu\u00e7<\/h2>\n
docker stats<\/code>, docker top<\/code> ve docker inspect<\/code> gibi basit komutlar\u0131, anl\u0131k durum tespiti i\u00e7in h\u0131zl\u0131 \u00e7\u00f6z\u00fcmler sunar. Ancak, b\u00fcy\u00fck \u00f6l\u00e7ekli ve kritik \u00fcretim ortamlar\u0131nda, Prometheus ve Grafana gibi geli\u015fmi\u015f izleme y\u0131\u011f\u0131nlar\u0131, cAdvisor ile entegre olarak kapsaml\u0131 metrik toplama, depolama, g\u00f6rselle\u015ftirme ve uyar\u0131 yetenekleri sunar.<\/p>\n