Observability: Kenapa Monitoring Sistem Saja Tidak Cukup

Dashboard menunjukkan seluruh server aktif. Penggunaan CPU masih normal, kapasitas penyimpanan cukup, dan tidak ada alert infrastruktur yang menyala.

Namun, pengguna tetap tidak dapat menyelesaikan transaksi.

Tim customer service mulai menerima komplain. Pesanan tertahan, data tidak diperbarui, dan beberapa pengguna harus mengulangi proses yang sama. Tim IT mengetahui bahwa terdapat masalah, tetapi tidak dapat segera menjawab bagian terpentingnya:

• Pengguna mana yang terdampak?
• Proses mana yang gagal?
• Sejak kapan kegagalan terjadi?
• Apakah masalah berasal dari aplikasi, database, atau integrasi?
• Apakah seluruh transaksi gagal atau hanya kondisi tertentu?
• Perubahan apa yang terjadi sebelum masalah muncul?
• Seberapa besar dampaknya terhadap operasional bisnis?

Situasi tersebut menunjukkan keterbatasan monitoring tradisional.

Monitoring dapat memberi tahu bahwa sebuah kondisi melewati batas yang sudah ditentukan. Namun, pada sistem enterprise yang terdiri dari banyak aplikasi, database, API, layanan cloud, dan integrasi pihak ketiga, mengetahui bahwa sesuatu bermasalah belum tentu cukup untuk menemukan penyebabnya.

Perusahaan membutuhkan observability.

Observability adalah kemampuan untuk memahami kondisi internal suatu sistem melalui data yang dihasilkan sistem tersebut. Data ini memungkinkan tim mengajukan pertanyaan baru, menelusuri hubungan antar-komponen, dan memahami masalah yang sebelumnya belum pernah diprediksi.

OpenTelemetry menjelaskan observability sebagai kemampuan memahami sistem dari luar dan menginvestigasi masalah baru atau unknown unknowns. Agar dapat dilakukan, aplikasi perlu menghasilkan telemetry seperti metrics, logs, dan traces.

Dengan observability, pertanyaan tim tidak berhenti pada:

“Apakah sistem sedang bermasalah?”

Tim dapat melanjutkan investigasi menjadi:

“Mengapa masalah terjadi, siapa yang terdampak, dan komponen mana yang menyebabkan kegagalan?”

Apa Itu Observability?

Istilah observability berasal dari teori kontrol, tetapi dalam software digunakan untuk menggambarkan seberapa baik tim dapat memahami perilaku internal sistem berdasarkan output yang tersedia.

Sebuah sistem dikatakan semakin observable ketika tim dapat:

• Mengetahui kondisi layanan dari perspektif pengguna.
• Mengikuti perjalanan satu transaksi dari awal sampai akhir.
• Menghubungkan error dengan perubahan kode tertentu.
• Mengidentifikasi dependency yang memperlambat proses.
• Memisahkan masalah aplikasi dari masalah infrastruktur.
• Mengetahui kelompok pengguna yang terdampak.
• Mengukur dampak gangguan terhadap proses bisnis.
• Menemukan pola masalah yang belum pernah dibuatkan alert.
• Menentukan prioritas perbaikan berdasarkan data.

Observability bukan hanya kumpulan dashboard.

Perusahaan tidak otomatis memiliki observability hanya karena sudah menggunakan monitoring tool, menyimpan log, atau memasang application performance monitoring.

Observability muncul ketika data aplikasi dan infrastruktur:

1. Dikumpulkan secara relevan.
2. Memiliki konteks yang cukup.
3. Dapat dikorelasikan.
4. Dapat dicari ketika insiden terjadi.
5. Menghasilkan informasi yang dapat ditindaklanjuti.
6. Terhubung dengan dampak terhadap pengguna dan bisnis.

AWS menjelaskan bahwa observability memungkinkan organisasi mengumpulkan dan menganalisis data aplikasi serta infrastruktur untuk memahami kondisi internal, mendeteksi masalah, melakukan troubleshooting, dan meningkatkan pengalaman pengguna. Observability juga dapat digunakan untuk mengukur KPI operasional dan Service Level Objectives.

Dengan kata lain, tujuan observability bukan mengumpulkan sebanyak mungkin data.

Tujuannya adalah memberikan kemampuan untuk memahami apa yang sedang terjadi ketika sistem berperilaku di luar ekspektasi.

