Docker 日志分析工具调研

在容器化已经变成“默认选项”的今天，Docker 的日志到底记到哪、集中到哪、在哪个平台里分析和告警，已经不只是“运维细节”，而是整套观测性方案里的基础设施问题。说是 Docker，其实更准确来说应该是应用部署的生产环境。

这篇文章打算聚焦在： 围绕 Docker，日志分析平台/工具到底怎么选？

这里挑两条常见路线对比着看：

Sentry： 偏“应用侧”的错误与日志分析平台
EFK（Elasticsearch + Fluentd + Kibana）： 偏“基础设施侧”的日志集中与搜索平台

Sentry：偏“应用侧”的日志 & 错误分析平台

从“Docker 日志平台”的视角看，Sentry 更像是：

贴着代码和请求栈的错误、事件分析平台，顺带承载了一部分日志能力，而不是一个“什么日志都往里倒”的通用日志池。

作为 Docker 日志平台时，它的优势

接入方式贴近应用，而不是贴近容器

支持主流语言和框架（Node、Python、Java、前端等），有现成 SDK。一旦接入：
- 异常、
- 请求上下文、
- Stack Trace、
- 用户信息、Release 版本
都能打包送进 Sentry。

对跑在 Docker 里的服务来说，只要镜像里是那套应用代码，Sentry 的接入和“是不是 Docker”没太大关系，反而更取决于你愿不愿意在代码里加埋点。
围绕“问题”和“Issue”而不是围绕“日志行”

这点和传统“日志平台”非常不一样：
- 自动聚合同一类错误为一个 Issue
- 可以按 Release/版本看错误趋势
- 支持告警、通知、分配给某个开发者处理
换句话说：

打开 Sentry，你看到的不是“某容器某天的 20 万行日志”，而是 “有哪些错误在持续发生，需要谁去修”。

这对 Docker 场景里的开发者而言，非常适合作为“应用错误视角的日志入口”。

作为 Docker 日志平台时，它的局限

对已有 Docker 日志体系不够“即插即用”

如果你现在已经有一堆跑在 Docker 上的服务，只是老老实实往 stdout/stderr 打日志，那：
- 想切到 Sentry，就得去改应用、加 SDK、重新发布；
- 对历史容器、黑箱应用、第三方镜像，改动成本往往不小。
所以它对“已有海量 Docker 服务，只想先集中日志”的场景并不友好。
自建 + 网络环境的成本
- 自建 Sentry：要准备数据库、存储和运维；
- 用官方 SaaS：服务器在国外，在国内环境里不可避免有网络和合规方面的顾虑。
作为通用日志平台时不够“全量”

Sentry 天生是为“异常/事件”设计的，不太适合当作“把所有 Docker 容器的原始日志全往里倒”的平台—— 日志量一大，成本和信噪比都很难看。

换个角度总结： Sentry 更像是“贴着 Docker 容器里那层应用代码的错误雷达”，不是那个装全站日志的“大池子”。

EFK：偏“基础设施侧”的 Docker 日志集中与分析平台

如果从“Docker 日志平台”的角度来设计系统，EFK 走的是另一条路：

先把所有容器的 stdout/stderr 日志通通收上来，统一进一个搜索与分析平台。

典型的 Docker Compose 形态大概是这样（略去细节）：

version: "3"

services:
  fluentd:
    build: ./fluentd
    links:
      - elasticsearch
    depends_on:
      - elasticsearch
    ports:
      - 24224:24224
      - 24224:24224/udp

  elasticsearch:
    image: elasticsearch:7.17.0
    container_name: elasticsearch
    environment:
      - "discovery.type=single-node"
    expose:
      - 9200
    volumes:
      - esdata:/usr/share/elasticsearch/data

  kibana:
    image: kibana:7.17.0
    links:
      - elasticsearch
    depends_on:
      - elasticsearch
    ports:
      - 5601:5601
    environment:
      - ELASTICSEARCH_HOSTS=http://elasticsearch:9200

volumes:
  esdata:

作为 Docker 日志平台时，它的优势

贴着 Docker 的日志管道设计

Docker 原生支持将容器日志驱动配置为 Fluentd，已有 stdout/stderr 日志几乎可以零侵入接入；

所以对“已经有一堆容器在跑，只是想把日志集中起来”的团队而言，

