AI Agent Loglarında Ne Tutulmalı? Tool Call, Hata, Maliyet ve Kullanıcı İşlemlerini İzleme Rehberi

Kısa özet

AI agent observability yalnızca prompt ve cevabı kaydetmek değildir. Production’da asıl bilinmesi gerekenler şunlardır: hangi kullanıcı hangi görevi başlattı, hangi agent/model çalıştı, hangi tool veya MCP server çağrıldı, hangi işlemler için onay istendi, ne kadar token ve süre harcandı, hangi işlem başarısız oldu ve sonuçta sistemde hangi değişiklik gerçekleşti?

OpenAI, kendi Codex kullanımında user prompt’ları, tool approval kararları, tool execution sonuçları, MCP server kullanımı ve network allow/deny olaylarını OpenTelemetry ile dışa aktarabildiğini açıklıyor. OpenTelemetry’nin GenAI semantic convention’ları da model, input/output token sayıları, operation duration ve tool-call bilgileri gibi alanların ortak biçimde izlenmesini amaçlıyor. (OpenAI) Ancak her şeyi loglamak da doğru değildir. Prompt’lar, tool parametreleri ve tool sonuçları:

• kişisel veri,
• müşteri verisi,
• API key,
• access token,

ticari sır içerebilir. Bu nedenle iyi AI observability sistemi: Maksimum veri toplamak yerine, problemi açıklamaya yetecek minimum güvenli veriyi toplamalıdır.

Kısa doğrudan cevap

Bir AI agent çalıştırmasında minimum olarak şu zincirin izlenebilir olması gerekir:

User / Trigger ↓ Agent Session ↓ Model Call ↓ Tool / MCP Call ↓ Approval Decision ↓ External System Action ↓ Result / Error ↓ Cost / Usage Her agent run için merkezi bir: trace_id veya: agent_session_id kullanmak güçlü bir başlangıçtır. Örneğin tek bir kullanıcı işlemi için:

trace_id = tr_123

User requested report ↓ Model call #1 ↓ search_customer tool ↓ database tool ↓ Model call #2 ↓ generate_pdf ↓ storage upload ↓ completed zinciri tek yerde görülebilmelidir.

Neden klasik application logları AI agent için yeterli değil?

Klasik uygulamada şu log yeterli olabilir:

POST /reports → 200 → 482 ms Agent sistemi ise aynı request içinde: Model ↓ Tool ↓ Model ↓ MCP ↓ Database ↓ Model ↓ External API çalıştırabilir. Kullanıcı: “Rapor neden 45 saniye sürdü?” diye sorduğunda yalnızca HTTP süresine bakmak yeterli değildir. Gecikme:

• model inference,
• yavaş tool,
• retry loop,
• MCP bağlantısı,
• harici API,
• queue,

database kaynaklı olabilir. OpenTelemetry’nin GenAI observability örneği de tam olarak bu problemi öne çıkarıyor: bir agent cevabının yavaşlığının modelden mi, tool call’dan mı yoksa retry döngüsünden mi kaynaklandığını anlamak için LLM ve tool operasyonlarının aynı trace içinde görülebilmesi gerekir. (OpenTelemetry)

Log, metric ve trace aynı şey mi?

Hayır. AI observability tasarımında üçü birlikte kullanılabilir. Log Belirli bir olaydır. Örneğin: tool_execution_failed veya: user_approval_denied Metric Zaman içinde toplulaştırılmış ölçümdür. Örneğin: AI request success rate = %98,4 P95 agent duration = 12,4 sn Input tokens/day = 8,2M Trace Tek bir kullanıcı işleminin bütün zincirini gösterir. User request ├─ Model ├─ Tool ``` │ └─ Database ``` ├─ Model └─ External API OpenAI Agents SDK de benzer biçimde bir Trace’i uçtan uca workflow, Span’leri ise model generation, tool execution, handoff veya agent run gibi tekil operasyonlar olarak ele alıyor. (OpenAI GitHub)

1. Her agent çalıştırması için kimlik oluşturun

İlk ihtiyaç:

trace_id veya: session_id olmalıdır. Örneğin: {

• "trace_id": "tr_01K4...",
• "session_id": "session_982",

"workflow": "invoice-analysis"

} Aynı ID:

• model çağrısı,
• tool çağrısı,
• database işlemi,
• queue message,
• worker,

error üzerinden taşınmalıdır. Böylece: “Bu faturayı neden yanlış işledi?” sorusunun cevabı onlarca ayrı log satırından manuel olarak çıkarılmak zorunda kalmaz. Workflow adı da tutulmalı Tek başına: trace_123 anlamlı değildir. Ek olarak:

workflow = customer-support

veya:

workflow = vessel-report-generation

