Ikon instana, diagram, dan ilustrasi yang dihubungkan oleh garis yang menunjukkan cara kerja sistem

Meningkatkan Pengamatan Instana: Menyelesaikan kesalahan menggunakan investigasi insiden multi-agen

Investigasi insiden multi-agen Instana mengotomatiskan analisis akar masalah dalam sistem TI perusahaan modern, mengurangi waktu penyelesaian dari jam menjadi menit.

AI agen untuk investigasi insiden melakukan analisis akar masalah otonom dan penyelidikan lebih dalam untuk menemukan kesalahan yang menyebabkan insiden. Instana secara otomatis menganalisis topologi sistem, pelacakan terdistribusi, metrik kinerja aplikasi, log dan peristiwa infrastruktur secara paralel.

Ini melakukan penyelidikan multi-entitas — analisis layanan dan infrastruktur terkait — memanfaatkan agen AI kolaboratif untuk investigasi insiden AI agen dan RCA yang dipandu grafik, memungkinkan identifikasi akar masalah yang lebih cepat dan lebih akurat dengan upaya manual yang minimal.

Tantangan: Menemukan akar masalah dalam Sistem terdistribusi yang kompleks

Mari kita pertimbangkan contoh bagaimana tantangan ini muncul:

  • Pada pukul 2:30 pagi, Alex, Senior SRE di FinTech Global, menerima peringatan mendesak: “Latensi Kritis Terdeteksi - API Pemrosesan Pembayaran.” Ketika Alex mengakses sistem pemantauan, situasinya jelas dan memprihatinkan.
  • Waktu respons pada API Pemrosesan Pembayaran telah melonjak dari 200 milidetik menjadi lebih dari 3 detik. Tingkat kesalahan telah naik melewati 5% dan lanjutkan meningkat. Beberapa layanan hilir menunjukkan kinerja yang menurun, dan dampak terhadap pelanggan dilaporkan dari berbagai wilayah.
  • Tim keuangan telah menghitung bahwa setiap menit gangguan pemrosesan pembayaran membebani perusahaan sekitar USD20.000 dalam transaksi yang hilang dan niat baik pelanggan.

Dalam alur kerja respons insiden tradisional, Alex akan menghadapi proses investigasi yang memakan waktu. Pekerjaan ini akan membutuhkan Jelajahi secara manual lusinan layanan dan beban kerja Kubernetes, melompat di antara dasbor di beberapa alat pengamatan, mengejar jejak dan log di beberapa lompatan grafik panggilan, dan mencoba merekonstruksi bagaimana kesalahan menyebar melalui sistem. Bahkan dengan platform pengamatan yang kuat yang menyediakan data telemetri yang komprehensif, beban kognitif untuk menghubungkan semua informasi ini dan mengidentifikasi akar masalah yang paling mungkin bisa memakan waktu berjam-jam.

Tantangan ini menjadi lebih akut karena organisasi telah berusaha mempercepat respons insiden dengan menambahkan agen model bahasa besar (LLM) tujuan umum di atas tumpukan pengamatan mereka.

Mengapa “tambahkan saja LLM” tidak berfungsi untuk insiden

Mengapa agen LLM generik belum menyelesaikan ini? Pola agen populer seperti ReAct atau “plan-and-act” terlihat menarik: biarkan model memutuskan apa yang harus ditanyakan, memanggil alat, dan membangun papan penalaran. Dalam praktiknya, skenario SRE dan ops mengekspos tiga masalah sulit:

Kekacauan konteks

Insiden menghasilkan sejumlah besar data termasuk jejak, log, metrik, peristiwa Kubernetes, dan riwayat perubahan. Membuang semua itu ke dalam satu jendela konteks tidak sesuai dengan skala. Konteks yang terlalu sedikit berarti agen melewatkan petunjuk yang menentukan, sementara terlalu banyak konteks berarti sinyal terkubur, latensi dan biaya melonjak dan penalaran menurun.

Penggunaan alat rapuh

Membiarkan alat panggilan LLM secara bebas dapat mengakibatkan pemilihan perintah yang salah, argumen yang tidak konsisten dengan parameter yang tidak sejajar (seperti jendela waktu, namespace, atau filter), dan panggilan berulang atau berlebihan yang membengkak konteks dan meningkatkan biaya. Di seluruh penyelidikan multi-langkah, masalah ini bertambah, memecah konteks dan meningkatkan kemungkinan akar masalah yang salah.

Keamanan dan kepercayaan

Dalam produksi, Anda tidak dapat memberikan LLM permukaan I/O terbuka. SRE membutuhkan penalaran yang dapat diaudit dan dapat direproduksi: Apa yang dilihat sistem? Mengapa memutuskan node ini adalah akar masalah? Apakah kita akan mendapatkan jawaban yang sama jika kita menjalankan kembali penyelidikan? Dengan kata lain: insiden bukanlah masalah obrolan. Ini adalah masalah penalaran yang terstruktur dalam bentuk grafik.

Dengan Instana, insinyur dapat melakukan sesuatu yang berbeda

