Veri Bilimi Okulu

Prometheus Nedir? Açık Kaynak İzleme Aracı
Prometheus Nedir? Açık Kaynak İzleme Aracı
prometheus_nedir_kapak_960x640

Loading

Merhaba arkadaşlar! Bugün sizlerle birlikte DevOps ve bulut dünyasının en popüler izleme (monitoring) araçlarından biri olan Prometheus‘u inceleyeceğiz. Eğer altyapınızı, uygulamalarınızı ve servislerinizi gerçek zamanlı olarak takip etmek istiyorsanız, Prometheus doğru seçim olabilir!

Prometheus’a Giriş: Neden Bu Kadar Popüler?

Prometheus, açık kaynaklı bir izleme (monitoring) ve uyarı (alerting) araç takımıdır (toolkit). İlk olarak 2012 yılında SoundCloud bünyesinde geliştirilmiş, ardından CNCF’e (Cloud Native Computing Foundation) devredilmiş ve Kubernetes’in ardından bu vakıftan mezun olan ikinci proje olmuştur [1][2]. Yani Prometheus’un arkasında ciddi bir topluluk ve kurumsal destek var.

Peki Prometheus’u bu kadar özel kılan ne? Temelde şu özelliklere sahip:

Prometheus, çok boyutlu bir veri modeli (multi-dimensional data model) kullanır. Zaman serisi verileri (time series data) bir metrik adı (metric name) ve anahtar-değer çiftlerinden (key-value pairs) oluşan etiketlerle (labels) tanımlanır [3]. Bu yapı sayesinde veriler son derece verimli bir şekilde saklanır ve sorgulanır. Prometheus kendi güçlü sorgu diline sahiptir: PromQL (Prometheus Query Language). Bu dil, metrikleri filtreleme, gruplama ve dönüştürme konusunda inanılmaz esneklik sunar [4].

Prometheus’un bir diğer önemli avantajı bağımsız çalışabilmesidir. Her Prometheus sunucusu kendi yerel depolama alanını (local storage) kullanır ve dağıtık depolama sistemlerine ihtiyaç duymaz [5]. Bu da onu güvenilir kılar; altyapınızın geri kalanı çökse bile Prometheus ayakta kalabilir.

Prometheus Mimarisi: Büyük Resmi Görelim

Prometheus’un nasıl çalıştığını anlamak için mimarisine bir göz atalım. Temel bileşenler şunlardır:

Prometheus Sunucusu (Prometheus Server): Sistemin kalbidir. Hedeflerden (targets) metrikleri toplar, bunları zaman serisi veritabanında (time series database) saklar ve PromQL sorgularını işler [6]. Sunucu, verileri hem bellekte (memory) tutar hem de diske yazar; böylece hem hız hem de dayanıklılık sağlanır.

Kazıyıcı (Scraper): Prometheus, çekme modeli (pull model) üzerinde çalışır. Bu ne demek? Prometheus sunucusu, belirli aralıklarla HTTP üzerinden hedef uç noktalardan (endpoints) metrikleri çeker [7]. Bu hedefler konteynerleriniz (containers), pod’larınız, sanal makineleriniz (virtual machines) veya herhangi bir Prometheus uyumlu uygulama olabilir. Varsayılan olarak her hedef /metrics yolu üzerinden metriklerini sunar.

İstemci Kütüphaneleri (Client Libraries): Go, Java, Python, Ruby, .NET, Node.js gibi birçok programlama dili için resmi istemci kütüphaneleri mevcuttur [8]. Bu kütüphaneler sayesinde geliştiriciler kendi uygulamalarına özel metrikler (custom metrics) tanımlayabilir.

Push Gateway: Kısa ömürlü işler (short-lived jobs) veya zamanlanmış görevler (cron jobs) gibi, Prometheus’un doğrudan kazıyamayacağı hedefler için bir ara katman görevi görür. Bu servisler metriklerini Push Gateway’e iter, ardından Prometheus oradan çeker [9].