gibi düşük cardinality alanı kullanılabilir. OpenAI Agents SDK, trace’lerde mantıksal workflow adı, trace ID, group ID ve metadata kullanmayı destekliyor. Aynı conversation veya süreç içindeki birden fazla trace group_id ile ilişkilendirilebiliyor. (OpenAI GitHub)

2. İşlemi kimin başlattığını kaydedin

Agent:

kendi kendine işlem yapıyor gibi görünse de production sisteminde çoğu işlemin arkasında:

• kullanıcı,
• servis,
• scheduled automation,
• webhook,

başka agent bulunur. Örneğin: {

• "initiator_type": "user",
• "initiator_id": "usr_312",

"organization_id": "org_22"

} veya: {

• "initiator_type": "automation",

"automation_id": "weekly-report"

} saklanabilir. GitHub agent audit event’leri de benzer biçimde agent işlemini gerçekleştiren actor ile agent session’ını ve agent işlemini başlatan kullanıcıyı ayrı alanlarla ilişkilendiriyor. agent_session_id agent session’ına, user ise işlemi başlatan kişiye bağlanabiliyor. (GitHub Docs)

Neden “kim başlattı?” bu kadar önemli?

Örneğin production’da agent:

customer_451 kaydını değiştirdi

Audit sırasında şu sorular sorulur:

• Kim istedi?

↓

Agent neden yaptı?

↓

Hangi tool yaptı?

↓

Hangi permission kullanıldı?

↓

İnsan onayladı mı?

Sadece:

AI_AGENT changed customer logu yetersizdir.

3. Kullanıcının niyetini saklayın — ama her zaman ham prompt’u değil

Agent-native observability’de önemli fark:

Yalnızca ne olduğunu değil, neden olduğunu anlamaktır. OpenAI, Codex telemetry’sinde kullanıcı prompt’larının isteğe bağlı biçimde loglanabildiğini ve bu bağlamın security investigation sırasında agent’ın neden belirli bir işlem yaptığını anlamaya yardımcı olduğunu açıklıyor. (OpenAI) Ancak: raw_user_prompt çok hassas olabilir. Örneğin prompt: “Müşteri Ahmet Yılmaz'ın şu sözleşmesini incele…” gibi kişisel veya ticari bilgi içerebilir.

Her prompt’u sonsuza kadar saklamak doğru mu?

Hayır. Alternatif olarak: {

• "intent": "generate-customer-report",
• "prompt_logged": false,
• "prompt_hash": "...",

"input_size": 2840

} saklanabilir. Yüksek güvenlik gerektiren sistemlerde raw content yerine: intent length template/version classification hash tutulabilir. İhtiyaç halinde yalnızca belirli debugging environment’larında tam content logging açılabilir.

OpenTelemetry neden prompt/content alanlarını opt-in düşünüyor?

OpenTelemetry semantic convention yaklaşımında yüksek hacimli veya hassas içeriklerin varsayılan zorunlu telemetry olmaması gerektiği vurgulanıyor; hassas veya verbose alanlar opt-in olmalı. GenAI telemetry’de prompt, completion ve tool-call içerikleri isteğe bağlı olarak kaydedilebilir. (OpenTelemetry) Bu iyi bir varsayılandır: Metadata default, raw content opt-in.

4. Kullanılan provider ve model mutlaka kaydedilmeli

Agent işlemi:

başarılı olabilir.

Ama hangi model yaptı?

Örneğin: {

• "provider": "openai",
• "model": "model-x",

"operation": "generate"

} tutulabilir. OpenTelemetry GenAI convention’ları model bilgisini ve GenAI operation tipini standart telemetry alanları arasında tanımlıyor. (OpenTelemetry) Bu özellikle model migration sırasında kritiktir. makaledeki gibi model değiştirirseniz: Model A → Model B

ve production kalite düşerse loglardan:

• Hangi request hangi modelden geçti?

görülebilir. Model alias kullanıyorsanız response modelini de kaydedin Request:

model = general-production

gibi internal profile ile yapılabilir. Ama provider gerçekte: model-x-2026-08 çalıştırmış olabilir. Mümkünse iki bilgi ayrı tutulabilir: {

• "requested_profile": "general-production",

"provider_model": "model-x-2026-08"

} Bu model migration ve regression investigation için değerlidir.

5. Prompt veya instruction versiyonu tutulmalı

Şu durum çok sık yaşanır:

Model aynı ↓ Kalite düştü Sonra aslında: system prompt v4 → system prompt v5 değişmiştir. Bu nedenle: {

• "prompt_template": "invoice-extraction",

"prompt_version": "v5"

} saklanabilir. AI davranışında en az: model + prompt + tools birlikte sonuç üretir. Dolayısıyla incident araştırmasında üçünün de versiyonu bilinmelidir.

6. Tool call’ları mutlaka ayrı event/span olarak izleyin

