Dozzle 匿名统计机制全解Beacon 字段、数据流向与隐私关闭方案【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzleDozzle 作为一款面向容器的实时日志查看器通过一个轻量级信标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结构体中当前版本包含以下字段字段JSON 键含义Namename事件类型如start启动、events客户端建立事件流VersionversionDozzle 自身版本号Browserbrowser发起请求的User-Agent用于了解客户端浏览器分布AuthProviderauthProvider启用的认证方式none、simple、github、oidc、proxy 等FilterLengthfilterLength配置的过滤器数量Clientsclients主机数量HasCustomAddresshasCustomAddress是否自定义了监听地址非默认的:8080HasCustomBasehasCustomBase是否设置了非/的 Base 路径HasHostnamehasHostname是否配置了自定义主机名RunningContainersrunningContainers运行中的容器数量HasActionshasActions是否启用了容器操作功能--enable-actionsHasShellhasShell是否启用了 Shell 功能--enable-shellIsSwarmModeisSwarmMode是否运行在 Swarm 模式ServerVersionserverVersionDocker Engine 版本号ServerIDserverID随机生成的安装 ID用于去重Modemode部署模式server、swarm、k8s、agentRemoteAgentsremoteAgents配置的远程 agent 数量RemoteClientsremoteClients配置的远程主机数量SubCommandsubCommand启动时使用的子命令概括而言信标携带的是环境与配置的指纹版本、部署模式、认证方式、少量功能开关、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函数将BeaconEvent结构体json.Marshal序列化构造POST https://b.dozzle.dev/event请求通过http.DefaultClient发送若返回状态码非 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_ANALYTICStrue二者的对应关系也记录在 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_ANALYTICS1与上述配置方式一致。Docker CLI 关闭示例对于不使用 Compose 的场景等价写法为docker run --name dozzle -d --volume/var/run/docker.sock:/var/run/docker.sock \ -e DOZZLE_NO_ANALYTICStrue \ -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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考