{"id":5196,"date":"2026-09-14T12:26:25","date_gmt":"2026-09-14T09:26:25","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/?p=5196"},"modified":"2026-09-14T06:17:29","modified_gmt":"2026-09-14T03:17:29","slug":"kubernetes-monitoring-kurulumu","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/kubernetes-monitoring-kurulumu\/","title":{"rendered":"Kubernetes Monitoring Nas\u0131l Kurulur?"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><div id=\"toc_container\" role=\"navigation\" aria-label=\"Table of Contents\" data-nosnippet class=\"toc_transparent no_bullets toc_numbered toc_title_center\"><p class=\"toc_title\">\u0130\u00e7indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Kubernetes_monitoring_kurulumu_nereden_baslamali\"><span class=\"toc_number toc_depth_1\">1.<\/span> Kubernetes monitoring kurulumu nereden ba\u015flamal\u0131?<\/a><\/li><li><a href=\"#Hangi_bilesen_neyi_izler\"><span class=\"toc_number toc_depth_1\">2.<\/span> Hangi bile\u015fen neyi izler?<\/a><\/li><li><a href=\"#On_hazirlik_cluster_ve_Helm_kontrolu\"><span class=\"toc_number toc_depth_1\">3.<\/span> \u00d6n haz\u0131rl\u0131k: cluster ve Helm kontrol\u00fc<\/a><\/li><li><a href=\"#Prometheus_Stack_kurulumu\"><span class=\"toc_number toc_depth_1\">4.<\/span> Prometheus Stack kurulumu<\/a><ul><li><a href=\"#Uretim_icin_temel_valuesyaml\"><span class=\"toc_number toc_depth_2\">4.1.<\/span> \u00dcretim i\u00e7in temel values.yaml<\/a><\/li><\/ul><\/li><li><a href=\"#Kurulumun_calistigini_nasil_dogrularim\"><span class=\"toc_number toc_depth_1\">5.<\/span> Kurulumun \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 nas\u0131l do\u011frular\u0131m?<\/a><\/li><li><a href=\"#Uygulama_metriklerini_Prometheus8217a_acmak\"><span class=\"toc_number toc_depth_1\">6.<\/span> Uygulama metriklerini Prometheus&#8217;a a\u00e7mak<\/a><\/li><li><a href=\"#Alarm_kurallari_cok_alarm_degil_dogru_alarm\"><span class=\"toc_number toc_depth_1\">7.<\/span> Alarm kurallar\u0131: \u00e7ok alarm de\u011fil, do\u011fru alarm<\/a><\/li><li><a href=\"#Kaynak_kullanimi_ve_kardinalite_tuzagi\"><span class=\"toc_number toc_depth_1\">8.<\/span> Kaynak kullan\u0131m\u0131 ve kardinalite tuza\u011f\u0131<\/a><\/li><li><a href=\"#Bir_DDoS_gecesinde_monitoring8217in_gercek_sinavi\"><span class=\"toc_number toc_depth_1\">9.<\/span> Bir DDoS gecesinde monitoring&#8217;in ger\u00e7ek s\u0131nav\u0131<\/a><\/li><li><a href=\"#Guvenlik_erisim_ve_maliyet\"><span class=\"toc_number toc_depth_1\">10.<\/span> G\u00fcvenlik, eri\u015fim ve maliyet<\/a><\/li><li><a href=\"#Monitoring8217i_isletmek_kurulumdan_sonraki_isler\"><span class=\"toc_number toc_depth_1\">11.<\/span> Monitoring&#8217;i i\u015fletmek: kurulumdan sonraki i\u015fler<\/a><\/li><li><a href=\"#Sik_Sorulan_Sorular\"><span class=\"toc_number toc_depth_1\">12.<\/span> S\u0131k Sorulan Sorular<\/a><ul><li><a href=\"#Prometheus_ile_Metrics_Server_arasindaki_fark_nedir\"><span class=\"toc_number toc_depth_2\">12.1.<\/span> Prometheus ile Metrics Server aras\u0131ndaki fark nedir?<\/a><\/li><li><a href=\"#Kubernetes_monitoring_icin_Grafana_kurmak_zorunlu_mu\"><span class=\"toc_number toc_depth_2\">12.2.<\/span> Kubernetes monitoring i\u00e7in Grafana kurmak zorunlu mu?<\/a><\/li><li><a href=\"#Prometheus_verileri_ne_kadar_sure_saklanmali\"><span class=\"toc_number toc_depth_2\">12.3.<\/span> Prometheus verileri ne kadar s\u00fcre saklanmal\u0131?<\/a><\/li><li><a href=\"#Alarm_sayisini_nasil_azaltabilirim\"><span class=\"toc_number toc_depth_2\">12.4.<\/span> Alarm say\u0131s\u0131n\u0131 nas\u0131l azaltabilirim?<\/a><\/li><\/ul><\/li><\/ul><\/div>\n<h2><span id=\"Kubernetes_monitoring_kurulumu_nereden_baslamali\">Kubernetes monitoring kurulumu nereden ba\u015flamal\u0131?<\/span><\/h2>\n<p>Kubernetes \u00fczerinde \u00e7al\u0131\u015fan bir uygulaman\u0131n ayakta olmas\u0131, sa\u011fl\u0131kl\u0131 oldu\u011fu anlam\u0131na gelmez. Pod <code>Running<\/code> g\u00f6r\u00fcnebilir; fakat CPU throttling artm\u0131\u015f, bellek kullan\u0131m\u0131 limitine dayanm\u0131\u015f, HTTP hatalar\u0131 \u00e7o\u011falm\u0131\u015f veya disk dolmak \u00fczere olabilir. Kullan\u0131c\u0131 sorunu bildirdi\u011finde bunlar\u0131 fark ediyorsan\u0131z monitoring de\u011fil, olay sonras\u0131 inceleme yap\u0131yorsunuz demektir.<\/p>\n<p>Ben Kubernetes monitoring kurulumu i\u00e7in genellikle Prometheus, Grafana ve Alertmanager \u00fc\u00e7l\u00fcs\u00fcn\u00fc tercih ediyorum. Prometheus metrikleri toplar, Grafana bunlar\u0131 okunabilir panellere \u00e7evirir, Alertmanager ise e\u015fikleri a\u015fan durumlar\u0131 e-posta, Slack veya ba\u015fka bir bildirim kanal\u0131na g\u00f6nderir. Kubernetes API&#8217;sinden gelen durum bilgileri i\u00e7in kube-state-metrics&#8217;i de bu yap\u0131ya eklerim.<\/p>\n<p>\u015e\u00f6yle anlatay\u0131m: Monitoring kurarken ilk hedefiniz y\u00fczlerce grafik olu\u015fturmak de\u011fil, gece sizi ger\u00e7ekten uyand\u0131racak sinyalleri se\u00e7mektir. Bir pod&#8217;un yeniden ba\u015flat\u0131ld\u0131\u011f\u0131n\u0131 bilmek de\u011ferlidir; fakat bunun ka\u00e7 kez oldu\u011fu, hangi deployment&#8217;a ait oldu\u011fu ve kullan\u0131c\u0131 trafi\u011fine yans\u0131y\u0131p yans\u0131mad\u0131\u011f\u0131 daha de\u011ferlidir.<\/p>\n<h2><span id=\"Hangi_bilesen_neyi_izler\">Hangi bile\u015fen neyi izler?<\/span><\/h2>\n<p>Kubernetes monitoring kurulumu s\u0131ras\u0131nda bile\u015fenlerin g\u00f6revlerini birbirine kar\u0131\u015ft\u0131rmak ileride gereksiz alarm \u00fcretir. A\u015fa\u011f\u0131daki ayr\u0131m pratikte i\u015fimi kolayla\u015ft\u0131r\u0131yor.<\/p>\n<table>\n<thead>\n<tr>\n<th>Bile\u015fen<\/th>\n<th>\u0130zledi\u011fi alan<\/th>\n<th>Ne zaman kullan\u0131l\u0131r?<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Prometheus<\/td>\n<td>Node, pod, uygulama ve Kubernetes metrikleri<\/td>\n<td>Zaman serisi verisi ve sorgulama i\u00e7in<\/td>\n<\/tr>\n<tr>\n<td>Grafana<\/td>\n<td>Prometheus verisinin panelleri<\/td>\n<td>G\u00f6rselle\u015ftirme ve operasyon takibi i\u00e7in<\/td>\n<\/tr>\n<tr>\n<td>Alertmanager<\/td>\n<td>Prometheus alarm kurallar\u0131ndan gelen bildirimler<\/td>\n<td>Uyar\u0131lar\u0131 gruplamak, susturmak ve y\u00f6nlendirmek i\u00e7in<\/td>\n<\/tr>\n<tr>\n<td>kube-state-metrics<\/td>\n<td>Deployment, pod, job ve node durumlar\u0131<\/td>\n<td>Kubernetes nesnelerinin beklenen durumunu izlemek i\u00e7in<\/td>\n<\/tr>\n<tr>\n<td>Node Exporter<\/td>\n<td>Linux i\u015fletim sistemi metrikleri<\/td>\n<td>CPU, RAM, dosya sistemi ve a\u011f takibi i\u00e7in<\/td>\n<\/tr>\n<tr>\n<td>Metrics Server<\/td>\n<td>Anl\u0131k kaynak kullan\u0131m \u00f6zeti<\/td>\n<td><code>kubectl top<\/code> ve HPA i\u00e7in<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Metrics Server ile Prometheus ayn\u0131 \u015fey de\u011fildir. Metrics Server k\u0131sa s\u00fcreli kaynak g\u00f6r\u00fcn\u00fcm\u00fc sunar; ge\u00e7mi\u015fe d\u00f6n\u00fck sorgular, uygulama metrikleri ve ayr\u0131nt\u0131l\u0131 alarmlar i\u00e7in Prometheus gerekir. <code>kubectl top nodes<\/code> \u00e7al\u0131\u015f\u0131yor diye monitoring tamamlanm\u0131\u015f say\u0131lmaz.<\/p>\n<h2><span id=\"On_hazirlik_cluster_ve_Helm_kontrolu\">\u00d6n haz\u0131rl\u0131k: cluster ve Helm kontrol\u00fc<\/span><\/h2>\n<p>Kuruluma ge\u00e7meden \u00f6nce cluster&#8217;a y\u00f6netici yetkiniz oldu\u011funu, Helm&#8217;in \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 ve hangi Kubernetes s\u00fcr\u00fcm\u00fcnde oldu\u011funuzu kontrol edin. Ben bu kontrolleri do\u011frudan \u00fcretimde de\u011fil, \u00f6nce evdeki Proxmox \u00fczerindeki test cluster&#8217;\u0131nda yap\u0131yorum. Deneme s\u0131ras\u0131nda bozuk bir chart veya yanl\u0131\u015f bir Service t\u00fcr\u00fc m\u00fc\u015fterinin trafi\u011fini etkilememeli.<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">kubectl cluster-info\nkubectl get nodes -o wide\nkubectl version\nhelm version<\/code><\/pre>\n<p>\u0130lk komut API sunucusunun eri\u015filebilir oldu\u011funu, ikinci komut node&#8217;lar\u0131n durumunu g\u00f6sterir. <code>helm version<\/code> \u00e7\u0131kt\u0131s\u0131 gelmiyorsa chart kurmaya ge\u00e7meden \u00f6nce Helm kurulmal\u0131d\u0131r.<\/p>\n<p>Monitoring bile\u015fenlerini ayr\u0131 bir namespace i\u00e7inde tutmak i\u00e7in \u00f6nce namespace olu\u015fturun:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">kubectl create namespace monitoring\nkubectl get namespace monitoring<\/code><\/pre>\n<p>Namespace zaten mevcutsa <code>AlreadyExists<\/code> mesaj\u0131 hata gibi g\u00f6r\u00fcnse de kurulumun \u00f6n\u00fcnde engel de\u011fildir. \u00dcretimde komutlar\u0131 tekrar \u00e7al\u0131\u015ft\u0131r\u0131labilir hale getirmek i\u00e7in <code>--dry-run=client -o yaml<\/code> \u00e7\u0131kt\u0131s\u0131n\u0131 Git&#8217;te saklamak daha d\u00fczenlidir.<\/p>\n<h2><span id=\"Prometheus_Stack_kurulumu\">Prometheus Stack kurulumu<\/span><\/h2>\n<p>Pratik ba\u015flang\u0131\u00e7lardan biri Prometheus Community taraf\u0131ndan s\u00fcrd\u00fcr\u00fclen <code>kube-prometheus-stack<\/code> chart&#8217;\u0131d\u0131r. Bu chart Prometheus Operator, Prometheus, Grafana, Alertmanager, node-exporter ve kube-state-metrics bile\u015fenlerini birlikte y\u00f6netebilir. Chart s\u00fcr\u00fcm\u00fcn\u00fc sabitlemenizi \u00f6neririm; rastgele bir g\u00fcncellemenin CRD davran\u0131\u015f\u0131n\u0131 de\u011fi\u015ftirmesini istemezsiniz.<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">helm repo add prometheus-community https:\/\/prometheus-community.github.io\/helm-charts\nhelm repo update\nhelm search repo prometheus-community\/kube-prometheus-stack<\/code><\/pre>\n<p>Repository eklenir ve g\u00fcncel chart listesi al\u0131n\u0131r. Kurulumdan \u00f6nce chart&#8217;\u0131n s\u00fcr\u00fcm\u00fcn\u00fc bu listeden not edin.<\/p>\n<p>Basit bir test ortam\u0131nda varsay\u0131lan de\u011ferlerle kurulum yap\u0131labilir:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">helm install monitoring prometheus-community\/kube-prometheus-stack \\\n  --namespace monitoring \\\n  --create-namespace<\/code><\/pre>\n<p>Bu komut <code>monitoring<\/code> adl\u0131 Helm release olu\u015fturur. \u00dcretimde varsay\u0131lan de\u011ferlerle ilerlemek yerine bir <code>values.yaml<\/code> dosyas\u0131 haz\u0131rlay\u0131n; \u00f6zellikle kal\u0131c\u0131 disk, kaynak limitleri ve Grafana eri\u015fimi bu dosyada a\u00e7\u0131k\u00e7a tan\u0131mlanmal\u0131d\u0131r.<\/p>\n<h3><span id=\"Uretim_icin_temel_valuesyaml\">\u00dcretim i\u00e7in temel values.yaml<\/span><\/h3>\n<p>A\u015fa\u011f\u0131daki \u00f6rnek ba\u015flang\u0131\u00e7 seviyesinde bir yap\u0131land\u0131rmad\u0131r. StorageClass ad\u0131n\u0131 kendi cluster&#8217;\u0131n\u0131zda <code>kubectl get storageclass<\/code> \u00e7\u0131kt\u0131s\u0131na g\u00f6re de\u011fi\u015ftirin. Her ortam\u0131n disk performans\u0131, saklama s\u00fcresi ve node kapasitesi farkl\u0131d\u0131r.<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">grafana:\n  admin:\n    existingSecret: grafana-admin\n  persistence:\n    enabled: true\n    storageClassName: standard\n    size: 10Gi\n  resources:\n    requests:\n      cpu: 100m\n      memory: 256Mi\n    limits:\n      cpu: 500m\n      memory: 512Mi\n\nprometheus:\n  prometheusSpec:\n    retention: 15d\n    retentionSize: 40GB\n    storageSpec:\n      volumeClaimTemplate:\n        spec:\n          storageClassName: standard\n          accessModes: [&#039;ReadWriteOnce&#039;]\n          resources:\n            requests:\n              storage: 50Gi\n    resources:\n      requests:\n        cpu: 500m\n        memory: 1Gi\n      limits:\n        cpu: 2\n        memory: 4Gi\n\nalertmanager:\n  alertmanagerSpec:\n    storage:\n      volumeClaimTemplate:\n        spec:\n          storageClassName: standard\n          accessModes: [&#039;ReadWriteOnce&#039;]\n          resources:\n            requests:\n              storage: 10Gi<\/code><\/pre>\n<p>Burada Prometheus verisi ve Grafana ayarlar\u0131 pod silinse bile kal\u0131c\u0131 disk \u00fczerinde tutulur. Disk boyutu yaln\u0131zca pod say\u0131s\u0131na g\u00f6re belirlenmez; scrape aral\u0131\u011f\u0131, etiket kardinalitesi ve retention s\u00fcresi de hesaba kat\u0131l\u0131r.<\/p>\n<p>Dosyay\u0131 kullanarak kurulumu veya g\u00fcncellemeyi \u015f\u00f6yle yapabilirsiniz:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">helm upgrade --install monitoring prometheus-community\/kube-prometheus-stack \\\n  --namespace monitoring \\\n  --values values.yaml \\\n  --wait \\\n  --timeout 10m<\/code><\/pre>\n<p><code>--wait<\/code> kaynaklar\u0131n haz\u0131r olmas\u0131n\u0131 bekler, fakat her sorunu \u00e7\u00f6zmez. Komut timeout verirse hemen tekrar kurmak yerine pod, event ve PVC durumunu kontrol edin.<\/p>\n<h2><span id=\"Kurulumun_calistigini_nasil_dogrularim\">Kurulumun \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 nas\u0131l do\u011frular\u0131m?<\/span><\/h2>\n<p>\u00d6nce namespace i\u00e7indeki pod&#8217;lar\u0131 izleyin:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">kubectl get pods -n monitoring -w<\/code><\/pre>\n<p>Pod&#8217;lar\u0131n <code>Running<\/code> veya uygun olanlarda <code>Completed<\/code> durumuna ge\u00e7mesini bekleyin. <code>Pending<\/code> bir pod genellikle kaynak yetersizli\u011fi, uygun node se\u00e7ilememesi veya PVC&#8217;nin ba\u011flanamamas\u0131 anlam\u0131na gelir.<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">kubectl get pvc -n monitoring\nkubectl get svc -n monitoring\nkubectl get events -n monitoring --sort-by=.lastTimestamp<\/code><\/pre>\n<p>Bu \u00fc\u00e7 komut depolama, servis ve namespace event&#8217;lerini birlikte g\u00f6sterir. \u00d6zellikle <code>FailedScheduling<\/code>, <code>FailedMount<\/code> ve image \u00e7ekme hatalar\u0131 kurulumun neden haz\u0131r olmad\u0131\u011f\u0131n\u0131 \u00e7o\u011fu zaman a\u00e7\u0131k eder.<\/p>\n<p>Prometheus ve Grafana&#8217;ya ilk test i\u00e7in port y\u00f6nlendirme kullanabilirsiniz:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">kubectl port-forward -n monitoring svc\/monitoring-kube-prometheus-prometheus 9090:9090\nkubectl port-forward -n monitoring svc\/monitoring-grafana 3000:80<\/code><\/pre>\n<p>Sonra yerel makinenizde <code>http:\/\/127.0.0.1:9090<\/code> ve <code>http:\/\/127.0.0.1:3000<\/code> adreslerini a\u00e7\u0131n. Port-forward yaln\u0131zca ge\u00e7ici test i\u00e7indir; Grafana&#8217;y\u0131 internete do\u011frudan a\u00e7mak yerine VPN, bastion host veya kimlik do\u011frulamal\u0131 bir reverse proxy kullan\u0131n. Hosting panellerine eri\u015fimde VPN ve bastion yakla\u015f\u0131m\u0131n\u0131 anlatt\u0131\u011f\u0131m <a href=\"https:\/\/www.dchost.com\/blog\/vpn-ve-bastion-host-ile-hosting-panellerine-guvenli-uzaktan-erisim-mimarisi\/\">VPN ve Bastion Host ile Hosting Panellerine G\u00fcvenli Uzaktan Eri\u015fim Mimarisi<\/a> yaz\u0131s\u0131ndaki prensipler burada da ge\u00e7erlidir.<\/p>\n<p>Prometheus aray\u00fcz\u00fcnde <code>up<\/code> sorgusunu \u00e7al\u0131\u015ft\u0131r\u0131n. De\u011feri 1 olan hedef eri\u015filebilir, 0 olan hedef ise scrape edilemiyor demektir. Grafana&#8217;da haz\u0131r Kubernetes panelleri g\u00f6r\u00fcn\u00fcr; fakat panelin g\u00f6r\u00fcnmesi verinin do\u011fru oldu\u011fu anlam\u0131na gelmez. Zaman aral\u0131\u011f\u0131n\u0131 de\u011fi\u015ftirerek ger\u00e7ekten veri ak\u0131\u015f\u0131 olup olmad\u0131\u011f\u0131n\u0131 kontrol edin.<\/p>\n<h2><span id=\"Uygulama_metriklerini_Prometheus8217a_acmak\">Uygulama metriklerini Prometheus&#8217;a a\u00e7mak<\/span><\/h2>\n<p>Node ve Kubernetes nesnelerini izlemek yeterli de\u011fildir. Kullan\u0131c\u0131ya hizmet veren uygulaman\u0131n istek say\u0131s\u0131, yan\u0131t s\u00fcresi ve hata oran\u0131 gibi metrikleri de \u00fcretmesi gerekir. Bir\u00e7ok framework i\u00e7in Prometheus client k\u00fct\u00fcphaneleri bulunur. Uygulama genellikle <code>\/metrics<\/code> endpoint&#8217;ini a\u00e7ar.<\/p>\n<p>Prometheus Operator kulland\u0131\u011f\u0131n\u0131zda bu endpoint&#8217;i bir <code>ServiceMonitor<\/code> nesnesiyle tan\u0131mlars\u0131n\u0131z. \u00d6nce uygulaman\u0131n servisi do\u011fru label ile se\u00e7ilmeli:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">apiVersion: monitoring.coreos.com\/v1\nkind: ServiceMonitor\nmetadata:\n  name: orders-api\n  namespace: monitoring\n  labels:\n    release: monitoring\nspec:\n  namespaceSelector:\n    matchNames:\n      - production\n  selector:\n    matchLabels:\n      app: orders-api\n  endpoints:\n    - port: metrics\n      path: \/metrics\n      interval: 30s<\/code><\/pre>\n<p>Buradaki <code>release: monitoring<\/code> label&#8217;\u0131 chart&#8217;\u0131n Prometheus se\u00e7icisiyle uyumlu olmal\u0131d\u0131r; sizin values dosyan\u0131zda farkl\u0131 bir selector varsa onu kullan\u0131n. Service \u00fczerinde <code>name: metrics<\/code> adl\u0131 port bulunmuyorsa ServiceMonitor olu\u015fturulsa bile veri gelmez.<\/p>\n<p>Kontrol i\u00e7in Prometheus aray\u00fcz\u00fcndeki <em>Status<\/em> ve <em>Targets<\/em> sayfalar\u0131na bak\u0131n. Hedef <em>UP<\/em> g\u00f6r\u00fcnm\u00fcyorsa \u00f6nce DNS, port, path ve NetworkPolicy kontrol edilir. Uygulama endpoint&#8217;i d\u0131\u015far\u0131dan eri\u015filebilir de\u011filse bu tek ba\u015f\u0131na sorun de\u011fildir; Prometheus&#8217;un bulundu\u011fu namespace&#8217;ten eri\u015filebilir olmas\u0131 yeterlidir.<\/p>\n<h2><span id=\"Alarm_kurallari_cok_alarm_degil_dogru_alarm\">Alarm kurallar\u0131: \u00e7ok alarm de\u011fil, do\u011fru alarm<\/span><\/h2>\n<p>Alertmanager yap\u0131land\u0131r\u0131lmadan alarm kural\u0131 yazmak eksik bir kurulumdur. Prometheus alarm\u0131 \u00fcretir; Alertmanager ayn\u0131 alarm\u0131 gruplayabilir, susturabilir ve do\u011fru ekibe g\u00f6nderebilir. <code>Pending<\/code> s\u00fcresi tan\u0131mlamak da k\u0131sa s\u00fcreli dalgalanmalar\u0131n gece bildirimi \u00fcretmesini engeller.<\/p>\n<p>\u00d6rne\u011fin bir deployment&#8217;\u0131n haz\u0131r pod say\u0131s\u0131 beklenenin alt\u0131ndaysa \u015fu kural kullan\u0131labilir:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">apiVersion: monitoring.coreos.com\/v1\nkind: PrometheusRule\nmetadata:\n  name: application-alerts\n  namespace: monitoring\n  labels:\n    release: monitoring\nspec:\n  groups:\n    - name: application.rules\n      rules:\n        - alert: DeploymentReplicasMismatch\n          expr: kube_deployment_status_replicas_available{namespace=&quot;production&quot;} &lt; kube_deployment_spec_replicas{namespace=&quot;production&quot;}\n          for: 10m\n          labels:\n            severity: warning\n          annotations:\n            summary: &quot;Deployment beklenen pod say\u0131s\u0131na ula\u015famad\u0131&quot;\n            description: &quot;{{ $labels.deployment }} i\u00e7in haz\u0131r pod say\u0131s\u0131 10 dakikad\u0131r d\u00fc\u015f\u00fck.&quot;\n\n        - alert: InstanceDown\n          expr: up{job=~&quot;.*&quot;} == 0\n          for: 5m\n          labels:\n            severity: critical\n          annotations:\n            summary: &quot;Monitoring hedefi eri\u015filemiyor&quot;\n            description: &quot;{{ $labels.instance }} hedefi scrape edilemiyor.&quot;<\/code><\/pre>\n<p>\u0130lk alarm deployment kapasitesindeki kal\u0131c\u0131 d\u00fc\u015f\u00fc\u015f\u00fc, ikincisi scrape hedefindeki eri\u015fim problemini bildirir. Ger\u00e7ek ortamda <code>up == 0<\/code> kural\u0131n\u0131 her hedefe uygulamak yerine kritik job&#8217;lar\u0131 ayr\u0131ca se\u00e7mek gerekebilir; bak\u0131m s\u0131ras\u0131nda gereksiz alarm ya\u011fmuru istemezsiniz.<\/p>\n<p>Alertmanager&#8217;da al\u0131c\u0131 tan\u0131mlarken SMTP parolas\u0131n\u0131 YAML i\u00e7ine d\u00fcz metin yazmay\u0131n. Kubernetes Secret veya secret y\u00f6netim sistemi kullan\u0131n. Bildirim kanal\u0131n\u0131 kurduktan sonra kontroll\u00fc bir test alarm\u0131 \u00fcretip mesaj\u0131n ger\u00e7ekten ula\u015ft\u0131\u011f\u0131n\u0131 do\u011frulay\u0131n. Sessizce duran Alertmanager, \u00e7al\u0131\u015fmayan bir yang\u0131n alarm\u0131na benzer.<\/p>\n<h2><span id=\"Kaynak_kullanimi_ve_kardinalite_tuzagi\">Kaynak kullan\u0131m\u0131 ve kardinalite tuza\u011f\u0131<\/span><\/h2>\n<p>Prometheus&#8217;un kendisi de izlenmesi gereken bir servistir. Bellek kullan\u0131m\u0131 art\u0131yorsa ilk \u015f\u00fcphelilerden biri y\u00fcksek kardinalitedir. Her istek i\u00e7in benzersiz URL, kullan\u0131c\u0131 ID&#8217;si veya sipari\u015f numaras\u0131n\u0131 label yapmak zaman serisi say\u0131s\u0131n\u0131 h\u0131zla b\u00fcy\u00fct\u00fcr.<\/p>\n<p>\u015eu iki label yakla\u015f\u0131m\u0131 ayn\u0131 de\u011fildir:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">http_requests_total{path=&quot;\/orders\/847291&quot;}\nhttp_requests_total{route=&quot;\/orders\/:id&quot;}<\/code><\/pre>\n<p>\u0130lk \u00f6rnekte her sipari\u015f i\u00e7in yeni bir seri olu\u015fabilir. \u0130kinci \u00f6rnek route&#8217;u geneller ve daha y\u00f6netilebilir bir kardinalite \u00fcretir. Metrik isimleri ve label&#8217;lar uygulama geli\u015ftirme a\u015famas\u0131nda kararla\u015ft\u0131r\u0131lmal\u0131; sorun \u00e7\u0131kt\u0131ktan sonra temizlemek daha zahmetlidir.<\/p>\n<p>Prometheus pod&#8217;u s\u00fcrekli yeniden ba\u015fl\u0131yorsa \u015funlara bak\u0131n:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">kubectl describe pod -n monitoring -l app.kubernetes.io\/name=prometheus\nkubectl logs -n monitoring -l app.kubernetes.io\/name=prometheus --previous\nkubectl top pod -n monitoring<\/code><\/pre>\n<p><code>--previous<\/code> se\u00e7ene\u011fi, yeniden ba\u015flat\u0131lm\u0131\u015f container&#8217;\u0131n bir \u00f6nceki logunu g\u00f6sterir. <code>OOMKilled<\/code> g\u00f6r\u00fcrseniz do\u011frudan limiti art\u0131rmak yerine retention, scrape aral\u0131\u011f\u0131 ve y\u00fcksek kardinaliteli metrikleri de inceleyin.<\/p>\n<h2><span id=\"Bir_DDoS_gecesinde_monitoring8217in_gercek_sinavi\">Bir DDoS gecesinde monitoring&#8217;in ger\u00e7ek s\u0131nav\u0131<\/span><\/h2>\n<p>\u0130lk b\u00fcy\u00fck DDoS gecemde dashboard&#8217;lar \u00e7al\u0131\u015f\u0131yor, node metrikleri normal g\u00f6r\u00fcn\u00fcyor, fakat uygulama eri\u015filebilirlik kontrollerinde hata oran\u0131 y\u00fckseliyordu. \u0130lk bak\u0131\u015fta trafik art\u0131\u015f\u0131n\u0131 ger\u00e7ek kullan\u0131c\u0131 yo\u011funlu\u011fu sanmak kolayd\u0131. Metrikleri istek kaynaklar\u0131 ve yan\u0131t kodlar\u0131yla birlikte inceledi\u011fimizde isteklerin \u00f6nemli b\u00f6l\u00fcm\u00fcn\u00fcn ger\u00e7ek ziyaret\u00e7i davran\u0131\u015f\u0131na benzemedi\u011fi ortaya \u00e7\u0131kt\u0131.<\/p>\n<p>Rate limit, co\u011frafi filtre ve ingress katman\u0131ndaki ba\u011flant\u0131 limitlerini devreye al\u0131rken m\u00fc\u015fteriye \u015fu ayr\u0131m\u0131 anlatmam gerekti: Her HTTP iste\u011fi ger\u00e7ek ziyaret\u00e7i de\u011fildir. Monitoring yaln\u0131zca CPU ve bellek grafi\u011fi sunmamal\u0131; HTTP 4xx\/5xx oran\u0131n\u0131, istek hacmini, yan\u0131t s\u00fcresini ve m\u00fcmk\u00fcnse kaynak da\u011f\u0131l\u0131m\u0131n\u0131 da g\u00f6stermelidir.<\/p>\n<p>O geceden sonra alarm kurallar\u0131n\u0131 yaln\u0131zca node sa\u011fl\u0131\u011f\u0131na g\u00f6re b\u0131rakmad\u0131m. Ingress 5xx oran\u0131, ani istek art\u0131\u015f\u0131 ve uygulaman\u0131n d\u0131\u015far\u0131dan yan\u0131t verip vermedi\u011fi ayr\u0131 sinyaller olarak tan\u0131mland\u0131. Alarm\u0131n kendisini de izlemek gerekir; Prometheus hedefleri scrape edemiyorsa, Grafana veri kayna\u011f\u0131na ba\u011flanam\u0131yorsa veya Alertmanager bildirim g\u00f6nderemiyorsa bunlar ayr\u0131 alarm \u00fcretmelidir.<\/p>\n<h2><span id=\"Guvenlik_erisim_ve_maliyet\">G\u00fcvenlik, eri\u015fim ve maliyet<\/span><\/h2>\n<p>Grafana panelleri zarars\u0131z g\u00f6r\u00fcn\u00fcr; fakat metriklerde servis adlar\u0131, namespace&#8217;ler, node isimleri ve bazen m\u00fc\u015fteri bilgisine d\u00f6n\u00fc\u015febilecek label de\u011ferleri bulunabilir. Grafana&#8217;y\u0131 anonim eri\u015fime a\u00e7may\u0131n. Kubernetes API&#8217;ye geni\u015f yetkili bir ServiceAccount vermek de gereksiz risk olu\u015fturur; chart&#8217;\u0131n ihtiya\u00e7 duydu\u011fu RBAC izinlerini ve olu\u015fturulan kaynaklar\u0131 inceleyin.<\/p>\n<p>NetworkPolicy kullan\u0131yorsan\u0131z Prometheus&#8217;un kube-state-metrics, node-exporter ve uygulama metric servislerine eri\u015febildi\u011finden emin olun. \u00d6nce policy&#8217;siz test edip sonra kademeli k\u0131s\u0131tlama uygulamak, her \u015feyi ayn\u0131 anda kapat\u0131p sorunun kayna\u011f\u0131n\u0131 aramaktan daha h\u0131zl\u0131d\u0131r.<\/p>\n<p>Veri saklama s\u00fcresi de maliyet yarat\u0131r. On be\u015f g\u00fcnl\u00fck ayr\u0131nt\u0131l\u0131 metrik \u00e7o\u011fu k\u00fc\u00e7\u00fck cluster i\u00e7in ba\u015flang\u0131\u00e7ta yeterli olabilir; fakat kapasite planlamas\u0131 i\u00e7in aylarca veri gerekiyorsa uzun s\u00fcreli saklama sistemleri veya uzaktan yazma se\u00e7enekleri de\u011ferlendirilir. Prometheus diskini s\u0131n\u0131rs\u0131z b\u00fcy\u00fctmek yerine retention ve retention size birlikte belirlenmelidir.<\/p>\n<h2><span id=\"Monitoring8217i_isletmek_kurulumdan_sonraki_isler\">Monitoring&#8217;i i\u015fletmek: kurulumdan sonraki i\u015fler<\/span><\/h2>\n<p>Bir dashboard&#8217;u a\u00e7\u0131p b\u0131rakmay\u0131n. Her hafta hangi alarmlar\u0131n \u00fcretildi\u011fini, ka\u00e7\u0131n\u0131n susturuldu\u011funu ve hangilerinin aksiyona d\u00f6n\u00fc\u015fmedi\u011fini inceleyin. \u00dc\u00e7 kez yanl\u0131\u015f alarm \u00fcreten bir kural ya e\u015fik, ya sorgu, ya da hizmetin tasar\u0131m\u0131 a\u00e7\u0131s\u0131ndan yeniden ele al\u0131nmal\u0131d\u0131r.<\/p>\n<p>Bak\u0131m s\u0131ras\u0131nda alarmlar\u0131 susturmak gerekiyorsa s\u00fcre ve a\u00e7\u0131klama girin. Sonsuza kadar a\u00e7\u0131k bir silence, alarm\u0131 kapatman\u0131n daha \u015f\u0131k yaz\u0131lm\u0131\u015f halidir. Deployment de\u011fi\u015fikliklerinden sonra \u00f6zellikle \u015fu kontrolleri otomatikle\u015ftirebilirsiniz:<\/p>\n<ul>\n<li>Prometheus target durumlar\u0131<\/li>\n<li>Grafana veri kayna\u011f\u0131 eri\u015fimi<\/li>\n<li>Alertmanager al\u0131c\u0131lar\u0131na test bildirimi<\/li>\n<li>PVC doluluk oran\u0131<\/li>\n<li>Pod restart say\u0131s\u0131 ve OOMKilled olaylar\u0131<\/li>\n<li>Node disk, CPU ve bellek bask\u0131s\u0131<\/li>\n<li>Ingress HTTP 5xx oran\u0131 ve yan\u0131t s\u00fcresi<\/li>\n<\/ul>\n<p>Uygulaman\u0131z Kubernetes \u00fczerinde \u00e7al\u0131\u015fsa bile kullan\u0131c\u0131 g\u00f6z\u00fcnden yap\u0131lan sentetik kontrolleri ayr\u0131ca tutun. Pod&#8217;lar\u0131n sa\u011fl\u0131kl\u0131 g\u00f6r\u00fcnmesi, \u00f6deme endpoint&#8217;inin ger\u00e7ekten cevap verdi\u011fini kan\u0131tlamaz. D\u0131\u015far\u0131dan bir HTTP kontrol\u00fc ve i\u00e7erideki Prometheus metrikleri birlikte de\u011ferlendirildi\u011finde yanl\u0131\u015f te\u015fhis ihtimali azal\u0131r.<\/p>\n<p>Kubernetes operasyonlar\u0131n\u0131n yan\u0131nda uygulama katman\u0131ndaki kontrolleri de ihmal etmeyin. Bir WordPress sunucusunda farkl\u0131 t\u00fcrde sa\u011fl\u0131k sinyallerini okumak i\u00e7in <a href=\"https:\/\/www.dchost.com\/blog\/wordpress-site-sagligi-raporu-nasil-okunur\/\">WordPress Site Sa\u011fl\u0131\u011f\u0131 Raporu Nas\u0131l Okunur?<\/a> ba\u015fl\u0131kl\u0131 rehberdeki yakla\u015f\u0131m burada da i\u015fe yarar: uyar\u0131y\u0131 g\u00f6rmek yetmez, hangi bile\u015fenin ve hangi kullan\u0131c\u0131 ak\u0131\u015f\u0131n\u0131n etkilendi\u011fini ay\u0131rmak gerekir.<\/p>\n<p>Kendi lab ortam\u0131mda chart g\u00fcncellemelerini \u00f6nce ayr\u0131 bir namespace&#8217;te deniyor, ard\u0131ndan test alarm\u0131 \u00fcretip dashboard sorgular\u0131n\u0131 kar\u015f\u0131la\u015ft\u0131r\u0131yorum. \u00dcretimde bir grafi\u011fin bo\u015f kalmas\u0131 \u00e7o\u011fu zaman Prometheus&#8217;un bozuk oldu\u011funu de\u011fil, label selector&#8217;\u0131n yeni deployment ile art\u0131k e\u015fle\u015fmedi\u011fini g\u00f6steriyor. Bu k\u00fc\u00e7\u00fck ayr\u0131m, saatler s\u00fcren gereksiz incelemeyi \u00f6nl\u00fcyor.<\/p>\n<h2><span id=\"Sik_Sorulan_Sorular\">S\u0131k Sorulan Sorular<\/span><\/h2>\n<h3><span id=\"Prometheus_ile_Metrics_Server_arasindaki_fark_nedir\">Prometheus ile Metrics Server aras\u0131ndaki fark nedir?<\/span><\/h3>\n<p>Metrics Server anl\u0131k CPU ve bellek kullan\u0131m\u0131n\u0131 Kubernetes API&#8217;ye sunar; <code>kubectl top<\/code> ve Horizontal Pod Autoscaler gibi \u00f6zelliklerde kullan\u0131l\u0131r. Prometheus ise zaman serisi verisini saklar, uygulama metriklerini toplar ve alarm kurallar\u0131 \u00e7al\u0131\u015ft\u0131r\u0131r.<\/p>\n<h3><span id=\"Kubernetes_monitoring_icin_Grafana_kurmak_zorunlu_mu\">Kubernetes monitoring i\u00e7in Grafana kurmak zorunlu mu?<\/span><\/h3>\n<p>Hay\u0131r. Prometheus sorgular\u0131 ve Alertmanager ile Grafana olmadan da monitoring yap\u0131labilir. Grafana, \u00e7ok say\u0131da metri\u011fi ekiplerin daha h\u0131zl\u0131 okuyabilece\u011fi panellere d\u00f6n\u00fc\u015ft\u00fcrd\u00fc\u011f\u00fc i\u00e7in pratikte s\u0131k tercih edilir.<\/p>\n<h3><span id=\"Prometheus_verileri_ne_kadar_sure_saklanmali\">Prometheus verileri ne kadar s\u00fcre saklanmal\u0131?<\/span><\/h3>\n<p>Bu s\u00fcre cluster b\u00fcy\u00fckl\u00fc\u011f\u00fcne, disk kapasitesine ve ge\u00e7mi\u015f analiz ihtiyac\u0131na ba\u011fl\u0131d\u0131r. Ba\u015flang\u0131\u00e7ta 7-15 g\u00fcnl\u00fck bir retention belirleyip disk kullan\u0131m\u0131n\u0131 izlemek, s\u0131n\u0131rs\u0131z saklama tan\u0131mlamaktan daha g\u00fcvenlidir.<\/p>\n<h3><span id=\"Alarm_sayisini_nasil_azaltabilirim\">Alarm say\u0131s\u0131n\u0131 nas\u0131l azaltabilirim?<\/span><\/h3>\n<p>\u00d6nce ayn\u0131 olay\u0131 farkl\u0131 kurallar\u0131n bildirip bildirmedi\u011fini kontrol edin. K\u0131sa s\u00fcreli dalgalanmalar i\u00e7in <code>for<\/code> s\u00fcresi ekleyin, kritik ve bilgilendirici seviyeleri ay\u0131r\u0131n; hi\u00e7bir i\u015flem gerektirmeyen alarm\u0131 silmekten \u00e7ekinmeyin.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Kubernetes monitoring kurulumu i\u00e7in Prometheus, Grafana, Alertmanager ve kube-state-metrics bile\u015fenlerini kurup g\u00fcvenli ve anlaml\u0131 alarmlar olu\u015fturma ad\u0131mlar\u0131.<\/p>\n","protected":false},"author":4,"featured_media":5192,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[27],"tags":[518,520,519,517,52,515,516],"class_list":["post-5196","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-bulut-bilisim","tag-alertmanager","tag-container-izleme","tag-devops","tag-grafana","tag-kubernetes","tag-kubernetes-monitoring","tag-prometheus"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/posts\/5196","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/comments?post=5196"}],"version-history":[{"count":1,"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/posts\/5196\/revisions"}],"predecessor-version":[{"id":5198,"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/posts\/5196\/revisions\/5198"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/media\/5192"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/media?parent=5196"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/categories?post=5196"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/tags?post=5196"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}