Dışa Aktarıcılar (Exporters): Prometheus metriklerini yerel olarak desteklemeyen yazılımlar için özel dışa aktarıcılar kullanılır. Örneğin, Node Exporter sanal makinelerin CPU, bellek ve disk istatistiklerini toplar. HAProxy, Nginx, MySQL gibi popüler yazılımlar için de hazır dışa aktarıcılar bulunur [10].

Uyarı Yöneticisi (Alertmanager): Prometheus’un tetiklediği uyarıları alır, gruplar, sessizleştirir ve Slack, Microsoft Teams, PagerDuty veya e-posta gibi kanallara yönlendirir [11].

Şekil-1: Prometheus Architecture

Metrik Türleri: Hangi Metriği Ne Zaman Kullanalım?

Prometheus’un veri modeli dört temel metrik türü (metric types) üzerine kuruludur. Her birinin kendine has kullanım senaryoları vardır. Bunları yakından tanıyalım.

1. Sayaç (Counter)

Sayaç, yalnızca artan tek yönlü bir metriktir; tıpkı bir arabanın kilometre sayacı gibi asla geriye gitmez [12]. Örneğin toplam HTTP istek sayısını (http_requests_total) veya toplam hata sayısını izlemek için sayaçları kullanırız. Servis yeniden başlatıldığında sayaç sıfırlanabilir, ancak Prometheus’un rate() ve increase() fonksiyonları bu durumu akıllıca yönetir [13].

Tipik bir PromQL sorgusu şöyle görünür:

rate(http_requests_total[5m])

Bu sorgu, son 5 dakika içindeki saniye başına ortalama istek oranını hesaplar [14].

2. Gauge

Gauge, hem artabilen hem de azalabilen bir değeri temsil eder. Anlık durumları izlemek için idealdir: mevcut bellek kullanımı (memory usage), CPU sıcaklığı, kuyruktaki iş sayısı (queue depth) veya eşzamanlı bağlantı sayısı (concurrent connections) gibi [15]. Şu anda ne olduğunu gösterir; geçmişte ne olduğunu değil.

Hatta predict_linear() fonksiyonuyla bir ölçerin gelecekteki değerini tahmin edebilirsiniz. Örneğin disk alanının 4 saat sonra ne durumda olacağını öngörmek için bu fonksiyonu kullanabilirsiniz [16].

3. Histogram

Histogram, değer dağılımlarını (distributions) ölçmek için kullanılır ve önceden tanımlanmış kovalara (buckets) göre gözlemleri sayar [17]. En yaygın kullanım alanı gecikme (latency) metrikleridir. Örneğin bir API’nin yanıt sürelerini 0.1s, 0.3s, 0.5s, 1s gibi kovalara bölerek her kovadaki istek sayısını takip edebilirsiniz.

Histogram, her kazıma işleminde (scrape) üç farklı zaman serisi sunar: _bucket (kova sayaçları), _sum (tüm gözlemlerin toplamı) ve _count (toplam gözlem sayısı) [18]. PromQL’deki histogram_quantile() fonksiyonuyla yüzdelik dilim (percentile) hesaplamaları yapabilirsiniz:

histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))

Bu sorgu, son 5 dakikadaki isteklerin %95’inin ne kadar sürede tamamlandığını gösterir [19].

4. Özet (Summary)

Özet, histograma benzer şekilde dağılımları ölçer ancak yüzdelik dilimleri (quantiles) sunucu tarafında değil, istemci tarafında (client-side) hesaplar [20]. Hassas yüzdelik dilim değerleri istediğinizde kullanılır. Ancak önemli bir kısıtlaması vardır: özetler birden fazla örnek (instance) arasında birleştirilemez (aggregate). Bu nedenle Prometheus topluluğu genel olarak histogramları özetlere tercih etmeyi önerir [21].

Yapılandırma: Prometheus’u Nasıl Kuracağız?

