Docker Konteynerlerinin CPU ve Bellek Kullanımını Etkin Bir Şekilde Nasıl İzlersiniz?

Docker Konteynerlerinin CPU ve Bellek Kullanımını Etkin Bir Şekilde Nasıl İzlersiniz?

Modern yazılım geliştirme dünyasında Docker konteynerleri, uygulamaları paketlemek, dağıtmak ve çalıştırmak için vazgeçilmez bir araç haline geldi. Ancak, konteynerlerin esnekliği ve hafif yapısı, beraberinde kaynak kullanımının dikkatli bir şekilde izlenmesi gerekliliğini getiriyor. Bir konteynerin CPU ve bellek tüketimini anlamak, uygulamanızın performansını optimize etmek, olası darboğazları önceden tespit etmek ve altyapı maliyetlerini kontrol altında tutmak için kritik öneme sahiptir. Bu makale, Docker konteynerlerinizin kaynak kullanımını nasıl etkin bir şekilde izleyeceğinizi, dahili araçlardan gelişmiş çözümlere kadar adım adım açıklayacaktır.

Docker Konteynerlerinin Kaynak Kullanımını İzlemek Neden Hayati Önem Taşır?

Günümüzün dinamik ve mikroservis tabanlı uygulama mimarilerinde, her bir bileşenin bir konteyner içinde çalışması oldukça yaygındır. Bu durum, kaynak yönetimini ve performans izlemeyi daha karmaşık ancak bir o kadar da önemli hale getirir. Konteynerlerin CPU ve bellek kullanımını düzenli olarak takip etmek, sadece mevcut sorunları çözmekle kalmaz, aynı zamanda gelecekteki performansı ve maliyetleri proaktif bir şekilde yönetmenizi sağlar. Peki, bu izleme neden bu kadar kritik?

Öncelikle, performans darboğazlarını tespit etmek için izleme şarttır. Bir uygulamanın yavaşlaması veya yanıt vermemesi genellikle yüksek CPU kullanımı, bellek sızıntıları veya yetersiz kaynak tahsisi gibi sorunlardan kaynaklanır. Konteyner bazında detaylı metrikler toplamak, sorunun tam olarak hangi servisten veya konteynerden kaynaklandığını hızlıca belirlemenize olanak tanır. Örneğin, bir e-ticaret sitesinde ödeme işlemleri sırasında CPU kullanımının aniden fırladığını görmek, ilgili mikroserviste bir optimizasyon ihtiyacına işaret edebilir. Bu tür bir gözlem olmadan, sorunun kök nedenini bulmak “samanlıkta iğne aramak” gibi zorlayıcı olabilir.

İkinci olarak, maliyet optimizasyonu açısından izleme büyük fayda sağlar. Bulut tabanlı altyapılarda kaynaklar kullandıkça öde (pay-as-you-go) modeliyle faturalandırılır. Eğer konteynerleriniz gereğinden fazla CPU veya bellek kaynağına sahipse, bu doğrudan gereksiz maliyetlere yol açar. Kaynak kullanımını izleyerek, her bir konteynere veya servise gerçekten ihtiyaç duyduğu kadar kaynak atayabilir, böylece altyapı maliyetlerinizde önemli tasarruflar sağlayabilirsiniz. Bir başka açıdan, yetersiz kaynak tahsisi de performans sorunlarına ve dolayısıyla müşteri memnuniyetsizliğine yol açarak dolaylı maliyetler yaratabilir. Doğru dengeyi bulmak, sürekli izleme ile mümkündür.

Üçüncü olarak, uygulama kararlılığı ve güvenilirliği için izleme vazgeçilmezdir. Bir konteynerin aşırı kaynak tüketimi, aynı ana makine üzerinde çalışan diğer konteynerleri de olumsuz etkileyebilir ve “komşu gürültüsü” (noisy neighbor) sorununa yol açabilir. Bu durum, tüm sistemin kararsızlaşmasına ve hatta çökmesine neden olabilir. Erken uyarı sistemleri kurarak ve anormallikleri izleyerek, potansiyel sorunları büyümeden önce tespit edip çözebilirsiniz. Bu, özellikle kritik iş yükleri ve 7/24 hizmet vermesi gereken uygulamalar için hayati öneme sahiptir.

Son olarak, kapasite planlaması için izleme verileri paha biçilmezdir. Uygulamanızın gelecekteki büyümesini ve artan yükü karşılayabilmesi için ne kadar ek kaynağa ihtiyaç duyacağınızı tahmin etmek, geçmişe dönük kaynak kullanım verileriyle çok daha kolaydır. Belirli dönemlerde (örneğin, özel indirim günleri veya sezonluk yoğunluklar) kaynak tüketiminin nasıl değiştiğini analiz ederek, altyapınızı buna göre ölçeklendirebilir ve beklenmedik performans düşüşlerinin önüne geçebilirsiniz. Bu, özellikle sürekli genişleyen ve kullanıcı sayısı artan platformlar için stratejik bir adımdır.