EFK 非常像一个“把日志往里一接，立刻就能搜”的通用平台。
完全自控的日志基础设施

三个组件都是开源，部署在自己的机房或云环境，不涉及跨境传输，也不依赖境外 SaaS。

对需要控制数据落地位置、保留周期、索引策略的团队来说，这更像是 “自家的日志数据湖”。
生态成熟，可扩展到“平台级”
- Fluentd/Fluent Bit 插件丰富：可以从 Docker 收一份日志，再按需转发到对象存储、消息队列、其他监控系统；
- Elasticsearch 支持结构化/半结构化数据检索；
- Kibana 可以做仪表盘、趋势分析、聚合视图。
这让 EFK 很适合作为 “公司级 Docker 日志平台的底座”。

作为 Docker 日志平台时，它的短板

默认只是“超级日志查看器”，不帮你“盯错误”

EFK 在原生形态下主要解决：
- 日志集中
- 检索、过滤、聚合
- 简单可视化
但某个容器挂了你得被提醒、错误要进入 Issue 流程这些事情，需额外接：

Alertmanager / ElastAlert / 自己写告警逻辑，以及与工单/Issue 系统的集成
使用门槛与维护成本

Kibana 功能很全，但对初学者来说不够直接友好，搭索引策略、冷热数据、集群扩容，都是长期运维话题，对只想“快速看某个服务最近 200 行日志”的人来说，体验可能不如某些轻量级 SaaS。
偏“日志数据视角”，不提供“错误生命周期管理”

例如：
- 不管理 Issue 生命周期
- 不关心 Release/回滚
- 不直接关联到“哪个开发者来修”
所以它更像是一层底座，上面你可以堆告警、APM、错误管理等其他平台。

一句话总结： EFK 是一个偏基础设施的 Docker 日志平台，擅长“把所有容器的日志集中、存好、搜得到”。

从“Docker 日志分析平台”的视角怎么选？

如果把问题明确成：

「我现在需要的是一套 围绕 Docker 的日志分析平台/工具，应该从哪边入手？」

可以按下面几个角度想一想。

你是先要“看得见日志”，还是“看得见问题”？

如果你现在最大的问题是： 线上出错没人发现、问题来了没人提醒、错误趋势完全看不到，那就更偏向：Sentry，这种诉求更像是“应用错误监控平台”，日志只是支撑材料。
如果你现在最大的问题是： 容器一多，日志散得到处都是，想找一段调用链日志非常痛苦，那就更偏向：EFK，你的诉求更像是“Docker 日志集中与检索平台”。

你手里是新项目，还是庞大的遗留 Docker 集群？

新项目，代码可改、埋点没压力

可以优先接入 Sentry，让每个容器里的应用“自己说话”。

有大量遗留服务，改代码成本很高

先上 EFK，把所有 Docker 日志汇总起来，立刻提升排障效率更现实。

通常最终会演化成： 先搭一个 EFK 日志底座 → 对关键服务逐步接入 Sentry 做应用级错误监控。

对网络、合规和数据控制的要求

数据不能随便出境，或者访问国外 SaaS 不稳定

更适合：自建 EFK， Sentry 如需自建，门槛和运维成本更高。
更看重省心 & 交付速度

直接上 Sentry SaaS，几行代码接入后马上能看到效果，后面再考虑是否需要自建日志平台托底。

小结

在 Docker 世界里，两者更像“搭档”而不是“谁替代谁”，从“Docker 日志分析平台/工具”的视角来看的话，可以这样理解：

EFK：

是 容器日志基础设施，类似一个“公司级日志中枢”，负责：把所有容器的日志集中、可查、可分析。

Sentry：

是 应用错误与事件中心，负责：识别问题、聚合 Issue、跟踪到 Release 和代码。

在实际工程里，一个比较健康的组合是：

用 EFK 搭 Docker 日志平台：

接管所有容器的 stdout/stderr，作为底层“日志池”和排障工具。

对关键服务接入 Sentry：

让关键应用在出错时主动“喊出来”，给开发者提供贴近代码视角的错误分析和告警。

这样，你既有一套“基础设施级的 Docker 日志平台”，又有一套“应用视角的错误分析工具”，两者叠起来，才算是真正把“Docker 日志分析”这件事做完整。