Visi Menuju Observabilitas dalam Praktek

Salah satu tren utama dalam infrastruktur perangkat lunak pada tahun 2019 adalah Observability .

Ini telah mendapatkan banyak perhatian baru-baru ini.

Apa yang bisa diamati?

Ada banyak diskusi dan lelucon tentang istilah ini. Sebagai contoh:

• Mengapa menyebutnya pemantauan? Itu tidak cukup seksi lagi.
• Dapat diamati, karena mengubah nama Ops sebagai DevOps tidak cukup buruk, sekarang mereka juga memantau dengan buruk.
• Chuck Norris baru dari DevOps.
• Saya seorang insinyur yang dapat membantu menyediakan pemantauan kepada insinyur lain di organisasi.
• > Hebat, ini $ 80k.
• Saya seorang arsitek yang dapat membantu menyediakan kemampuan pengamatan untuk aplikasi berbasis wadah yang asli cloud.
• > Luar Biasa! Ini $ 300k!

Cindy sridharan

Apa perbedaan antara pemantauan dan Observabilitas jika ada?

Melihat Kembali ...

Bertahun-tahun yang lalu, kami kebanyakan menjalankan perangkat lunak kami di server fisik. Aplikasi kami adalah monolit yang dibangun di atas LAMP atau tumpukan lainnya. Memeriksa waktu kerja sesederhana mengirim ping biasa dan memeriksa penggunaan CPU / disk untuk aplikasi Anda.

Pergeseran paradigma

Pergeseran paradigma utama datang dari bidang infrastruktur dan arsitektur. Arsitektur cloud, layanan mikro, Kubernetes, dan infrastruktur tidak berubah mengubah cara perusahaan membangun dan mengoperasikan sistem.



Sebagai hasil dari pengadopsian ide-ide baru ini, sistem yang kami bangun telah menjadi semakin tersebar dan singkat.

Kerangka kerja virtualisasi, containerisasi, dan orkestrasi bertanggung jawab untuk menyediakan sumber daya komputasi dan menangani kegagalan menciptakan lapisan abstraksi untuk perangkat keras dan jaringan.

Bergerak menuju abstraksi dari perangkat keras dan jaringan yang mendasarinya berarti kita harus fokus untuk memastikan bahwa aplikasi kita berfungsi sebagaimana dimaksud dalam konteks proses bisnis kita.

Apa itu pemantauan?

Pemantauan untuk operasi pada dasarnya adalah pengujian untuk pengembangan perangkat lunak. Bahkan, tes memeriksa perilaku komponen sistem terhadap serangkaian input di lingkungan berpasir, biasanya dengan sejumlah besar komponen yang diejek.



Masalah utama adalah bahwa jumlah masalah yang mungkin terjadi dalam produksi tidak dapat ditutup dengan pengujian dengan cara apa pun. Sebagian besar masalah dalam sistem yang matang dan stabil tidak diketahui-tidak diketahui yang terkait tidak hanya dengan pengembangan perangkat lunak itu sendiri, tetapi juga dengan dunia nyata.

Kotak Hitam vs. Pemantauan kotak putih

Ada dua pendekatan untuk pemantauan.

Dalam hal pemantauan kotak hitam, kami memperlakukan sistem atau bagian-bagiannya sebagai kotak hitam dan mengujinya di luar. Ini bisa berarti memeriksa panggilan API, memuat waktu, atau ketersediaan berbagai bagian sistem. Dalam hal ini, jumlah informasi tentang dan kontrol atas sistem terbatas.



Pemantauan kotak putih mengacu pada situasi, di mana kami memperoleh informasi dari internal sistem. Ini bukan ide revolusioner, tetapi baru-baru ini mendapat banyak perhatian.



Jadi, Observability hanyalah nama lain untuk pemantauan kotak putih? Tidak cukup.

Mengapa Kita Membutuhkan Jenis Pemantauan Baru

