Sebuah frontend mengembalikan 500. Stack trace menunjuk ke komponen React. Masalah sebenarnya berada tiga layanan jauhnya, di connection pool basis data yang habis karena job latar belakang yang bocor.

Anda bisa menelusuri waterfall trace, mengkorelasi timestamp, dan membaca riwayat commit. Atau Anda bisa menyerahkannya ke Seer milik Sentry, agen debugging yang didukung LLM yang membaca trace, error, dan kode Anda, lalu memberi tahu Anda apa yang rusak.

Seer pandai melakukan ini. Ia bukan paranormal. Celah antara dua pernyataan itu adalah apa yang akan dibahas dalam posting ini.

Apa sebenarnya yang dimaksud dengan statistical debugging

Statistical debugging menggunakan pola di berbagai eksekusi untuk menunjukkan bug. Debugger tradisional menunjukkan satu kali eksekusi. Pendekatan statistik melihat distribusi: fungsi mana yang gagal bersama, trace mana yang berkorelasi dengan error, commit mana yang mendahului lonjakan crash.

Sentry telah melakukan bagian statistik selama bertahun-tahun. Seer menambahkan LLM untuk menalar tentang kausalitas di atas data itu. Ia tidak menggantikan statistik. Ia menafsirkan statistik tersebut.

Seer tidak menghasilkan akar masalah dari kekosongan. Ia melihat trace dan stack trace yang sama seperti yang akan Anda lihat, tetapi ia membaca ribuan span dalam hitungan detik dan mengkorelasikannya dengan codebase Anda.

Cara Seer membaca trace tanpa tenggelam dalam span

Sebuah trace terdistribusi bisa berisi ribuan span. Memasukkan semuanya ke dalam jendela konteks LLM adalah resep kebingungan. Model tersebut terfokus pada detail yang tidak relevan dan melewatkan sinyal.

Sentry mengatasi ini dengan membangun pohon trace yang dirangkum. Alih-alih setiap span, Seer melihat hierarki transaksi, yaitu service boundaries yang mengelompokkan span menjadi unit yang bermakna. Pohon tersebut menunjukkan transaksi mana yang memanggil transaksi lain, berapa lama waktu yang dibutuhkan, dan apakah ada error yang terjadi di dalamnya.

Berikut tampilan trace mentah secara konseptual:

GET /api/checkout
├── POST /payment-service/process
│   ├── SELECT * FROM orders
│   └── UPDATE inventory
├── GET /user-service/profile
│   └── SELECT * FROM users WHERE id = ?
└── POST /notification-service/email
    └── SMTP send

Seer menerima pohon ini yang dianotasi dengan status waktu dan error. Ia melihat permintaan checkout memanggil tiga layanan hilir. Ia tidak melihat setiap query basis data secara individual kecuali jika ia memintanya.

Kata kuncinya adalah “kecuali.” Seer memiliki alat. Jika pohon tersebut menunjukkan layanan pembayaran adalah masalahnya, ia bisa mengambil span lengkap di dalam transaksi itu, event error yang terhubung berdasarkan ID, atau profil CPU. Ia memutuskan apa yang akan dilihat selanjutnya.

Pendekatan agentic ini adalah perbedaan antara “tempelkan trace ini ke ChatGPT” dan apa yang sebenarnya dilakukan Seer. Sebuah chatbot mendapat satu kesempatan. Seer mendapat sebuah loop: amati, nalar, ambil lebih banyak data, nalar lagi.

Masalah lintas-layanan yang Seer dibangun untuk pecahkan

Sebelum trace, Seer (saat itu bernama Autofix) bergantung pada stack trace dan breadcrumbs. Ini berhasil untuk monolit. Ia gagal untuk sistem terdistribusi.

Pertimbangkan error 500 di frontend. Stack trace menunjuk ke panggilan fetch. Tanpa trace, Seer akan menyimpulkan frontend-nya yang rusak. Dengan trace, ia melihat frontend memanggil API gateway, yang memanggil layanan auth, yang melempar error validasi token karena sertifikat yang diputar.

Tim Sentry sendiri mengalami ini secara internal. Masalah autentikasi antara backend Sentry dan mikrolayanan Seer telah bertahan selama berhari-hari. Seer, diberi pohon trace dan akses ke kedua repositori, mengidentifikasi akar masalah dan membuka pull request di kedua layanan.

