Monitoring and event management

Purpose in one sentenceTujuan dalam satu kalimatSystematically observe services and their components, and record and report selected changes of state identified as events.Mengamati layanan dan komponennya secara sistematis, serta mencatat dan melaporkan perubahan kondisi tertentu yang diidentifikasi sebagai event.

You can’t manage what you can’t see. Monitoring and event management watches services and their components so problems are spotted early, ideally before users notice. The challenge is balance: too little monitoring and you are blind, too much and the team drowns in alerts and starts ignoring them.

Anda tidak bisa mengelola apa yang tidak bisa Anda lihat. Monitoring and event management mengamati layanan dan komponennya agar masalah terdeteksi lebih awal, idealnya sebelum pengguna menyadarinya. Tantangannya adalah keseimbangan: terlalu sedikit monitoring membuat Anda buta, terlalu banyak membuat tim tenggelam dalam peringatan dan mulai mengabaikannya.

Key ideasKonsep kunci

Not every event is bad. Events can be informational (a backup finished), a warning (disk 80% full) or an exception (service down).
An alert needs an owner. Only events that need action should alert someone, and always the right someone.
Thresholds need tuning. Set them from normal behavior, then adjust them regularly to keep noise down.
Watch the service, not just the servers. End-to-end checks and observability show what users actually experience.
Automate known responses. If the fix for an event is always the same, let the system do it, and log it.

Tidak semua event itu buruk. Event bisa berupa informasi (backup selesai), peringatan (disk terisi 80%), atau pengecualian (layanan mati).
Setiap alert butuh pemilik. Hanya event yang perlu ditindaklanjuti yang boleh memicu peringatan, dan selalu kepada orang yang tepat.
Ambang batas perlu disetel. Tetapkan berdasarkan perilaku normal, lalu sesuaikan secara rutin agar peringatan tidak berlebihan.
Pantau layanannya, bukan hanya server. Pengecekan end-to-end dan observability menunjukkan apa yang benar-benar dialami pengguna.
Otomasi respons yang sudah diketahui. Jika perbaikan untuk suatu event selalu sama, biarkan sistem melakukannya, dan catat.

Key activitiesAktivitas kunci

A typical flow. Real work loops back and skips steps when it makes sense.

Alur yang umum. Dalam praktik, pekerjaan bisa kembali ke langkah sebelumnya atau melewati langkah tertentu bila masuk akal.

Decide what to watchStart from critical services, then their components.
Set rulesThresholds, baselines and who gets which alert.
Detect and filterIgnore noise, keep what matters.
CorrelateGroup related events into one picture.
RespondAuto-fix, alert a person, or open an incident.
Review and tuneRemove useless alerts; add missing checks.

Menentukan yang dipantauMulai dari layanan kritis, lalu komponennya.
Menetapkan aturanAmbang batas, baseline, dan siapa menerima peringatan apa.
Mendeteksi dan menyaringAbaikan yang tidak penting, simpan yang penting.
MengorelasikanKelompokkan event yang saling terkait menjadi satu gambaran.
MeresponsPerbaiki otomatis, beri peringatan ke petugas, atau buka incident.
Meninjau dan menyetelHapus peringatan yang tidak berguna; tambahkan pengecekan yang kurang.

How to measure itCara mengukurnya

MetricMetrik	What it tells youApa yang ditunjukkan	Watch out forPerhatikan
% of incidents detected before users% incident terdeteksi sebelum pengguna	How proactive you areSeberapa proaktif Anda	Incidents logged by monitoring after users calledIncident dicatat monitoring setelah pengguna menelepon
Actionable alert ratioRasio peringatan yang bisa ditindaklanjuti	How much of the noise is usefulSeberapa banyak peringatan yang benar-benar berguna	Hundreds of alerts nobody readsRatusan peringatan yang tidak dibaca siapa pun
Mean time to detectRata-rata waktu deteksi	How fast you notice problemsSeberapa cepat Anda menyadari masalah	Clock starting only when someone noticesHitungan waktu baru dimulai saat ada yang menyadari
Critical services with end-to-end checksLayanan kritis dengan pengecekan end-to-end	Coverage from the user’s viewCakupan dari sudut pandang pengguna	Only checking that servers respondHanya memeriksa bahwa server merespons
False positive rateTingkat peringatan palsu	Trust in your alertsKepercayaan terhadap peringatan Anda	People silencing alerts on their ownOrang membisukan peringatan atas inisiatif sendiri

What each level looks likeGambaran setiap level

Use these descriptions as a quick self-check before running the full assessment. Level 3 is a strong, realistic target for most teams.

Gunakan deskripsi ini sebagai pengecekan cepat sebelum menjalankan asesmen lengkap. Level 3 adalah target yang kuat dan realistis bagi sebagian besar tim.

L1InitialUsers are the monitoring system. IT finds out when someone calls.
L2RepeatableSome tools watch servers, but alerts go to a mailbox nobody checks.
L3DefinedCritical services are monitored end to end, with set thresholds, owners for alerts, and links to incident management.
L4MeasuredDetection time and alert noise are measured and tuned, and most incidents are found by monitoring first.
L5OptimizedPredictive monitoring and automatic fixes for known events, with alerts continually tuned.

