Monitoring Logs

Halaman Monitoring memberi Anda visibilitas ke apa yang sedang dilakukan layanan backend agent pada tingkat teknis. Jika Dashboard menunjukkan apa yang terjadi dan Feedback menunjukkan bagaimana perasaan pengguna, log Monitoring menunjukkan mengapa — urutan peristiwa, pemanggilan layanan, dan error yang persis di balik setiap percakapan.

Gunakan Monitoring untuk mendiagnosis kegagalan integrasi, memastikan perubahan konfigurasi telah berlaku, dan membangun jejak audit untuk kepatuhan atau respons insiden.

Membuka Halaman Monitoring

Di sidebar, buka Analytics dan klik Logs.

Halaman Monitoring terbuka dengan tata letak yang bisa diprediksi:

1. Bar filter di bagian atas.
2. Tabel hasil di bagian tengah.
3. Tombol aksi tingkat-baris di sisi kanan setiap entri log.

Jika tabel terlihat kosong pada pemuatan pertama, jangan langsung berasumsi bahwa logging rusak. Periksa dulu apakah filter Anda saat ini (terutama Log Source, Level, dan rentang DateTime) terlalu sempit.

Level Log

Setiap entri log diberi label salah satu dari enam tingkat keparahan. Warna chip-nya memungkinkan Anda melakukan triase sekilas.

Filter Default yang Disarankan

Dalam monitoring sehari-hari, filter ke Warning ke atas. Ini menghilangkan noise dari operasi normal dan hanya menampilkan entri yang memerlukan perhatian.

Simpan Information untuk investigasi yang bertarget — misalnya, meninjau urutan permintaan/respons lengkap untuk integrasi tertentu setelah perubahan konfigurasi.

Gunakan Trace dan Debug hanya saat Anda perlu menelusuri jalur eksekusi yang sangat spesifik dan tidak bisa mengidentifikasi masalahnya dari log tingkat yang lebih tinggi.

Menerapkan Filter

Bar filter di atas tabel log memungkinkan Anda mempersempit hasil di tiga dimensi.

Gunakan urutan operasi ini setiap kali untuk menghindari false negative:

1. Atur Log Source terlebih dahulu (Published atau Draft).
2. Atur Log Level kedua (mulai dari Warning ke atas untuk triase).
3. Atur Start DateTime dan End DateTime terakhir.
4. Klik Apply Filter.
5. Pastikan tabel dimuat ulang dan timestamp barisnya sesuai dengan rentang waktu insiden yang Anda maksud.

Log Source — Published Agent vs Draft Agent

Ini adalah salah satu filter paling penting dan sering terlewatkan.

• Published Agent — Log dari versi yang sedang diajak bicara oleh pengguna akhir Anda. Gunakan ini untuk semua monitoring produksi dan investigasi insiden.
• Draft Agent — Log dari konfigurasi yang sedang dikembangkan. Gunakan ini segera setelah menyimpan perubahan untuk memverifikasi pengaturan baru berfungsi sebelum Anda publikasikan.

Selalu periksa log Draft Agent sebelum mempublikasikan perubahan konfigurasi apa pun. Error yang terlihat di Draft dan Anda pilih untuk diabaikan akan menjadi error produksi begitu Anda publikasikan.

Log Level

Pilih tingkat keparahan minimum atau pilih All untuk melihat semuanya. Default-nya adalah Information.

Mengubah filter level tidak memuat ulang halaman — hasilnya diperbarui di tempat, membuatnya cepat untuk meningkatkan dari Warning ke Error ke semua level saat mengejar insiden tertentu.

Start / End DateTime

Rentang tanggal secara default adalah 24 jam terakhir. Saat menginvestigasi insiden tertentu, persempit ini ke jendela waktu persis saat insiden terjadi. Mengurangi rentang waktu secara drastis mengurangi jumlah baris di tabel dan membuatnya jauh lebih mudah untuk menemukan entri yang relevan.