Prometheus’un binary dosyalarını indirip doğrudan çalıştırabilir veya Docker konteynerinde başlatabilirsiniz [22]. Yapılandırmanın kalbi prometheus.yml dosyasıdır.

Bu dosyada iki temel ayar bulunur:

Genel Ayarlar (Global Settings): Kazıma aralığı (scrape interval) burada belirlenir. Varsayılan olarak 15 saniyeye ayarlıdır, ancak Kubernetes ortamlarında genellikle 30 saniye kullanılır. Daha sık kazıma daha doğru veriler sağlar ama ağ üzerinde daha fazla yük oluşturur. Değerlendirme aralığı (evaluation interval) ise kuralların ne sıklıkla değerlendirileceğini belirler.

Kazıma Yapılandırmaları (Scrape Configs): Her hedef uygulama veya servis için ayrı bir iş (job) tanımlanır. Her iş, statik hedefler (static configs) veya servis keşfi (service discovery) mekanizmaları aracılığıyla hedeflere ulaşır [23].

Basit bir yapılandırma dosyası şu şekilde görünür:

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'web-app'
    static_configs:
      - targets: ['localhost:5000']
  - job_name: 'node-exporter'
    static_configs:
      - targets: ['localhost:9100']

Kubernetes ortamında ise hedefler sürekli değişebildiği için Prometheus’un servis keşfi (service discovery) mekanizması devreye girer. Yeni bir pod oluşturulduğunda veya kaldırıldığında yapılandırma dosyalarını elle güncellemenize gerek kalmaz [24]. Ayrıca Servis Monitör (ServiceMonitor) adlı küçük YAML nesneleri kullanarak Prometheus’un yapılandırmasını Kubernetes’e özgü bir şekilde yönetebilirsiniz.

PromQL ile Prometheus Verisi Sorgulama

PromQL, Prometheus’un en güçlü yanlarından biridir. Zaman serisi verileri üzerinde filtreleme, toplama (aggregation) ve dönüştürme işlemleri yapmanızı sağlar [25]. Temel kavramlara bakalım:

Anlık Vektör (Instant Vector): Belirli bir zaman noktasındaki metrik değerlerini döndürür. Basitçe metrik adını yazmak yeterlidir: http_requests_total.

Aralık Vektörü (Range Vector): Belirli bir zaman aralığındaki değerleri getirir: http_requests_total[5m]. Bu, son 5 dakikadaki tüm veri noktalarını içerir [26].

Etiket Seçicileri (Label Selectors): Süslü parantezlerle filtreleme yapılır: http_requests_total{status="500"}. Bu sorgu yalnızca 500 hata koduna sahip istekleri getirir. Düzenli ifade (regex) eşleştirmesi için =~ operatörü kullanılır [27].

Sıkça kullanılan bazı fonksiyonlar:

rate() fonksiyonu sayaç metriklerinde saniye başına ortalama artış oranını hesaplar. increase() fonksiyonu belirli bir zaman dilimindeki toplam artışı verir. sum(), avg(), max(), min() gibi toplama operatörleri (aggregation operators) birden fazla zaman serisini birleştirmek için kullanılır [28].

Örneğin prod ortamdaki toplam hata oranını görmek için:

sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

Bu sorgu, son 5 dakikadaki 5xx hatalarının toplam isteklere oranını hesaplar [29].

Grafana ile Görselleştirme

Prometheus kendi başına basit bir ifade tarayıcısı (expression browser) sunar, ancak profesyonel panolar (dashboards) ve görselleştirme için genellikle Grafana kullanılır [30]. Grafana, Prometheus’u yerel bir veri kaynağı (data source) olarak destekler ve yapılandırma son derece basittir.