Apa Perbedaan Monitoring dan Observability?

Monitoring dan observability bukan dua konsep yang saling menggantikan.

Monitoring merupakan bagian penting dari observability. Perbedaannya terletak pada jenis pertanyaan yang dapat dijawab.

Google SRE mendefinisikan monitoring sebagai proses mengumpulkan, memproses, menggabungkan, dan menampilkan data kuantitatif real-time mengenai sistem, seperti jumlah request, error, waktu proses, dan masa aktif server.

Monitoring biasanya bekerja berdasarkan kondisi yang sudah diketahui.

Contohnya:

• Berikan alert jika CPU melebihi 80%.
• Berikan alert jika database tidak dapat diakses.
• Berikan alert jika error rate melebihi 5%.
• Berikan alert jika penyimpanan tersisa kurang dari 10%.
• Berikan alert jika response time melebihi dua detik.

Aturan tersebut efektif untuk masalah yang sudah dapat diprediksi.

Observability dibutuhkan ketika masalahnya belum diketahui atau melibatkan hubungan yang lebih kompleks.

Monitoring dapat menunjukkan bahwa response time meningkat.

Observability membantu tim mengetahui bahwa peningkatan tersebut hanya terjadi pada pengguna dari wilayah tertentu, setelah deployment terbaru, ketika aplikasi memanggil API pembayaran tertentu, dan saat database replica mengalami keterlambatan sinkronisasi.

Monitoring memberitahukan gejalanya. Observability menyediakan konteks untuk memahami penyebabnya.

Kenapa Monitoring Saja Tidak Lagi Cukup?

1. Sistem Enterprise Tidak Berjalan sebagai Satu Aplikasi

Sistem bisnis modern jarang hanya terdiri dari satu server dan satu database.

Satu proses transaksi dapat melibatkan:

• Aplikasi web atau mobile.
• API gateway.
• Authentication service.
• Order management.
• Database.
• Payment gateway.
• Inventory system.
• ERP.
• Notification service.
• Cloud storage.
• Analytics platform.
• Layanan pihak ketiga.

Ketika pengguna menekan satu tombol, request dapat melewati beberapa komponen sebelum proses selesai.

Jika hanya endpoint terakhir yang menghasilkan error, monitoring mungkin menunjukkan bahwa aplikasi utama tetap aktif. Padahal, transaksi bisnisnya gagal.

Pada sistem terdistribusi, status setiap komponen secara individual belum tentu menggambarkan kesehatan proses secara keseluruhan.

2. Infrastruktur Sehat Belum Berarti Pengguna Berhasil

CPU rendah, memory tersedia, dan server aktif bukan jaminan pengguna dapat menyelesaikan pekerjaannya.

Sebuah aplikasi dapat memberikan HTTP status 200, tetapi menampilkan data yang tidak lengkap. Payment service dapat menerima request, tetapi callback tidak pernah diproses. Sistem inventori dapat aktif, tetapi stok yang ditampilkan terlambat diperbarui.

OpenTelemetry menekankan bahwa reliability harus dinilai berdasarkan apakah layanan melakukan apa yang diharapkan pengguna. Sistem dapat aktif sepanjang waktu, tetapi tetap tidak reliable apabila hasil yang diberikan tidak benar.

Karena itu, observability harus mencakup indikator bisnis, bukan hanya indikator infrastruktur.

Contohnya:

• Checkout success rate.
• Persentase pembayaran terverifikasi.
• Jumlah order yang tertahan.
• Waktu approval.
• Kecepatan sinkronisasi stok.
• Dokumen yang berhasil diproses.
• Jumlah transaksi duplikat.
• Persentase laporan yang selesai dibuat.

3. Masalah Tidak Selalu Menghasilkan Error yang Jelas

Beberapa kegagalan terlihat sebagai error. Masalah lain menghasilkan respons yang tampak berhasil, tetapi hasilnya salah atau terlambat.

Contohnya:

• Proses mengembalikan status berhasil, tetapi data tidak tersimpan.
• Email konfirmasi berhasil dikirim, tetapi pesanan gagal dibuat.
• Data masuk ke queue, tetapi tidak pernah selesai diproses.
• Retry menyembunyikan kegagalan awal.
• Cache menampilkan data lama.
• Laporan selesai dibuat, tetapi menggunakan data yang belum sinkron.