Kısacası, Docker konteynerlerinin CPU ve bellek kullanımını izlemek, modern DevOps pratiklerinin temel taşlarından biridir. Bu, sadece teknik bir gereklilik değil, aynı zamanda iş sürekliliği, maliyet verimliliği ve müşteri memnuniyeti açısından stratejik bir yatırımdır. İzleme sayesinde, konteynerize edilmiş uygulamalarınızın her zaman en yüksek performansta ve en verimli şekilde çalışmasını sağlayabilirsiniz.

Docker’ın Dahili İzleme Araçları Nelerdir ve Nasıl Kullanılır?

Docker, konteynerlerin temel kaynak kullanımını hızlı ve kolay bir şekilde izlemek için birkaç dahili komut satırı aracı sunar. Bu araçlar, karmaşık bir izleme altyapısı kurmaya gerek kalmadan anlık durum tespiti yapmak için oldukça kullanışlıdır. Özellikle geliştirme ortamlarında veya hızlı sorun giderme senaryolarında bu komutlar adeta bir cankurtaran görevi görür. Şimdi bu temel araçlara ve kullanımlarına daha yakından bakalım.

docker stats Komutu: Canlı Kaynak Kullanımına Hızlı Bir Bakış

docker stats komutu, çalışan konteynerlerin CPU, bellek, ağ G/Ç (I/O) ve disk G/Ç gibi kaynak kullanım istatistiklerini gerçek zamanlı olarak gösterir. Bu komut, Unix sistemlerindeki top komutuna benzer bir arayüz sunar ve her birkaç saniyede bir güncellenen dinamik bir tablo görüntüler. Bu sayede, hangi konteynerin ne kadar kaynak tükettiğini anlık olarak takip edebilirsiniz.

Varsayılan olarak, docker stats komutunu parametresiz çalıştırdığınızda, çalışan tüm konteynerlerin istatistiklerini görürsünüz:

docker stats

Çıktı genellikle aşağıdaki gibi bir tablo formatında olacaktır:

CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
a1b2c3d4e5f6        my-web-app          0.12%               12.3MiB / 1.952GiB    0.62%               7.81kB / 4.54kB     0B / 0B             7
f7e6d5c4b3a2        my-db-server        0.05%               25.6MiB / 1.952GiB    1.28%               12.3kB / 8.76kB     0B / 0B             12

Bu çıktıda dikkat etmeniz gereken bazı önemli sütunlar şunlardır:

• CPU %: Konteynerin CPU kullanım yüzdesi. Yüksek değerler, konteynerin yoğun işlem yaptığını veya bir performans sorunu yaşadığını gösterebilir.
• MEM USAGE / LIMIT: Konteynerin anlık bellek kullanımı ve kendisine atanan bellek limiti. Bu limit, eğer belirlenmişse, konteynerin ne kadar bellek kullanabileceğini gösterir.
• MEM %: Konteynerin atanan bellek limitine göre bellek kullanım yüzdesi. Bu değer %100’e yaklaştığında veya aştığında, bellek yetersizliği sorunları yaşanabilir.
• NET I/O: Konteynerin ağ üzerinden gönderdiği ve aldığı veri miktarı.
• BLOCK I/O: Konteynerin disk üzerinde yaptığı okuma ve yazma işlemleri.

Belirli bir konteyneri izlemek isterseniz, komutun sonuna konteyner ID’sini veya adını ekleyebilirsiniz:

docker stats my-web-app

docker stats komutu, anlık durum tespiti için harika olsa da, geçmişe dönük veri depolamaz veya gelişmiş uyarı mekanizmaları sunmaz. Bu nedenle, daha kapsamlı izleme senaryoları için yetersiz kalabilir.

docker top Komutu: Konteyner İçindeki Süreçleri Görüntüleme

Bir konteynerin neden yüksek CPU veya bellek kullandığını merak ediyorsanız, sorunun kaynağını bulmak için konteynerin içindeki süreçleri incelemek isteyebilirsiniz. docker top komutu tam olarak bu işe yarar. Belirli bir konteynerin içinde çalışan tüm süreçleri, PID (Process ID), CPU kullanım yüzdesi ve bellek kullanımı gibi detaylarla birlikte listeler.

docker top my-web-app

Bu komutun çıktısı, ana makinedeki top komutunun çıktısına benzerdir ve konteyner içinde hangi sürecin (örneğin, bir Python uygulaması, bir Nginx web sunucusu veya bir veritabanı motoru) en çok kaynak tükettiğini görmenizi sağlar. Bu bilgi, bir performans sorununun doğrudan hangi uygulama bileşeninden kaynaklandığını anlamak için çok değerlidir.

docker inspect Komutu: Detaylı Konteyner Yapılandırması ve Kaynak Limitleri

Konteynerin mevcut kaynak kullanımını görmek kadar, ona atanan kaynak limitlerini de bilmek önemlidir. docker inspect komutu, bir konteynerin veya Docker objesinin (imaj, ağ, hacim vb.) tüm detaylı yapılandırma bilgilerini JSON formatında döndürür. Bu bilgiler arasında, konteynere atanan CPU ve bellek limitleri de bulunur.