Agent sisteminin gerçek riskli bölümü çoğu zaman model generation değil:

tool execution katmanıdır. Örneğin agent: search_database send_email create_invoice deploy_production araçlarını kullanabilir. Her tool call için en az: {

• "tool_name": "create_invoice",
• "tool_call_id": "call_123",
• "started_at": "...",
• "duration_ms": 842,

"status": "success"

} tutulabilir.

OpenTelemetry GenAI attribute modelinde tool adı, tool tipi ve tool call ID gibi bilgiler tanımlanıyor. (OpenTelemetry)

Tool parametrelerinin tamamı loglanmalı mı?

Varsayılan olarak hayır. Örneğin: {

• "card_number": "...",
• "api_key": "...",

"customer_email": "..."

} tool argument içinde bulunabilir. Daha güvenli: {

• "tool": "charge_customer",

"arguments": {

• "customer_id": "cust_123",
• "amount": 12500,

"currency": "TRY"

} } gibi kontrollü whitelist veya redacted argument logging kullanılabilir. Tool sonucunun tamamını loglamak da risklidir Örneğin: get_customer tool’u bütün müşteri profilini döndürüyor olabilir. Logda: name email phone address payment details notes saklamak observability ihtiyacından daha fazla veri toplanmasına yol açar. Daha iyi: {

• "tool": "get_customer",
• "status": "success",
• "records_returned": 1,

"payload_logged": false

} olabilir. OpenAI Agents SDK tarafında da hassas veri kontrolü var OpenAI Agents SDK, generation ve function/tool span’lerinin input/output içerebileceğini ve bunların sensitive olabileceğini açıkça belirtiyor. Bu nedenle trace’lerde sensitive-data capture kapatılabiliyor; span yine oluşurken içerik kaydedilmeyebiliyor. (OpenAI GitHub) Bu iyi bir mimari örnektir: Tool çalıştı ✅ logla Tool'un bütün özel verisi

❌ varsayılan olarak loglama

7. MCP server kullanımı ayrı izlenmeli

Bir agent:

MCP üzerinden şirket sistemine bağlanabilir. Örneğin: crm-mcp database-mcp github-mcp deployment-mcp kullanabilir. Log: {

• "mcp_server": "crm-mcp",
• "tool": "search_customer",

"status": "success"

} gibi olabilir. OpenAI’nin kendi Codex observability yaklaşımı MCP server kullanımını agent-native telemetry event’lerinden biri olarak açıkça sayıyor. (OpenAI)

MCP tarafında ayrıca ne tutulmalı?

Makul alanlar:

server tool duration status approval error_type resource_scope Örneğin: {

• "mcp_server": "production-db-mcp",
• "tool": "execute_read_query",
• "scope": "customer:read",

"approved": true

} Özellikle 4. makaledeki MCP authorization modelinde audit ile permission zincirinin birbirine bağlanması önemlidir.

8. Kullanıcı approval kararlarını kaydedin

Agent sistemlerinde önemli olaylardan biri:

Agent yapmak istedi ile: İşlem gerçekten yapıldı arasındaki approval’dır. Örneğin: deploy_production işlemi için: {

• "approval_required": true,
• "approval_decision": "approved",
• "approved_by": "usr_72",

"approved_at": "..."

} tutulabilir.

OpenAI, kendi Codex telemetry’sinde tool approval kararlarını izlediğini açıkça belirtiyor. (OpenAI)

“Approved” tek başına yeterli mi?

Daha iyi audit:

• Kim?

Neyi?

Hangi scope ile?

Ne zaman?

Hangi session için?

sorularını cevaplamalıdır. Örneğin: {

• "tool": "delete_test_environment",
• "decision": "approved",
• "approver": "user_42",
• "trace_id": "tr_123",

"session_id": "session_9"

} Denied approval da önemlidir

Şu metrik:

• Agent kaç kez approval istedi?

tek başına yeterli değildir. Ayrıca: Approval denied rate izlenebilir. Örneğin yüksek denied rate:

• agent çok geniş yetki istiyor,
• instruction yanlış,
• permission model zayıf,

kullanıcı agent’a güvenmiyor sinyali olabilir.

9. Network erişimini de agent trace'ine bağlayın

Agent terminal veya tool üzerinden dış dünyaya çıkabiliyorsa:

network request güvenlik açısından önemli olaydır. OpenAI’nin iç Codex modelinde network proxy:

• allow,
• deny,

approval kararları telemetry içine dahil ediliyor. (OpenAI) Örneğin: {

• "destination": "api.example.com",
• "decision": "allow",

"tool_call_id": "call_123"

} veya: {

• "destination": "unknown-domain.example",

"decision": "deny"

} tutulabilir.

Network loglarında full URL tutmak her zaman doğru mu?

Hayır.

URL:

gibi credential içerebilir. Tercih: scheme host port decision gibi güvenli metadata olabilir. Query parametreleri varsayılan olarak sanitize edilmelidir.

10. Hataları sınıflandırmadan yalnızca error message tutmayın

Şu log:

Something went wrong işe yaramaz. AI sistemlerinde error taxonomy oluşturun. Örneğin: model_timeout model_rate_limit model_invalid_request tool_timeout tool_permission_denied tool_execution_error mcp_connection_error mcp_auth_error schema_validation_error user_approval_denied guardrail_blocked gibi.

Error type neden önemlidir?

Dashboard:

Agent failure rate = %7 diyebilir. Ama bunun: %5 rate limit %1 tool timeout %1 validation olduğunu bilmeden doğru çözüm bulunamaz. OpenTelemetry genel semantic convention yaklaşımında başarısız operasyonlar için düşük-cardinality error.type benzeri sınıflandırmalar öneriliyor. (OpenTelemetry)

Ham exception ayrıca tutulabilir mi?

Evet, fakat:

• credential,
• query,

customer data içerip içermediği kontrol edilmelidir. Örneğin production log: {

• "error_type": "tool_timeout",
• "error_code": "UPSTREAM_TIMEOUT",

"message": "CRM request timed out"

} olabilir. Stack trace yalnızca güvenli internal observability sisteminde tutulabilir.

11. Retry'ları mutlaka görünür hale getirin

Agent yavaşlığının gizli nedenlerinden biri:

retry olabilir. Örneğin kullanıcı: 12 saniyelik cevap görür. Trace: Model call → 2 sn Tool call → timeout 4 sn Retry → timeout 4 sn Fallback → 2 sn gösterir. Log: {

• "attempt": 3,
• "max_attempts": 3,

"retry_reason": "timeout"

} gibi olabilir. Retry metriği özellikle maliyet için önemlidir Tek kullanıcı isteği: 1 LLM call yerine gizlice: 4 LLM call çalışıyor olabilir. Sonuç: Latency ↑ Cost ↑ Rate-limit pressure ↑ Bu nedenle: model_calls_per_agent_run önemli bir metriktir.

12. Token usage izlenmeli

GenAI sistemlerinin temel operasyon metriği:

input tokens output tokens olabilir. OpenTelemetry GenAI convention’ları:

• input token,
• output token,

cache-related token kullanımı için ortak telemetry attribute’ları tanımlıyor. (OpenTelemetry) Örneğin: {

• "input_tokens": 18240,

"output_tokens": 2120

}

Token neden yalnızca maliyet metriği değildir?

Aynı zamanda:

• context büyümesi,
• prompt verimliliği,
• conversation leakage,

retrieval kalitesi hakkında sinyal verir. Örneğin aynı görevin input token’ı: 8K → 18K → 42K büyüyorsa context management problemine işaret edebilir.

Hangi token metrikleri tutulabilir?

Örneğin: input_tokens output_tokens cached_input_tokens reasoning_tokens — provider destekliyorsa Ancak provider’ların token accounting modellerinin birebir aynı olduğu varsayılmamalıdır.

13. Maliyet nasıl hesaplanmalı?

Agent telemetry’de iki farklı kavram tutulabilir:

Usage Provider’dan gelen gerçek: token counts Estimated cost Şirketin pricing tablosuyla hesapladığı: estimated_cost_usd Örneğin: estimated_cost = input_tokens × input_rate + output_tokens × output_rate Ama pricing zamanla değişebilir. Bu nedenle cost calculation sırasında: {

"pricing_version": "2026-08-01"

} gibi bir versiyon saklanabilir.

Neden provider faturası ile internal tahmin aynı olmayabilir?

Çünkü:

• cached tokens,
• batch pricing,
• tool pricing,
• special tiers,
• rounding,

minimum charges gibi farklar olabilir. Dolayısıyla dashboard’a: Estimated AI Cost demek: Provider Invoice demekten daha doğrudur. OpenTelemetry de token usage metric’lerinin maliyet tahmini ve “token-hungry” prompt’ları tespit etmek için kullanılabileceğini belirtiyor. (OpenTelemetry)

Maliyet yalnızca kullanıcı bazında mı izlenmeli?

Birden fazla boyut değerlidir:

cost / organization cost / user cost / workflow cost / agent cost / model cost / feature cost / successful task Özellikle sonuncusu önemlidir. $100 harcadık demek tek başına anlamlı değil Örneğin: Feature A $100 → 10.000 başarılı task Feature B $100 → 800 başarılı task Cost efficiency farklıdır. Daha güçlü: Cost per successful task veya: AI cost / generated report gibi business metric kullanılabilir.

14. Latency'yi yalnızca toplam süre olarak tutmayın

Toplam:

18 saniye yerine: Model: 4.2 sn Tool: 7.1 sn MCP: 1.3 sn Retry: 4.0 sn Other: 1.4 sn görmek gerekir. OpenTelemetry GenAI metric örneklerinde model çağrısı duration histogram’ları ve token kullanım metric’leri standart observability kullanım alanları olarak gösteriliyor. (OpenTelemetry) P50, P95 ve P99 birlikte izlenmeli Average: 2 saniye olabilir. Ama kullanıcıların %5’i: 25 saniye bekliyorsa ciddi UX sorunu vardır. Bu nedenle: P50 P95 P99 değerleri daha anlamlıdır. Streaming agent için Time to First Token / Chunk da değerli Kullanıcı açısından: toplam süre kadar: ilk cevabın ne zaman geldiği önemlidir. OpenTelemetry GenAI attribute setinde streaming response için ilk chunk süresini temsil eden alanlar da tanımlanmıştır. (OpenTelemetry)

15. Final outcome mutlaka tutulmalı

Agent:

LLM request başarılı olabilir. Tool call’lar da başarılı olabilir. Ama gerçek görev: başarısız olabilir. Bu nedenle: HTTP 200 başarı metriği değildir. Task outcome örneği {

• "task_status": "completed",
• "business_outcome": "report_generated",

"human_correction_required": false

} veya: {

• "task_status": "completed",
• "business_outcome": "incorrect_result",

"human_correction_required": true

} tutulabilir. AI sistemlerinde en önemli metriklerden biri: successful task rate Örneğin: Agent completed technically: %99 User accepted result: %81 ise gerçek başarı: %99 değildir. Bu nedenle product-level success metric model telemetry ile birlikte düşünülmelidir.

16. İnsan müdahalesi ve düzeltmeler izlenmeli

Agent sonucu sonrası kullanıcı:

edit retry regenerate override cancel yapabilir. Bu davranışlar kalite sinyalidir. Örneğin: Agent-generated reports: %72 accepted %19 edited %6 regenerated %3 rejected çok değerli ürün metriğidir. Agent steering de kalite metriği olabilir GitHub agent sessions, kullanıcıların agent çalışırken follow-up prompt ile agent’ı yeniden yönlendirmesine izin veriyor ve session log’larında süreç izlenebiliyor. (GitHub Docs) Dolayısıyla: steering_count_per_session ölçülebilir. Sürekli: 3–4 correction gereken workflow’da:

• instruction,
• tool design,
• model,

context problemi olabilir.

17. File/system değişiklikleri audit’e bağlanmalı

Coding agent özelinde:

• hangi dosya değişti?

hangi commit oluştu?

hangi PR açıldı?

izlenmelidir. GitHub Copilot cloud agent commit’lerini agent session’ıyla ilişkilendiriyor; agent-authored commit message session log’una bağlantı içeriyor ve session üzerinden neden değişiklik yapıldığı izlenebiliyor. (GitHub Docs) Bu güçlü bir audit pattern’idir: System change → Agent session → User intent zinciri korunur.

18. Security event'leri normal telemetry'den ayırın

Örneğin: agent searched file normal telemetry olabilir. Ama: agent tried to access /etc/ssh security event olabilir. Ayrıca: network denied tool permission denied secret scanning blocked production approval requested SIEM’e gönderilebilir. OpenAI, Codex OpenTelemetry loglarının SIEM ve compliance logging sistemlerinde merkezileştirilebildiğini ve security triage için kullanıldığını açıklıyor. (OpenAI) Güvenlik alert örnekleri Unknown MCP server used Production tool requested outside business hours Network request to non-approved domain Agent attempted to read credential path Unusual approval-denied spike gibi kurallar düşünülebilir.

19. Agent loglarını klasik audit loglarından ayrı düşünmeyin

Agent sonunda:

database update GitHub PR cloud deployment CRM record gibi normal enterprise kaynaklarında işlem yapar. Bu nedenle en güçlü model: Agent trace + Application audit + Cloud audit + Repository audit birlikte korele edilebilmelidir. Örnek

trace_id = tr_123

Agent: deploy requested GitHub: PR merged CI: workflow run 883 Cloud: deployment xyz Application: release 2026.08.23 aynı olay zincirine bağlanabilir.

20. Queue ve worker kullanıyorsanız trace context kaybolmamalı

makaledeki background-job mimarisinde:

API ↓ Queue ↓ Worker vardı. Burada agent trace: API'de bitmemeli. Queue message’a trace context taşınarak worker operasyonu aynı distributed trace ile ilişkilendirilebilir. OpenTelemetry messaging convention’ları producer tarafından oluşturulan trace context’in mesaj üzerinden consumer’a taşınmasını öneriyor; aksi halde producer ve consumer trace’lerinin doğrudan korelasyonu kaybolabilir. (OpenTelemetry) Örnek job payload {

