Pasukan Foundry Microsoft telah menambah penjejakan berasaskan OpenTelemetry ke dalam rangka kerja ejennya, memberikan pembangun cara untuk melihat pelaksanaan hujung-ke-hujung merentasi ejen berkuasa LLM yang heterogen.

Mengapa sistem pelbagai ejen memerlukan lebih daripada fail log

Latihan tindak balas insiden dipacu AI yang tipikal menggunakan ejen komander yang menyelaraskan beberapa ejen pakar: satu menganalisis log, satu lagi mengesan anomali metrik, yang ketiga memadankan simptom dengan buku panduan (runbooks), dan penghala (router) memilih model bahasa terbaik untuk setiap sub-tugasan. Setiap pakar mungkin memanggil model yang berbeza—contohnya, varian “gpt-5-mini”—dan menggunakan alatnya sendiri. Apabila sesuatu berlaku, jurutera hanya melihat log yang terasing yang menunjukkan apa yang dilakukan oleh setiap komponen, tetapi tiada gambaran tentang bagaimana bahagian-bahagian tersebut saling berkaitan.

Tanpa trace yang bersatu, punca utama tersembunyi dalam proses penyerahan antara ejen. Komander mungkin menghantar permintaan yang dikendalikan dengan betul oleh pembaca log, namun pakar metrik tersalah tafsir data dan mencadangkan buku panduan yang salah. Menyahpepijat (debugging) rantaian tersebut secara manual memakan masa dan terdedah kepada ralat.

Bagaimana OpenTelemetry menyatukan aliran kerja

OpenTelemetry mentakrifkan dua konsep teras: traces dan spans. Trace ialah pengenal pasti unik yang mengikuti permintaan daripada kemasukan sehingga respons akhir. Span merekodkan satu operasi tunggal—seperti panggilan ke model bahasa atau penggunaan alat—di dalam trace tersebut.

Apabila ejen menerima permintaan, ia mengambil Trace ID yang masuk daripada metadata permintaan dan mencipta child span yang mewarisi ID yang sama. Child span tersebut merekodkan masa mula, tempoh, atribut (nama model, alat yang digunakan) dan sebarang ralat. Proses ini berulang untuk setiap ejen hiliran (downstream), membina satu pohon yang mencerminkan aliran logik tugasan keseluruhan.

OpenTelemetry juga menyokong Baggage, iaitu pembawa ringan untuk pasangan kunci-nilai (key-value pairs) tersuai. Dengan menyertakan “drill-id” atau konteks perniagaan lain pada baggage di bahagian atas trace, setiap span hiliran secara automatik mewarisi pengenal pasti tersebut. Pemproses span kemudian menaik taraf baggage tersebut menjadi atribut biasa, menjadikannya mudah untuk membuat pertanyaan (query) bagi semua span yang tergolong dalam latihan insiden tertentu.

Rupa permukaan penjejakan baharu

Dengan instrumentasi yang telah disediakan, Azure Monitor (atau mana-mana backend yang serasi dengan OpenTelemetry) memaparkan hierarki visual:

  • Nama / ID ejen – menunjukkan komponen mana yang melaksanakan operasi tersebut.
  • Penggunaan alat – merekodkan perkhidmatan atau fungsi luaran mana yang telah dipanggil.
  • Versi model – merekodkan LLM tepat yang digunakan, berguna untuk menjejaki kemerosotan (regressions) selepas naik taraf model.
  • Penggunaan token – menangkap berapa banyak token yang dihantar ke dan diterima daripada model, membantu pasukan mengurus kos.
  • Latensi / tempoh – menonjolkan di mana kesesakan (bottlenecks) berlaku, sama ada dalam inferens model atau I/O alat.

Dalam contoh latihan insiden, root span komander menghasilkan child spans untuk setiap pakar, dan setiap pakar menghasilkan child spans seterusnya untuk panggilan modelnya. Klik pada mana-mana nod untuk mendedahkan set atribut penuh, supaya jurutera dapat melihat butiran setiap operasi dengan serta-merta.

Kepentingan bagi operasi berpusatkan AI

  • Kepantasan analisis punca utama – Pasukan menjejaki kegagalan kembali ke span tepat yang mencetuskan ralat, sekali gus mengurangkan masa purata penyelesaian (mean time to resolution).
  • Kebolehlihatan kos – Bilangan token diletakkan bersebelahan dengan latensi, membolehkan bahagian kewangan mengesan penggunaan melampau sebelum bil awan melambung tinggi.
  • Penalaan prestasi – Span dengan latensi tinggi merentasi ejen menunjukkan di mana penyetempatan (caching), pemilihan model atau reka bentuk semula alat boleh meningkatkan daya pemprosesan (throughput).

Apa yang perlu diperhatikan seterusnya

Projek yang dibina berasaskan LangChain, OpenAI SDK atau lapisan penyelarasan (orchestration) lain boleh menggunakan konvensyen semantik yang sama untuk GenAI, membuka jalan kepada trace yang mengalir merentasi penyedia awan dan penggunaan dalam premis (on-premise).

Organisasi hanya perlu mengaktifkan OpenTelemetry SDK dalam ejen mereka dan menghantar data ke Azure Monitor atau pengumpul sumber terbuka (open-source collector).

Kesimpulan

OpenTelemetry memberikan "perekat" yang hilang kepada sistem AI pelbagai ejen yang menukarkan himpunan log yang berselerak kepada naratif yang koheren. Dengan menyebarkan satu Trace ID merentasi LLM yang heterogen, penghala, dan panggilan alat, pembangun dapat mengesan kegagalan, memantau kos, dan mengoptimumkan prestasi tanpa perlu membina semula infrastruktur penjejakan.