docker inspect my-web-app

Bu komutun çıktısında, "HostConfig" bölümü altında "CpuShares", "Memory", "MemorySwap" gibi alanları arayarak konteynerin kaynak kısıtlamalarını görebilirsiniz. Örneğin, eğer bir konteynere --memory=512m parametresiyle 512 MB bellek limiti atadıysanız, bu bilgiyi docker inspect çıktısında bulabilirsiniz. Bu, bir konteynerin neden bellek yetersizliği hatası verdiğini anlamak veya kaynak tahsisini doğrulamak için kritik bir bilgidir.

Bu dahili Docker araçları, konteynerlerinizin kaynak kullanımını hızlıca anlamak ve anlık sorunları gidermek için mükemmel bir başlangıç noktasıdır. Ancak, büyük ölçekli üretim ortamlarında veya uzun vadeli performans analizi gerektiren durumlarda, daha gelişmiş ve merkezi izleme çözümlerine ihtiyaç duyulur. Bu araçlar, sadece “o an” ne olduğunu gösterir; “geçmişte ne oldu” veya “gelecekte ne olabilir” gibi sorulara yanıt veremezler. İşte bu noktada, Prometheus ve Grafana gibi harici çözümler devreye girer.

Gelişmiş İzleme Çözümleri: Prometheus ve Grafana Entegrasyonu ile Daha Derin Analizler

Docker’ın dahili izleme araçları, anlık durum tespiti için kullanışlı olsa da, büyük ölçekli ve dinamik konteyner ortamlarında yetersiz kalır. Gerçek zamanlı uyarılar, geçmişe dönük veri analizi, merkezi bir görünüm ve özelleştirilebilir gösterge tabloları gibi gelişmiş özellikler için harici izleme çözümlerine ihtiyaç duyarız. Bu alanda en popüler ve güçlü kombinasyonlardan biri Prometheus ve Grafana’dır. Bu ikili, konteyner metriklerini toplamak, depolamak, görselleştirmek ve uyarılar oluşturmak için kapsamlı bir çözüm sunar.

Neden Harici İzleme Araçlarına İhtiyaç Duyarız?

Dahili araçların aksine, harici çözümlerin sunduğu avantajlar şunlardır:

• Geçmiş Veri Analizi: Metrikleri uzun süre depolayarak trendleri izleyebilir, geçmiş performans sorunlarını analiz edebilir ve kapasite planlaması yapabilirsiniz.
• Merkezi Görünüm: Tüm konteynerlerinizin, hatta tüm altyapınızın metriklerini tek bir yerden görüntüleyebilir, farklı servisler arasındaki korelasyonları kolayca tespit edebilirsiniz.
• Uyarı Mekanizmaları: Belirlenen eşik değerleri aşıldığında (örneğin, CPU kullanımı %80’in üzerine çıktığında), otomatik olarak bildirimler (e-posta, Slack vb.) alabilirsiniz.
• Gelişmiş Görselleştirme: Özelleştirilebilir gösterge tabloları (dashboard’lar) ile verileri anlamlı grafikler ve tablolar halinde sunabilirsiniz.
• Entegrasyon Yeteneği: Diğer sistemlerle (loglama, otomatik ölçekleme vb.) kolayca entegre olabilirler.

Prometheus Nedir ve Metrikleri Nasıl Toplar?

Prometheus, CNCF (Cloud Native Computing Foundation) tarafından desteklenen açık kaynaklı bir zaman serisi veritabanı ve izleme sistemidir. Temel çalışma prensibi “çekme” (pull) modelidir; yani izlenecek hedeflerden (uygulamalar, servisler, ana makineler) düzenli aralıklarla metrikleri çeker ve kendi veritabanında depolar. Prometheus, zengin bir sorgu dili olan PromQL’i kullanarak toplanan metrikler üzerinde karmaşık analizler yapılmasına olanak tanır.

Docker konteynerlerinden metrik toplamak için genellikle cAdvisor (Container Advisor) adı verilen bir araç kullanılır. cAdvisor, Google tarafından geliştirilmiş ve Docker ile entegre olan, çalışan konteynerlerin kaynak kullanımını (CPU, bellek, ağ, disk I/O) toplayan ve bu metrikleri Prometheus’un anlayabileceği formatta (/metrics endpoint’i üzerinden) sunan bir aracıdır. cAdvisor’ı bir Docker konteyneri olarak çalıştırmak oldukça kolaydır:

docker run \
  --volume=/:/rootfs:ro \
  --volume=/var/run:/var/run:ro \
  --volume=/sys:/sys:ro \
  --volume=/var/lib/docker/:/var/lib/docker:ro \
  --volume=/dev/disk/:/dev/disk:ro \
  --publish=8080:8080 \
  --detach=true \
  --name=cadvisor \
  google/cadvisor:latest

Bu komut, cAdvisor’ı 8080 portunda çalıştırır ve Docker ana makinesinin çeşitli dizinlerine salt okunur erişim sağlayarak konteyner metriklerini toplamasına izin verir. cAdvisor çalıştığında, Prometheus’un yapılandırma dosyasında (prometheus.yml) onu bir hedef olarak tanımlayabiliriz:

# prometheus.yml
global:
  scrape_interval: 15s # Her 15 saniyede bir metrikleri çek

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090'] # Prometheus'un kendi metrikleri

  - job_name: 'cadvisor'
    static_configs:
      - targets: ['localhost:8080'] # cAdvisor'ın metrikleri

Prometheus, bu yapılandırma sayesinde localhost:8080 adresindeki cAdvisor’dan düzenli olarak metrikleri çeker ve depolar. Bu metrikler arasında container_cpu_usage_seconds_total ve container_memory_usage_bytes gibi kritik veriler bulunur.

Grafana Nedir ve Metrikleri Nasıl Görselleştirir?

Prometheus metrikleri depolasa da, bunları anlamlı bir şekilde görselleştirmek ve izlemek için genellikle Grafana kullanılır. Grafana, açık kaynaklı bir veri görselleştirme ve gösterge paneli (dashboard) aracıdır. Prometheus, Elasticsearch, Graphite, InfluxDB gibi birçok veri kaynağını destekler ve kullanıcıların bu verilerle etkileşimli, özelleştirilebilir panolar oluşturmasına olanak tanır.

Grafana’yı da bir Docker konteyneri olarak çalıştırmak oldukça basittir:

docker run -d -p 3000:3000 --name=grafana grafana/grafana

Grafana çalıştığında, web tarayıcınızdan http://localhost:3000 adresine giderek erişebilirsiniz (varsayılan kullanıcı adı/şifre: admin/admin). Ardından, Prometheus’u bir veri kaynağı olarak ekleyebilir ve cAdvisor’dan gelen Docker metriklerini kullanarak çeşitli panolar oluşturabilirsiniz. Grafana’nın zengin görselleştirme seçenekleri (çizgi grafikler, bar grafikler, tablolar vb.) sayesinde, konteynerlerinizin CPU ve bellek kullanımını zaman içinde kolayca takip edebilir, tepe noktalarını ve düşüşleri gözlemleyebilirsiniz.

Vaka Analizi: E-ticaret Uygulamasının Kaynak İzlemesi

Hayal edin ki, bir e-ticaret platformunuz var ve bu platform, bir Nginx web sunucusu, bir Node.js API servisi ve bir MongoDB veritabanı olmak üzere üç ana Docker konteynerinden oluşuyor. Yoğun satış dönemlerinde (örneğin, “Kara Cuma” indirimleri) uygulamanızın performansında düşüşler yaşanıyor ve müşterilerden şikayetler geliyor. Bu durumu çözmek için Prometheus ve Grafana’yı devreye sokmaya karar verdiniz.

1. Kurulum: Ana sunucunuzda cAdvisor, Prometheus ve Grafana’yı Docker konteynerleri olarak çalıştırdınız.
2. Metrik Toplama: cAdvisor, tüm konteynerlerinizin (Nginx, Node.js, MongoDB) CPU ve bellek metriklerini topluyor. Prometheus, cAdvisor’dan bu metrikleri düzenli aralıklarla çekip depoluyor.
3. Görselleştirme: Grafana’da, her bir konteyner için ayrı ayrı CPU kullanım yüzdesi ve bellek tüketimi grafiklerinin olduğu bir pano oluşturdunuz. Ayrıca, tüm konteynerlerin toplam CPU ve bellek kullanımını gösteren genel bir grafik de eklediniz.
4. Anomali Tespiti: “Kara Cuma” döneminde, Grafana panolarını izlerken Node.js API servisi konteynerinin CPU kullanımının sürekli %90’ın üzerinde seyrettiğini ve bellek tüketiminin de limitlerine yaklaştığını fark ettiniz. Diğer konteynerler (Nginx ve MongoDB) ise normal sınırlar içinde çalışmaya devam ediyor.
5. Çözüm: Bu gözlem sayesinde, performans darboğazının Nginx veya MongoDB’den değil, Node.js API servisinden kaynaklandığını anladınız. Geliştirme ekibiniz, Node.js uygulamasının kodunu incelediğinde, belirli bir API endpoint’inin yoğun veritabanı sorguları tetiklediğini ve bu sorguların önbelleğe alınmadığını tespit etti. Gerekli optimizasyonları (önbellekleme, sorgu iyileştirmeleri) yaparak ve gerekirse API servisi için daha fazla kaynak ayırarak veya yatayda ölçeklendirerek sorunu çözdünüz.

Bu vaka analizi, Prometheus ve Grafana’nın sadece anlık durumu göstermekle kalmayıp, geçmiş verileri analiz ederek sorunların kök nedenlerini bulmada ve proaktif çözümler üretmede ne kadar güçlü olduğunu ortaya koymaktadır. Merkezi bir izleme platformu, karmaşık konteynerize edilmiş uygulamaların sağlığını ve performansını yönetmek için vazgeçilmezdir.

Merkezi Loglama ve Kaynak Kullanım Anormalliklerini Tespit Etme

