SmaugBrain
← Back to News
news Feature story

AI Agent Observability: Monitoring, Logging, and Tracing for Production Systems

7 9 月 2026 smaugbrain 8 min read WordPress post

AI Agent Observability: Monitoring, Logging, and Tracing for Production Systems

Introduction

When an AI agent fails in production, the first question is always the same: **what happened?** Unlike traditional software where you can read stack traces and logs, AI agents introduce a new layer of complexity—non-deterministic model outputs, tool call failures, memory state drift, and multi-step reasoning chains that can break at any point.

Observability isn’t just about fixing bugs faster. It’s the foundation of trust. Teams that can see inside their agents’ decision-making processes deploy with confidence. Those that can’t spend hours debugging “why did it do that?” questions instead of building new features.

This guide covers the three pillars of AI agent observability—logging, metrics, and tracing—plus practical implementation patterns you can use today.

Why AI Agents Need Different Observability

Traditional application logging focuses on request flows and database queries. AI agents add several new dimensions:

  • **Token usage and cost tracking** — Every API call has a price tag
  • **Model output sampling** — You need to see what the model actually produced
  • **Tool execution traces** — Each tool call may succeed, fail, or return unexpected data
  • **Memory state snapshots** — Agent context evolves across turns
  • **Reasoning chain visibility** — Multi-step decisions need to be auditable
  • Without proper observability, you’re flying blind. A 404 error is obvious; a silent hallucination that cost you $2.50 in API fees and damaged user trust is not.

    The Three Pillars of AI Agent Observability

    Three pillars of AI agent observability: logging, metrics, and tracing

    1. Structured Logging

    Structured logs are machine-readable records of agent activity. Unlike plain text logs, structured formats (JSON) let you query, filter, and visualize agent behavior at scale.

    Key logging patterns for AI agents:

  • **Request logging**: Capture input prompts, model names, and token counts
  • **Tool execution logging**: Record which tools were called, with what arguments, and what they returned
  • **Error logging**: Log failures with context—what triggered them, what state preceded them
  • **Cost logging**: Track cumulative spend per session, per user, per task
  • {
      "timestamp": "2026-09-07T10:30:00Z",
      "agent_id": "support-agent-01",
      "session_id": "sess_abc123",
      "event": "tool_call",
      "tool": "search_knowledge_base",
      "input": {"query": "return policy"},
      "output_length": 1247,
      "duration_ms": 342,
      "model": "gpt-4o",
      "tokens_used": {"prompt": 856, "completion": 124, "total": 980}
    }

    Best practices:

  • Use consistent field names across all log sources
  • Include correlation IDs for cross-service tracing
  • Never log sensitive data (PII, API keys, credentials)
  • Set log levels appropriately (DEBUG for development, INFO for production)
  • 2. Metrics and Monitoring

    Metrics give you the high-level health signals. While logs tell you what happened, metrics tell you whether things are working.

    Essential agent metrics:

    | Metric | What It Shows | Alert Threshold |
    |——–|————–|—————–|
    | Token usage per hour | Cost trajectory | Spike >200% of baseline |
    | Tool call success rate | Reliability | Drop below 95% |
    | Response latency P99 | User experience | >10s for interactive agents |
    | Error rate by type | Failure patterns | Any new error type |
    | Session duration distribution | Engagement quality | Bimodal distribution |
    | Model fallback rate | Infrastructure health | >10% fallbacks |

    Implementation approaches:

  • **Custom counters**: Increment metrics in your agent code for key events
  • **OpenTelemetry integration**: Export standardized metrics to Prometheus, Datadog, or similar
  • **CloudWatch/CloudWatch Logs Insights**: For AWS-hosted agents
  • **Third-party observability platforms**: Langfuse, Phoenix, Arize, or Weights & Biases for LLM-specific observability
  • 3. Distributed Tracing

    Tracing follows a single request through every component it touches. For AI agents, this means tracking the journey from user input through model reasoning, tool calls, memory reads, and final response.

    Trace structure for AI agents:

    “`
    ┌─────────────────────────────────────────────────────────────┐
    │ Span: user_request (100ms total) │
    ├─────────────────────────────────────────────────────────────┤
    │ ├─ Span: model_inference (65ms) │
    │ │ ├─ Input: “What’s my order status?” │
    │ │ ├─ Model: gpt-4o │
    │ │ └─ Output: [thinking tokens] → tool_call │
    │ ├─ Span: tool_execution (200ms) │
    │ │ ├─ Tool: order_lookup │
    │ │ ├─ Input: {order_id: “ORD-123”} │
    │ │ └─ Output: {status: “shipped”, eta: “2 days”} │
    │ └─ Span: model_inference (80ms) │
    │ ├─ Input: [context + tool result] │
    │ └─ Output: “Your order has shipped…” │
    └─────────────────────────────────────────────────────────────┘
    “`

    Tools for agent tracing:

  • **OpenTelemetry**: Vendor-neutral standard, works with any backend
  • **Langtrace/Langfuse**: Purpose-built for LLM applications
  • **Phoenix (Arize)**: Advanced LLM evaluation and tracing
  • **Weights & Biases**: Experiment tracking with tracing capabilities
  • Practical Implementation Patterns

    AI agent monitoring dashboard with latency and cost metrics

    Pattern 1: The Observability Wrapper

    Wrap your agent’s core loop with an observability decorator that automatically captures:

    from functools import wraps
    import time
    import logging
    
    def with_observability(agent_function):
        @wraps(agent_function)
        def wrapper(*args, **kwargs):
            start_time = time.time()
            session_id = kwargs.get('session_id', generate_id())
            
            log.info({
                "event": "agent_start",
                "session_id": session_id,
                "input": str(kwargs.get('user_input'))[:500]
            })
            
            try:
                result = agent_function(*args, **kwargs)
                
                log.info({
                    "event": "agent_complete",
                    "session_id": session_id,
                    "duration_ms": int((time.time() - start_time) * 1000),
                    "output_length": len(result) if result else 0
                })
                return result
                
            except Exception as e:
                log.error({
                    "event": "agent_error",
                    "session_id": session_id,
                    "error_type": type(e).__name__,
                    "error_message": str(e)[:500]
                })
                raise
        return wrapper

    Pattern 2: Tool Call Instrumentation

    Every tool call should be instrumented to capture:

    def instrumented_tool_call(tool_name, tool_func):
        @wraps(tool_func)
        def wrapper(*args, **kwargs):
            start = time.time()
            logger.info({
                "event": "tool_start",
                "tool": tool_name,
                "args": sanitize_args(args, kwargs)
            })
            
            try:
                result = tool_func(*args, **kwargs)
                duration = time.time() - start
                
                logger.info({
                    "event": "tool_success",
                    "tool": tool_name,
                    "duration_ms": int(duration * 1000),
                    "result_size": len(str(result)) if result else 0
                })
                return result
                
            except Exception as e:
                logger.error({
                    "event": "tool_error",
                    "tool": tool_name,
                    "error": str(e)
                })
                raise
        return wrapper

    Pattern 3: Cost Tracking Middleware

    Implement middleware that tracks API costs in real-time:

    class CostTracker:
        def __init__(self):
            self.session_costs = {}
            self.rate_limits = {
                'gpt-4o': {'rpm': 1000, 'tpm': 200000}
            }
        
        def track_usage(self, model, prompt_tokens, completion_tokens):
            session_id = get_current_session()
            cost = calculate_token_cost(model, prompt_tokens, completion_tokens)
            
            if session_id not in self.session_costs:
                self.session_costs[session_id] = {
                    'total_cost': 0,
                    'token_usage': {'prompt': 0, 'completion': 0},
                    'model_counts': {}
                }
            
            self.session_costs[session_id]['total_cost'] += cost
            self.session_costs[session_id]['token_usage']['prompt'] += prompt_tokens
            self.session_costs[session_id]['token_usage']['completion'] += completion_tokens
            
            log_metric('agent_token_cost', cost, {'model': model, 'session': session_id})

    Common Observability Pitfalls

    Pitfall 1: Logging Everything Without Filtering

    Problem: Logging full prompt and response bodies creates massive data volumes and risks exposing sensitive information.

    Solution: Implement selective logging with sanitization:

  • Log metadata (token counts, timestamps, error codes) by default
  • Log full content only at DEBUG level or for specific error cases
  • Always sanitize PII before logging
  • Pitfall 2: Ignoring Cost Metrics

    Problem: Teams focus on functionality metrics while costs spiral. A single misconfigured agent can burn through budget before anyone notices.

    Solution: Set up cost alerts at multiple levels:

  • Per-session cost limits
  • Hourly/daily spend thresholds
  • Model-specific budget allocation
  • Pitfall 3: No Baseline Comparison

    Problem: Metrics without context are just numbers. A 5% increase in latency means nothing without knowing if that’s normal.

    Solution: Establish baselines during stable periods and compare current metrics against them:

  • Week-over-week comparisons
  • Time-of-day normalization
  • Seasonal adjustment for predictable traffic patterns
  • Building an Observability Dashboard

    A good observability dashboard gives you answers in seconds, not minutes. Here’s what to include:

    Top section: Health Overview

  • Total sessions in the last hour
  • Error rate (current vs. baseline)
  • Average latency P50/P95/P99
  • Current cost rate ($/hour)
  • Middle section: Detailed Metrics

  • Token usage by model over time
  • Tool call success/failure rates
  • Session duration distribution
  • Error breakdown by type
  • Bottom section: Live Activity

  • Recent agent sessions (last 10)
  • Active errors with context
  • Cost accumulator by session
  • Tools for dashboarding:

  • **Grafana**: Connect to Prometheus or CloudWatch for custom dashboards
  • **Langfuse UI**: Purpose-built for LLM observability
  • **Kibana**: If using Elasticsearch for log storage
  • **CloudWatch Console**: For AWS-native setups
  • Case Study: Reducing Debug Time by 80%

    A production AI support agent had recurring issues with order lookup failures. Before observability:

  • **Debug time**: 4-6 hours per incident
  • **User impact**: Unable to resolve tickets for 2+ hours
  • **Cost**: Estimated $500/hour in support overhead
  • After implementing structured logging and tracing:

    1. **Identified the root cause** in 15 minutes: A specific tool was returning malformed JSON 12% of the time
    2. **Set up automated alerts** for tool failures
    3. **Created session replay** capability to reproduce issues
    4. **Reduced mean time to resolution** from 4 hours to 15 minutes

    The observability investment paid for itself in the first week.

    FAQ

    Q1: How do I trace requests across multiple services?

    Use distributed tracing with OpenTelemetry. Set a trace ID at the entry point and propagate it through all service calls. Most observability platforms automatically correlate traces across services if they’re instrumented with the same standard.

    Q2: What’s the minimum observability setup for a small team?

    Start with structured logging (JSON format) and basic metrics (token counts, error rates, latency). Use a managed service like Langfuse or Logtail if you don’t want to maintain infrastructure. This gives you 80% of the value with 20% of the effort.

    Q3: How do I handle PII in logs and traces?

    Implement a sanitization layer that:

  • Detects PII patterns (email, phone, credit card, etc.)
  • Hashes or masks detected values
  • Runs asynchronously to avoid blocking the agent loop
  • Allows you to toggle sanitization based on environment (strict in production, detailed in staging)
  • Q4: Should I log the full conversation or just summaries?

    Log summaries by default (first 500 chars of each turn). Enable full logging only for:

  • Sessions marked for debugging
  • Error cases
  • High-value interactions (e.g., sales conversions)
  • This balances visibility with storage costs.

    Q5: How do I detect when an agent is “going off track”?

    Implement behavioral monitoring:

  • Track tool call sequences for unusual patterns
  • Monitor token usage per step (sudden spikes indicate loops)
  • Set up semantic similarity checks to detect topic drift
  • Compare current behavior against trained baseline patterns
  • Q6: What’s the difference between monitoring and observability?

    Monitoring tells you when something is broken (alerts on thresholds). Observability helps you understand why it’s broken (tracing, structured logs, metrics correlation). You need both for production reliability.

    Next Steps

    Observability isn’t a one-time setup—it’s an ongoing practice. Start with the basics:

    1. **Week 1**: Implement structured logging for all agent interactions
    2. **Week 2**: Add cost tracking and basic metrics
    3. **Week 3**: Set up distributed tracing for critical paths
    4. **Week 4**: Build your first dashboard and alert rules
    5. **Ongoing**: Refine based on incident patterns and team feedback

    The goal isn’t perfect observability—it’s the ability to answer “what happened?” when your agent misbehaves at 2 AM.

    Ready to make your agents more reliable? Visit [SmaugBrain](https://www.smaugbrain.com/) to explore production-ready AI agent frameworks with built-in observability.