คาร์ดินาลิตีของเมทริกซ์และแนวทางปฏิบัติที่ดีในการติดป้ายกำกับ
เรียนรู้ว่าป้ายกำกับสร้างคาร์ดินาลิตีได้อย่างไร เหตุใดคาร์ดินาลิตีสูงจึงทำให้ระบบเมทริกซ์มีปัญหา และวิธีออกแบบรูปแบบป้ายกำกับให้รวดเร็วและมีต้นทุนเหมาะสม
คาร์ดินาลิตีของเมทริกซ์และแนวทางปฏิบัติที่ดีในการติดป้ายกำกับ เป็นบทเรียน System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry) ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry) และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry) มีบทเรียนทั้งหมด 4 บทเรียน
บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ
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.
เรียนรู้ System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry) ด้วย AI tutor — ฟรี
เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป
- คอร์ส
- 12
- บทเรียน
- 48
คำถามที่พบบ่อย
บทเรียน “คาร์ดินาลิตีของเมทริกซ์และแนวทางปฏิบัติที่ดีในการติดป้ายกำกับ” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “คาร์ดินาลิตีของเมทริกซ์และแนวทางปฏิบัติที่ดีในการติดป้ายกำกับ” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry) ให้อัปเกรดเป็น CoddyKit PRO คอร์ส System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry) มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “คาร์ดินาลิตีของเมทริกซ์และแนวทางปฏิบัติที่ดีในการติดป้ายกำกับ”
เรียนรู้ว่าป้ายกำกับสร้างคาร์ดินาลิตีได้อย่างไร เหตุใดคาร์ดินาลิตีสูงจึงทำให้ระบบเมทริกซ์มีปัญหา และวิธีออกแบบรูปแบบป้ายกำกับให้รวดเร็วและมีต้นทุนเหมาะสม คุณปฏิบัติ System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry) ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry) หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry) บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน
บทเรียน “คาร์ดินาลิตีของเมทริกซ์และแนวทางปฏิบัติที่ดีในการติดป้ายกำกับ” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry) นี้ได้ไหม
ได้ บทเรียน System Observability: Logging, Metrics & Tracing (ELK + OpenTelemetry) ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- อธิบายประเภทของตัวชี้วัด
- กลยุทธ์การรวบรวมตัวชี้วัด
- การแสดงผลและการแจ้งเตือนตัวชี้วัด
- คาร์ดินาลิตีของเมทริกซ์และแนวทางปฏิบัติที่ดีในการติดป้ายกำกับ