Konteynerlerin CPU ve bellek kullanımını izlemek, performans sorunlarını tespit etmenin önemli bir parçasıdır. Ancak, bu metrikler tek başına her zaman sorunun tam resmini vermeyebilir. Bir konteynerin neden aniden yüksek CPU kullanmaya başladığını veya bellek sızıntısı yaşadığını anlamak için, genellikle o konteynerin ürettiği log (günlük) kayıtlarına da bakmak gerekir. Loglar, uygulamanın iç işleyişi, hata mesajları, uyarılar ve kullanıcı etkileşimleri hakkında değerli bilgiler sağlar. Bu nedenle, merkezi loglama çözümleri, kaynak izleme ile birlikte kullanıldığında çok daha güçlü bir sorun giderme ve anomali tespit aracı haline gelir.

Logların İzleme ile İlişkisi

Bir konteynerin CPU veya bellek kullanımında anormal bir artış gördüğünüzde, bu artışın nedenini açıklayabilecek ipuçlarını loglarda bulabilirsiniz. Örneğin:

• Yüksek CPU kullanımı: Loglarda sürekli tekrarlanan hata mesajları, sonsuz döngüye giren bir işlem, yoğun hesaplama gerektiren bir iş yükünün tetiklenmesi veya veritabanı bağlantı sorunları nedeniyle sürekli yeniden denemeler gibi durumlar CPU kullanımını artırabilir.
• Bellek sızıntısı: Uygulama loglarında bellek dışı (out-of-memory) hataları, çöp toplama (garbage collection) uyarıları veya belirli bir işlemin sürekli olarak bellek tüketimini artırdığına dair göstergeler olabilir.
• Ağ sorunları: Ağ G/Ç metriklerinde bir anormallik varsa, loglarda bağlantı zaman aşımı (timeout), ağ bağlantısı kesilmesi veya API çağrılarında hatalar gibi bilgiler bulunabilir.

Bu tür senaryolarda, sadece metrikleri değil, aynı zamanda logları da merkezi bir yerde toplayıp analiz etmek, sorunun kök nedenini çok daha hızlı ve doğru bir şekilde tespit etmenizi sağlar.

ELK Stack (Elasticsearch, Logstash, Kibana) veya Splunk’ın Rolü

Merkezi loglama için piyasada birçok güçlü çözüm bulunmaktadır. En popüler açık kaynaklı çözümlerden biri ELK Stack‘tir (şimdi Elastic Stack olarak da bilinir). Bu yığın üç ana bileşenden oluşur:

• Elasticsearch: Ölçeklenebilir, dağıtık ve yüksek performanslı bir arama ve analiz motorudur. Tüm log verilerini indeksler ve hızlı sorgulamalar yapılmasını sağlar.
• Logstash: Çeşitli kaynaklardan (dosyalar, veritabanları, ağ protokolleri vb.) log verilerini toplar, işler (filtreleme, dönüştürme) ve Elasticsearch’e gönderir.
• Kibana: Elasticsearch’te depolanan verileri görselleştirmek için kullanılan bir kullanıcı arayüzüdür. Logları grafikler, tablolar ve gösterge panoları (dashboard’lar) halinde sunar, böylece log verileri üzerinde kolayca arama yapabilir ve analiz edebilirsiniz.

Alternatif olarak, Splunk gibi ticari çözümler de benzer işlevsellik sunar ve büyük kurumsal ortamlarda yaygın olarak kullanılır. Splunk, log toplama, indeksleme, arama, raporlama ve uyarı mekanizmaları konularında kapsamlı yeteneklere sahiptir.

Konteyner Loglarını Toplama ve Korelasyon

Docker konteynerlerinden log toplamak için genellikle Docker’ın kendi loglama sürücüleri (örneğin, json-file, syslog, fluentd, gelf) kullanılır. Örneğin, fluentd veya gelf sürücülerini kullanarak konteyner loglarını doğrudan Logstash’e veya Elasticsearch’e gönderebilirsiniz. Ya da her ana makinede çalışan bir Filebeat (Elastic Stack’in bir parçası) veya Fluent Bit gibi hafif bir log toplayıcı, Docker log dosyalarını okuyarak merkezi loglama sistemine iletebilir.

Loglar merkezi bir yerde toplandığında, Kibana gibi araçlar sayesinde CPU veya bellek metriklerinizdeki anormallikler ile loglardaki olayları korele edebilirsiniz. Örneğin, Prometheus’tan gelen bir uyarı (Node.js konteyneri %90 CPU kullanıyor) ile Kibana’da o konteynerin loglarını filtreleyerek eş zamanlı olarak hangi hata mesajlarının veya yoğun işlemlerin gerçekleştiğini görebilirsiniz. Bu sayede, “Ne oldu?” sorusunun cevabını metriklerden alırken, “Neden oldu?” sorusunun cevabını loglardan bulabilirsiniz.

Vaka Analizi: Mikroservis Ortamında Kaynak Anormalliği Tespiti

