微服务架构日志收集方案与硬件协同优化

在知易网做硬件维护久了，常遇到开发同事跑来问：服务器看着没问题，但系统突然卡了，查半天找不到原因。其实问题可能不在硬件，而在日志没收集好。

以前单体应用时代，所有日志都写在一个文件里，翻一翻就能定位问题。现在一个业务拆成十几个微服务，用户下个单，订单、库存、支付、通知各自记一笔日志，分散在不同机器上。想串起来看？得登录五六台服务器，效率低还容易漏。

常见的做法是每台服务器上部署一个日志采集代理，比如 Filebeat 或 Fluent Bit，它会监听服务输出的日志文件，实时转发到统一的存储中心。像 Elasticsearch 这类工具就常被用来存日志，配合 Kibana 做查询展示。

比如在 Nginx 微服务节点上加一行配置：

filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/nginx/access.log
output.elasticsearch:
  hosts: ["http://es-server:9200"]

这样日志就会自动发往 Elasticsearch，不用再手动去翻服务器。

多个服务日志混在一起，怎么知道哪条属于哪个请求？可以在日志里加入唯一追踪 ID（Trace ID），从入口网关开始生成，一路透传到下游服务。出了问题，拿这个 ID 一搜，整个调用链的日志全出来了。

比如 Java 项目里用 Sleuth，Spring Cloud 配置一下就行：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>

不需要改代码，日志自动带上 trace 和 span ID。

日志集中后，Elasticsearch 节点压力不小，尤其是高并发场景。我们之前遇到过，每天新增几十 GB 日志，ES 节点磁盘撑爆，查询变慢。后来加了 SSD 硬盘，做了索引按天滚动，才缓过来。

所以别只盯着 CPU 和内存，日志系统的磁盘 IO 和网络带宽也得监控。特别是在做硬件巡检时，多看一眼磁盘使用率，能避免不少半夜告警。

微服务架构下的日志收集实践