Docker 扩展将 Docker Desktop 的功能拓展到了本地开发环境之外。只需要简单的配置，开发人员就可以安装相关工具，然后直接在工作流中查看日志、指标和追踪信息。这种即时可视化不仅缩短了调试周期，还能帮助开发人员在开发过程中更好地理解容器的行为。
然而，一键式可观测性的便捷性背后可能隐藏着更大的挑战。在开发人员的笔记本电脑上运行良好的方案，并不一定能直接转化为企业级可观测性。随着企业容器化工作负载的规模不断增加，必须解决安全、合规、成本管理以及与现有监控平台集成等多个方面的问题。
可见性差距
Docker 扩展旨在提升开发人员的工作效率。它们能够快速访问遥测数据，并提供直观的界面来检查容器行为。
然而，企业可观测性需要集中式可视化、历史日志和保留机制，以及跨分布式系统的连接能力。
开发环境中生成的遥测数据往往处于孤立状态。在生产环境发生故障时，运维团队可能会发现，保存在本地的详细日志或跟踪信息从未导出到集中式监控平台。
仪表板可能仅存在于单台机器上，而跟踪数据可能缺乏事件调查所需的保留策略。
虽然遥测数据确实存在，但由于未集成到企业可观测性管道中，所以在规模化场景下无法使用或不被信赖。
为什么可观测性对企业很重要
企业级可观测性不局限于查看日志和指标。企业必须确保遥测数据符合公司需求。可观测性数据通常包含敏感信息，例如身份信息、API 令牌以及请求有效负载的部分内容。在许多企业环境中，由于加密不彻底或访问控制不足，曾经有过遥测管道无意中泄露这类数据的情况，这表明可观测性工具会扩大攻击面。告警、事件响应和根因分析依赖于跨服务的历史数据和关联数据，仅凭本地仪表板无法提供这些功能。
组织需要遵守《支付卡行业数据安全标准》（PCI-DSS）、《萨班斯-奥克斯利法案》（SOX）和《通用数据保护条例》（GDPR）等法规所制定的指导方针。这些法规要求对敏感数据进行屏蔽处理、确保遥测管道可审计，并制定受控的保留政策。如果团队能够主动解决这些问题，而不是等到审计时被发现，便可以帮助组织节省宝贵的时间和资金。
架构上的转变
不应该只把 Docker 扩展视为可视化工具，而应该把它看成是进入企业遥测管道的入口。
扩展可作为遥测桥接器，从容器中收集信号并将其转发至标准的可观测性工作流。在这个架构中，OpenTelemetry Collector 发挥着核心作用，负责接收遥测数据、丰富元数据、执行策略，并将数据导出至多个后端。
此外，通过将“策略即代码”直接嵌入到遥测管道中，就可以在不同的环境中实现一致的屏蔽、采样和路由处理，而不需要各团队再手动处理。结合传输层安全（TLS）或证书验证等传输安全措施，即使遥测数据离开本地系统，也能确保其安全。
这样做的好处是，开发人员不需要大幅改变工作方式。治理和企业集成层是以现有管道为基础构建的，而不是取代现有的工作流。
企业级可观测性扩展的设计原则
以下是实施该架构模型时应遵循的一些最佳实践或设计原则：
通过 OpenTelemetry 标准化遥测数据，实现可观测性平台之间的互操作性，并降低供应商锁定的风险。
在管道早期阶段引入策略执行机制，通过屏蔽敏感属性，避免下游的合规性和成本挑战。
在早期阶段引入加密、证书验证和访问控制等安全机制，帮助人们建立对遥测数据的信任，使其成为运营资产而非单纯的调试工具。
与现有的可观测性平台集成，通过扩展功能来补充当前使用的工作流，并加速跨团队的采用。
为了了解这种方法在端到端流程中的实际运作方式，让我们看看遥测数据是如何在系统中流动的。这一过程始于扩展组件，它们会收集容器日志和指标，并将这些数据传递给一条管道，由它负责数据增强、策略执行以及将数据安全地传输至企业后端。
下图展示了该插件在开发人员笔记本电脑上的常规工作方式与遥测桥接模型的对比。在这个模型中，开发人员的工作流可以接入各种可观测性平台。
图 1：本地开发插件可在 Docker Desktop 中提供即时可见性，但遥测数据仍然局限于开发人员的笔记本电脑——既未导出至企业平台，也无数据保留策略，更缺乏相应的治理控制措施。
图 2：企业遥测网关通过 OpenTelemetry Collector 转发容器信号，在将数据导出至 Splunk、Datadog 和 Loki 等多个后端可观测性平台之前，实施“策略即代码”、身份控制和传输安全措施。
设计企业级 Docker 扩展
让我们以 OBSBridge 为例来说明下这些概念。OBSBridge 是我们假设的一个扩展，旨在将本地 Docker 环境与企业级可观测性后端连接起来。
OpenTelemetry 收集器配置
收集器充当容器与可观测性后端之间的中介，在遥测管道中提供一个策略执行点。以下是一个配置示例：
# otel-collector/config.yamlreceivers: otlp: protocols: grpc: http:processors: batch: attributes: actions: - key: user_id action: delete - key: credit_card action: delete memory_limiter: check_interval: 1s limit_mib: 512exporters: loki: endpoint: http://grafana-loki.default:3100 prometheus: endpoint: "0.0.0.0:9090" otlp: endpoint: "splunk.example.com:4317" tls: ca_file: /certs/ca.pemservice: pipelines: logs: receivers: [otlp] processors: [attributes, batch] exporters: [loki, otlp] metrics: receivers: [otlp] processors: [batch] exporters: [prometheus]该配置允许该扩展程序接收遥测数据、移除敏感属性，并将经过标准化处理的信号转发至多个后端。
利用“策略即代码”实现合规
可观测性策略可以作为受版本控制的工件进行存储，其中定义了屏蔽和采样规则。
以下是一个包含采样规则的配置：
# policy.yamlmasking: - field: user.email pattern: '(.+)@(.+)' replace: '***@\\2' - field: card_number pattern: '\\d{16}' replace: '**** **** **** ****'sampling: traces: 25 # sample 25% of traces logs: 50 # sample 50% of logs把这类策略存储在 Git 中，既能确保可审计，又能实现跨环境的一致性保证。
当遥测数据经过标准化处理并通过扩展程序导出后，团队便能将应用程序信号（如请求量）与基础设施指标（如 CPU 使用率）关联起来。通常，这种可见性的共享能缩短事件发生时的根本原因调查时间，因为团队不再依赖分散的本地仪表板。
连接到现有的平台，如 Splunk 或 Datadog
使用 SaaS 可观测性平台的组织可以通过 OTLP 或 HTTP 导出器集成这些扩展程序。团队可以使用 Docker Secrets 进行凭据管理，并通过环境变量将其外部化。
最佳运营实践
构建可观测性扩展只是第一步。真正的挑战在于如何运行它，使其在长期使用的时候仍然可靠并且实用。
团队通常会发现，遥测管道需要被看成是真正的系统，而非后台工具。日志和指标在仪表板上看似简单，但在到达目的地之前，它们需要经过多个组件的处理。如果其中一个组件发生故障，可能就会有重要的信号悄无声息地消失。因此，许多团队将屏蔽和采样规则保存在受版本控制的文件中，以便能像常规代码一样对变更进行审查和追踪。
另一个挑战在于可观测性系统生成的海量数据。容器能够以极快的速度产生大量的日志和追踪信息。永久存储所有数据不仅成本高，还会导致仪表板难以解读。为了解决这一问题，团队通常会对数据进行采样或分组，保留有用的信号，同时避免系统过载。
随着环境的扩展，可靠性也变得至关重要。在小型部署中，单个收集器可能就足以胜任这项工作，但在大型系统中，通常需要运行多个收集器，这样即使个别组件发生故障，遥测数据也能持续传输。
最后，对可观测性系统进行监控非常有帮助。简单的健康信号可以显示遥测管道的运行是否符合预期，从而及早发现问题，并保持对监控工具的信心。
随着时间的推移，可观测性逐渐成为开发、安全和运维团队共同的责任。当所有人都依赖相同的遥测信号时，问题诊断会更加迅速，协作也会更加顺畅。
小结
Docker 扩展功能让开发人员在日常工作流程中可以更轻松地获得可观测性。然而，企业环境需要的不仅仅是本地仪表板和可以快速获取的调试洞察。一旦遥测数据需要从笔记本电脑传输到企业后端，就必须确保其安全性、受到有效管理，并与组织现有的监控平台进行集成。
经过精心设计的扩展程序，能够兼顾开发人员的便利性与企业的运维可见性。OpenTelemetry 等标准有助于在不同工具、团队和环境之间可靠地传输遥测数据。而屏蔽、采样和加密等策略控制措施，则有助于确保遥测数据的安全性和合规性。可观测性或许始于一台笔记本电脑，但其可靠性取决于遥测数据如何在更广泛的范围内进行传输。
声明：本文为 InfoQ 翻译，未经许可禁止转载。
原文链接：https://www.infoq.com/articles/enterprise-grade-observability-extension-docker/