Timestamp dengan presisi milidetik tersedia di baris log itu sendiri setelah Anda menemukan peristiwa yang relevan.

Klik Apply Filter untuk memuat ulang tabel log dengan pilihan Anda.

Jika tidak ada baris yang muncul setelah menerapkan filter, perluas dengan urutan ini:

1. Perluas rentang DateTime (misalnya dari 15 menit menjadi 24 jam).
2. Turunkan Log Level dari Warning ke Information.
3. Verifikasi Anda berada pada Log Source yang benar (Draft vs Published).

Urutan ini membantu Anda memulihkan sinyal dengan cepat tanpa langsung membanjiri tabel dengan peristiwa bernilai rendah.

Membaca Entri Log

Setiap baris di tabel log berisi:

Baca baris dari kiri ke kanan untuk menghindari salah diagnosis:

1. Mulai dengan Timestamp untuk memverifikasi urutan peristiwa.
2. Periksa Level untuk menentukan urgensi.
3. Gunakan Service untuk mengidentifikasi lapisan pemilik (AI, retrieval, function tools, channel, auth).
4. Gunakan Message hanya sebagai ringkasan, lalu buka aksi baris untuk bukti lengkap.

Ketika beberapa error terlihat serupa, urutkan secara mental berdasarkan timestamp dan periksa yang paling awal terlebih dahulu. Kegagalan pertama sering berisi konteks kausal paling lengkap, sementara baris-baris berikutnya bisa jadi efek sekunder.

Menafsirkan Nama Service

Layanan yang berbeda muncul di log tergantung bagian sistem mana yang aktif:

• AI service — Log terkait completion model, penggunaan token, dan manajemen context window
• Knowledge service — Operasi retrieval terhadap vector database
• Function tool service — Panggilan Custom API dan eksekusi plugin
• Channel service — Pesan masuk dan keluar pada channel yang terhubung (WhatsApp, widget, dll.)
• Auth service — Peristiwa autentikasi dan otorisasi

Ketika sebuah error muncul, nama service memberi tahu Anda lapisan mana yang harus diinvestigasi terlebih dahulu.

Tombol Aksi

Setiap baris log memiliki tiga tombol aksi di sisi kanan.

View Conversation

Membuka thread percakapan lengkap yang terkait dengan peristiwa log ini. Gunakan ini untuk menelusuri error teknis kembali ke interaksi pengguna yang persis menyebabkannya. Melihat percakapan berdampingan dengan entri log hampir selalu mengungkapkan apakah kegagalan tersebut adalah masalah integrasi, masalah konten, atau masalah perilaku model.

Ini memerlukan izin Conversation history pada catatan contributor Anda. Izin ini menyala secara default; jika Owner atau Admin mematikannya untuk Anda, tombolnya tetap muncul tetapi percakapannya diganti peringatan — entri log-nya sendiri tetap bisa dibaca seutuhnya. Lihat Mengelola Akses Agent.

Jika organization memiliki Mode Privasi yang aktif, percakapan bisa saja menampilkan placeholder konten yang telah dihapus — terlepas dari izin Conversation history Anda — setelah jendela retensinya berlalu.

View User

Membuka dialog dengan detail tentang pengguna yang memicu peristiwa ini. Berguna untuk mengidentifikasi apakah pola error terisolasi pada satu pengguna (kemungkinan masalah konfigurasi atau izin khusus untuk pengguna tersebut) atau memengaruhi banyak pengguna (kegagalan integrasi sistemik).

View Context

Membuka panel yang menampilkan metadata key-value terstruktur yang melekat pada peristiwa log tersebut.

Panel context adalah sumber informasi debug paling kaya yang tersedia di halaman Monitoring. Biasanya mencakup:

• Payload permintaan lengkap yang dikirim ke API eksternal
• Kode status HTTP dan body respons yang dikembalikan oleh API eksternal
• Data timing (berapa lama setiap langkah berlangsung)
• Jumlah token dan parameter model untuk completion AI
• Detail error dari operasi mana pun yang gagal