Bir bankacılık uygulamasının mikroservis mimarisinde çalıştığını ve bu uygulamanın binlerce müşteriye hizmet verdiğini düşünelim. Bir sabah, Prometheus’tan “Hesap Bakiyesi Servisi” konteynerinin CPU kullanımının normalin çok üzerinde seyrettiği ve bellek tüketiminin de hızla arttığına dair bir uyarı aldınız. Hemen Grafana panolarınıza baktınız ve bu durumu doğruladınız.

Şimdi sıra loglarda. Kibana’ya girerek, aynı zaman dilimi içinde “Hesap Bakiyesi Servisi”ne ait logları filtrelediniz. Loglarda, beklenenden çok daha fazla sayıda “Veritabanı bağlantı hatası” ve “Tekrar deneme (retry)” mesajları olduğunu fark ettiniz. Bu hataların, belirli bir veritabanı sunucusundan geldiğini de gördünüz. Ayrıca, her bir tekrar deneme işleminin yoğun CPU ve bellek kaynağı tükettiği anlaşıldı.

Bu korelasyon sayesinde, sorunun doğrudan “Hesap Bakiyesi Servisi” uygulamasından veya Docker konteynerinden kaynaklanmadığını, aslında veritabanı bağlantı sorunları nedeniyle uygulamanın sürekli tekrar denemeler yaparak CPU ve belleği tükettiğini tespit ettiniz. Veritabanı ekibiyle iletişime geçildiğinde, ilgili veritabanı sunucusunda bir bakım çalışması yapıldığı veya bir ağ kesintisi yaşandığı ortaya çıktı. Sorunu veritabanı tarafında çözdükten sonra, “Hesap Bakiyesi Servisi” konteynerinin CPU ve bellek kullanımı normale döndü.

Bu örnek, metrik izleme ve merkezi loglama arasındaki sinerjinin ne kadar önemli olduğunu göstermektedir. Birbirini tamamlayan bu iki yaklaşım, karmaşık konteyner ortamlarında sorunları hızlıca teşhis etmek ve çözmek için güçlü bir kombinasyon sunar. Sadece “ne” olduğunu değil, aynı zamanda “neden” olduğunu da anlamak, sistemlerinizin istikrarlı ve güvenilir çalışmasını sağlamanın anahtarıdır.

Konteyner Kaynaklarını Etkin Yönetme ve Otomatik Ölçekleme Stratejileri

Konteynerlerin CPU ve bellek kullanımını izlemek, sadece sorunları tespit etmekle kalmaz, aynı zamanda bu sorunları önlemek ve kaynakları daha verimli kullanmak için de bir temel oluşturur. İzleme verilerini kullanarak, konteynerlerinize doğru kaynak limitlerini atayabilir, sağlık kontrolleriyle uygulamaların durumunu denetleyebilir ve değişen yüklere göre otomatik ölçekleme stratejileri geliştirebilirsiniz. Etkin kaynak yönetimi, hem uygulamanızın performansını ve kararlılığını artırır hem de altyapı maliyetlerinizi optimize eder.

Konteyner Kaynak Limitleri ve Rezervasyonları

Docker, bir konteynerin kullanabileceği CPU ve bellek miktarını sınırlamanıza olanak tanır. Bu, özellikle aynı ana makine üzerinde birden fazla konteyner çalıştırırken “komşu gürültüsü” sorununu önlemek ve her konteynere adil bir kaynak dilimi sağlamak için kritik öneme sahiptir. İki ana kavram vardır:

• Limitler (Limits): Bir konteynerin kullanabileceği maksimum kaynak miktarıdır. Örneğin, --memory=512m bir konteynerin 512 MB’tan fazla bellek kullanmasını engeller. Eğer konteyner bu limiti aşarsa, Docker onu durdurabilir (OOM – Out Of Memory hatası). CPU için --cpus=0.5, konteynerin tek bir CPU çekirdeğinin %50’sini kullanabileceği anlamına gelir.
• Rezervasyonlar (Reservations): Bir konteyner için garanti edilen minimum kaynak miktarıdır. Örneğin, --memory-reservation=256m, konteynerin en az 256 MB belleğe sahip olacağını garanti eder. Eğer ana makinede bellek sıkıntısı yaşanırsa, diğer konteynerler bu rezervasyonun altına düşebilirken, rezervasyonu olan konteynerin performansı korunmaya çalışılır.

Bu parametreleri docker run komutuyla veya docker-compose.yml dosyasında belirleyebilirsiniz. Örneğin:

docker run -d \
  --name my-limited-app \
  --cpus=0.5 \
  --memory=512m \
  my-image:latest

Veya Docker Compose ile:

version: '3.8'
services:
  my-app:
    image: my-image:latest
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 512M
        reservations:
          cpus: '0.25'
          memory: 256M

Doğru limitleri belirlemek için, konteynerlerinizin ortalama ve tepe kaynak kullanımını izleme verilerinizden (Prometheus/Grafana) analiz etmeniz gerekir. Aşırı düşük limitler performansı düşürürken, aşırı yüksek limitler kaynak israfına yol açar.