Itulah janjinya. Masalahnya adalah penyiapannya.

Apa yang Seer butuhkan sebelum bisa membantu Anda

Seer membutuhkan tiga hal untuk bekerja dengan baik:

1. Trace yang terhubung.

Jika layanan Anda menggunakan proyek Sentry yang berbeda tanpa distributed tracing, Seer melihat error yang terisolasi, bukan pohon trace. Anda memerlukan Sentry SDK di setiap layanan dan propagasi header trace.

Di Python:

import sentry_sdk

sentry_sdk.init(
    dsn="https://your-dsn.ingest.sentry.io/project-id",
    traces_sample_rate=0.1,  # Adjust for your volume
)

Untuk propagasi lintas-layanan, SDK membaca dan menulis header sentry-trace dan baggage secara otomatis pada klien HTTP yang didukung. Jika Anda membuat klien sendiri, lampirkan header secara manual:

from sentry_sdk import continue_trace

headers = {}
continue_trace(headers).apply_to_request(headers)
response = my_custom_http_client.get(
    "http:// downstream-service/api",
    headers=headers,
)

Tanpa ini, Seer melihat error frontend dan backend sebagai insiden yang tidak terkait. Pohon trace tidak pernah terbentuk.

2. Kode yang terhubung.

Seer mencari codebase Anda untuk mengkorelasi trace dengan implementasi. Ini memerlukan integrasi GitHub dan pemetaan repositori ke proyek Sentry. Seer tidak bisa membaca kode Anda dari file zip atau path lokal.

3. Sinyal yang cukup.

Sebuah trace dengan hanya span HTTP yang diinstrumentasi secara otomatis memberi tahu Seer bahwa layanan A memanggil layanan B. Ia tidak memberi tahu Seer logika bisnis apa yang terjadi di antaranya. Custom span itu penting.

from sentry_sdk import start_span

def process_payment(order_id):
    with start_span(op="payment.process", description="Validate and charge"):
        validate_order(order_id)
        charge_customer(order_id)

Tanpa ini, Seer melihat sebuah kotak hitam antara permintaan HTTP dan query basis data.

Kompromisi yang tidak ada orang tulis di materi pemasaran

Seer memiliki keterbatasan nyata, dan Sentry cukup jujur tentang hal itu.

Akurasi tinggi, tetapi bukan 100%.

Sentry melaporkan tingkat identifikasi akar masalah 94,5%. Itu berarti kira-kira satu dari dua puluh masalah didiagnosis salah. Untuk insiden dengan tingkat keparahan tinggi, Anda masih membutuhkan manusia untuk memverifikasi kesimpulan Seer sebelum menerapkan perbaikan.

Biayanya uang per kali dijalankan.

Biaya menjalankan Seer sekitar $1 per analisis akar masalah, ditambah langganan bulanan. Pemindaian otomatis lebih murah di $0,003 per masalah. Untuk tim yang menangani puluhan masalah setiap hari, ini bertambah. Konfigurasikan ambang batas otomatisasi dengan hati-hati.

Ia tidak bisa memperbaiki apa yang tidak bisa ia lihat.

Jika trace Anda disampling pada 1% dan bug hanya muncul di 99% lainnya, Seer tidak akan menemukannya. Jika akar masalahnya ada di layanan pihak ketiga yang tidak mengirim trace ke Sentry, Seer akan menemui jalan buntu. Jika masalahnya adalah bug logis yang tidak pernah melempar error, Seer tidak akan pernah terpicu.

LLM masih buruk dalam beberapa jenis penalaran.

Sebuah studi Microsoft membuktikan apa yang kebanyakan pengembanga duga: agen AI unggul dalam melokalisasi masalah tetapi kesulitan dengan analisis akar masalah ketika penyebabnya jauh dari gejalanya. Kausalitas di selang waktu, terutama dengan kondisi balapan atau korupsi state, tetap sulit.

Kapan Seer unggul dan kapan melewatkannya