Monitoring yang hanya menghitung server error dapat melewatkan kondisi tersebut.

Observability perlu menghubungkan event teknis dengan hasil proses bisnis.

4. Average Metrics Dapat Menyembunyikan Masalah

Rata-rata response time dapat terlihat normal meskipun sebagian pengguna mengalami keterlambatan yang signifikan.

Misalnya, 95% request selesai dalam 300 milidetik, tetapi 5% lainnya membutuhkan lebih dari sepuluh detik. Apabila sistem menangani jutaan request, lima persen tersebut dapat mewakili banyak pengguna.

Karena itu, tim perlu melihat distribusi dan percentile seperti p50, p95, dan p99, bukan hanya rata-rata.

Google SRE pernah menjelaskan bagaimana penggunaan mean performance dapat menyembunyikan kelompok request yang jauh lebih lambat dan menghasilkan alert yang tidak membantu tim memahami dampak aktual terhadap pengguna.

5. Retry Dapat Menyembunyikan Kegagalan

Retry membantu sistem pulih dari gangguan sementara.

Namun, retry juga dapat membuat sistem terlihat sehat. Request akhirnya berhasil, tetapi membutuhkan tiga atau empat percobaan.

Dari perspektif pengguna, aplikasi menjadi lambat. Dari perspektif dependency, jumlah request meningkat. Jika gangguan membesar, retry dapat menambah tekanan dan memperburuk overload.

Observability perlu menampilkan:

• Jumlah percobaan ulang.
• Penyebab retry.
• Layanan yang menghasilkan kegagalan awal.
• Waktu tambahan akibat retry.
• Persentase transaksi yang berhasil pada percobaan pertama.
• Dampaknya terhadap pengguna.

6. Kegagalan Baru Tidak Memiliki Alert

Alert hanya dapat dibuat untuk kondisi yang sudah diperkirakan.

Namun, software terus berubah. Fitur baru, pola pengguna baru, dependency baru, dan pertumbuhan data dapat menciptakan bentuk kegagalan yang belum pernah terjadi.

Tim tidak mungkin membuat alert untuk setiap kemungkinan.

Observability memungkinkan tim melakukan analisis ad hoc ketika masalah baru muncul. Data yang sudah memiliki konteks dapat ditelusuri tanpa menunggu developer menambahkan log baru dan melakukan deployment ulang.

Metrics, Logs, dan Traces

Observability sering dibahas melalui tiga jenis telemetry utama: metrics, logs, dan traces.

OpenTelemetry saat ini mendukung beberapa jenis signal, termasuk traces, metrics, logs, dan baggage, dengan kemampuan lain seperti profiles terus berkembang.

Ketiga telemetry utama tersebut memberikan sudut pandang yang berbeda.

Metrics: Menunjukkan Pola dan Perubahan

Metrics adalah data numerik yang dikumpulkan dari waktu ke waktu.

Contohnya:

• Request per second.
• Error rate.
• Response time.
• CPU utilization.
• Memory usage.
• Database connection.
• Queue depth.
• Checkout success rate.
• Jumlah order per menit.

Metrics efektif untuk melihat tren, membandingkan kondisi, membuat dashboard, dan memicu alert.

Namun, metrics biasanya sudah melalui agregasi. Metrics dapat menunjukkan bahwa error meningkat, tetapi belum tentu menjelaskan transaksi mana yang gagal.

Logs: Memberikan Detail Kejadian

Logs merupakan catatan mengenai event tertentu.

Contohnya:

• Pengguna berhasil login.
• Payment callback diterima.
• Query database gagal.
• File tidak ditemukan.
• Token kedaluwarsa.
• Order berhasil dibuat.
• Permission ditolak.

Logs membantu melihat detail teknis dan kronologi.

Namun, log yang tidak terstruktur atau tidak memiliki correlation ID sulit digunakan pada sistem dengan banyak layanan.

OpenTelemetry menjelaskan bahwa logs menjadi lebih berguna ketika dapat dikorelasikan dengan trace dan span karena log individual biasanya tidak memiliki konteks lengkap mengenai perjalanan request.

Traces: Mengikuti Perjalanan Transaksi

Distributed trace menunjukkan perjalanan satu request melalui beberapa komponen.

Sebuah transaksi checkout, misalnya, dapat melewati:

1. Mobile application.
2. API gateway.
3. Authentication.
4. Cart service.
5. Inventory service.
6. Payment provider.
7. Order database.
8. Notification service.

Setiap aktivitas direpresentasikan sebagai span. Kumpulan span membentuk trace end-to-end.

Distributed tracing membantu tim mengetahui:

• Layanan yang membutuhkan waktu paling lama.
• Komponen yang menghasilkan error.
• Dependency yang gagal.
• Urutan proses.
• Request yang melakukan retry.
• Perubahan latency antar-komponen.

OpenTelemetry menyebut distributed tracing penting untuk memahami request yang bergerak melalui sistem kompleks dan membantu mendiagnosis peril trace end-to-end.

Distributed tracing me

• Layanan yang membutuhkan aku yang sulit direproduksi secara lokal.

Observability Juga Membutuhkan Business Events

Metrics, logs, dan traces teknis belum tentu cukup untuk menjelaskan dampak bisnis.

Perusahaan juga perlu merekam business events, seperti:

• Order created.
• Payment completed.
• Payment failed.
• Approval submitted.
• Approval rejected.
• Inventory reserved.
• Delivery assigned.
• Document verified.
• Refund processed.
• Report generated.

Business event membantu tim menghubungkan kesehatan software dengan hasil operasional.

Misalnya, error rate aplikasi hanya meningkat 0,5%. Secara teknis, angka tersebut mungkin terlihat kecil.

Namun, jika seluruh error terjadi pada transaksi pembayaran bernilai tinggi, dampak bisnisnya dapat signifikan.

Sebaliknya, jumlah warning dapat meningkat drastis tetapi tidak memengaruhi proses kritis. Tanpa konteks bisnis, tim dapat menghabiskan waktu menangani sinyal yang tidak penting.

Empat Golden Signals dari Google SRE

Google SRE memperkenalkan empat golden signals yang dapat digunakan sebagai titik awal monitoring layanan:

Latency

Waktu yang dibutuhkan untuk memproses request.

Latency perlu membedakan request berhasil dan gagal. Request yang gagal cepat tidak selalu lebih baik daripada request berhasil yang sedikit lebih lambat.

Traffic

Jumlah demand yang diterima sistem.

Traffic dapat diukur melalui request per second, transaksi, session, pesan, atau volume pekerjaan lain yang relevan.

Errors

Jumlah atau persentase request yang gagal.

Error tidak hanya mencakup HTTP 500. Hasil yang salah, timeout, atau proses yang melanggar business rule juga dapat dikategorikan sebagai kegagalan.

Saturation

Seberapa dekat resource terhadap kapasitas maksimumnya.

Contohnya:

• CPU.
• Memory.
• Database connection.
• Queue.
• Disk.
• Thread pool.
• Rate limit pihak ketiga.

Keempat golden signals membantu perusahaan menghindari dashboard yang dipenuhi metrics tetapi tidak menjawab kondisi layanan. Google SRE merekoard layanan setidaknya mencakup bentuk dari golden signals tersebut.

Namun, golden signals bukan checklist final.

Perusahaan tetap perlu menambahkan indikator yang sesuai dengan proses bisnis dan karakteristik sistem.

Contoh: Monitoring Hijau, tetapi Checkout Gagal

Bayangkan sebuah platform e-commerce memiliki kondisi berikut:

• CPU berada pada 40%.
• Memory berada pada 55%.
• Database aktif.
• API utama mengembalikan status 200.
• Tidak ada server yang mati.

Dashboard monitoring terlihat normal.

Namun, pengguna dari aplikasi Android versi tertentu tidak dapat menyelesaikan pembayaran.

Dengan observability, tim dapat menelusuri:

1. Checkout success rate menurun pada aplikasi Android versi tertentu.
2. Trace menunjukkan request berhenti pada payment adapter.
3. Log memperlihatkan format nomor telepon yang tidak sesuai.
4. Perubahan format berasal dari aplikasi versi terbaru.
5. Error tidak menghasilkan HTTP 500 karena payment adapter mengembalikan status bisnis tertentu.
6. Dashboard infrastruktur tidak mendeteksinya karena seluruh server tetap sehat.

Tanpa observability, tim mungkin baru mengetahui masalah dari customer support.

Dengan observability, penurunan business metric dapat digunakan sebagai sinyal awal, kemudian trace dan log membantu menemukan penyebabnya.

Hubungan Observability dengan Incident Management

Observability tidak menggantikan Incident Management.

Incident management menentukan bagaimana perusahaan merespons gangguan: siapa yang memimpin, bagaimana prioritas ditentukan, bagaimana komunikasi dilakukan, dan bagaimana layanan dipulihkan.

Observability menyediakan data yang dibutuhkan selama proses tersebut.

Tanpa observability, tim incident response bekerja berdasarkan dugaan:

• Mencoba restart layanan.
• Menaikkan kapasitas tanpa mengetahui bottleneck.
• Menelusuri log satu per satu.
• Menghubungi banyak tim.
• Membandingkan deployment secara manual.
• Menunggu masalah muncul kembali.

Dengan telemetry yang terhubung, tim dapat mempersempit ruang investigasi lebih cepat.

Observability membantu menurunkan:

• Mean Time to Detect.
• Mean Time to Acknowledge.
• Mean Time to Diagnose.
• Mean Time to Restore.

Namun, observability hanya memberikan nilai jika alert dan data dapat ditindaklanjuti.

Google SRE menyarankan agar alert yang memanggil manusia menunjukkan kondisi mendesak, berdampak pada pengguna, dan memiliki tindakan yang dapat dilakukan. Terlalu banyak alert tidak relevan d fatigue dan membuat tim melewatkan masalah yang benar-benar penting.

Hubungan Observability dengan Cost of Change

Artikel Cost of Change menjelaskan bahwa bug setelah production dapat menghasilkan biaya yang jauh melampaui proses memperbaiki kode.

Biaya dapat mencakup:

• Diagnosis.
• Hotfix.
• Rollback.
• Pemulihan data.
• Downtime.
• Customer support.
• Gangguan operasional.
• Pelanggaran SLA.
• Kerusakan reputasi.

Observability tidak selalu mencegah bug masuk production. Namun, observability dapat mengurangi biaya melalui deteksi yang lebih cepat dan diagnosis yang lebih akurat.

Semakin cepat tim mengetahui:

• Di mana masalah terjadi.
• Pengguna mana yang terdampak.
• Perubahan apa yang memicunya.
• Data apa yang perlu dipulihkan.
• Tindakan mitigasi apa yang paling aman.

Semakin kecil kemungkinan insiden berkembang tanpa kendali.

Observability juga membantu tim mengevaluasi apakah perbaikan benar-benar berhasil, bukan hanya membuat alert berhenti menyala.

Cara Membangun Observability pada Sistem Enterprise

1. Mulai dari Critical User Journey

Jangan memulai dari pertanyaan, “Tool apa yang harus dibeli?”

Mulailah dengan proses yang paling penting bagi pengguna dan bisnis.

Contohnya:

• Login.
• Pembuatan pesanan.
• Pembayaran.
• Persetujuan.
• Reservasi stok.
• Pembuatan invoice.
• Sinkronisasi data.
• Pengiriman.
• Pelaporan.

Untuk setiap journey, identifikasi:

• Titik awal dan akhir.
• Layanan yang terlibat.
• Dependency eksternal.
• Business event.
• Kondisi berhasil.
• Kondisi gagal.
• Target performa.
• Dampak ketika proses terganggu.

Pendekatan ini memastikan investasi observability diarahkan pada proses bernilai tinggi.

2. Tentukan SLI dan SLO

Service Level Indicator adalah pengukuran perilaku layanan.

Contohnya:

• Persentase checkout berhasil.
• P95 response time.
• Persentase transaksi tanpa duplikasi.
• Waktu sinkronisasi.
• Ketersediaan API.

Service Level Objective adalah target yang ingin dicapai.

Contohnya:

• 99,9% checkout berhasil dalam satu bulan.
• 95% halaman dimuat di bawah dua detik.
• 99% sinkronisasi selesai dalam lima menit.
• Tidak ada transaksi keuangan duplikat.

OpenTelemetry menjelaskan bahwa SLI sebaiknya mengukur layanan dari perspektif pengguna, sekan indikator tersebut dengan ekspektasi organisasi dan nilai bisnis.

3. Instrumentasikan Aplikasi Sejak Development

Observability sebaiknya menjadi bagian dari desain dan development, bukan ditambahkan setelah insiden besar terjadi.

