Peringatan dan SLO
Pelajari cara mengubah data keteramatan menjadi peringatan yang dapat ditindaklanjuti menggunakan Service Level Objectives, anggaran kesalahan, dan peringatan berbasis gejala yang mengurangi kebisingan serta hanya menghubungi manusia saat benar-benar penting.
Peringatan dan SLO adalah pelajaran Microservices Communication Patterns (Saga, Circuit Breaker) gratis di CoddyKit. Ini adalah pelajaran 4 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar Microservices Communication Patterns (Saga, Circuit Breaker), dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus Microservices Communication Patterns (Saga, Circuit Breaker) mencakup 4 pelajaran total.
Bagian dari pelajaran ini belum diterjemahkan dan ditampilkan dalam bahasa Inggris.
From Observability to Action
Traces, logs, and metrics tell you what is happening. Alerting decides when a human needs to act. The goal is to page on real user pain, not on every blip.
What Is an SLI?
A Service Level Indicator is a measured aspect of service behavior, such as request latency, error rate, or availability. SLIs are the raw signal you alert on.
ok = 995
total = 1000
availability = ok / total * 100
print('Availability SLI:', availability, '%')What Is an SLO?
A Service Level Objective is a target for an SLI over a window, for example 'availability >= 99.9% over 30 days'. It defines what 'good enough' means.
Error Budgets
If your SLO is 99.9%, then 0.1% of requests are allowed to fail. That 0.1% is your error budget. Spend it on risk; if you burn it, slow down and stabilize.
slo = 99.9
budget_pct = 100 - slo
monthly_requests = 1000000
allowed_failures = monthly_requests * budget_pct / 100
print('Error budget (failures/month):', allowed_failures)Symptom vs Cause Alerts
Alert on symptoms users feel (high error rate, slow responses), not on every internal cause (one pod restarted). Cause alerts create noise; symptom alerts capture real impact.
Burn-Rate Alerting
Instead of paging the instant the SLO is missed, alert on how fast you are burning the error budget. A fast burn pages immediately; a slow burn opens a ticket.
def burn_rate(observed_error_rate, budget_rate):
return observed_error_rate / budget_rate
print('Burn rate:', burn_rate(0.01, 0.001), 'x budget')Reducing Alert Fatigue
Too many alerts and engineers ignore them all. Keep pages rare and meaningful:
- Every page must be actionable.
- Route non-urgent issues to tickets.
- Group related alerts together.
The Four Golden Signals
Google's SRE book recommends alerting on four signals:
- Latency
- Traffic
- Errors
- Saturation
Cover these and you catch most user-facing problems.
Severity Levels
Classify alerts by severity so the response matches the impact.
severity = {'P1': 'page on-call now', 'P2': 'page during hours', 'P3': 'create ticket'}
print(severity['P1'])Runbooks
Attach a runbook link to every alert. It tells the responder what the alert means, how to confirm impact, and the first steps to mitigate. Runbooks turn panic into procedure.
Closing the Loop
After each incident, review which alerts fired (and which should have). Tune thresholds, delete noisy alerts, and update runbooks. Alerting quality improves through iteration.
Quick Check
You have an SLO of 99.9% availability. What does the remaining 0.1% represent?
Recap
You learned alerting and SLOs:
- SLIs measure behavior; SLOs set targets; error budgets quantify allowed failure.
- Alert on symptoms and burn rate, not every cause.
- Use severity levels and runbooks to make pages actionable.
- Iterate to cut alert fatigue.
Good alerting pages humans only when users actually hurt.
Belajar Microservices Communication Patterns (Saga, Circuit Breaker) dengan tutor AI — gratis
Tulis dan jalankan kode asli di browser kamu, dapatkan bantuan instan dari tutor AI 24/7, dan lanjutkan di mana kamu tinggalkan di web atau aplikasi.
- Kursus
- 12
- Pelajaran
- 48
Pertanyaan yang Sering Diajukan
Apakah pelajaran “Peringatan dan SLO” gratis?
Ya — teks lengkap “Peringatan dan SLO” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus Microservices Communication Patterns (Saga, Circuit Breaker), upgrade ke CoddyKit PRO. Kursus Microservices Communication Patterns (Saga, Circuit Breaker) mencakup 4 pelajaran total.
Apa yang akan aku pelajari di “Peringatan dan SLO”?
Pelajari cara mengubah data keteramatan menjadi peringatan yang dapat ditindaklanjuti menggunakan Service Level Objectives, anggaran kesalahan, dan peringatan berbasis gejala yang mengurangi kebising… Kamu berlatih Microservices Communication Patterns (Saga, Circuit Breaker) dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.
Apakah aku perlu pengalaman untuk memulai Microservices Communication Patterns (Saga, Circuit Breaker)?
Tidak diperlukan pengalaman sebelumnya. Microservices Communication Patterns (Saga, Circuit Breaker) di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 4 dari 4.
Berapa lama pelajaran “Peringatan dan SLO” memakan waktu?
Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.
Bisakah aku menulis dan menjalankan kode dalam pelajaran Microservices Communication Patterns (Saga, Circuit Breaker) ini?
Ya. Setiap pelajaran Microservices Communication Patterns (Saga, Circuit Breaker) menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.
Semua pelajaran dalam kursus ini
- Konsep Pelacakan Terdistribusi
- Strategi Logging Terpusat
- Metrik dan Pemeriksaan Kondisi
- Peringatan dan SLO