• "job_id": "job_123",
• "trace_id": "tr_456",

"task": "analyze-document"

} Gerçek OpenTelemetry context propagation yalnızca manuel trace_id alanına göre değil, standardın context propagation mekanizmasına göre uygulanmalıdır; bu JSON yalnızca kavramsal örnektir.

Agent log event şeması nasıl olabilir?

Örneğin:

type AgentEvent = {

timestamp: string traceId: string sessionId: string workflow: string initiatorType:

initiatorId?: string event:

provider?: string model?: string tool?: string mcpServer?: string durationMs?: number inputTokens?: number outputTokens?: number

status?: 'success' | 'error' errorType?: string } Bu InoviqLab örnek event modelidir; OpenTelemetry veya herhangi bir vendor’ın zorunlu schema’sı değildir. Örnek güvenli tool logu {

• "timestamp": "2026-08-23T13:02:41Z",
• "trace_id": "tr_8f92",
• "session_id": "session_1042",
• "workflow": "customer-report",
• "initiator_id": "usr_91",
• "event": "tool_call",
• "tool": "get_customer_orders",
• "mcp_server": "crm-mcp",
• "duration_ms": 412,
• "status": "success",
• "records_returned": 12,

"raw_payload_logged": false

} Burada:

• müşteri siparişlerinin kendisi yok,
• credential yok,

full prompt yok. Ama sistem davranışını araştırmak için yeterli telemetry bulunuyor. Her şeyi tek büyük log objesine koymayın Şu yapı: {

"entireAgentSession": {
"everything": "..."

} } arama ve metric üretimini zorlaştırır. Daha iyi: session_start model_call tool_call tool_result approval error session_end gibi event stream olabilir. Trace sistemi bu event’leri/spans’i tek execution altında birleştirir.

OpenTelemetry kullanmak zorunlu mu?

Hayır. Örneğin:

• kendi structured logging sisteminiz,
• Datadog,
• Grafana,
• Elastic,
• SIEM,

vendor tracing sistemi kullanabilirsiniz. OpenTelemetry’nin avantajı: ortak telemetry modeline ve vendor-neutral export yaklaşımına yakınlaşmasıdır. OpenAI Codex’in OTel export desteği ve GenAI semantic conventions’ın provider/model/tool/token gibi alanları ortaklaştırmaya çalışması bu nedenle önemlidir. (OpenAI) Ancak OpenTelemetry GenAI convention'ları hâlâ gelişiyor Bu önemli. OpenTelemetry GenAI semantic convention’ları aktif biçimde geliştiriliyor ve bazı alanlar/dokümantasyon yeni dedicated GenAI conventions repository’sine taşınmış durumda. (OpenTelemetry) Bu nedenle: Şirket içi telemetry schema’nızı yalnızca tek experimental field adına sıkı biçimde bağlamayın. Internal semantic model + exporter yaklaşımı daha dayanıklı olabilir.

Loglanmaması gereken veriler

1. API key

❌

2. Access/refresh token

❌

3. Password

❌

4. Full authentication headers

❌

5. Gereksiz kişisel veri

❌

6. Production database credential

❌

7. Sensitive tool payload'ın tamamı

varsayılan olarak ❌

“Redact ederiz” demek yeterli mi?

Redaction kurallarının test edilmesi gerekir. Örneğin secret yalnızca:

API_KEY=

formatında gelmeyebilir. Şurada bulunabilir: {

"authorization": "Bearer ..."

} veya: postgres://user:password@host Bu nedenle:

• known secret keys,
• auth headers,
• connection strings,

sensitive field names maskelenmelidir. Log retention ayrıca belirlenmeli Her telemetry verisi sonsuza kadar tutulmamalıdır. Örneğin: Operational metrics → uzun süre aggregation Detailed traces → 30–90 gün Sensitive debugging traces → çok daha kısa Security audit → compliance ihtiyacına göre kullanılabilir. Süreler örnektir; gerçek retention KVKK/GDPR, sözleşme, güvenlik ve operasyon ihtiyaçlarına göre belirlenmelidir.

Sampling kullanılabilir mi?

Çok yüksek hacimli agent sisteminde bütün successful traces’i sonsuza kadar saklamak pahalı olabilir. Örneğin: success trace → %10 sample error trace → %100 security event → %100 high-cost request → %100 gibi strateji düşünülebilir. Ancak security/audit gereksinimi bulunan eylemler sampling dışında tutulmalıdır.

Hangi dashboard'lar hazırlanmalı?

Operasyon

Agent success rate P50 / P95 latency Tool error rate MCP error rate Retry rate Maliyet Tokens / day Cost / workflow Cost / user Cost / successful task Kalite Human correction rate Regeneration rate Task acceptance Tool success Güvenlik Approval denied Network denied Restricted tool attempts Unknown MCP usage AI Agent için önerilen 15 temel metrik

