Dozzle 匿名统计机制全解：Beacon 字段、数据流向与隐私关闭方案

Dozzle 匿名统计机制全解：Beacon 字段、数据流向与隐私关闭方案

【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzle

Dozzle 作为一款面向容器的实时日志查看器，通过一个轻量级信标（beacon）采集匿名使用数据，用于帮助这个没有资金支持的开源项目确定功能与修复的优先级。本文将结合 types/beacon.go、internal/analytics/http_beacon.go 与 internal/support/cli/analytics.go 等源码，逐一拆解 Beacon 事件的字段含义、发送时机、数据存储方式，并给出--no-analytics/DOZZLE_NO_ANALYTICS的完整关闭方案，帮助你精确掌控 Dozzle 实例对外上报了哪些信息。

为什么 Dozzle 要采集统计数据

Dozzle 是一个没有商业资金支持的开源项目，开发者需要在有限的精力下决定"下一个功能做什么、哪个 Bug 最值得先修"。匿名使用数据因此成为确定投入方向的主要依据——例如部署模式占比、Docker Engine 版本分布、认证方式的启用情况等，都直接影响功能设计的取舍。

这一点在官方文档中表述得很直白：数据用于"确定功能和修复的优先级"。从实现层面看，采集通过 HTTP 信标完成，设计上刻意保持轻量——不依赖任何重型 SDK，只发一次简单的 JSON POST 请求。

Beacon 事件到底采集了哪些字段

信标事件的数据结构定义在 types/beacon.go 的BeaconEvent结构体中，当前版本包含以下字段：

概括而言，信标携带的是环境与配置的"指纹"：版本、部署模式、认证方式、少量功能开关、Docker Engine 版本，以及主机数、容器数、过滤器数等数量统计，外加一个用于去重的随机安装 ID。

字段的实际填充逻辑

不同事件类型填充的字段有所不同：

• 启动事件：由 internal/support/cli/analytics.go 的StartEvent构造，会填充Mode、RemoteAgents、RemoteClients、SubCommand、HasActions、HasShell、HasCustomAddress、HasCustomBase、HasHostname、FilterLength，并读取容器客户端的ServerID、ServerVersion、IsSwarmMode。注意其中多个布尔字段是通过与默认值比较得到的，例如args.Addr != ":8080"、args.Base != "/"、args.Hostname != ""——即只上报"是否偏离默认配置"，而非上报具体的自定义值。
• 事件流事件：由 internal/web/events.go 的sendBeaconEvent构造（约第 302 行），当客户端连接到事件流、容器列表就绪后，以go sendBeaconEvent(h, r, len(allContainers))的方式异步发送（约第 172 行），不阻塞主请求链路。该事件会填充AuthProvider、Browser（取请求头User-Agent）、Clients、RunningContainers等字段。

明确的隐私边界：什么永远不会被采集

官方文档明确承诺，以下内容绝不发送：

• 日志内容
• 容器名称
• 镜像名称
• IP 地址
• 用户标识

对照 types/beacon.go 的结构体定义可以印证：全部字段中没有一个是字符串形式的名称或标识，ServerID是随机的安装级 ID，而非主机名或 IP。Browser字段虽然携带 User-Agent，但这也是浏览器通用信息，不构成用户标识。

数据流向：信标发到哪里、如何存储

信标的发送逻辑集中在 internal/analytics/http_beacon.go 的SendBeacon函数：

1. 将BeaconEvent结构体json.Marshal序列化；
2. 构造POST https://b.dozzle.dev/event请求；
3. 通过http.DefaultClient发送；
4. 若返回状态码非 2xx，记录 Debug 日志并返回错误（不影响 Dozzle 主流程）。

官方文档说明，b.dozzle.dev是一个小型 Go 服务，事件会被写入托管在 DigitalOcean 上的平面文件（flat file），供后续离线处理——这是一种极简的采集架构，与信标本身的轻量定位一致。

值得注意的两点实现细节：

• 发送全程使用log.Trace()/log.Debug()级别记录，默认日志级别（info）下不会在日志中刷屏；
• 信标发送失败仅记录日志，不会导致 Dozzle 启动失败或事件流中断，属于完全旁路的非侵入式设计。

如何关闭匿名统计

关闭后不会发出任何信标请求。有两种等价方式，由 internal/support/cli/args.go 中的参数定义支撑：

• 命令行标志：--no-analytics
• 环境变量：DOZZLE_NO_ANALYTICS=true

二者的对应关系也记录在 docs/zh/guide/supported-env-vars.md 的全局配置表中，默认值为false。

在启动路径上，main.go 会将args.NoAnalytics透传到handler配置（见 internal/web/routes.go 的NoAnalytics字段）；internal/support/cli/analytics.go 的StartEvent和 internal/web/events.go 的sendBeaconEvent都会在第一时间检查该开关并直接返回，从源头杜绝信标请求。

Docker Compose 关闭示例

官方文档给出了 Docker Compose 的关闭配置：

services: dozzle: image: amir20/dozzle:latest environment: DOZZLE_NO_ANALYTICS: "true"

仓库自带的 docker-compose.yml 也在各示例服务中统一使用了DOZZLE_NO_ANALYTICS=1，与上述配置方式一致。

Docker CLI 关闭示例

对于不使用 Compose 的场景，等价写法为：

docker run --name dozzle -d --volume=/var/run/docker.sock:/var/run/docker.sock \ -e DOZZLE_NO_ANALYTICS=true \ -p 8080:8080 \ amir20/dozzle:latest

或使用命令行标志：

docker run --name dozzle -d --volume=/var/run/docker.sock:/var/run/docker.sock \ --no-analytics \ -p 8080:8080 \ amir20/dozzle:latest

字段演进与权威依据

官方文档特别强调：具体字段会随时间变化。因此若需确认真实事件结构，应以当前仓库的 types/beacon.go 为权威依据；发送逻辑与重试/失败处理则以 internal/analytics/http_beacon.go 为准；两个实际构造事件的位置分别在 internal/support/cli/analytics.go（启动事件）与 internal/web/events.go（事件流事件）。

这套"结构体定义 + 发送函数 + 两个构造点"的职责划分，使统计数据的采集范围完全对开发者透明——任何新增字段都能在源码中直接追踪到其来源与用途。

【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzle