Konsep Observability dan proses perkembangan alat

• Konsep Observability:

  • Ukuran yang menunjukkan seberapa baik keadaan internal sistem dapat diinferensikan dari hasil keluaran eksternal sistem (pengetahuan)
  • Sistem dinamis yang dirancang untuk memperkirakan keadaan sistem dari pengukuran nilai keluaran
  • Observability menjadi diperlukan seiring populernya lingkungan cloud, aplikasi yang dikontainerisasi dengan Docker, dan arsitektur microservices

• Perbedaan Observability dan monitoring:

  • Monitoring: sesuatu yang dilakukan pengguna. Menunjukkan apa yang salah
  • Observability: konsep yang lebih luas yang mencakup monitoring. Memberikan informasi konteks internal yang kaya dan membantu menyelesaikan masalah sistem yang mendalam. Menunjukkan hingga ‘mengapa’ sesuatu salah

• Situasi ketika organisasi membutuhkan Observability:

  • Saat muncul isu di production dan tim bertanya, ‘data apa yang bisa digunakan untuk mengidentifikasi penyebab masalah, di mana data itu berada, dan bagaimana data tersebut harus dilihat?’
  • Saat layanan yang baik-baik saja sampai 1 menit lalu tiba-tiba bermasalah, dan tim menghadapi pertanyaan ‘di mana harus mencari akar penyebabnya?’
  • Saat organisasi memikirkan ‘bagaimana agar tim pengembang bisa mengetahui gejala anomali layanan lebih dulu daripada pelanggan atau tim support/operasional?’
  • Saat ingin tahu cara efektif melacak error layanan dan error performa pada microservices, atau apakah hal itu bisa diperiksa melalui log atau Application Performance Monitoring (APM)

• Proses perkembangan alat Observability:

  • Sejak 2010-an, berbagai alat Observability bermunculan di industri IT
  • Pada 2010, Google memperkenalkan infrastruktur pelacakan sistem terdistribusi skala besar ‘Dapper’
  • Setelah itu, Uber dan Twitter masing-masing membuat sistem distributed tracing ‘Jaeger’ (Uber) dan ‘Zipkin’ (Twitter)
  • Muncul ‘Open Tracing’, sekumpulan API standar untuk terus memodelkan dan menjelaskan perilaku sistem terdistribusi
  • ‘Open Census’ dirilis: sekumpulan library untuk berbagai bahasa yang mengumpulkan metrik aplikasi dan distributed tracing, lalu mengirimkan data ke backend secara real-time
  • Setelah itu muncul ‘Prometheus’
  • Pada 2019, dirilis kumpulan alat, API, dan SDK bernama ‘Open Telemetry (OTel)’ yang mengintegrasikan Open Tracing dan Open Census

• Open Telemetry:

  • Framework Observability open source yang netral vendor
  • Ada data telemetri berupa log, metrik, dan trace yang membantu menganalisis performa dan perilaku software, dan Open Telemetry digunakan untuk menginstrumentasi, menghasilkan, mengumpulkan, serta mengekspornya
    • Log: metadata timestamp. Digunakan untuk menilai akar penyebab isu
    • Metrik: data statistik atau agregat dengan tag key/value yang diukur dari layanan. Nilai pengukuran layanan yang ditangkap saat runtime
    • Trace: catatan event yang terjadi pada pengguna dan aplikasi. Mencatat jalur propagasi tiap request
  • Cara penggunaan: alat Observability mengirim alert -> periksa isi alert, lalu buka dashboard untuk melihat titik masalah -> kueri bagian tertentu secara detail pada titik masalah itu -> cari dan periksa log -> temukan data trace yang terkait dengan log tersebut lalu bentuk polanya -> dari sini masalah diidentifikasi dan diperbaiki, sehingga Observability terwujud
  • Sebagian besar alat Observability modern kini mendukung Open Telemetry secara default

• Alasan Open Telemetry muncul:

  • Di masa lalu, tiap backend Observability memiliki library instrumentasi dan agent sendiri untuk mengirim data dari alat, dan ada berbagai cara untuk menginstrumentasi kode
  • Tidak ada format data standar untuk mengirim data ke backend Observability
  • Kemudian, untuk membuat satu standar, Open Tracing dan Open Census digabungkan sehingga lahirlah Open Telemetry

• SigNoz: alat APM open source

  • Membantu memonitor aplikasi dan menyelesaikan masalah
  • Menggunakan teknologi distributed tracing untuk memahami software stack pengguna
    • memonitor metrik aplikasi seperti latency, requests per second, dan error rates
    • juga mengamati metrik infrastruktur seperti penggunaan CPU atau penggunaan memori
    • melacak request pengguna di seluruh layanan
    • menyiapkan alert pada metrik
    • dapat menuju trace yang tepat yang menyebabkan masalah untuk menemukan akar penyebabnya
    • juga dapat melihat flame graph terperinci dari pelacakan request individual

[ninebow]

Terima kasih untuk artikelnya yang bagus!

[ironlung]

Terima kasih atas komentarnya! :)

[kaistj]

Terima kasih atas tulisannya yang bagus~

[ironlung]

Terima kasih atas komentarnya! :)

[jujumilk3]

Bagaimana cara memantau apakah monitoring bekerja dengan baik?

Aku pernah memikirkan hal yang mirip dengan dilema di komik Watchmen, ternyata memang ada istilah observability ya, terima kasih.

[ironlung]

Terima kasih! Belakangan ini saya juga melihat ada tempat-tempat yang mengembangkan alat untuk menyederhanakan observability dengan AI. Ini bidang yang ingin saya pelajari lebih jauh! :)

[inthelife]

Terima kasih untuk tulisannya yang bagus :)

[ironlung]

Terima kasih! :D