我为本地开发构建了一个轻量级的 OpenTelemetry 查看器

Source: Dev.to

问题

每次我想在本地测试 OpenTelemetry 插装时，都必须启动 Jaeger 或完整的 collector 堆栈。docker‑compose up，等待，配置导出器，祈祷端口 4317 不冲突……这对于一次“我的追踪是否正确？”的检查来说显得仪式感太重。

于是我构建了 otel‑front：一个接收 OTLP 数据并在 Web UI 中展示的单一二进制文件。无需 Docker、外部数据库，也不需要配置文件。

brew tap mesaglio/otel-front
brew install mesaglio/otel-front/otel-front
otel-front          # → opens http://localhost:8000

将你的应用指向 localhost:4318（HTTP）或 localhost:4317（gRPC），就完成了。

它的功能

• Traces – 瀑布视图、火焰图、并排追踪比较、按操作或 trace ID 搜索
• Logs – 全文搜索、严重性/服务过滤、通过 trace_id 与追踪关联
• Metrics – 查询构建器、时间序列图表、聚合（avg、sum、min、max、count）

Traces

并排比较 用于在两次运行之间发现回归：

通过 trace_id 关联的日志 可直接在追踪视图中查看：

Logs

Metrics

构建方式

约束： 单二进制文件，无外部依赖。

Go + 嵌入式前端

后端使用 Go（Gin）。React 前端使用 Vite 构建后，直接通过 Go 的 embed.FS 嵌入到二进制文件中：

//go:embed static/*
var staticFiles embed.FS

一次 go build，生成一个提供全部功能的二进制文件。

DuckDB 作为内存存储

我需要 SQL（用于灵活的过滤和聚合），但不想随应用一起分发数据库。DuckDB 完全在进程内运行，无需任何设置，并且对分析查询支持良好。

所有 Span、日志和指标都存入 DuckDB 表中，属性使用 JSON 列，例如：

CREATE TABLE spans (
    trace_id               TEXT,
    span_id                TEXT,
    name                   TEXT,
    start_time_unix_nano   BIGINT,
    end_time_unix_nano     BIGINT,
    attributes             JSON,
    ...
);

我没有从头编写 protobuf 解析器，而是复用了 OpenTelemetry Collector 的 pdata 库。它负责反序列化，我只需把结果转换为内部模型即可。

快速开始

Homebrew

brew tap mesaglio/otel-front
brew install otel-front
otel-front

Docker

docker run -p 8000:8000 -p 4317:4317 -p 4318:4318 \
  ghcr.io/mesaglio/otel-front:latest

二进制（macOS / Linux，x86_64 & ARM64）

下载自最新发布。

配置您的应用：

export OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4318"
export OTEL_EXPORTER_OTLP_PROTOCOL="http/protobuf"
export OTEL_LOGS_EXPORTER="otlp"
export OTEL_TRACES_EXPORTER="otlp"
export OTEL_METRICS_EXPORTER="otlp"

UI 包含一个…（继续您的其余内容）。

# Copy‑paste helper for these env vars

Source

GitHub: mesaglio/otel-front

PRs and feedback welcome. If you’re working with OpenTelemetry locally and find it useful (or broken), let me know in the comments.

PRs 和反馈欢迎。如果你在本地使用 OpenTelemetry 并觉得它有用（或出现问题），请在评论中告诉我。