Setiap layanan perlu menghasilkan telemetry yang relevan, termasuk:

• Request ID.
• Trace ID.
• User atau tenant identifier yang aman.
• Service name.
• Environment.
• Version.
• Endpoint.
• Error type.
• Dependency.
• Processing duration.
• Business event.

Namun, jangan mencatat password, token, nomor kartu, atau data pribadi secara sembarangan.

Instrumentasi harus mengikuti kebijakan keamanan dan privasi data perusahaan.

4. Gunakan Correlation ID

Correlation ID memungkinkan tim mengikuti satu proses di beberapa layanan.

Misalnya, satu order memiliki correlation ID yang sama ketika melewati:

• Order service.
• Payment service.
• Inventory service.
• ERP integration.
• Notification service.

Tanpa correlation ID, tim harus mencocokkan timestamp dan data secara manual.

5. Gunakan Standar yang Mengurangi Ketergantungan Vendor

OpenTelemetry merupakan framework observability open-source dan vendor-neutral untulkan, serta mengekspor telemetry seperti traces, metrics, dan logs.

Menggunakan standar terbuka membantu perusahaan memisahkan instrumentasi aplikasi dari platform penyimpanan atau analisis yang digunakan.

Hal ini tidak menghilangkan seluruh vendor lock-in, tetapi dapat membuat data telemetry lebih mudah dipindahkan atau dikirim ke beberapa backend.

6. Bangun Dashboard Berdasarkan Tingkat Pengguna

Satu dashboard tidak dapat menjawab seluruh kebutuhan.

Perusahaan dapat membagi dashboard menjadi:

Dashboard Bisnis

Menampilkan:

• Jumlah transaksi.
• Success rate.
• Order tertahan.
• Payment failure.
• Waktu approval.
• Dampak terhadap cabang atau pelanggan.

Dashboard Layanan

Menampilkan:

• Latency.
• Traffic.
• Error.
• Saturation.
• Dependency.
• Queue.
• Availability.

Dashboard Teknis

Menampilkan:

• CPU.
• Memory.
• Database.
• Container.
• Network.
• Cache.
• Runtime.
• Infrastructure events.

Pembagian ini membantu setiap tim memperoleh konteks yang sesuai.

7. Buat Alert Berdasarkan Dampak

Tidak semua perubahan metrics membutuhkan notifikasi kepada manusia.

Alert sebaiknya memiliki:

• Kondisi yang jelas.
• Tingkat prioritas.
• Dampak pengguna.
• Owner.
• Runbook.
• Jalur eskalasi.
• Tindakan awal.
• Batas waktu respons.

CPU tinggi selama satu menit belum tentu membutuhkan engineer on-call.

Namun, penurunan checkout success rate selama lima menit dapat membutuhkan respons segera meskipun CPU tetap normal.

8. Uji Observability

Telemetry juga perlu diuji.

Perusahaan dapat melakukan simulasi:

• Mematikan satu dependency.
• Menghasilkan error aplikasi.
• Memperlambat query.
• Menambah queue.
• Menghentikan worker.
• Menjalankan deployment bermasalah.
• Membuat transaksi gagal.

Kemudian periksa:

• Apakah masalah terdeteksi?
• Apakah alert mencapai tim yang tepat?
• Apakah trace tersedia?
• Apakah log memiliki konteks?
• Apakah dashboard menunjukkan dampak?
• Apakah runbook dapat digunakan?
• Apakah recovery dapat diverifikasi?

AWS merekomendasikan penggunaan pengujian seperti load, exception, dan synthetic transaction ne serta memahami metrics dan log event yang mengindikasikan masalah.

Tahapan Kematangan Observability

Perusahaan tidak harus langsung berada pada tingkat tertinggi.

Prioritasnya adalah meningkatkan kemampuan berdasarkan risiko dan kompleksitas sistem.

Sistem internal sederhana mungkin tidak membutuhkan distributed tracing yang kompleks. Sistem dengan banyak layanan, transaksi, dan integrasi memiliki kebutuhan berbeda.

Metrik untuk Mengukur Efektivitas Observability

Mean Time to Detect

Berapa lama waktu antara masalah mulai terjadi dan tim mengetahuinya?

Mean Time to Diagnose

Berapa lama waktu yang dibutuhkan untuk menemukan komponen atau kondisi penyebab?