Grafana’da Prometheus’u veri kaynağı olarak eklemek için Prometheus sunucusunun URL’sini (varsayılan olarak http://localhost:9090) girmeniz yeterlidir. Ardından PromQL sorgularıyla panolar oluşturabilir, önceden hazırlanmış pano şablonlarını (dashboard templates) içe aktarabilir (import) ve uyarı kurallarını görsel olarak yönetebilirsiniz [31].

Grafana’nın topluluğu tarafından paylaşılan yüzlerce hazır pano şablonu bulunmaktadır. Örneğin Node Exporter Full panosu, sunucu kaynaklarını (CPU, bellek, disk, ağ) kapsamlı bir şekilde görselleştirir [32]. Bu şablonları Grafana.com üzerinden kolayca bulabilir ve kendi ortamınıza aktarabilirsiniz.

Kubernetes ile Entegrasyon

Prometheus’un cloud-native dünyada bu denli yaygınlaşmasının en büyük nedenlerinden biri Kubernetes ile mükemmel uyumudur. Kubernetes altyapıları son derece dinamiktir; pod’lar sürekli oluşturulur ve yok edilir. Prometheus’un servis keşfi mekanizması bu dinamik yapıyla sorunsuz çalışır [33].

Kubernetes ortamında Kubernetes API sunucusu (API server), kubelet’ler, kube-state-metrics gibi bileşenlerden metrikler toplanabilir. ServiceMonitor nesneleri kullanılarak her yeni servis için Prometheus yapılandırması otomatik olarak güncellenir. Bu, manuel yapılandırma dosyası düzenlemesinden kurtulmanızı sağlar.

Bulut sağlayıcıları da Prometheus desteğini benimsemiştir. Örneğin Microsoft Azure, yönetilen bir Prometheus hizmeti (Azure Monitor managed service for Prometheus) sunarak AKS kümelerinden otomatik metrik toplama ve 18 aya kadar veri saklama imkânı tanır [34].

ÖzellikAWSGoogle Cloud (GCP)Microsoft Azure
Servis AdıAmazon Managed Service for Prometheus (AMP)Google Cloud Managed Service for Prometheus (GMP)Azure Monitor managed service for Prometheus
AltyapıCortex tabanlı (açık kaynaklı, yatayda ölçeklenebilir).Monarch tabanlı (Google’ın kendi devasa iç izleme sistemi).Azure Monitor altyapısına entegre edilmiştir.
Veri SaklamaStandart 150 gün (ayarlanabilir).24 ay (2 yıl) standart saklama süresi sunar.Standart 18 ay (ayarlanabilir).
En İyi UyumAmazon EKS, ECS ve Fargate.Google Kubernetes Engine (GKE) ve Cloud Run.Azure Kubernetes Service (AKS) ve Azure Arc.
SorgulamaTam PromQL desteği.PromQL ve Google’ın kendi MQL dili.Tam PromQL desteği.

Uzağa Yazma (Remote Write) ve Uzun Vadeli Depolama (Long-Term Storage)

Prometheus varsayılan olarak verileri yerel diskte saklar ve kısa vadeli tutma (retention) süreleri uygular. Ancak uzun vadeli depolama (long-term storage) ihtiyaçları için uzağa yazma (remote write) özelliği devreye girer. Bu özellik sayesinde Prometheus verileri Grafana Mimir, VictoriaMetrics, Thanos veya Cortex gibi uzun vadeli depolama çözümlerine aktarılabilir [35].

Bu yapı aynı zamanda Prometheus’u yüksek kullanılabilir (highly available) hale getirmek için de kullanılır. Birden fazla Prometheus sunucusu (instance) çalıştırıp verilerini merkezi bir depoya yazabilirsiniz.

Prometheus Pratik Bilgiler

Prometheus Hakkında Bilmeniz Gereken 7 Şey
  1. Prometheus 2012’de SoundCloud’da doğdu ve Kubernetes’ten sonra CNCF’den mezun olan ikinci projedir. Yani bu araç “hobi projesi” değil, endüstri standardı.
  2. Çekme modeli (pull model) kullanır. Prometheus hedeflerinize gidip metrikleri kendisi çeker. Uygulamalarınızın bir yere veri göndermesine gerek yok, sadece /metrics endpoint’i açık olsun yeter.
  3. Dört temel metrik türü vardır: Counter (sayaç), Gauge (ölçer), Histogram ve Summary (özet). Bu dördünü anlamadan Prometheus’u verimli kullanamazsınız.
  4. PromQL, Prometheus’un kendi sorgu dilidir ve SQL’den tamamen farklıdır. Öğrenme eğrisi var ama rate(), increase(), histogram_quantile() gibi fonksiyonları öğrendiğinizde elinize güçlü bir silah geçiyor.
  5. Harici veritabanına ihtiyaç duymaz. Her Prometheus sunucusu bağımsız çalışır, kendi yerel depolama alanını kullanır. Altyapınızın geri kalanı çökse bile Prometheus ayakta kalır.
  6. Kubernetes ile mükemmel uyum sağlar. ServiceMonitor nesneleri sayesinde yeni bir servis deploy ettiğinizde Prometheus yapılandırması otomatik güncellenir, elle config dosyası düzenlemenize gerek kalmaz.
  7. Prometheus tek başına görselleştirme için yeterli değildir. Grafana ile birlikte kullanıldığında gerçek gücüne ulaşır. Hazır pano şablonlarıyla dakikalar içinde profesyonel dashboard’lar oluşturabilirsiniz.
Prometheus Kullanırken Kaçınılması Gereken 5 Hata
  1. Yüksek kardinalite (high cardinality) tuzağına düşmek. Etiketlerde (labels) kullanıcı ID’si, session token veya istek URL’si gibi sınırsız değerler kullanmak Prometheus’u dize getirir. Etiketleri düşük kardinaliteli tutun: method, status_code, endpoint gibi.
  2. Scrape interval’ı gereğinden fazla kısmak. “Ne kadar sık kazırsam o kadar iyi” düşüncesi yanlış. 5 saniyeye çekmek ağ trafiğini ve depolama maliyetini patlatır. Kubernetes ortamlarında 30 saniye altın standarttır; gerçekten ihtiyacınız yoksa değiştirmeyin.
  3. Counter metriğini doğrudan okumaya çalışmak. Counter sürekli artan bir değerdir, ham haliyle anlamsızdır. Mutlaka rate() veya increase() ile sorgulayın. Aksi halde grafiklerde sürekli yükselen bir çizgi görürsünüz ve bu size hiçbir şey söylemez.
  4. Histogram bucket sınırlarını rastgele belirlemek. Varsayılan bucket’lar her senaryo için uygun değildir. API yanıt süreniz genelde 50-200ms aralığındaysa ama bucket’larınız 1s, 5s, 10s ise tüm istekleriniz aynı kovaya düşer ve dağılımı göremezsiniz. Bucket’ları kendi SLA’lerinize göre ayarlayın.
  5. Uyarı kurallarını (alert rules) Prometheus’un web UI’ında test etmeden üretime almak. Hatalı bir PromQL sorgusu ya sessiz kalır ya da gece 3’te sizi yalancı alarmlarla uyandırır. Önce Prometheus UI’da sorgunuzu çalıştırın, beklediğiniz sonucu verdiğinden emin olun, sonra Alertmanager’a bağlayın.
Prometheus’u Öğrenirken İşinize Yarayacak 6 PromQL Sorgusu
  1. Saniye başına istek oranı: rate(http_requests_total[5m]) — Son 5 dakikadaki istek hızınızı gösterir. İzlemeye buradan başlayın.
  2. Hata oranı yüzdesi: sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) * 100 — 5xx hatalarınızın toplam trafiğe oranını verir. SRE’ler bu sorguyu çok sever.
  3. 95. yüzdelik dilim gecikme: histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) — İsteklerinizin %95’inin kaç saniyede tamamlandığını gösterir.
  4. Anlık bellek kullanımı: node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes — Sunucunuzda şu anda ne kadar bellek kullanıldığını gösterir.
  5. Disk dolum tahmini: predict_linear(node_filesystem_free_bytes[6h], 4*3600) — Son 6 saatlik trende bakarak 4 saat sonra ne kadar disk alanınız kalacağını tahmin eder. Kapasite planlaması için mükemmel.
  6. En çok istek alan endpoint’ler: topk(5, sum by(handler) (rate(http_requests_total[5m]))) — Hangi endpoint’lerinizin en yoğun trafiği aldığını sıralar.