Seringkali, perbedaan dibuat antara pemantauan dan konsep Observability, dengan yang terakhir didefinisikan sebagai sesuatu yang mengumpulkan data tentang keadaan infrastruktur / aplikasi dan jejak kinerja dalam satu atau lain cara (https://thenewstack.io/monitoring-and -observability-whats the difference-dan-why-do-it-matter /).

Atau, menurut honeycomb.io :

• "Anda memeriksa status dan perilaku sistem Anda terhadap data dasar yang diketahui, untuk menentukan apakah ada yang tidak sesuai dengan yang diharapkan."
• "Anda dapat menulis cek Nagios untuk memverifikasi bahwa banyak hal berada dalam ambang batas yang diketahui."
• "Anda dapat membuat dasbor dengan Graphite atau Ganglia untuk mengelompokkan kumpulan grafik yang berguna."
• "Semua ini adalah alat yang hebat untuk memahami yang tidak diketahui tentang sistem Anda."

Ekosistem besar produk seperti New Relic, HP, dan AppDynamics telah berevolusi. Semua alat ini sangat cocok untuk pemantauan tingkat rendah dan menengah atau untuk mengatasi masalah kinerja.

Namun, mereka tidak dapat menangani pertanyaan pada data dengan kardinalitas tinggi dan berkinerja buruk dalam kasus masalah yang terkait dengan masalah integrasi pihak ketiga atau perilaku sistem kompleks besar dengan banyak layanan yang bekerja di lingkungan virtual modern.

Mengapa Dasbor Tidak Berguna

Sebenarnya tidak. Tetapi hanya jika Anda tahu kapan dan di mana harus menonton. Kalau tidak, lebih baik menonton YouTube.

Dasbor tidak berskala.

Bayangkan situasi di mana Anda memiliki banyak metrik yang terkait dengan infrastruktur Anda (misalnya, kuota cpu_usage / disk) dan aplikasi (misalnya, JVM alokasi_kecepatan / Menjalankan GC), dll. Jumlah total metrik tersebut dapat dengan mudah bertambah hingga ribuan atau puluhan ribu. Semua dasbor Anda berwarna hijau, tetapi kemudian terjadi masalah di layanan integrasi pihak ketiga. Dasbor Anda masih hijau, tetapi pengguna akhir sudah terpengaruh.

Anda memutuskan untuk menambahkan pemeriksaan layanan integrasi pihak ketiga ke pemantauan Anda dan mendapatkan banyak metrik dan dasbor tambahan di perangkat TV Anda. Hingga kasus selanjutnya muncul.

Ketika ditanya mengapa pelanggan tidak dapat membuka situs, responsnya sering terlihat seperti ini:



Spagettifikasi dashboard

Sementara mengadopsi telemetri dari berbagai bagian sistem adalah praktik yang umum, biasanya berakhir dengan sekelompok spageti yang tergambar di dashboard.

Ini adalah metrik operasional GitLab yang terbuka untuk umum.

Dan ini hanya sebagian kecil dari seluruh pasukan dasbor



Sepertinya permadani di mana mudah kehilangan utasnya.

Agregasi log

Alat agregasi log seperti ELK Stack atau Splunk digunakan oleh sebagian besar perusahaan IT modern. Instrumen-instrumen ini sangat membantu untuk analisis akar penyebab atau post mortem. Mereka juga dapat digunakan untuk memantau beberapa kondisi yang dapat diturunkan dari aliran log Anda.

Namun, ia datang dengan biaya. Sistem modern menghasilkan sejumlah besar log dan peningkatan lalu lintas Anda dapat menghabiskan sumber daya ELK Anda atau meningkatkan tingkat penagihan Splunk ke bulan.

Ada beberapa teknik pengambilan sampel yang dapat mengurangi jumlah yang disebut log membosankan dengan beberapa urutan besarnya dan menyimpan semua yang tidak normal. Ini dapat memberikan tinjauan tingkat tinggi tentang perilaku sistem normal dan tampilan terperinci dari setiap peristiwa yang bermasalah.

Dari Log ke Model Acara

Biasanya, baris log mencerminkan peristiwa yang terjadi dalam sistem. Misalnya, membuat koneksi, mengautentikasi, menanyakan database, dan sebagainya. Melaksanakan semua fase berarti bahwa suatu pekerjaan telah selesai. Acara definisi sebagai karya logis dapat dilihat sebagai bagian dari Tujuan Tingkat Layanan yang terkait dengan layanan tertentu. Yang dimaksud dengan "layanan" yang saya maksud bukan hanya layanan perangkat lunak, tetapi juga perangkat fisik tertentu, seperti sensor atau mesin lain dari dunia IoT.

Ini juga sangat melengkapi prinsip-prinsip desain berbasis domain. Isolasi dan pembagian tanggung jawab antara layanan atau domain membuat acara spesifik untuk setiap bagian pekerjaan di setiap bagian sistem.

Misalnya, peristiwa layanan masuk dapat dipisahkan oleh berhasil_logins, gagal_login dengan konteks dinamisnya sendiri.

Metrik dan peristiwa harus membangun cerita di sekitar proses dalam sistem.

Acara dapat disampel sedemikian rupa sehingga dalam kasus perilaku sistem normal hanya sebagian kecil dari mereka yang disimpan dan semua peristiwa yang bermasalah disimpan seperti apa adanya. Acara dikumpulkan dan disimpan sebagai indikator kinerja utama berdasarkan tujuan layanan tertentu.

Ini dapat menyatukan metrik tujuan layanan dan metadata terkait yang memanfaatkan koneksi antara masalah-masalah setiap saat.

Ditulis dengan kardinalitas tinggi dalam pikiran data ini mengungkapkan yang tidak diketahui-tidak diketahui dalam sistem.

Apakah ini bentuk instrumentasi perangkat lunak? Ya Namun, ketika Anda membandingkan jumlah data yang berasal dari pencatatan tingkat debug dan instrumentasi lengkap, pemisahan log menjadi peristiwa memungkinkan untuk minum dari selang kebakaran di lingkungan produksi tanpa tenggelam dalam data dan biaya.

“Mendefinisikan suatu peristiwa sebagai bagian dari pekerjaan dapat dilihat sebagai terkait dengan tujuan layanan tertentu.”

Mengapa Kami Tidak Siap untuk Solusi AI Lengkap

AI adalah kata kunci yang bagus untuk menarik investasi pemula. Namun, iblis selalu detail.

1. Reproduksibilitas

Masalah dari sistem berbasis pembelajaran mesin sepenuhnya (yang disebut pendekatan AI penuh) adalah bahwa karena terus-menerus mempelajari perilaku baru, tidak ada reproduktifitas. Jika Anda ingin memahami mengapa, misalnya, suatu kondisi mengakibatkan peringatan, Anda tidak dapat memeriksanya, karena model telah berubah. Solusi apa pun yang bergantung pada pembelajaran perilaku yang konstan menghadapi masalah ini.

Sangat penting untuk mengoptimalkan sistem itu sendiri ketika Anda beroperasi dengan data atau metrik yang sangat granular, tetapi sangat sulit untuk melakukannya tanpa reproduktifitas.

2. Konsumsi sumber daya

Untuk segala jenis pembelajaran mesin konstan, Anda memerlukan sejumlah besar sumber daya komputasi. Biasanya, ini mengambil bentuk kumpulan pemrosesan data. Dalam hal beberapa produk, persyaratan minimal untuk memproses 200.000 metrik adalah v32CPU dan 64 Gb RAM. Jika Anda ingin menggandakan jumlah metrik, Anda membutuhkan mesin lain yang memenuhi persyaratan yang sama.

3. Anda belum dapat mempelajari otomatisasi dalam skala penuh

Menurut tesis master yang ditulis oleh Samreen Hassan Massak (belum sepenuhnya selesai), proses pelatihan untuk ribuan metrik membutuhkan waktu CPU selama berhari-hari atau senilai waktu GPU dalam hitungan jam. Anda tidak dapat mengatur skala tanpa membesar-besarkan anggaran Anda.

4. Kecepatan

Solusi seperti Amazon Forecast yang berfungsi sebagai layanan pemrosesan batch yang menggunakan data dan menunggu perhitungannya berakhir tidak sesuai untuk itu.

5. Kejelasan

Berdasarkan pengalaman Google:

"Aturan yang menangkap insiden nyata paling sering harus sesederhana, dapat diprediksi, dan dapat diandalkan sebanyak mungkin."

landing.google.com/sre/sre-book/chapters/monitoring-distributed-systems

Ketika model atau aturan terus berubah, Anda kehilangan pemahaman tentang sistem dan berfungsi sebagai kotak hitam.

Anomali = Lansiran?

Katakanlah Anda memiliki ribuan metrik dan jika Anda ingin memiliki Pengamatan yang baik, Anda perlu mengumpulkan data kardinal tinggi. Setiap detak jantung sistem akan menghasilkan fluktuasi statistik di segerombolan metrik Anda.

https://berlinbuzzwords.de/15/session/signatures-patterns-and-trends-timeseries-data-mining-etsy

Pelajaran utama yang dapat diambil dari proyek Kale Etsy:



Memperingatkan tentang anomali metrik pada akhirnya akan mengarah ke sejumlah besar lansiran dan pekerjaan manual yang dimainkan dengan ambang batas dan filter kerajinan tangan.

Mengapa Kami Membutuhkan Pendekatan Streaming

Mendapatkan Pengamatan dan membawa yang tidak diketahui-tidak diketahui menjadi sorotan membutuhkan data yang sangat granular yang dapat dikategorikan oleh pusat data, versi pembuatan, layanan, platform, dan tipe sensor. Agregasi mereka dalam kombinasi apa pun bersifat kombinatorik.

Bahkan jika Anda dengan hati-hati merancang metrik dan acara, Anda akhirnya akan mendapatkan jumlah yang cukup besar. Ketika beroperasi pada skala ini dalam waktu nyata, pekerjaan kueri atau batch yang teratur akan memiliki latensi dan overhead yang signifikan.

Hal-hal yang harus dipertimbangkan

Setiap operasi yang dilakukan pada aliran data yang tak terbatas merupakan upaya rekayasa. Anda perlu berurusan dengan implikasi yang berkaitan dengan sistem terdistribusi.



Saat memantau peristiwa, sasaran tingkat layanan, atau KPI pada tingkat tinggi, Anda harus reaktif dan tidak terus-menerus menanyakan data Anda, tetapi sebaliknya beroperasi pada aliran yang dapat menskalakan secara horizontal dan mencapai throughput dan kecepatan yang besar tanpa mengkonsumsi jumlah yang berlebihan dari sumber daya.

Beberapa kerangka streaming, seperti Apache Storm, Apache Flink, dan Apache Spark, berorientasi pada pemrosesan tuple dan tidak menuju pemrosesan time-series di luar kotak.

Ada juga masalah dengan semantik sistem terdistribusi.

Katakanlah Anda memiliki banyak penyebaran di pusat data yang berbeda. Anda dapat memiliki masalah jaringan dan agen yang menyimpan metrik KPI Anda tidak dapat meneruskannya. Setelah beberapa saat - katakanlah 3 menit - agen mengirim data ini ke sistem. Dan informasi baru ini harus memicu tindakan berdasarkan kondisi ini. Haruskah kita menyimpan jendela data ini dalam memori dan memeriksa kondisi tidak hanya mundur tetapi juga dalam waktu? Seberapa besar seharusnya jendela desinkronisasi ini? Beroperasi pada ribuan metrik secara real time menjadikan pertanyaan ini sangat penting. Anda tidak dapat menyimpan semua yang ada di database jika sistem pemrosesan aliran tanpa kehilangan kecepatan.

Analisis aliran waktu-nyata dari data deret waktu dalam sistem terdistribusi rumit, karena peristiwa mengenai perilaku sistem dapat tidak beraturan dan kondisi yang dapat muncul berdasarkan data ini tergantung pada urutan kejadian. Ini berarti bahwa semantik setidaknya satu kali dapat dicapai dengan mudah, tetapi ketika semantik hanya sekali bisa jauh lebih sulit.

Fitur yang Diinginkan dari Strategi Pemantauan Menurut Google SRE Workbook

• "Desain modern biasanya melibatkan pemisahan pengumpulan dan evaluasi aturan (dengan solusi seperti server Prometheus), penyimpanan seri jangka panjang (InfluxDB), agregasi waspada (Alertmanager), dan dashboarding (Grafana)."
• “Sistem berbasis log Google memproses sejumlah besar data yang sangat terperinci. Ada beberapa penundaan yang melekat antara saat suatu peristiwa terjadi dan ketika itu terlihat dalam log. Untuk analisis yang tidak peka waktu, log ini dapat diproses dengan sistem batch, diinterogasi dengan kueri ad hoc, dan divisualisasikan dengan dasbor. Contoh alur kerja ini akan menggunakan Cloud Dataflow untuk memproses log, BigQuery untuk permintaan ad hoc, dan Data Studio untuk dasbor. "
• “Sebaliknya, sistem pemantauan berbasis metrik kami, yang mengumpulkan sejumlah besar metrik dari setiap layanan di Google, memberikan informasi yang jauh lebih kecil, tetapi dalam waktu yang hampir bersamaan. Karakteristik ini cukup khas dari sistem pemantauan berbasis log dan metrik lainnya, meskipun ada pengecualian, seperti sistem log waktu-nyata atau metrik kardinalitas tinggi. "
• “Di dunia yang ideal, kode pemantauan dan peringatan harus tunduk pada standar pengujian yang sama dengan pengembangan kode. Sementara pengembang Prometheus sedang mendiskusikan pengembangan unit test untuk pemantauan, saat ini tidak ada sistem yang diadopsi secara luas yang memungkinkan Anda untuk melakukan ini. "
• “Di Google, kami menguji pemantauan dan peringatan kami menggunakan bahasa khusus domain yang memungkinkan kami membuat rangkaian waktu sintetis. Kami kemudian menulis pernyataan berdasarkan nilai-nilai dalam deret waktu yang diturunkan, atau status pembakaran dan label keberadaan peringatan tertentu. "

Terima kasih banyak untuk Jurusan Amal dan Cindy Sridharan
Terima kasih kepada Sigrid Maasen atas bantuannya