Seer layak dicoba ketika:

  • Anda memiliki sistem terdistribusi dengan trace yang terhubung di berbagai layanan
  • Masalahnya melibatkan event error yang jelas yang telah ditangkap Sentry
  • Akar masalahnya kemungkinan ada di kode Anda sendiri, bukan dependensi pihak ketiga
  • Anda memiliki volume trace yang cukup sehingga investigasi manual membosankan

Lewatkan ketika:

  • Trace Anda tidak terhubung di seluruh layanan
  • Masalahnya bersifat intermiten dan jarang tertangkap dalam trace
  • Anda memerlukan resolusi di bawah satu menit untuk insiden aktif (Seer membutuhkan beberapa menit untuk dijalankan)
  • Akar masalahnya hampir pasti infrastruktur, bukan kode

Cara sebenarnya untuk mencobanya

Jika Anda sudah berada di paket berbayar Sentry, Seer tersedia sebagai uji coba 14 hari.

  1. Hubungkan GitHub di pengaturan organisasi Sentry Anda
  2. Petakan repositori Anda ke proyek Sentry Anda di pengaturan Seer
  3. Pastikan tracing diaktifkan di SDK Anda dengan traces_sample_rate yang diatur
  4. Buka masalah apa pun dan klik Find Root Cause

Untuk dijalankan secara otomatis, konfigurasikan titik penghentian. Sebagian besar tim memulai dengan Stop after Root Cause. Setelah Anda mempercayai akurasinya, Anda bisa membiarkannya mengusulkan solusi atau menyusun pull request.

Jika Anda menggunakan Cursor atau Claude Code, Anda bisa memanggil Seer melalui server MCP Sentry langsung di chat IDE Anda.

Kesimpulan jujur

Seer bisa menemukan akar masalah dalam trace dengan membangun pohon trace yang dirangkum, mengambil data detail sesuai permintaan, dan menalar di seluruh codebase Anda. Untuk sistem terdistribusi yang terhubung dan diinstrumentasi dengan baik, ia benar-benar berguna. Para engineer Sentry sendiri telah menghemat waktu debugging berhari-hari untuk masalah lintas-layanan.

Ia bukan pengganti untuk memahami sistem Anda sendiri. Ia adalah magang yang sangat cepat dan sangat banyak membaca yang bisa membaca trace dan kode tetapi masih sesekali menyalahkan layanan yang salah. Gunakan untuk mempercepat investigasi, bukan untuk menghilangkannya.

Jika trace Anda bersih, terhubung, dan penuh dengan span yang berguna, Seer mungkin akan mengesankan Anda. Jika tidak, perbaiki trace-nya terlebih dahulu. Tidak ada LLM yang bisa mendebug apa yang tidak pernah Anda instrumen.

FAQ

Apakah Seer bekerja dengan Sentry self-hosted? Tidak. Seer adalah layanan cloud yang memerlukan sentry.io. Ia bergantung pada infrastruktur Sentry sendiri untuk menjalankan agen LLM dan mengakses telemetri Anda. Instansi self-hosted tidak memiliki akses ke Seer.

Bisakah Seer menganalisis trace dari bahasa selain Python dan JavaScript? Ya. Seer membaca data trace dari Sentry, bukan telemetri khusus bahasa. Layanan apa pun yang diinstrumentasi dengan Sentry SDK yang menghasilkan trace dapat dimasukkan ke Seer. Langkah analisis kode memerlukan integrasi GitHub, yang berfungsi dengan bahasa apa pun.

Apa yang terjadi jika Seer salah dalam menentukan akar masalah? Anda bisa memberikan feedback selama analisis, dan Seer akan memasukkannya. Output akhir selalu memerlukan persetujuan manusia sebelum perubahan kode apa pun diterapkan atau PR dibuka. Tidak ada yang dirilis secara otomatis kecuali Anda secara eksplisit mengkonfigurasikannya untuk melakukannya.

Apa bedanya dengan hanya menempelkan stack trace ke Claude atau ChatGPT? Sebuah chatbot mendapat satu jendela konteks dengan apa pun yang Anda tempel. Seer mendapat loop agentic dengan akses ke pohon trace lengkap Anda, error yang terhubung, profil CPU, dan codebase. Ia bisa mengambil lebih banyak data saat ia menalar, dan ia tahu struktur sistem Anda karena ia membaca kode aktualnya.