Metrik

Ne anlatır?

Agent runs

Kullanım Successful task rate Gerçek başarı P50 duration Normal deneyim P95/P99 duration Kötü uçlar Model calls/run Agent verimliliği Tool calls/run Workflow karmaşıklığı Tool failure rate Entegrasyon kalitesi MCP failure rate Tool altyapısı Retry rate Gizli hata/maliyet Input tokens Context maliyeti Output tokens Generation maliyeti Cost/task Ekonomik verim Approval request rate Permission yükü Approval deny rate Risk/UX problemi Human correction rate

Output kalitesi

Agent başına mı workflow başına mı dashboard hazırlanmalı?

İkisi de faydalıdır. Ama business açısından: invoice extraction agent yerine: Invoice processing workflow daha değerli olabilir. Çünkü workflow: Agent A → Tool → Agent B içerebilir. Bu yüzden OpenAI Agents SDK’de de trace mantığı logical workflow’u, span’ler ise içindeki agent/tool/model operasyonlarını temsil ediyor. (OpenAI GitHub)

GitHub coding agent örneği bize ne öğretiyor?

GitHub Copilot agent session sayfaları:

• agent progress,
• token usage,
• session length,
• kullanılan araçlar,

file changes gibi bilgileri gösterebiliyor. Agent-authored commit’ler session log’larıyla ilişkilendiriliyor. (GitHub Docs) Enterprise audit log tarafında ise agent işlemleri: action actor_is_agent agent_session_id user gibi alanlarla izlenebiliyor. (GitHub Docs) Bu iyi bir ayrımı gösteriyor: Detailed agent session telemetry ile: Enterprise audit event aynı şey değildir. İkisine de ihtiyaç olabilir. Session log ile audit log farkı Session log

Soruyu cevaplar:

• Agent nasıl düşündü/ilerledi ve hangi araçları kullandı?

Pratikte görülebilir agent execution context’i, tool kullanımı ve değişiklik süreci gibi ayrıntıları içerir. Audit log

Soruyu cevaplar:

Kurumsal sistemde hangi eylem, hangi kimlik tarafından, ne zaman gerçekleşti?

Audit log daha kalıcı güvenlik/compliance kaydıdır. Bu iki kavram birbirine karıştırılmamalıdır. GitHub'da da her veri audit log içinde değil GitHub, enterprise audit log’un agent activity’yi içerebildiğini ancak local Copilot client session prompt’ları gibi session verilerinin genel enterprise audit log’un parçası olmadığını belirtiyor. Uzun dönem enterprise analizi için audit stream gibi ayrı mekanizmalar kullanılabiliyor. (GitHub Docs) Bu da genel prensibi destekliyor: Audit ve debugging telemetry farklı veri setleri olabilir.

Agent hook'ları özel audit için kullanılabilir mi?

GitHub Copilot hooks:

• session start,
• session end,
• user prompt submitted,

tool use gibi agent lifecycle noktalarında custom shell command çalıştırmaya izin veriyor. GitHub bunu custom validation ve audit logging kullanım alanları arasında açıkça sayıyor. (GitHub Docs) Benzer event hook modeli kendi agent platformunuzda da uygulanabilir. Kritik distinction: Observability ≠ surveillance Agent observability: Çalışanın yazdığı her kelimeyi sonsuza kadar saklamak anlamına gelmemelidir. Amaç:

• sistemi debug etmek,
• güvenliği denetlemek,
• maliyeti yönetmek,
• kaliteyi ölçmek,