Prometheus vs Diğerleri: 4 Maddede Neden Prometheus?
  1. Datadog/New Relic → Güçlü ama paralı. Prometheus açık kaynak ve ücretsiz. Küçük ekipler ve startup’lar için maliyet avantajı büyük.
  2. Zabbix/Nagios → Geleneksel izleme araçları. Kubernetes ve mikroservis dünyasında esneklikleri yetersiz kalıyor. Prometheus’un servis keşfi (service discovery) ve etiket tabanlı veri modeli bu dinamik ortamlar için tasarlandı.
  3. ELK Stack → Loglar için harika ama metrikler için optimize değil. Prometheus zaman serisi verileri için özel olarak tasarlandı ve PromQL ile çok daha verimli sorgulama yapabilirsiniz.
  4. InfluxDB → İyi bir zaman serisi veritabanı ama Prometheus’un ekosistemi (exporters, client libraries, Grafana entegrasyonu, Alertmanager) çok daha geniş. Topluluk desteği ve hazır entegrasyonlar açısından Prometheus bir adım önde.

Sonuç

Prometheus, modern altyapı izlemenin temel taşlarından biridir. Çok boyutlu veri modeli, güçlü PromQL sorgu dili, çekme tabanlı (pull based) mimari ve geniş ekosistemi sayesinde küçük projelerden kurumsal ölçekli Kubernetes cluster’larına kadar her yerde etkin bir şekilde kullanılabilir.