Mean Time to Restore

Berapa lama waktu sampai layanan kembali stabil?

Incident Detection Source

Berapa banyak insiden ditemukan oleh sistem internal dibandingkan laporan pengguna?

Jika mayoritas insiden diketahui dari pelanggan, coverage observability perlu dievaluasi.

Alert Precision

Berapa banyak alert yang benar-benar membutuhkan tindakan?

Alert precision rendah menunjukkan terlalu banyak noise.

Critical Journey Coverage

Berapa persen proses bisnis kritis sudah memiliki SLI, trace, log, dan dashboard yang memadai?

Telemetry Completeness

Apakah telemetry memiliki service name, environment, version, correlation ID, dan atribut penting lainnya?

Repeated Incident Rate

Apakah insiden serupa terus terjadi meskipun data sebelumnya sudah tersedia?

Jika iya, masalahnya mungkin bukan kurangnya data, tetapi kurangnya follow-up dan pengelolaan technical debt.

Observability Cost

Berapa biaya penyimpanan, pengiriman, dan analisis telemetry?

Observability yang tidak memiliki retention, sampling, dan prioritas dapat menghasilkan biaya tinggi tanpa memberikan informasi yang sebanding.

Kesalahan yang Membuat Observability Tidak Efektif

Menganggap Observability sebagai Produk

Membeli platform tidak otomatis membuat sistem observable.

Aplikasi tetap membutuhkan instrumentasi, struktur data, ownership, dan proses respons.

Mengumpulkan Semua Data

Lebih banyak data tidak selalu berarti lebih banyak pemahaman.

Data yang tidak memiliki konteks hanya menambah biaya penyimpanan dan menyulitkan pencarian.

Hanya Memantau Infrastruktur

Server dapat sehat sementara proses bisnis gagal.

Gunakan business metrics dan synthetic transaction untuk melihat layanan dari perspektif pengguna.

Membuat Alert untuk Setiap Metrics

Alert yang terlalu banyak menyebabkan alert fatigue.

Dashboard digunakan untuk observasi. Alert digunakan untuk kondisi yang membutuhkan tindakan.

Tidak Menentukan Owner

Setiap layanan, dashboard, dan alert harus memiliki owner.

Alert tanpa owner hanya memindahkan kebingungan dari sistem ke manusia.

Menyimpan Data Sensitif di Logs

Logs dapat berisi informasi yang sangat detail.

Perusahaan perlu menerapkan masking, access control, encryption, retention, dan audit.

Tidak Menyertakan Version dan Deployment

Ketika error meningkat, tim perlu mengetahui perubahan apa yang baru dirilis.

Telemetry sebaiknya dapat dikaitkan dengan application version, deployment, dan feature flag.

Tidak Menghubungkan Telemetry

Metrics berada di satu platform, logs di tempat lain, dan traces tidak menggunakan identifier yang sama.

Akibatnya, tim tetap harus melakukan investigasi secara manual.

Dashboard Tidak Pernah Digunakan Saat Insiden

Dashboard yang tampak lengkap belum tentu membantu.

Setelah insiden, evaluasi dashboard dan alert yang benar-benar digunakan oleh tim. Hapus visualisasi yang tidak memberikan nilai dan tambahkan konteks yang hilang.

Observability untuk Startup dan Enterprise

Startup tidak harus langsung membangun observability platform yang sangat kompleks.

Namun, sejak versi awal, startup sebaiknya memiliki:

• Centralized error logging.
• Basic application metrics.
• Deployment tracking.
• Critical journey monitoring.
• Database monitoring.
• Alert untuk kegagalan utama.
• Identifikasi pengguna atau transaksi terdampak.

Ketika sistem berkembang menjadi scale-up, kebutuhan bertambah:

• Distributed tracing.
• SLO.
• On-call process.
• Service ownership.
• Dependency mapping.
• Capacity metrics.
• Automated response.
• Business-level observability.

Untuk perusahaan enterprise, tantangannya sering bukan kekurangan tools, tetapi data yang tersebar pada banyak aplikasi dan vendor.

Observability enterprise perlu menghubungkan:

• Legacy system.
• Custom application.
• ERP.
• CRM.
• Cloud infrastructure.
• Mobile application.
• API pihak ketiga.
• Database.
• Proses operasional.