incident araştırmak olmalıdır. Bu nedenle privacy-by-design uygulanmalıdır. AI Agent Logging Kontrol Listesi Kimlik Her run için trace_id mevcut. Session ID mevcut. Workflow adı belli. User/automation initiator belli. Organization/tenant context güvenli biçimde ilişkilendiriliyor. Model Provider kaydediliyor. Model kaydediliyor. Prompt/template version kaydediliyor. Model call duration ölçülüyor. Finish/outcome bilgisi tutuluyor. Usage Input tokens ölçülüyor. Output tokens ölçülüyor. Cache token kullanımı gerekiyorsa izleniyor. Model calls/run ölçülüyor. Estimated cost hesaplanabiliyor. Tool Tool adı loglanıyor. Tool call ID bulunuyor. Duration ölçülüyor. Tool success/failure tutuluyor. Sensitive arguments redacted. Tool result’ın gereksiz raw içeriği tutulmuyor. MCP MCP server adı biliniyor. MCP tool adı biliniyor. Error type ölçülüyor. Permission/scope gerektiğinde audit ediliyor. Approval Approval request loglanıyor. Decision loglanıyor. Approver belli. Denied approval’lar ölçülüyor. Kritik action ile approval event korele edilebiliyor. Error Error taxonomy var. Retry attempt kaydediliyor. Provider ve tool hataları ayrılıyor. Sensitive exception data sanitize ediliyor. Error traces sampling dışında değerlendiriliyor. Security Network allow/deny izleniyor. Restricted tool denemeleri alert üretebiliyor. Secret loglanmıyor. Authentication header loglanmıyor. SIEM entegrasyonu gerektiğinde mevcut. Product Successful task rate ölçülüyor. Human correction rate var. Regeneration/retry kullanıcı davranışı ölçülüyor. Workflow bazında maliyet görülebiliyor. Minimum production log modeli Küçük bir AI özelliği için başlangıçta şu kadar bile yeterli olabilir: trace_id user_id workflow provider model duration input_tokens output_tokens status error_type Tool kullanan agent’a geçince: tool tool_duration tool_status approval eklenebilir. MCP ve network kullanan daha güçlü agent’ta: mcp_server network_decision permission_result eklenebilir. InoviqLab teknik değerlendirmesi Bu bölüm InoviqLab değerlendirmesidir; OpenAI, GitHub veya OpenTelemetry’nin zorunlu schema’sı değildir. AI observability konusunda en sık yapılan hata: Prompt ve cevabı database’e kaydettik, log sistemimiz var. demektir. Bu yaklaşım hem gereksiz veri toplar hem de gerçek operasyon problemlerini her zaman açıklamaz. Daha güçlü model: Identity + Intent + Model + Tool + Permission + Outcome + Cost zincirini izlemektir. Birinci prensip: Agent'ın ne söylediğinden çok ne yaptığını izleyin Chatbot: metin üretir. Agent: sistem değiştirir. Dolayısıyla agent observability’de en kritik alan: Action olabilir. Örneğin: Model output: "Kaydı siliyorum." yerine: delete_customer tool actually executed = true daha önemlidir. İkinci prensip: User intent ile system action'ı bağlayın En değerli audit zinciri: User intent ↓ Agent decision ↓ Approval ↓ Tool action ↓ System result olmalıdır.

Böylece olay sonrası:

• Bu deployment neden gerçekleşti?

sorusu cevaplanabilir. Üçüncü prensip: Prompt logging default olmamalı Raw prompt yüksek debugging değeri taşır. Ama aynı zamanda yüksek privacy riskidir. Bu nedenle InoviqLab açısından daha sağlıklı varsayılan: Production: metadata + redacted content Controlled debugging: temporary full-content trace modelidir. Dördüncü prensip: Cost metriğini business outcome'a bağlayın Şu bilgi: Bu ay AI maliyeti $2.800 tek başına karar vermeye yetmez. Daha güçlü: $0,07 / successful report veya: $0,015 / resolved support request gibi ölçümlerdir. Böylece model optimization yalnızca token azaltmak değil: Aynı business outcome’u daha verimli üretmek haline gelir. Beşinci prensip: Her AI call ayrı ürün metriği değildir Bir agent run: 6 model call + 4 tool call yapabilir. Kullanıcı açısından ise: 1 görev vardır. Bu nedenle operasyon: model call metrics ile ürün metriği: task success ayrı tutulmalıdır. Altıncı prensip: Agent logları security boundary'nin parçası haline geliyor Agent’lar:

• terminal,
• repository,
• MCP,
• cloud,

database erişimi kazandıkça telemetry yalnızca performance aracı olmaktan çıkar. Aynı zamanda: security audit trail haline gelir. OpenAI’nin kendi Codex kullanımında agent logs + endpoint security + security triage yaklaşımını birlikte kullanması bunun güncel bir örneğidir. (OpenAI)

Sonuç

AI agent logları yalnızca:

prompt + response olmamalıdır. Production agent için daha güçlü görünüm: WHO ↓ requested WHAT ↓ which AGENT / MODEL ↓ used which TOOL / MCP ↓

with which PERMISSION

↓ what ACTION happened ↓ what RESULT occurred ↓ how much TIME / TOKENS / COST sorularını cevaplamalıdır. OpenAI Codex’in güncel telemetry yaklaşımı:

• user prompt,
• tool approval,
• tool execution,
• MCP usage,

network policy olaylarının izlenebildiğini gösteriyor. (OpenAI) OpenTelemetry GenAI convention’ları ise:

• model,
• operation,
• tool,
• token,

latency gibi agent/LLM observability alanlarını sağlayıcılar arasında daha ortak biçimde ifade etmeyi hedefliyor. (OpenTelemetry) Ancak asıl prensip teknoloji bağımsızdır: İyi AI observability sistemi her şeyi kaydetmez; sistemi açıklamak, maliyeti ölçmek ve güvenlik olayını araştırmak için gereken doğru veriyi kaydeder.