L1InitialPenggunalah sistem monitoringnya. TI baru tahu saat ada yang menelepon.
L2RepeatableBeberapa tools memantau server, tetapi peringatannya masuk ke kotak surat yang tidak dicek siapa pun.
L3DefinedLayanan kritis dipantau end-to-end, dengan ambang batas, pemilik peringatan, dan keterkaitan dengan incident management.
L4MeasuredWaktu deteksi dan tingkat kebisingan peringatan diukur dan disetel, dan sebagian besar incident ditemukan monitoring lebih dulu.
L5OptimizedMonitoring prediktif dan perbaikan otomatis untuk event yang sudah dikenal, dengan peringatan yang terus disetel.

Assess monitoring and event management in the wizardNilai monitoring and event management di wizard →

Using AIMemanfaatkan AI

Correlation and de-duplication (often called AIOps) turn thousands of events into a few meaningful alerts.
Anomaly detection spots unusual patterns that fixed thresholds miss.
Forecasting predicts when disks, licenses or capacity will run out.
Automated runbooks carry out known fixes, such as restarting a stuck service.

Korelasi dan penghapusan duplikat (sering disebut AIOps) mengubah ribuan event menjadi beberapa peringatan yang bermakna.
Deteksi anomali menemukan pola tidak wajar yang terlewat oleh ambang batas tetap.
Prakiraan memprediksi kapan disk, lisensi, atau kapasitas akan habis.
Runbook otomatis menjalankan perbaikan yang sudah dikenal, seperti me-restart layanan yang macet.

Keep a human in the loopTetap libatkan manusiaStart automatic fixes with low-risk actions, log everything, and keep a person approving anything that could cause damage.Mulai perbaikan otomatis dari tindakan berisiko rendah, catat semuanya, dan pastikan tindakan yang bisa menimbulkan kerusakan tetap disetujui manusia.

Key ideaInti materiGood monitoring isn’t more alerts. It’s the right alerts, reaching the right people, early enough to act.Monitoring yang baik bukan berarti lebih banyak peringatan, melainkan peringatan yang tepat, sampai ke orang yang tepat, cukup awal untuk ditindaklanjuti.

Real-world example: 4,000 alerts a dayContoh kasus: 4.000 peringatan sehari3 min3 menit

An online retailer’s operations team receives about 4,000 alerts a day. They have learned to ignore them, and one evening they miss a real checkout outage for 25 minutes.

Tim operasional sebuah peritel online menerima sekitar 4.000 peringatan per hari. Mereka terbiasa mengabaikannya, dan suatu malam mereka melewatkan gangguan checkout yang nyata selama 25 menit.

They remove duplicates, set thresholds per service, and add a synthetic test that places a fake order every minute. Alerts fall to about 150 a day, all actionable, and checkout problems are now detected in about 3 minutes.

Mereka menghapus duplikat, menetapkan ambang batas per layanan, dan menambahkan uji sintetis yang membuat pesanan palsu setiap menit. Peringatan turun menjadi sekitar 150 per hari, semuanya bisa ditindaklanjuti, dan masalah checkout kini terdeteksi dalam sekitar 3 menit.

Common pitfallsJebakan umum

Monitoring components but not the services users depend on.
Setting thresholds once and never tuning them.
Alerts with no clear owner.
Beautiful dashboards that nobody watches.

Memantau komponen tetapi tidak memantau layanan yang diandalkan pengguna.
Menetapkan ambang batas sekali dan tidak pernah menyetelnya lagi.
Peringatan tanpa pemilik yang jelas.
Dashboard cantik yang tidak dilihat siapa pun.

Related practicesPractice terkait

PracticePractice	How they connectBagaimana keterkaitannya
Incident management	Events that need a response become incidents.Event yang perlu ditanggapi menjadi incident.
Capacity and performance management	Uses monitoring data to plan capacity.Memakai data monitoring untuk merencanakan kapasitas.
Availability management	Uses monitoring to measure availability.Memakai monitoring untuk mengukur ketersediaan.
Infrastructure and platform management	Owns many of the components being monitored.Memiliki banyak komponen yang dipantau.

Beginner tipsTips untuk pemula

List your five most important services and ask: "How would we know it’s broken?"
Silence or delete any alert nobody acted on in the last 30 days.
Add one synthetic test that behaves like a real user for your most important service.

Daftar lima layanan terpenting Anda dan tanyakan: "Bagaimana kita tahu layanan ini rusak?"
Bisukan atau hapus peringatan yang tidak ditindaklanjuti siapa pun dalam 30 hari terakhir.
Tambahkan satu uji sintetis yang berperilaku seperti pengguna nyata untuk layanan terpenting Anda.

The practice name and purpose follow ITIL. KPIs, level descriptions, AI uses and pitfalls are practical guidance written in our own words, not official ITIL text.Nama dan tujuan practice mengikuti ITIL. KPI, deskripsi level, pemanfaatan AI, dan jebakan umum adalah panduan praktis yang ditulis dengan kata-kata sendiri, bukan teks resmi ITIL.