Tujuannya bukan memindahkan seluruh data ke satu dashboard, tetapi memastikan perusahaan memiliki pandangan end-to-end terhadap proses kritis.

Kapan Sistem Membutuhkan Peningkatan Observability?

Beberapa tanda yang perlu diperhatikan:

• Tim sering mengetahui masalah dari pelanggan.
• Diagnosis incident membutuhkan waktu lama.
• Restart menjadi solusi default.
• Log hanya tersedia pada server tertentu.
• Tidak ada correlation ID.
• Perubahan kode sulit dikaitkan dengan incident.
• Tim tidak mengetahui transaksi yang terdampak.
• Dashboard hanya berisi CPU dan memory.
• Alert terlalu banyak dan sering diabaikan.
• Dependency pihak ketiga tidak dipantau.
• Sistem memiliki banyak integrasi.
• Data tidak konsisten antar-aplikasi.
• Post-mortem berulang kali menyebut monitoring sebagai masalah.
• Manajemen tidak mengetahui dampak bisnis dari downtime.

Masalah tersebut tidak selalu membutuhkan pembangunan ulang sistem.

Observability dapat ditambahkan secara bertahap melalui instrumentasi, centralized logging, tracing, dashboard, alerting, dan perbaikan arsitektur.

Kesimpulan

Monitoring tetap menjadi bagian penting dalam pengelolaan software.

Namun, monitoring saja sering hanya mampu memberi tahu bahwa kondisi tertentu melewati batas yang telah ditentukan.

Pada sistem bisnis yang semakin terdistribusi dan terintegrasi, perusahaan juga perlu memahami hubungan antara aplikasi, database, layanan cloud, pengguna, transaksi, dan proses operasional.

Observability membantu perusahaan menjawab:

• Apa yang terjadi?
• Mengapa hal tersebut terjadi?
• Siapa yang terdampak?
• Seberapa besar dampaknya?
• Perubahan apa yang memicunya?
• Bagaimana masalah dapat dipulihkan?
• Apa yang harus diperbaiki setelahnya?

Metrics menunjukkan pola. Logs memberikan detail kejadian. Traces mengikuti perjalanan transaksi. Business events menghubungkan kondisi teknis dengan hasil operasional.

Namun, observability bukan sekadar mengumpulkan ketiganya.

Observability adalah kemampuan menggunakan data tersebut untuk mengambil keputusan ketika sistem menghadapi kondisi yang tidak diperkirakan.

Perusahaan yang hanya memiliki monitoring mungkin mengetahui bahwa sistem sedang gagal.

Perusahaan yang memiliki observability memiliki peluang lebih besar untuk mengetahui mengapa sistem gagal dan bagaimana mengurangi dampaknya sebelum gangguan berkembang menjadi kerugian bisnis yang lebih besar.

Tingkatkan Observability Sistem Bersama Crocodic

Crocodic membantu perusahaan membangun dan meningkatkan sistem enterprise yang tidak hanya berfungsi, tetapi juga lebih mudah dipantau, dipahami, dan dipulihkan ketika terjadi gangguan.

Melalui layanan Custom Enterprise Software, kebutuhan observability dapat dirancang sejak awal melalui application logging, business event, monitoring, audit trail, integrasi, serta arsitektur yang mendukung penelusuran proses end-to-end.

Untuk sistem yang sudah berjalan, Crocodic membantu melakukan assessment dan peningkatan melalui layanan Enterprise System Upgrade.

Peningkatan dapat mencakup:

• Centralized application logging.
• Monitoring aplikasi dan database.
• Distributed tracing.
• Business metrics.
• Alerting dan dashboard.
• Performance assessment.
• Dependency mapping.
• Integrasi API.
• Perbaikan technical debt.
• Backup, recovery, dan incident readiness.

Pendekatan dilakukan secara bertahap agar perusahaan dapat meningkatkan visibilitas sistem tanpa harus langsung membangun ulang seluruh aplikasi dari nol.

Jika tim Anda sering kesulitan menemukan penyebab gangguan, mengetahui masalah dari pelanggan, atau tidak dapat menghubungkan error teknis dengan dampak bisnis, sistem tersebut mungkin tidak kekurangan monitoring—tetapi kekurangan observability.

Diskusikan kebutuhan observability dan peningkatan sistem enterprise Anda bersama Crocodic.