From HAR to OpenTelemetry Trace: Redefining Observability Architecture

Introduction

In the realm of modern observability, the ability to trace and analyze distributed systems is critical for debugging and performance optimization. Traditional tools like HAR (HTTP Archive) provide granular insights into web interactions, but they lack the standardized, scalable framework required for complex microservices environments. This article explores how integrating HAR data with OpenTelemetry transforms observability, enabling seamless trace generation, processing, and streaming within the CNCF ecosystem.

Core Concepts

HAR (HTTP Archive)

HAR is a format that captures detailed HTTP request/response data, including resource downloads and timing metrics. While useful for debugging, its unstructured nature limits its utility in modern observability pipelines.

OpenTelemetry

OpenTelemetry is an open-source observability framework that standardizes trace, metric, and log data through semantic conventions. It provides a unified API for instrumenting applications, making it ideal for cross-service tracing and centralized monitoring.

Thousand Eyes

Thousand Eyes is a network monitoring tool that generates HAR data by simulating user interactions. Its integration with OpenTelemetry enables the transformation of HAR into structured traces, bridging legacy data formats with modern observability practices.

Conversion Workflow

HAR Data Parsing

Each HTTP request in HAR is mapped to an OpenTelemetry Span, with attributes such as:

  • Name: Method + Target (e.g., GET /api/v1/data)
  • Type: Client
  • Timestamps: Start/End time
  • Status Code: Marked as error for failed requests
  • Trace/Span IDs: Automatically generated
  • Semantic Attributes: HTTP method, host, target, status code, and port

Security Considerations: Sensitive headers (e.g., cookies, authorization tokens) are excluded to mitigate data leakage risks.

Resource Attributes

Metadata about the telemetry source is recorded, including:

  • Thousand Eyes account details
  • Test name, type, and ID
  • Agent ID and allocation
  • Permanent link to the Thousand Eyes issue view

Architecture Design

Data Flow Pipeline

  1. Kafka: Acts as the ingestion layer, receiving HAR data from agents.
  2. Collector (Phase 1):
    • Filter: Discards non-essential telemetry data.
    • Processor: Enriches data with agent location and test metadata.
    • Export: Routes data to the Integrations Collector.
  3. Integrations Collector:
    • Processor: Duplicates traces and adds integration-specific attributes.
    • Routing: Directs traces to observability backends (e.g., Jaeger, Grafana) based on integration IDs.
  4. Observability Backend: Receives and visualizes traces for analysis.

Dual Collector Design

  • Trace Collector: Scales horizontally to handle high-volume trace data.
  • Integrations Collector: Manages integration-specific routing and redundancy, supporting multiple backends.

Implementation Demonstration

Test Case Setup

A Thousand Eyes page load test is configured to monitor cisco.com, generating HAR data.

Data Flow

  1. HAR data is exported to an OpenTelemetry integration.
  2. Data is streamed via Kafka to the Collector, where it is converted into traces.
  3. Traces are visualized in Jaeger, with each HTTP request represented as a Span.

Key Observations

  • Problem Identification: Traces reveal issues like failed resource loads or slow endpoints.
  • Performance Analysis: Comparative trace timing (e.g., 7s vs. 5s) highlights variations in request volume and latency.

Technical Considerations

Semantic Conventions

Standardized attributes ensure consistency across traces, enhancing queryability and visualization.

Performance Optimization

  • Parallel Processing: Reduces latency in trace conversion.
  • Dynamic Routing: Adjusts backend selection based on workload and integration requirements.

Scalability

  • Decoupled Collectors: Enables independent scaling of trace processing and integration routing.
  • Multi-Backend Support: Facilitates compatibility with diverse observability tools (e.g., Jaeger, Grafana).

Conclusion

The integration of HAR data with OpenTelemetry redefines observability by transforming unstructured logs into standardized traces. This approach leverages the CNCF ecosystem’s strengths in streaming, processing, and distributed tracing, offering a scalable solution for modern applications. By adopting semantic conventions and a dual-collector architecture, organizations can achieve robust, secure, and extensible observability pipelines. For teams transitioning from legacy tools, this framework provides a clear path to modernize their monitoring strategies while maintaining compatibility with existing workflows.