Bahkan dengan platform pengamatan yang kuat, menemukan akar penyebab yang paling mungkin bisa memakan waktu berjam-jam. Dan upaya untuk “hanya menambahkan agen LLM” di atas tumpukan observabilitas sering gagal dengan cara yang halus: kelebihan konteks, panggilan alat rapuh, atau alasan buram yang tidak ingin dipercaya oleh SRE di tengah pemadaman.

Dengan IBM Instana, Alex dan Insinyur Keandalan lainnya dapat melakukan sesuatu yang berbeda: Dia membuka insiden di Instana, menggulir ke Akar Masalah yang mungkin dan mengklik Jalankan investigasi.

Dalam beberapa menit, penyelidikan yang didukung AI mengidentifikasi kondisi kesalahan yang tepat, akar masalah yang memicu insiden dan memetakan bagaimana kegagalan menyebar melalui sistem. Berbekal diagnosis ini, organisasi sekarang dapat segera melanjutkan untuk perbaikan masalah, secara dramatis mengurangi Mean Time to Resolution (MTTR).

Eksplorasi yang dipandu grafik mengarah ke penyelidikan yang lebih dalam

Sistem modern sudah tahu bagaimana semuanya terhubung: Layanan memanggil layanan lain, layanan berjalan pada kontainer, node dan klaster, dan sistem termasuk peta konfigurasi, antrian, database, dan dependensi eksternal. Peristiwa perubahan seperti penerapan, push konfigurasi, autoscaling, dan lainnya semuanya dilacak dan dihubungkan.

Anda dapat menganggap ini sebagai grafik operasional: node adalah entitas (layanan, pemalut, host, konfigurasi), tepi adalah hubungan (panggilan, runs-on, depends-on). Insiden bukanlah lonjakan terisolasi; mereka adalah kesalahan yang menyebar melalui grafik ini dari waktu ke waktu.

Pergeseran kuncinya adalah membiarkan sistem (topologi, kesalahan, algoritma kausal) memandu agen untuk bernalar dalam bagian-bagian kecil yang terdefinisi dengan baik. Itulah ide di balik investigasi Insiden cerdas Instana.

Dari tampilan insiden, orang seperti Alex dapat melihat kemungkinan entitas akar penyebab yang telah diidentifikasi oleh Instana menggunakan AI Causal (lihat blog terperinci) di samping konteks aplikasi dan infrastruktur di mana masalah terjadi, Topologi dan radius ledakan menunjukkan beberapa layanan dan dependensi yang terkena dampak, detail kesalahan dan grafik latensi.

Dasbor menunjukkan akar masalah.

Alih-alih menelusuri dasbor secara manual, dia cukup mengklik "jalankan investigasi"dan Hasil mulai berdatangan.

Apa yang sebenarnya terjadi ketika Anda mengklik “Jalankan investigasi”

Investigasi Insiden Cerdas adalah alur kerja baru yang dibantu LLM multi-fase, dipandu grafik.

Investigasi insiden terjadi dalam empat langkah, menganalisis data insiden dalam konteks yang dikuratori oleh kausal ai (apa yang sudah ditemukan Instana?) , perubahan analisis peristiwa (apa yang berubah di sekitar insiden?) , investigasi multi-entitas (bagaimana kesalahan menyebar?) dan laporan yang dihasilkan AI (apa penyebab, bukti, dan remediasi yang paling mungkin?).

Dasbor Instana yang menampilkan laporan investigasi.

Langkah 1: Gambaran awal: mengklarifikasi insiden

Instana dimulai dari entitas yang diperingatkan (dalam kasus Alex, API Pemrosesan Pembayaran dan beberapa layanan hilir), kandidat akar penyebab yang mungkin saat ini dan topologi lokal termasuk panggilan hulu/hilir, induk/anak infrastruktur, dan sumber daya Kubernetes terkait.

Alih-alih membanjiri model dengan semua telemetri, sistem bertanya: “Mengingat insiden ini, entitas dan hubungan mana yang paling menjanjikan untuk diperiksa terlebih dahulu?” Pengontrol menyemai antrian investigasi dengan entitas tersebut dan mulai mengambil paket konteks terbatas untuk masing-masing: irisan k-hop kecil dari grafik di sekitar entitas, ditambah log, jejak, dan metrik yang relevan.

Langkah 2: Ubah analisis peristiwa: “Apa yang berubah baru-baru ini?”

Kebanyakan SRE secara naluriah bertanya: “Apa yang berubah tepat sebelum ini meledak?” Investigasi mengotomatiskan langkah itu dengan melihat jendela waktu (misalnya, 60 menit sebelum hingga 20 menit setelah insiden dimulai), mengumpulkan penerapan, perubahan konfigurasi, peristiwa penskalaan, dan sinyal perubahan lainnya di seluruh layanan dan infrastruktur yang relevan, dan muncul yang perubahannya paling mencurigakan dengan permulaan insiden.

Alih-alih Alex menelusuri riwayat penerapan dan mencoba menyelaraskan garis waktu dengan mata, mesin investigasi agen melakukan korelasi itu untuknya.

Langkah 3: Investigasi multi-entitas: ikuti kesalahan, bukan kebisingan

