AI Agent Observability: traces, κόστος και alerts πριν σε τρελάνει

Γιατί τα agents σπάνε διαφορετικά

Σε ένα κλασικό API, η αποτυχία φαίνεται: status 500, timeout, exception. Σε έναν agent όχι — γιατί ο agent μπορεί να «πετύχει» τεχνικά και να αποτύχει πραγματικά.

Συνεπώς, το observability για agents δεν είναι «να βλέπω logs». Είναι να μπορώ να απαντήσω: γιατί αυτό το trace κόστισε $1,40 όταν το μέσο είναι $0,05; και να το απαντήσω σε δευτερόλεπτα, όχι σε ώρες.

Monitoring, observability, evals — τι είναι τι

Τα μπερδεύουν όλοι. Η διαφορά:

Ο σωστός συνδυασμός: metrics για alerts, traces για debugging, evals για ποιότητα. Και οι τρεις τροφοδοτούνται από την ίδια πηγή — τα OpenTelemetry GenAI conventions.

Setup A — τοπικός έλεγχος σε 2 λεπτά (Aspire Dashboard)

Πριν αγοράσεις οτιδήποτε, έλεγξε ότι ο κώδικάς σου εκπέμπει σωστά. Το Aspire Dashboard είναι δωρεάν, ανοιχτό, δέχεται OTLP απευθείας και έχει ενσωματωμένο trace viewer και GenAI visualizer.

# δωρεάν OTLP backend με trace viewer + GenAI visualization
docker run --rm -p 18888:18888 -p 4317:18889 -p 4318:18890 -d --name aspire-dashboard \
  -e ASPIRE_DASHBOARD_UNSECURED_ALLOW_ANONYMOUS=true \
  mcr.microsoft.com/dotnet/aspire-dashboard:latest

Στέλνεις εκεί OTLP στο http://localhost:4318 και ανοίγεις http://localhost:18888 για να δεις traces, metrics και logs. Ιδανικό για local ανάπτυξη και debugging — δεν θέλεις cloud λογαριασμό για να δεις αν δουλεύει.

Setup B — Langfuse με OTLP (cloud)

Το Langfuse δέχεται traces ως απλό OpenTelemetry backend στο endpoint /api/public/otel. Δεν χρειάζεται έτοιμο integration — αρκεί να στέλνεις OTLP.

# EU data region (υπάρχουν και US, Japan, HIPAA)
OTEL_EXPORTER_OTLP_ENDPOINT="https://cloud.langfuse.com/api/public/otel"

# Basic Auth: base64 των "pk-lf-...:sk-lf-..."
OTEL_EXPORTER_OTLP_HEADERS="Authorization=Basic ${AUTH_STRING},x-langfuse-ingestion-version=4"

# φτιάξε το AUTH_STRING από τα API keys σου
echo -n "pk-lf-1234567890:sk-lf-1234567890" | base64

Τρεις λεπτομέρειες που κολλάνε τους περισσότερους

• Το x-langfuse-ingestion-version: 4 header είναι υποχρεωτικό για να εμφανίζονται τα δεδομένα σε πραγματικό χρόνο. Χωρίς αυτό, τα spans μπορεί να αργήσουν έως και 10 λεπτά.
• Μόνο OTLP over HTTP (JSON ή protobuf). Το gRPC δεν υποστηρίζεται ακόμα — αν ο exporter σου είναι gRPC, άλλαξέ τον σε http/protobuf.
• Signal-specific endpoints: αν ο collector σου χρειάζεται ξεχωριστό traces endpoint, είναι /api/public/otel/v1/traces.

Setup C — OpenTelemetry Collector

Όταν οι εφαρμογές σου είναι παραπάνω από μία, βάζεις Collector στη μέση: δέχεται OTLP από όλες και προωθεί με ξεχωριστό auth.