Konteyner Sağlık Kontrolleri (Health Checks)

Bir konteynerin çalışıyor olması, uygulamanın içinde düzgün çalıştığı anlamına gelmez. Örneğin, bir web sunucusu konteyneri çalışıyor olabilir ancak içerisindeki uygulama veritabanına bağlanamadığı için hata veriyor olabilir. Docker sağlık kontrolleri (HEALTHCHECK), bir konteynerin içindeki uygulamanın gerçekten sağlıklı ve hizmet vermeye hazır olup olmadığını periyodik olarak kontrol etmenizi sağlar.

Bir HEALTHCHECK, Dockerfile içinde tanımlanır ve belirli bir komutun (örneğin, bir HTTP endpoint’ine istek göndermek veya bir veritabanı bağlantısını test etmek) başarılı bir şekilde çalışıp çalışmadığını denetler. Eğer sağlık kontrolü belirli bir sayıda başarısız olursa, Docker konteyneri “sağlıksız” (unhealthy) olarak işaretler. Bu bilgi, konteyner orkestrasyon araçları (Docker Swarm, Kubernetes) tarafından kullanılarak sağlıksız konteynerlerin otomatik olarak yeniden başlatılmasına veya trafikten çıkarılmasına olanak tanır.

# Dockerfile
FROM nginx:latest
RUN apt-get update && apt-get install -y curl
HEALTHCHECK --interval=5s --timeout=3s --retries=3 \
  CMD curl --fail http://localhost || exit 1

Bu örnekte, Nginx konteyneri her 5 saniyede bir http://localhost adresine istek gönderecek. Eğer 3 saniye içinde yanıt alamazsa veya başarısız olursa, bu 3 kez tekrarlandıktan sonra konteyner sağlıksız kabul edilecektir. Sağlık kontrolleri, kaynak izleme ile birlikte kullanıldığında, bir konteynerin neden yüksek CPU kullandığını anlamanıza yardımcı olabilir; örneğin, sağlıksız bir durumdayken sürekli yeniden başlatılmaya çalışılan bir uygulama döngüye girip CPU’yu tüketebilir.

Otomatik Ölçekleme Mekanizmaları

Değişken iş yüklerine sahip uygulamalar için manuel kaynak yönetimi pratik değildir. Yoğunluk arttığında uygulamanın performansının düşmesini engellemek ve gereksiz maliyetlerden kaçınmak için otomatik ölçekleme (auto-scaling) mekanizmalarına ihtiyaç duyarız. Konteyner orkestrasyon platformları, bu konuda güçlü yetenekler sunar:

• Docker Swarm: Docker’ın kendi orkestrasyon aracıdır. Servislerinizi CPU veya bellek kullanımına göre otomatik olarak ölçeklendirmek için kurallar tanımlayabilirsiniz. Örneğin, bir servisin CPU kullanımı %70’i aştığında otomatik olarak yeni bir konteyner örneği (replica) başlatılmasını sağlayabilirsiniz.
• Kubernetes: Sektör standardı haline gelmiş bir konteyner orkestrasyon platformudur. Horizontal Pod Autoscaler (HPA) adı verilen bir bileşeni vardır. HPA, bir Deployment veya ReplicaSet’in pod sayısını (yani konteyner örneklerini) izlenen metrikler (CPU kullanımı, bellek kullanımı, özel metrikler) bazında otomatik olarak ayarlar. Örneğin, bir uygulamanın CPU kullanımının %50’nin üzerine çıkması durumunda HPA, pod sayısını artırarak yükü dağıtabilir. Yük azaldığında ise pod sayısını düşürerek kaynak tasarrufu sağlar.

Otomatik ölçekleme stratejileri, izleme verilerine dayanır. Prometheus gibi bir sistemden toplanan CPU ve bellek metrikleri, otomatik ölçekleme kararlarının tetikleyicisi olarak kullanılır. Bu sayede, uygulamanız her zaman en uygun kaynaklarla çalışır, performans düşüşleri yaşanmaz ve maliyetler kontrol altında tutulur. Bu, modern bulut yerel (cloud-native) uygulamaların esneklik ve dayanıklılık hedeflerine ulaşmasında kilit bir rol oynar.

Sonuç olarak, konteyner kaynaklarını etkin bir şekilde yönetmek, sadece anlık izleme yapmakla kalmaz, aynı zamanda geleceğe yönelik planlama, proaktif sorun önleme ve dinamik ölçeklendirme stratejilerini de içerir. İzleme verilerini kullanarak doğru limitleri belirlemek, sağlık kontrolleriyle uygulamanın iç durumunu anlamak ve otomatik ölçekleme ile değişen yüklere adapte olmak, modern konteynerize edilmiş uygulamaların başarısı için vazgeçilmezdir.

Sıkça Sorulan Sorular (SSS)

1. Docker konteyner izleme için en iyi yöntem nedir?

