Belajar OpenTelemetry - GenAI & AI Observability

#Pendahuluan

Ekosistem AI telah menjadi bagian dari pipeline produksi — dan pertanyaan observasi yang sama muncul kembali dengan lapisan baru: berapa biaya satu prompt? Kenapa LLM lambat? Mengapa agent menghasilkan output berbeda? Episode 21 membahas GenAI observability dengan OpenTelemetry: semantic conventions khusus AI, tracing prompt/response, dan korelasi dengan telemetry aplikasi biasa.

Mengapa penting? LLM adalah sistem nondeterministik dan mahal — tanpa observability, biaya token membengkak diam-diam, latency naik tanpa diketahui, dan kegagalan "lambat vs salah" tidak bisa dibedakan. OTel GenAI semantic conventions, yang kini didukung tool seperti VS Code Copilot, OpenAI Codex, dan Claude Code, adalah bahasa standar untuk mengamati semua itu.

#GenAI Semantic Conventions

OTel GenAI semantic conventions mendefinisikan penamaan standar untuk telemetry AI:

• Span name: gen_ai.client.request, gen_ai.agent.run, gen_ai.tool.invoke.
• Attribute:
  • gen_ai.system — vendor (openai, anthropic, google, bedrock).
  • gen_ai.request.model — model yang diminta (gpt-4o-mini).
  • gen_ai.request.prompt — prompt (hati-hati: bisa berisi data sensitif).
  • gen_ai.response.finish_reason — stop, length, content_filter.
  • gen_ai.usage.input_tokens / gen_ai.usage.output_tokens — biaya token.
  • gen_ai.agent.name / gen_ai.tool.name — identitas agent dan tool.

Tujuannya: telemetry AI dari OpenAI, Anthropic, atau model self-host bisa dibandingkan di dashboard yang sama.

#Instrumentasi SDK OpenAI & LangChain

Berita baiknya: SDK dan framework besar sudah terinstrumentasi.

#Python: OpenAI SDK

pip install opentelemetry-instrumentation-openai

from opentelemetry.instrumentation.openai import OpenAIInstrumentor
 
OpenAIInstrumentor().instrument()

Setiap panggilan openai.chat.completions.create(...) otomatis menjadi span dengan attribute gen_ai.system, model, token usage, dan latency — plus trace_id dari aplikasi sekitarnya.

#LangChain

from opentelemetry.instrumentation.langchain import LangchainInstrumentor
 
LangchainInstrumentor().instrument()

Ini menghasilkan hierarki span yang kaya: chain → LLM call → tool invocation → vector DB query. Persis struktur agent yang ingin kalian telusuri saat menjawab "mengapa agent mengambil jalan ini?".

#Melacak Prompt & Response

Satu keputusan penting: apakah prompt/response perlu disimpan di telemetry? Dua sisi yang harus dipertimbangkan:

• Untuk debugging: melihat prompt asli membantu memahami output aneh dan token usage.
• Untuk keamanan: prompt bisa berisi PII pelanggan atau secret — kebocoran ke vendor observability berisiko.

Praktik yang aman:

1. Simpan metadata (model, finish_reason, token usage) secara default.
2. Simpan prompt/response hanya untuk environment yang diizinkan (staging, atau produksi dengan redaksi).
3. Gunakan gen_ai.request.prompt dengan kebijakan redaksi di collector (episode 16).

processors:
  transform/ai-redact:
    error_mode: ignore
    trace_statements:
      - context: span
        statements:
          - delete_key(attributes, "gen_ai.request.prompt")
          - delete_key(attributes, "gen_ai.response.text")

#Evaluasi (Evals) dan Korelasi

Evals memastikan kualitas output LLM — dan semakin banyak tool yang mengikat hasil evals ke trace yang sama, sehingga satu trace menjawab "siapa, kapan, model apa, dan seberapa baik".

Alur praktiknya:

1. Evaluator menghasilkan skor (correctness, relevance, safety) untuk sebuah respons.
2. Skor disimpan sebagai atribut pada span gen_ai.client.response.
3. Dari skor rendah, kalian melompat ke trace penuh untuk melihat konteks input.

Inilah mengapa GenAI observability tidak terpisah dari observability biasa: evaluasi yang tidak tertaut ke trace tidak bisa dipakai untuk debugging. Satu trace_id menyatukan seluruh cerita AI.

#Korelasi dengan Aplikasi Sekitar

Kekuatan terakhir: telemetry AI berjalan dalam pipeline yang sama dengan aplikasi biasa. Satu request pengguna yang memicu LLM akan menghasilkan trace seperti ini:

Tidak ada backend terpisah untuk AI dan non-AI — semua mengalir via OTLP ke collector yang sama, dengan resource service.name yang sama. Biaya AI, latency, dan error rate bisa dibandingkan berdampingan dengan metrik aplikasi biasa.

#Common Pitfalls

• Prompt penuh disimpan tanpa redaksi — PII pelanggan bocor ke vendor observability.
• Instrumentasi ganda — OpenAI SDK di-instrumentasi lewat dua library; span terduplikasi.
• Evals tanpa trace link — skor ada tapi tidak bisa ditelusuri ke input.
• Lupa observasi biaya — token usage tidak di-alert; biaya AI meledak tanpa diketahui.

#Penutup

Pada episode 21 ini, kalian telah menguasai observability untuk aplikasi AI.

Inti yang harus dibawa pulang:

• GenAI semantic conventions menstandarkan span gen_ai.* dan attribute model/token/biaya.
• Instrumentasi SDK OpenAI dan LangChain menghasilkan span otomatis — cek ketersediaan di registry.
• Prompt/response adalah keputusan keamanan: simpan metadata, redaksi atau batasi konten sensitif.
• Telemetry AI dan aplikasi biasa mengalir di pipeline yang sama — korelasi dan alerting jadi satu.

Di episode 22 selanjutnya, episode terakhir series ini, kita akan membahas production migration, best practice & refleksi akhir — roadmap adopsi dari instrumentasi hingga sampling dan Kubernetes, cara menghindari vendor lock-in, rekap seluruh materi, serta checklist produksi lengkap sebelum menutup series. Sampai jumpa di episode 22!