Metrik Kardinalitesi ve Etiketleme için En İyi Uygulamalar
Etiketlerin kardinaliteyi nasıl oluşturduğunu, yüksek kardinalitenin metrik sistemlerini neden bozduğunu ve hızlı ve uygun maliyetli kalan etiket şemalarının nasıl tasarlanacağını öğrenin.
Metrik Kardinalitesi ve Etiketleme için En İyi Uygulamalar, CoddyKit'te ücretsiz bir System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry) dersidir. Bu, 4 dersinin 4. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry) öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry) kursu toplamda 4 dersten oluşur.
Bu dersin bazı bölümleri henüz çevrilmemiş olup İngilizce olarak gösterilmektedir.
What Is Cardinality?
Cardinality is the number of unique time series produced by a metric. Each distinct combination of a metric name and its label values is a separate series.
http_requests_total{method="GET"}is one series- Adding
status="200"multiplies the count
Labels Multiply
Cardinality grows by the product of the number of values per label. Three methods times five status codes times ten endpoints equals 150 series for one metric.
method: 3 values
status: 5 values
endpoint: 10 values
=> 3 * 5 * 10 = 150 seriesWhy High Cardinality Hurts
Each series consumes memory, disk, and index space. Unbounded labels can explode a single metric into millions of series, slowing queries and crashing collectors.
- Memory pressure on the TSDB
- Slow dashboards and alerts
- Higher storage cost
The Classic Anti-Pattern
Putting unbounded values like user IDs, request IDs, or full URLs into labels is the most common mistake. These create one series per unique value.
http_requests_total{user_id="48213"}
http_requests_total{request_id="a9f...c1"}Bounded vs Unbounded Labels
Good labels have a small, finite set of values.
- Bounded:
method,status_class,region - Unbounded:
user_id,session_id,email
Keep unbounded data in logs or traces, not metric labels.
Normalize Before Labeling
Reduce cardinality by bucketing values. Replace exact status codes with classes and template dynamic path segments.
status=503 -> status_class="5xx"
/users/48213 -> route="/users/:id"Estimating Series Count
Before adding a label, estimate its impact. Multiply the existing series count by the number of new label values.
existing = 200 series
new label region: 4 values
=> 200 * 4 = 800 seriesAggregation Removes Detail
When you query, aggregations like sum by (status_class) collapse series. Design labels so the dimensions you aggregate by are exactly the ones you need.
sum by (status_class) (rate(http_requests_total[5m]))Limits and Guardrails
Most TSDBs let you cap cardinality.
- Prometheus:
sample_limitper scrape - OpenTelemetry: cardinality limit on aggregations
- Alert when series counts spike
Dropping Bad Labels
If a noisy label slips in, drop or relabel it at ingestion rather than storing it.
metric_relabel_configs:
- source_labels: [user_id]
action: labeldropA Healthy Label Set
Aim for a handful of bounded labels per metric. This example stays well under a few hundred series.
orders_total{region="eu", status_class="2xx", channel="web"}Quick Check
Identify the riskiest label choice.
Recap
You learned that cardinality is the count of unique series, that labels multiply it, and that unbounded values like IDs must stay out of labels. Bucket and template values, estimate impact before adding labels, and enforce guardrails to keep metrics fast and cheap.
Sıkça Sorulan Sorular
“Metrik Kardinalitesi ve Etiketleme için En İyi Uygulamalar” dersi ücretsiz mi?
Evet — “Metrik Kardinalitesi ve Etiketleme için En İyi Uygulamalar” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry) kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry) kursu toplamda 4 dersten oluşur.
“Metrik Kardinalitesi ve Etiketleme için En İyi Uygulamalar” dersinde ne öğreneceğim?
Etiketlerin kardinaliteyi nasıl oluşturduğunu, yüksek kardinalitenin metrik sistemlerini neden bozduğunu ve hızlı ve uygun maliyetli kalan etiket şemalarının nasıl tasarlanacağını öğrenin. System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry) ile uygulamalı kodu tarayıcıda doğrudan çalıştırarak pratik yaparsın ve 7/24 yapay zeka koçu dersi çalışırken sorularını yanıtlar.
System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry) öğrenmeye başlamak için deneyim gerekli mi?
Önceden deneyim gerekmez. CoddyKit'te System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry), başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 4. dersidir.
“Metrik Kardinalitesi ve Etiketleme için En İyi Uygulamalar” dersi ne kadar sürer?
Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.
Bu System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry) dersinde kod yazıp çalıştırabilir miyim?
Evet. Her System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry) dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.
Bu kursun tüm dersleri
- Ölçüm Türleri Açıklaması
- Ölçüm Toplama Stratejileri
- Ölçüm Görselleştirme ve Uyarı
- Metrik Kardinalitesi ve Etiketleme için En İyi Uygulamalar