Gunakan pola pembacaan cepat ini di dalam View Context:

1. Temukan payload permintaan upstream dan validasi field yang wajib diisi.
2. Temukan kode status respons downstream.
3. Baca body respons untuk teks error yang konkret.
4. Bandingkan timestamp/durasi untuk menemukan pola timeout.
5. Korelasikan dengan kolom Service dan Message pada baris tabel yang Anda buka.

Ini mencegah Anda hanya fokus pada ringkasan tabel sambil melewatkan detail payload akar masalah yang sebenarnya.

Tip: Saat men-debug panggilan Custom API yang gagal, selalu buka View Context pada log Error. Context akan berisi kode status HTTP dan body respons yang persis dari API eksternal Anda — jauh lebih bisa ditindaklanjuti dibanding pesan ringkasan pada baris tabel.

Pola yang Perlu Ditindaklanjuti

Tabel di bawah ini mencantumkan pola log yang paling umum dan apa yang harus dilakukan saat Anda menemukannya.

Perbedaan Antara Error dan Warning

Error berarti sebuah operasi gagal dan pengguna kemungkinan menerima respons yang menurun kualitasnya atau salah. Error memerlukan investigasi segera.

Warning berarti sistem menyadari sesuatu yang tak terduga tetapi berhasil pulih. Warning yang terus muncul hari demi hari sebaiknya tetap diinvestigasi meski belum meningkat menjadi Error — ini sering menjadi indikator awal dari kegagalan yang akan datang.

Menggunakan Monitoring untuk Validasi Pasca-Perubahan

Setiap kali Anda mempublikasikan perubahan konfigurasi, buka Monitoring dan filter ke:

1. Log Source: Draft Agent (periksa sebelum publikasi)
2. Log Level: Warning ke atas
3. Start DateTime: Waktu saat konfigurasi disimpan

Gulir melalui entri untuk memastikan tidak ada error baru yang muncul. Lalu publikasikan. Alihkan ke Published Agent dan periksa lagi 15 menit setelah publikasi untuk memastikan produksi berperilaku sesuai harapan.

Validasi dua langkah ini (Draft dulu, Published kemudian) mencegah sebagian besar error konfigurasi mencapai pengguna.

Membangun Alur Kerja Debug

Ketika seorang pengguna melaporkan bahwa agent memberikan jawaban yang salah atau tak terduga, ikuti urutan ini di Monitoring:

1. Identifikasi rentang waktu — tanyakan kepada pengguna perkiraan waktunya, atau cari di thread percakapan.
2. Filter ke rentang tersebut — atur Start/End DateTime ke ±5 menit di sekitar peristiwa tersebut.
3. Filter ke Warning ke atas — jika tidak ada yang muncul, perluas ke Information.
4. Temukan baris yang relevan — cari entri dari function tool service atau AI service yang sesuai dengan percakapan tersebut.
5. Klik View Conversation — pastikan ini adalah percakapan yang benar.
6. Klik View Context — baca permintaan lengkap, respons, dan detail error.
7. Identifikasi titik kegagalan — tentukan apakah kegagalan ada di AI (halusinasi model, pemotongan context window), retrieval knowledge (tidak ada chunk relevan yang ditemukan), atau function tool (error API eksternal).
8. Bertindak pada akar masalah — titik kegagalan menentukan bagian konfigurasi mana yang perlu diubah.

Halaman Terkait

• Baca Dashboard — lacak volume percakapan dan adopsi function-tool sekilas
• Analisis Feedback Pengguna — pahami apa yang dinilai negatif oleh pengguna sebelum masuk ke log
• Ikhtisar Analytics & Logs — ritme monitoring dan siklus perbaikan
• Otomatisasi dengan Custom API — konfigurasikan function tool yang errornya akan Anda debug di sini