Bu yazıda Prometheus’un ne olduğunu, mimarisini, metrik türlerini, yapılandırmasını, PromQL sorgularını ve Grafana entegrasyonunu özet olarak inceledik. Docker Compose ile lokal ortamınızda bir Prometheus ve Grafana yığını (stack) kurarak bu araçları bizzat deneyimleyebilirsiniz.

Bir sonraki adım olarak kendi uygulamalarınıza istemci kütüphaneleriyle metrikler eklemeyi, özel panolar oluşturmayı ve uyarı kuralları tanımlamayı öğrenmenizi şiddetle tavsiye ederim. İzleme dünyasının kapıları sizlere sonuna kadar açık!

Kubernetes üzerinde uygulamalı bir deneyim isterseniz VBO Kubernetes Bootcamp for Data Professionals eğitimini tavsiye ederim.

Bir sonraki yazıda görüşmek üzere, kendinize iyi bakın!

Kaynaklar

[1] Prometheus — Monitoring system & time series database. https://prometheus.io/

[2] “Prometheus: Open-source metrics and monitoring systems and services,” Help Net Security, December 2025. https://www.helpnetsecurity.com/2025/12/15/prometheus-open-source-metrics-monitoring-systems-services/

[3] “Prometheus (software),” Wikipedia. https://en.wikipedia.org/wiki/Prometheus_(software)

[4] “Overview,” Prometheus Documentation. https://prometheus.io/docs/introduction/overview/

[5] “Prometheus Monitoring: From Zero to Hero, The Right Way,” Dash0. https://www.dash0.com/guides/prometheus-monitoring

[6] “Prometheus,” GitHub. https://github.com/prometheus/prometheus

[7] “Prometheus for Developers: An Introduction,” daily.dev. https://daily.dev/blog/prometheus-for-developers-an-introduction

[8] “Prometheus Monitoring,” GeeksforGeeks. https://www.geeksforgeeks.org/devops/prometheus-monitoring/

[9] “Prometheus Monitoring OSS,” Grafana Labs. https://grafana.com/oss/prometheus/

[10] “Overview of Azure Monitor with Prometheus,” Microsoft Learn. https://learn.microsoft.com/en-us/azure/azure-monitor/metrics/prometheus-metrics-overview

[11] “Metric types,” Prometheus Documentation. https://prometheus.io/docs/concepts/metric_types/

[12] “Understanding the Prometheus Metric Types,” Dash0. https://www.dash0.com/knowledge/prometheus-metrics

[13] “Prometheus Metrics Explained: Counters, Gauges, Histograms & Summaries,” VictoriaMetrics Blog. https://victoriametrics.com/blog/prometheus-monitoring-metrics-counters-gauges-histogram-summaries/

[14] “Understanding metric types,” Prometheus Documentation. https://prometheus.io/docs/tutorials/understanding_metric_types/

[15] “An introduction to the 4 primary Prometheus metrics types,” Chronosphere. https://chronosphere.io/learn/an-introduction-to-the-four-primary-types-of-prometheus-metrics/

[16] “Prometheus Metric Types,” OpenObserve. https://openobserve.ai/blog/prometheus-metrics-types/

[17] “Prometheus Metrics Types — A Deep Dive,” Last9. https://last9.io/blog/prometheus-metrics-types-a-deep-dive/

[18] “What are the 4 Types of Metrics in Prometheus,” SigNoz. https://signoz.io/guides/what-are-the-4-types-of-metrics-in-prometheus/

[19] “Querying basics,” Prometheus Documentation. https://prometheus.io/docs/prometheus/latest/querying/basics/

[20] “Metric Types,” Prometheus Java Client. http://prometheus.github.io/client_java/getting-started/metric-types/

[21] “Prometheus metric type conversion,” Amazon CloudWatch Docs. https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus-metrics-conversion.html

[22] “Grafana support for Prometheus,” Prometheus Documentation. https://prometheus.io/docs/visualization/grafana/

[23] “Get started with Grafana and Prometheus,” Grafana Documentation. https://grafana.com/docs/grafana/latest/getting-started/get-started-grafana-prometheus/

[24] “Creating Grafana Dashboards for Prometheus: A Beginner’s Guide,” Better Stack. https://betterstack.com/community/guides/monitoring/visualize-prometheus-metrics-grafana/

[25] “PromQL Cheat Sheet,” PagerTree. https://pagertree.com/blog/promql-cheat-sheet-a-quick-guide-to-prometheus-query-language

[26] “Query examples,” Prometheus Documentation. https://prometheus.io/docs/prometheus/latest/querying/examples/

[27] “PromQL for Beginners,” Last9. https://last9.io/blog/promql-for-beginners-getting-started-with-prometheus-query-language/

[28] “PromQL: A Developer’s Guide to Prometheus Query Language,” Last9. https://last9.io/blog/guide-to-prometheus-query-language/

[29] “Essential Prometheus Queries: Simple to Advanced,” Last9. https://last9.io/blog/prometheus-query-examples/

[30] “The Beginner’s Handbook to PromQL,” Better Stack. https://betterstack.com/community/guides/monitoring/promql/

[31] “Prometheus data source,” Grafana Documentation. https://grafana.com/docs/grafana/latest/datasources/prometheus/

[32] “Prometheus Grafana Dashboard,” OpenLogic. https://www.openlogic.com/blog/how-visualize-prometheus-data-grafana

[33] “Prometheus Querying Best Practices,” Medium. https://medium.com/@yogeshkolhatkar/prometheus-querying-best-practices-a-complete-guide-a2f0b2899a93

[34] “Overview of Azure Monitor with Prometheus,” Microsoft Learn. https://learn.microsoft.com/en-us/azure/azure-monitor/metrics/prometheus-metrics-overview

[35] “Essential PromQL Cheat Sheet,” SigNoz. https://signoz.io/guides/promql-cheat-sheet/

0

Bir yanıt yazın

Password Requirements:

  • At least 8 characters
  • At least 1 lowercase letter
  • At least 1 uppercase letter
  • At least 1 numerical number
  • At least 1 special character