Modul 12Penggal 4 · Operasi production11 item poster

Observability dan SRE

Log masuk untuk menyimpan kemajuan anda merentas peranti. Sehingga itu, ia disimpan dalam pelayar ini.

Mengapa ini penting

Jika pelanggan memberitahu anda sesuatu rosak sebelum amaran anda berbunyi, anda tidak ada monitoring, anda ada pelanggan yang membuat QA. Observability juga yang menjadikan kod tulisan AI boleh di-debug: apabila anda tidak menulis kod itu, anda perlukan sistem untuk memberitahu apa yang sedang dilakukannya.

Hasil pembelajaran

  1. Keluarkan log, metrik dan trace berstruktur dengan OpenTelemetry.
  2. Takrifkan SLI dan SLO yang mencerminkan kepuasan pengguna, dan gunakan error budget.
  3. Tulis amaran yang boleh diambil tindakan dan tidak menyebabkan keletihan.
  4. Bina dashboard untuk empat golden signal.
  5. Pantau tingkah laku, kos dan kualiti LLM serta ejen.

Pelajaran

12.1 Tiga isyarat (58 hingga 61, 66)

  • Log (59): JSON berstruktur, satu event setiap baris, dengan request_id, user_id/tenant_id (bukan PII), level, event, tempoh. Jangan sekali-kali log secret, token, kata laluan, nombor kad penuh atau data peribadi mentah. Tetapkan tempoh simpanan.
  • Metrik (61): siri masa berangka yang murah. RED untuk servis (Rate, Errors, Duration); USE untuk sumber (Utilisation, Saturation, Errors).
  • Trace (60): satu request diikuti merentas servis, queue dan panggilan LLM, dengan span dan masa. Sebarkan trace context melalui queue dan webhook.
  • Monitoring (58) memerhati mod kegagalan yang diketahui. Observability (66) membolehkan anda bertanya soalan baharu kepada sistem yang sedang berjalan tanpa ship kod baharu. Anda perlukan kedua-duanya.
  • Gunakan OpenTelemetry supaya anda tidak terkunci dengan satu vendor.

12.2 Empat golden signal

Latency, trafik, ralat, saturation (daripada amalan SRE Google). Satu dashboard bagi setiap servis, di bahagian atas halaman.

12.3 SLI, SLO dan error budget (63, 64, 65)

  • SLI (64): nisbah terukur bagi event yang baik: "request yang berjaya dilayan dalam masa kurang 500 ms / jumlah request."
  • SLO (63): sasaran bagi SLI dalam satu tempoh: "99.9% sepanjang 28 hari."
  • Error budget (65): kegagalan yang dibenarkan: 0.1% daripada 28 hari ialah kira-kira 40 minit. Bajet masih ada: ship dengan bebas. Bajet habis: perlahankan dan baiki kebolehpercayaan.
  • Pilih SLO mengikut perjalanan pengguna (log masuk, checkout, jawapan AI), bukan mengikut server. 100% ialah sasaran yang salah: ia tidak mampu dibiayai dan menghentikan semua perubahan.

12.4 Amaran (62)

  • Page manusia hanya apabila pengguna sedang terjejas sekarang atau tidak lama lagi (berasaskan simptom), bukan pada setiap lonjakan CPU.
  • Utamakan amaran burn-rate pada SLO (burn pantas dihantar sebagai page, burn perlahan sebagai tiket).
  • Setiap amaran dipautkan kepada runbook: apa maksudnya, cara menyemak, cara meredakan.
  • Amaran perniagaan juga: sifar pendaftaran dalam sejam, kadar kejayaan pembayaran menurun, lonjakan perbelanjaan LLM, DLQ membesar, heartbeat cron terlepas.
  • Semak bunyi bising amaran setiap bulan; padam amaran yang tiada sesiapa ambil tindakan.

12.5 Health check dan probe (56, 57)

Lihat 07 · Corak Ketahanan. Tambah synthetic monitoring luaran bagi perjalanan sebenar dari berbilang rantau.

12.6 Observability LLM dan ejen

Trace setiap panggilan model: model, versi, versi prompt, token masuk/keluar, kos, latency (masa ke token pertama dan jumlah), panggilan alat, sumber retrieval, maklum balas pengguna dan skor eval. Alat: Langfuse, Helicone, Braintrust, atau konvensyen OpenTelemetry GenAI ke dalam backend sedia ada anda. Perhatikan hanyutan kualiti selepas perubahan model atau prompt.

12.7 Error tracking dan RUM

Exception tracking dengan source map dan tag release (Sentry atau yang setara). Real-user monitoring bagi Core Web Vitals.

Makmal 12: Tahu sebelum mereka tahu

  1. Instrumentasikan aplikasi dengan OpenTelemetry (log, metrik, trace) dari hujung ke hujung, termasuk satu lompatan queue dan satu panggilan LLM.
  2. Takrifkan 3 SLO untuk perjalanan kritikal; bina dashboard dan amaran burn-rate.
  3. Tulis runbook untuk setiap amaran.
  4. Rosakkan sesuatu di staging; ukur masa dari kerosakan hingga amaran.
  5. Bina panel kos dan kualiti LLM.

Definition of Done

Pek prompt AI

  • "Tambah instrumentasi OpenTelemetry pada servis ini. Sebarkan context melalui queue. Tambah span di sekeliling setiap panggilan LLM dan alat dengan atribut token dan kos."
  • "Audit panggilan logging kami dan tandakan mana-mana yang boleh log secret, token atau data peribadi."