Di sinilah alur kerja Exploration Over Graph (EOG) memungkinkan Instana untuk menentukan kesalahan. Untuk setiap entitas dalam antrian investigasi, sistem membuat panggilan alat, mengumpulkan paket bukti dan bertanya kepada agen: apakah entitas ini adalah akar masalah, gejala, atau buktinya tidak meyakinkan? Apakah bukti menunjukkan bahwa kesalahan menyebar di sepanjang tepi tertentu (misalnya, dari layanan A ke layanan B, atau dari file yang salah dikonfigurasi ke layanan)? Sistem kemudian memperbarui subgraf kausal yang menangkap tepi propagasi yang dikonfirmasi (“Kegagalan A menyebabkan B gagal”) dan entitas yang diklasifikasikan sebagai akar masalah versus gejala versus dibebaskan.

Instana mengelola antrian, memastikan LLM hanya melihat irisan sistem yang terfokus dan mempertahankan penjelasan yang dapat diaudit dan dapat direproduksi. Selama beberapa iterasi, investigasi AI mengidentifikasi akar masalah — kumpulan koneksi yang salah dikonfigurasi dalam layanan Payment Gateway — dan melacak rantai propagasi kesalahan lengkap melalui API Pemrosesan Pembayaran ke semua layanan hilir, memberikan langkah-langkah remediasi yang dapat ditindaklanjuti.

Dampak terukur pada respons insiden

Dampak dari investigasi multi-agensi Instana tidak hanya terbatas pada insiden individu. Dengan mengotomatiskan korelasi topologi, jejak, log, metrik, dan peristiwa perubahan, Instana mengurangi waktu yang diperlukan untuk mengidentifikasi akar masalah dari jam ke menit, secara langsung mengurangi waktu rata-rata hingga resolusi (MTTR). Bagi organisasi yang menjalankan layanan dengan transaksi tinggi di mana setiap menit gangguan berdampak pada pendapatan dan pengalaman pelanggan, peningkatan ini memberikan nilai bisnis langsung.

Tim SRE menerima penjelasan insiden yang koheren dan didukung bukti daripada telemetri mentah yang tersebar di beberapa dasbor. Data pengamatan penuh tetap dapat diakses untuk penyelidikan lebih dalam bila diperlukan, tetapi sistem memberikan titik awal yang jelas yang menghilangkan jam kerja korelasi manual. Karena penyelidikan dapat diaudit dan dapat direproduksi, tim SRE dapat memvalidasi kesimpulan AI dan membangun kepercayaan pada sistem dari waktu ke waktu. Alasannya transparan: entitas mana yang diperiksa, bukti apa yang dikumpulkan dan mengapa simpul tertentu diidentifikasi sebagai akar penyebabnya.

Ketika AI menangani pekerjaan korelasi yang memakan waktu selama insiden, tim SRE dapat mengarahkan upaya ke arah praktik keandalan proaktif seperti tujuan tingkat layanan (SLOs), manajemen anggaran kesalahan, dan rekayasa kekacauan. Pergeseran dari pemadaman kebakaran yang reaktif ke rekayasa keandalan yang proaktif ini meningkatkan stabilitas sistem secara keseluruhan dan mengurangi frekuensi insiden penting.

Dalam evaluasi internal di ITBench, rangkaian pembandingan untuk Otomatisasi dan tugas-tugas insiden, pendekatan investigasi yang dipandu grafik Instana menghasilkan grafik akar masalah yang lebih akurat dengan jalan memutar yang jauh lebih sedikit daripada agen LLM gaya React tradisional, sambil menjaga ukuran konteks kecil dan perilaku dapat diaudit. Validasi ini menunjukkan bahwa pendekatan terstruktur dan dipandu grafik memberikan hasil yang unggul dibandingkan dengan pola agen LLM generik.

Memulai dengan Instana agentic AI untuk investigasi insiden

Sebagai bagian dari kemampuan Investigasi Insiden Cerdas Instana yang didukung AI, serta seluruh alur kerja penyebab utama yang mungkin terjadi, Anda dapat: Buka Acara → Insiden, filter Peringatan Cerdas Aplikasi dengan penyebab utama yang mungkin terjadi, Klik Jalankan investigasi untuk memulai investigasi multi-entitas yang didukung AI.

Dari sana, Anda akan melihat: Fase investigasi streaming secara real time, rantai propagasi kesalahan di seluruh layanan dan infrastruktur, dan saran remediasi yang didukung bukti yang dapat Anda tangani segera.

Jelajahi halaman produk 

Baca lebih banyak berita tentang investigasi insiden 

Pelajari lebih lanjut tentang topik ini

Ameet Annasaheb Rahane

Data Scientist

Neel Bhavsar

Software Engineer

Ragu Kattinakere

Senior Development Manager, AIOps, Instana

Saurabh Jha

Staff Research Scientist/ Product Focal for Instana / AI & Observability

IBM

Dengan terima kasih kepada kontributor Dishant Kaushik, Marc Palaci-Olgun, Shivangi Pathak, Chun-Wah Chung, Adwan Syed, Nevil Kandathil Sintho, Melissa Denby, Paul Watkins dan Gopika Murali K.