receivers:
  otlp:
    protocols:
      grpc:  { endpoint: 0.0.0.0:4317 }
      http:  { endpoint: 0.0.0.0:4318 }

processors:
  memory_limiter:
    limit_mib: 1500        # 80% του μέγιστου, έως 2G
    spike_limit_mib: 512
    check_interval: 5s
  batch:

exporters:
  otlphttp/langfuse:
    endpoint: "https://cloud.langfuse.com/api/public/otel"
    headers:
      Authorization: "Basic ${AUTH_STRING}"
      x-langfuse-ingestion-version: "4"

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlphttp/langfuse]

Τα attributes που μετράς (gen_ai.*)

Τα OpenTelemetry GenAI Semantic Conventions ορίζουν τα gen_ai.* attributes σε spans, metrics και events — για LLM clients και MCP. Αυτά είναι τα ίδια conventions που καταναλώνουν Langfuse, Arize, Datadog και οποιοδήποτε OTLP backend, άρα δεν κλειδώνεστε σε εργαλείο.

Trace attributes σε όλα τα spans (Baggage)

Το Langfuse φιλτράρει και ομαδοποιεί όλο και περισσότερο σε επίπεδο observation, όχι μόνο trace. Αν θες να φιλτράρεις με userId, sessionId ή tags, πρέπει να υπάρχουν σε κάθε span του trace — όχι μόνο στο root. Το πρότυπο είναι το OpenTelemetry Baggage με BaggageSpanProcessor.

1. Βάζεις τα attributes ως baggage entries στην αρχή του trace
2. Τα βάζεις και στο ενεργό span
3. Ο BaggageSpanProcessor τα αντιγράφει αυτόματα σε όλα τα παιδιά

Στο Langfuse SDK υπάρχουν οι συναρτήσεις propagate_attributes() (Python) / propagateAttributes() (TS) που το κάνουν αυτό χωρίς χειροκίνητη δουλειά. Αν χρησιμοποιείς απλό OTel SDK, βάλε χειροκίνητα attributes με prefix langfuse.trace.metadata.* για να είναι filterable.

Το dashboard που χρειάζεσαι (5 charts, όχι 50)

Debugging σε πράξη: 3 περιπτώσεις

Περίπτωση 1 — Loop 30 tool calls

Σύμπτωμα: κόστος ×8, χρόνος απόκρισης 90s. Τι ψάχνεις: στο trace, μετράς πόσα execute_tool spans έχει το ίδιο όνομα και ίδια arguments. Αν βρεις 30 φορές το web.search με το ίδιο query, το πρόβλημα είναι στο tool result — προφανώς επιστρέφει κάτι που δεν ικανοποιεί τον agent, οπότε προσπαθεί ξανά. Η λύση είναι καλύτερο tool result ή σαφέστερη οδηγία, όχι περισσότερα iterations.

# στο observations table: βρες looping agents
observation.type = "tool"  AND  count(tool.name) >= 30

Περίπτωση 2 — Κόστος $1,40 ανά trace

Ταξινομείς τα generations ανά gen_ai.usage.* και βλέπεις το χτυπημένο: συνήθως ένα τεράστιο input_tokens σε ένα retrieval observation. Δηλαδή το RAG γύρισε 40 αποσπάσματα αντί για 4, ή το prompt ξαναστέλνει όλη τη συνομιλία. Είναι μίας γραμμής η διόρθωση — αλλά μόνο αν το είδες.

Περίπτωση 3 — Agent «κολλάει» σε input-required

Το task μένει input-required και κανείς δεν τον ξαναπαίρνει. Με rate metric (

trace: req-xyz
  └─ invoke_agent  supervisor-agent
     ├─ invoke_agent  research-agent   (A2A delegation)
     │  ├─ chat  gpt-4.1
     │  └─ execute_tool  web.search     (MCP)
     ├─ invoke_agent  analyst-agent
     │  └─ chat  claude-sonnet-4.5
     └─ execute_tool  report.save