微服务日志采集实战：Fluent Bit 开箱即用方案全解析

做微服务时间一长大家都会遇到同一个魔幻场景服务有几十上百个日志散落在不同的主机、不同的目录、不同的 Pod 里线上一报警排查的人要先打开四五个终端挨个登录、grep、tail运气不好还要等日志文件轮转之后去翻压缩包。我最初接手这套系统时光是搞清楚每个服务到底把日志写在哪就花了两天。后来把日志采集切换到 Fluent-Bit整套链路从零到跑通差不多只用了半天。这篇内容就是把我在微服务日志采集实战中沉淀下来的 Fluent-Bit 开箱即用方案完整写出来里面有配置、部署、调优、排障也有不少我在实际项目中踩过的坑目标是让正在折腾微服务日志的同学可以直接参照落地不用再从一堆官网文档里拼方案。这篇内容适合几类人准备给自己的微服务体系搭日志采集但还没想好用哪个组件的已经在用 Fluent-Bit但只会最基础的 tail 到 stdout遇到多行堆栈、离线部署、日志乱序不知道怎么办的以及想在 K8s、ARM 国产化环境、云上迁移这些场景里把日志采集链路做得更稳的。下面我按自己的实战顺序从选型、架构、配置、部署到排障一条线讲清楚。1. 为什么微服务日志采集我最后选了 Fluent Bit1.1 微服务日志到底难在哪很多人一开始觉得日志采集很简单不就是读文件转发出去嘛。真上了微服务之后才发现事情没那么简单。第一个痛点是日志没有统一入口。同一个系统里有的服务跑在容器里stdout 被容器引擎接管有的服务还是传统部署自己写文件还有的服务走日志框架直接落到磁盘。如果不做统一采集排查一次跨服务调用得按调用链依次去翻不同位置的日志效率极低。第二个痛点是格式五花八门。有的服务打的是普通 text一行一条有的是 JSON字段还各不相同异常堆栈偏偏又是多行的Java 一个 OOM 堆栈恨不得打印二十行。采集器如果只是简单按行读堆栈会被拆得稀碎后面做检索时根本没法看。第三个痛点是峰值流量。平时日志量不大一到秒杀、促销或者压测服务日志瞬间暴涨。我见过有团队用 Logstash 采集压测刚跑起来采集器先把自己内存吃满了结果业务没挂日志组件先挂了。这四个字概括一下就是分散、多格式、高峰值、易丢失。选日志采集组件本质上就是在跟这四件事做对抗。1.2 Fluent Bit 和几个主流采集器怎么选现在市面上的采集器不少主流的无非是 Fluent Bit、Fluentd、Filebeat、Logstash。我直接说结论再解释原因。采集器语言内存占用插件丰富度最适合的场景Fluent BitC10-50MB多且持续增加资源受限的节点级/边车级采集FluentdRuby100-500MB很丰富复杂过滤、数据加工量大的场景FilebeatGo20-60MB中偏 ELK 生态Elastic 技术栈里的轻量采集LogstashJVM1GB 起丰富但重中心化的日志清洗与转换我在微服务场景里优先选 Fluent Bit原因很直接。服务节点本身就跑着业务进程日志采集器是附加的它占用的 CPU 和内存越少越好Fluent Bit 的 C 语言实现和单个静态二进制让它在这点上优势明显。而且它天然支持 tail、systemd、tcp、fluentd 转发协议输出端兼容 Elasticsearch、Kafka、Loki、S3、OSS没必要再在多套组件之间做胶水集成。Fluentd 不是不好它插件生态更丰富适合做复杂数据处理但那套 Ruby 运行时在资源受限的容器环境里不够轻。Logstash 更不用说功能强大但太重通常我只会把它放在中心处理层不会放在每个业务节点上。Filebeat 在 ELK 体系里表现不错但它对 Kafka、Loki、S3 的支持没有 Fluent Bit 那么顺手而且配置抽象程度略高出问题时调试路径相对长。1.3 什么情况适合“开箱即用”这套方案我得说实话不是所有场景都适合 Fluent Bit。如果你的日志处理需求极其复杂到了需要写自定义 grok 规则做多字段提取、做上下文关联、做基于日志事件触发动作的程度那 Fluent Bit 的过滤器体系会略显单薄这时候 Fluentd 或 Logstash 更合适。但如果你面对的是一套常规微服务体系日志要统一收集起来存到 Elasticsearch 里检索或者汇到 Kafka 里做进一步消费同时希望采集器资源占用小、部署简单——那这套方案几乎就是为这个场景设计的。我这次实战涉及的架构是微服务拆分后跑在单节点 K8s 上服务日志既有容器标准输出也有业务往 /data/logs 下写的文件通过 Fluent Bit 一个 DaemonSet 就能全部覆盖。所谓“开箱即用”对我个人来说意味着不再需要为每个服务单独改日志采集配置不用在业务容器里塞 agent不用等开发改代码。日志格式统一后Fluent Bit 的配置可以一套模板吃遍所有服务。2. 整体链路与日志规范先行2.1 日志采集链路怎么搭日志采集从来不是一个组件单打独斗的事它是一个完整链路。我常用的结构是这样微服务实例产生日志包括标准输出和文件日志节点上部署 Fluent Bit 采集器通过 tail 输入插件读取日志进入 Fluent Bit 内部经过解析、过滤、字段加工后写入本地缓冲或直接转发最终输出到 Elasticsearch、Loki 或 Kafka在这一层做存储和检索如果走 Kafka后边再挂消费程序做实时分析或者同步到数仓。节点级 DaemonSet 模式和边车模式是微服务里最常用的两种部署方式。节点级 DaemonSet 是每个 K8s 节点跑一个 Fluent Bit统一采集节点上所有容器的 stdout 和主机的文件日志资源占用小运维简单我首选这个。边车模式是每个业务 Pod 里塞一个 Fluent Bit 容器适合日志需要跟业务容器同生命周期、或者需要按 Pod 做复杂处理的场景但资源开销明显更大Pod 一变多就肉疼。如果你的服务暂未容器化还跑在传统主机上那就把 Fluent Bit 直接装成 systemd 服务道理一样每台主机一个实例。这也是我这次在国产化 ARM 环境里做的事后面会详细说。2.2 先统一日志格式再让 Fluent Bit 干活我在实战里最有体会的一件事就是采集器之前的日志规范化比选哪款采集器更重要。因为再好的采集器遇到乱糟糟的日志也只能处理成乱糟糟的数据。微服务日志里最核心的字段就那么几个时间、级别、服务名、traceId、消息体。如果服务端用的是 Java 系的 logback建议直接上 JSON encoder比如配合 logstash-logback-encoder让日志以 JSON 形式输出。像若依微服务这类框架改起来并不难logback-spring.xml 里把 pattern 换成 JSON encoder 就行。做成 JSON 格式后日志里天然带着可解析的字段结构Fluent Bit 解析时直接用 json 格式就够了不用写复杂的正则。而且 traceId 能在跨服务调用时把一条链路串起来对排查问题帮助巨大。如果日志是普通文本也要尽量固定切割符比如用时间 | 级别 | 服务名 | 内容让解析规则稳定下来。这套规范一定要在团队内推下去开发、运维、SRE 之间对齐口径否则日志采集链路再稳定检索和告警的效果也会打折扣。2.3 微服务日志字段建议表一个标准日志字段集我通常建议团队按下面的表来约定。字段名类型说明timestampstring/date日志产生时间建议 ISO8601 格式levelstringDEBUG/INFO/WARN/ERROR 等servicestring服务名比如 user-centertraceIdstring链路追踪 ID跨服务串联时用spanIdstring链路内跨度 ID可选messagestring日志核心内容stackstring异常堆栈多行场景时保留hoststring主机名或 Pod 名部署时由采集器自动补充字段不是越多越好我见过有人把十几个业务字段全塞进去结果日志体积大、解析性能差、索引成本高。微服务采集阶段先保住上面这一套标准字段后续有需要再通过 Fluent Bit 过滤器的 record_modifier 或者应用侧输出时补充千万别一开始就放飞。3. 开箱即用的 Fluent Bit 配置拆解3.1 核心配置读取、解析、过滤、输出先给出一份我在项目里常用的核心配置这个配置可以覆盖大多数微服务场景。它做了这么几件事读取 /data/logs 下各服务的日志文件用 json 解析器解析内容过滤出指定级别的日志补充环境和服务名然后输出到 Elasticsearch。[SERVICE] Flush 1 Daemon Off Log_Level info Parsers_File parsers.conf HTTP_Server On HTTP_Listen 0.0.0.0 HTTP_Port 2020 storage.path /var/log/fluent-bit storage.metrics on [INPUT] Name tail Tag app.* Path /data/logs/*/*.log Exclude_Path /data/logs/*/*backup.log DB /var/log/fluent-bit/fluent-bit.db Read_from_Head Off Buffer_Max_Size 512k Skip_Long_Lines On Mem_Buf_Limit 10M Refresh_Interval 5 [FILTER] Name grep Match app.* Regex level ^(INFO|WARN|ERROR|DEBUG)$ [FILTER] Name record_modifier Match app.* Record env prod Record cluster k8s-app Remove_key timestamp [OUTPUT] Name es Match app.* Host 10.0.0.8 Port 9200 Index micro-app Type _doc HTTP_User elastic HTTP_Passwd xxxx tls On tls.verify Off Suppress_Type_Name On配置里每个字段都是有讲究的我挑几个重点说明。Flush 1表示每秒尝试把 buffered 数据刷出去这个值不是越小越好太小会增加 IO 压力太大则日志产生到可检索的延迟变大。实际项目中我先用 1 秒如果业务对实时性要求低改成 2~5 秒也没问题。Buffer_Max_Size 512k是 tail 插件内部单条记录的最大缓冲超过会先截断处理。配合Skip_Long_Lines On可以防止某条异常超大日志把采集线程拖垮。线上日志偶尔会有几 MB 的怪物记录这个开关是我必开的。DB /var/log/fluent-bit/fluent-bit.db是 Fluent Bit 用来记录文件读取偏移量的 SQLite 文件非常重要。有了这个文件重启 Fluent Bit 后它能接着上次的位置继续读不会重复读很大一段日志也不会漏读轮转期间新增的内容。我见过有人图省事删掉 DB 文件结果一重启采集器从头读了一遍历史日志ES 里瞬间涌进大量重复数据教训很深刻。3.2 多行堆栈日志怎么拼微服务日志十有八九要处理异常堆栈问题。Java 服务的异常堆栈是典型的多行结构第一行是异常类型和描述后面每一行以空格加 at 开头。如果采集器不处理多行堆栈就会被拆成十几条独立日志检索时想看完整堆栈特别费劲。Fluent Bit 处理多行堆栈的思路是先把每行日志与正则做匹配判断它是不是第一行、是不是堆栈延续行然后按规则拼接。在这个项目中我在 parsers.conf 里加了一个多行解析器用来识别常见的 Java 或 Go 堆栈。[MULTILINE_PARSER] name java_stack type regex flush_timeout 1000 rule start_state /^[a-zA-Z].*Exception/ cont rule cont /^\sat / cont rule cont /^\s\.\.\.\d common frames omitted/ cont然后在 tail 输入里开启多行[INPUT] Name tail Path /data/logs/user-center/*.log Multiline On Parser json Multiline.Parser java_stack这里要注意Parser json负责处理首行的 JSON 解析Multiline.Parser负责把匹配到的后续堆栈行拼接到前一条日志上。如果你的日志头是纯文本Parser就配置成对应的时间格式解析器比如 common log parser。实际测试下来这种方式能非常好地把 Java 异常堆栈还原成一条完整日志。后面在 ES 里做搜索时可以直接把堆栈作为一个整体检索不会再出现日志中间被截断、看不到异常根因的情况。3.3 输出端选型ES、Kafka、Loki 怎么接输出端决定日志数据流到哪个环节这个要根据消费方式定不能照搬。我分别说下我在实际环境里用过的三种输出方式。如果团队主要靠 Kibana 看日志那直接输出到 Elasticsearch 最省事。ES 输出配置需要注意两个点一是Index的命名尽量用micro-app这样固定的前缀后面再接日期归档避免索引过杂二是写权限和 TLS 校验自建 ES 经常只开内网但也要把用户名密码配置好。如果日志不仅要检索还要做实时解析、审计、告警那输出到 Kafka 更合理。Fluent Bit 输出 Kafka 的配置不复杂[OUTPUT] Name kafka Match app.* Brokers 10.0.0.10:9092,10.0.0.11:9092 Topics microservice-logs rdkafka.linger.ms 20 rdkafka.acks 1rdkafka.linger.ms控制消息在本地攒多久再批量发送调大能提升吞吐但也会增加延迟。Kafka 在这种场景下最大的价值是把日志生产和消费解耦下游哪怕是崩溃重建日志也不会像直接写 ES 那样容易因为索引压力被拒绝。如果是轻量日志检索不想维护 ESLoki 是很好的选择Fluent Bit 的 loki 输出插件同样现成。[OUTPUT] Name loki Match app.* Host 10.0.0.6 Port 3100 Labels jobfluent-bit,service Remove_Label on输出端可以灵活切换配置文件里只改 Output 段即可输入和过滤基本不用动。这也是 Fluent Bit 让日志组件“开箱即用”的关键原因之一。你不需要因为换存储而重新搭一套采集链路。4. K8s 与 ARM 环境的部署实操4.1 二进制、容器、K8s DaemonSet 三种部署方式部署方式取决于你的环境。单机或传统主机上直接装二进制最合适。Fluent Bit 官方提供了编译好的二进制包解压就能跑。生产环境我建议把目录固定在/opt/fluent-bit再写一个 systemd unit开机自启。容器环境下最简单的方式是直接跑官方镜像把日志目录挂载进去。命令长这样docker run -d \ -v /data/logs:/data/logs:ro \ -v /var/log/fluent-bit:/var/log/fluent-bit \ -p 2020:2020 \ -v /etc/fluent-bit/fluent-bit.conf:/fluent-bit/etc/fluent-bit.conf \ fluent/fluent-bit:latestK8s 里正规做法是用 DaemonSet每个节点跑一个。把 ConfigMap 挂载配置用 hostPath 挂载宿主机日志目录既能采集业务写出来的文件日志也能通过 tail 读容器标准输出文件。资源 requests 和 limits 建议给到requests: cpu 50m, memory 30Milimits 宽松一些避免 Fluent Bit 被频繁 OOMKilled也别让它占到业务资源。DaemonSet 模式的一个天然好处是新增节点时Fluent Bit 会自动跟着调度过去不用手动给新主机装 agent。这在扩缩容频繁的微服务环境里非常省心。4.2 麒麟 V10 ARM64 上离线安装的完整过程这个话题是在国产化环境里被问得最多的。项目需要在 Kylin Linux Advanced Server V10 ARM64 环境离线部署 Fluent Bit。很多人一上来就踩坑因为官网默认下载的是 x86_64 包直接装了跑不起来。我实测可行的路径是这样。先在能联网的机器上拿到 ARM64 版本的二进制包。官方发布页面会提供fluent-bit-version-linux-aarch64.tar.gz这个包解压后自带 bin 和 lib 目录。把包拷贝到目标机器解压mkdir -p /opt/fluent-bit tar -xzf fluent-bit-2.1.10-linux-aarch64.tar.gz -C /opt/fluent-bit --strip-components1 ln -s /opt/fluent-bit/bin/fluent-bit /usr/local/bin/fluent-bit关键是检查动态库依赖。用 ldd 看一下ldd /opt/fluent-bit/bin/fluent-bit如果提示缺少libssl.so或libcrypto.so这类库常见解决办法是给系统装 openssl 兼容包。但离线环境装依赖也不容易我当时的操作是把官方 tar 包里的lib目录加进 LD_LIBRARY_PATH然后直接用 bin 下的可执行文件一般不缺主要依赖。如果始终报缺库再找一台同系统架构的机器把对应的.so复制过去放到/usr/lib64执行ldconfig刷新。装好后写 systemd 配置[Unit] DescriptionFluent Bit logger Afternetwork.target [Service] EnvironmentLD_LIBRARY_PATH/opt/fluent-bit/lib ExecStart/opt/fluent-bit/bin/fluent-bit -c /etc/fluent-bit/fluent-bit.conf Restartalways RestartSec10 [Install] WantedBymulti-user.target然后systemctl daemon-reload systemctl enable fluent-bit systemctl start fluent-bit离线安装最大的坑就是架构不匹配和动态库缺失。记住一点先在目标机器或同架构机器上执行ldd验证一遍再拿到现场部署避免反复搬运包。4.3 从单节点 K8s 迁移到云上日志采集要注意什么最近帮人做过一次迁移原来跑在单节点 K8s 上的整套微服务要迁到云上 ECS并且要求不停服、不丢数据。日志采集端在迁移中属于看起来不起眼、但最容易出问题的环节。我总结下来要重点看四件事。一是采集配置里的路径迁移后宿主机的日志目录、容器运行时目录可能变了DaemonSet 里 hostPath 的路径要对齐否则 Pod 日志采不到。二是输出端地址原来走内网直连 ES云上要改用云上 ES 或 Kafka 的接入地址并且开启鉴权云上端口一般不直接暴露到公网需要通过私网连接。三是时间问题云上节点时区可能默认是 UTC容器的日志时间和云上监控的时间会对不上建议在容器和主机上统一设置TZAsia/Shanghai。四是流量冲击迁移后如果还接着压测日志量会突然暴涨Fluent Bit 的缓冲区要提前调大。当时压测人员用配套的 Jmeter 脚本做高并发验证业务侧扛住了并发但日志侧出现了短暂的输出延迟。原因就是 Fluent Bit 默认的Flush 1和较小的storage.max_chunks_up在日志洪峰下吞吐受限。后来把 Flush 调到 2 秒给输出端 Kafka 配置rdkafka.linger.ms做了批量优化问题缓解。这里有一个比较实用的建议迁移前先用压测脚本把日志峰值打到接近预期的上限观察 Fluent Bit 的队列积压情况不要等迁移完再发现。日志采集这种组件平时很透明只有在峰值时才显形。4.4 高并发压测下 Fluent Bit 的稳定性验证有人会担心 Fluent Bit 这么轻扛不扛得住高并发场景。我在压测环境里专门盯过它的实时指标。Fluent Bit 开启了 HTTP Server 后可以直接通过 API 看到内部状态非常方便。curl -s http://127.0.0.1:2020/api/v1/uptime curl -s http://127.0.0.1:2020/api/v2/metrics | jq我压测时主要看input的 bytes、output的 proc_records、storage的 chunks观察有没有持续积压或重试增长。实测在单节点日志吞吐每秒几 MB 的规模下Fluent Bit 的 CPU 占用控制在单核 20% 以内内存稳定在 50MB 上下表现很稳。压测时最容易看到的异常是输出端 ES 跟不上、导致 Fluent Bit 大量重试。这时候往往不缺 CPU而是输出端索引压力大。不要盲目给 Fluent Bit 加并发 worker先优化输出端的写入性能和批量参数通常更对症。5. 性能调优与数据一致性的几个关键点5.1 内存和吞吐怎么平衡Fluent Bit 最吸引人的是内存占用低但如果你不做任何限制它也可能在日志洪峰时吃掉大量内存。原因很简单输出端如果写入变慢输入端还在不停读文件数据就会暂存在内存缓冲里。我的经验是三个参数配合使用。Mem_Buf_Limit限制单个输入插件的最大缓冲内存超过后新的日志会被丢弃或进入文件系统缓冲storage.path允许把缓冲溢写到磁盘缓解内存压力storage.max_chunks_up控制最多有多少个 chunk 保留在内存中超出的部分会被写到磁盘 backlog。[SERVICE] storage.path /var/log/fluent-bit/backlog storage.max_chunks_up 128符合直觉的理解是内存是缓冲第一层磁盘 backlog 是第二层输出端是最终出口。如果你发现 Fluent Bit 内存上涨先查输出端为什么不消费而不是直接调大缓冲区后者只是推迟问题爆发而已。5.2 不丢数据、不重复数据的兜底措施日志数据丢失和重复是两类相反的问题处理方式也不同。防丢失的关键在于两点一个是 DB 文件记录偏移让重启后能续读另一个是输出端要开启重试。Fluent Bit 对输出失败有内置重试机制但如果 ES 长期不可用积压的数据会越来越多这时候你需要在Retry_Limit里设置一个策略。我通常设置Retry_Limit False表示不限制重试次数因为日志数据可以接受延迟但不要轻易丢弃。如果担心磁盘被塞满再配合storage.delete_irrecoverable来控制在极端情况下的数据清理。防重复相对麻烦一点。日志重复常见场景就是文件轮转读串了比如同一份日志被两个 input 规则匹配或者 DB 文件损坏后重建导致从文件头重新读。解决办法是检查 input 的 Path 是否重叠尽量避免覆盖范围过大。若输出到 ES可以在输出端设置文档 ID 为主机和文件偏移的组合从根上做去重如果输出到 Kafka则设置合理的消息 key让同一文件日志进同一分区既保证顺序也方便下游做幂等。5.3 日志乱序和时区问题怎么处理日志乱序是微服务日志采集里特别容易被忽略的问题。日志进入采集后有多个处理线程输出到 Kafka 时如果打散到多个分区某些下游消费看到的顺序就可能是乱的。我对顺序要求高的场景会做三件事。第一单个日志文件只让 Fluent Bit 的单 worker 处理不要随意加大 tail 插件的 workers 数避免同一个文件的日志被并行分发。第二输出到 Kafka 时把 key 设置成服务实例 ID 或文件名保证同一 key 的消息进同一分区。第三展示端排序不要依赖接入顺序要按照日志自带的时间戳字段排序这是最后一道兜底。时区问题也常见。应用打日志用东八区采集器默认按系统时区处理如果容器或主机是 UTCKibana 里看到的时间就会差 8 小时。最简单的做法是在 Fluent Bit 容器环境变量里设TZAsia/Shanghai解析器里尽量使用带时区信息的格式比如 ISO8601。如果日志时间从应用侧生成时已经是东八区那就统一让解析后的 timestamp 直接保留日志内容而不要依赖采集器自以为的本地时间。6. 常见问题与排查技巧实录6.1 一次“日志采集消失了”的排查分享一个我实际遇到过的案例。某次压测结束后开发反馈 ES 里某个服务的新日志完全不涨了。我上服务器看了一下服务进程正常日志文件也一直在写文件在变大但 Fluent Bit 就是纹丝不动。我先是直接手动跑了一次单测命令fluent-bit -i tail -p path/data/logs/order-service/*.log -p read_from_headOn -o stdout手动能读到日志说明文件和配置本身没问题。接着我又确认了 DB 文件存在Fluent Bit 也在正常运行。最后把问题锁定在文件轮转上。那个服务的日志文件是按天滚动的滚动后新生成的日志文件接续关系变了Fluent Bit 的 tail 插件依赖 DB 里的 inode 和 offset 判断读取位置滚动后新文件未被正确识别成新目标所以一直停在那里。应急办法是停 Fluent Bit、删除对应的 DB 文件、再启动让它重新扫描文件。但这不是长久之计原因在于我最初没有把滚动场景考虑进配置。后面我在 Path 里同时匹配了*.log和轮转后的历史文件模式并把Refresh_Interval调小让 Fluent Bit 更快发现新文件问题才真正解决。这类问题最典型的特征就是“文件在涨ES 不涨”大家遇到先按这个思路排查效率会高不少。6.2 常见故障速查表把平时最常碰到的几个问题整理成一个速查表方便你直接对号入座。症状可能原因排查方向ES/Kafka 里完全没数据tail 路径配置不匹配用 stdout 输入单测确认文件是否能被读到只有历史日志、没有新日志DB 文件里记录了旧偏移未识别新文件检查文件是否轮转必要时重建 DB多行堆栈被拆成多条未开启 Multiline.Parser配置多行解析器并将它与 Parser 配合使用日志时间差 8 小时采集器时区与日志时间不一致容器内设置 TZ解析器使用带时区的格式内存持续上涨输出端消费慢内存缓冲积压查看 /api/v2/metrics优先解决输出端瓶颈出现重复日志两个 input 规则匹配同一文件或 DB 重建检查 Path 是否重叠必要时设置文档 ID日志大量失败重试ES 写索引失败或 Kafka 不可达查看输出日志的 error 信息确认鉴权配置离线环境运行时缺 .so 库动态库依赖未满足ldd 检查补齐 openssl 等兼容库排查日志问题时我个人的习惯是永远从链路两端往中间收先确认日志确实在业务侧产生了再确认输出端确实能收到。很多时候问题不在 Fluent Bit 本身而是配置文件里某个路径少了通配符或者输出端索引权限没开。最后再分享一个经验总结吧。日志采集这套东西看起来是一堆配置文件的拼凑但真正让它稳定跑起来是在规范化、部署方式、峰值调度和故障预案这些细节上下了功夫的。Fluent Bit 给了我一个很轻量、很可靠的基础但用好它还是得把日志链路的整体设计想清楚。如果你正要给微服务搭日志体系我建议你从这篇里的日志规范开始先把落地规则定好再逐步把采集、输出、监控一点点补全别一上来就贪多求全。