En iyi yöntem, ihtiyaçlarınıza ve altyapınızın karmaşıklığına bağlıdır. Hızlı ve anlık durum tespiti için docker stats gibi dahili komutlar yeterli olabilir. Ancak üretim ortamları için Prometheus, Grafana ve cAdvisor kombinasyonu gibi gelişmiş, merkezi çözümler önerilir. Bu çözümler, geçmişe dönük analiz, uyarı mekanizmaları ve gelişmiş görselleştirme yetenekleri sunar. Loglama için ELK Stack veya Splunk gibi sistemlerle entegrasyon da sorun giderme yeteneğini artırır.

2. Kaynak limitleri belirlemek neden önemlidir?

Kaynak limitleri (CPU, bellek), bir konteynerin kullanabileceği maksimum kaynak miktarını kısıtlar. Bu, aynı ana makine üzerinde çalışan diğer konteynerlerin performansını korumak (“komşu gürültüsü” sorununu önlemek) ve tek bir konteynerin tüm sistem kaynaklarını tüketmesini engellemek için önemlidir. Ayrıca, kaynak israfını önleyerek maliyet optimizasyonuna da yardımcı olur ve kapasite planlaması için temel oluşturur.

3. docker stats komutu neden bazen “0%” gösterir?

docker stats komutu, CPU kullanımını genellikle son bir veya iki saniyelik aralıkta hesaplar. Eğer konteyneriniz o an hiçbir işlem yapmıyorsa veya çok düşük bir iş yüküne sahipse, CPU kullanımı “0%” olarak görünebilir. Bu genellikle bir sorun işareti değildir, ancak uygulamanızın aktif olması gerektiği halde sürekli “0%” gösteriyorsa, uygulamanın durduğunu veya bir sorun yaşadığını kontrol etmeniz gerekebilir.

4. İzleme araçları konteyner performansını nasıl etkiler?

İzleme araçları, metrik toplama işlemleri nedeniyle çok küçük bir performans yükü oluşturabilir. Ancak modern izleme sistemleri (Prometheus, cAdvisor gibi) genellikle oldukça hafif olacak şekilde tasarlanmıştır ve bu yük genellikle ihmal edilebilir düzeydedir. Yine de, binlerce konteynerin olduğu çok büyük ölçekli ortamlarda, izleme sisteminin kendi kaynak tüketimini de optimize etmek ve izlemek önemlidir.

5. Hangi metrikler öncelikli olarak izlenmelidir?

En öncelikli metrikler şunlardır: CPU kullanımı (yüzde veya çekirdek bazında), bellek kullanımı (mutlak değer ve yüzde olarak), ağ G/Ç (gönderilen/alınan bayt) ve disk G/Ç (okunan/yazılan bayt). Bunlara ek olarak, uygulamanın kendi metrikleri (istek sayısı, hata oranları, yanıt süreleri) ve sağlık durumu (sağlık kontrolü sonuçları) da kritik öneme sahiptir. Bu metriklerin birleşimi, uygulamanızın ve konteynerlerinizin genel sağlığı hakkında kapsamlı bir görünüm sunar.

Sonuç

Docker konteynerlerinin CPU ve bellek kullanımını izlemek, modern uygulama geliştirme ve operasyon süreçlerinin ayrılmaz bir parçasıdır. Geliştirme ortamından üretime kadar her aşamada, konteynerlerin kaynak tüketimini anlamak, uygulamalarınızın istikrarlı, performanslı ve maliyet etkin bir şekilde çalışmasını sağlamanın anahtarıdır. Bu makalede ele aldığımız gibi, Docker’ın dahili docker stats, docker top ve docker inspect gibi basit komutları, anlık durum tespiti için hızlı çözümler sunar. Ancak, büyük ölçekli ve kritik üretim ortamlarında, Prometheus ve Grafana gibi gelişmiş izleme yığınları, cAdvisor ile entegre olarak kapsamlı metrik toplama, depolama, görselleştirme ve uyarı yetenekleri sunar.

Ayrıca, merkezi loglama çözümleri olan ELK Stack veya Splunk gibi araçlarla metrik izlemeyi birleştirmek, performans anormalliklerinin kök nedenlerini tespit etmede paha biçilmez bir sinerji yaratır. İzleme verileriyle desteklenen doğru kaynak limitleri belirlemek, sağlık kontrolleriyle uygulamanın içsel durumunu anlamak ve Kubernetes veya Docker Swarm gibi orkestrasyon araçlarıyla otomatik ölçekleme stratejilerini uygulamak, konteynerize edilmiş altyapıların esnekliğini ve dayanıklılığını maksimum seviyeye çıkarır.

Unutmayın ki, izleme bir kerelik bir işlem değildir; sürekli bir süreçtir. Uygulamalarınız geliştikçe, iş yükleriniz değiştikçe ve altyapınız genişledikçe, izleme stratejilerinizi de düzenli olarak gözden geçirmeli ve güncellemelisiniz. Bu sayede, Docker konteynerlerinizin potansiyelini tam olarak kullanabilir ve dijital hizmetlerinizin her zaman en iyi performansta çalışmasını sağlayabilirsiniz.

#Docker #Konteyner #İzleme #Performans #DevOps #Prometheus #Grafana #ElasticStack