告别散落日志：用华为云 CSS 从零搭建企业级日志分析与全文检索平台

一、背景与痛点

# 1. 登录跳板机
# 2. 找到对应节点
ssh order-node-03
# 3. grep 关键字
grep "OutOfMemory" /var/log/app/order-service.log | tail -100
# 4. 时间不对还得切文件
grep "2024-01-15 14:3" /var/log/app/order-service.log.2024-01-15-14

二、方案设计

2.1 为什么用 CSS 而不是自建 ELK

2.2 日志链路架构

微服务实例（Spring Boot）
   │
   │ Filebeat / LTS 采集
   ▼
日志汇聚层（Logstash / LTS 直接转发）
   │
   ├─ 过滤：grok 解析、字段提取
   ├─ 富化：添加 env、service_name、trace_id
   └─ 路由：按索引模板分发
   │
   ▼
CSS 集群（Elasticsearch）
   │
   ├─ 索引：按月滚动（logs-2024-01）
   ├─ 分片：3 primary + 1 replica
   └─ ILM：热温冷数据生命周期管理
   │
   ▼
Kibana 可视化
   │
   ├─ Discover：秒级全文检索
   ├─ Dashboard：错误率/吞吐量/延迟面板
   └─ Alerting：错误突增告警

2.3 索引设计

logs-order-service-2024.01
logs-user-service-2024.01
logs-inventory-service-2024.01

• 按时间删除旧数据，直接删索引，不影响写入
• 按服务查时只搜对应索引，性能高
• 不同服务字段结构不同，mapping 互不干扰

三、实操步骤

3.1 创建 CSS 集群

1. 进入云搜索服务 CSS 控制台 → 创建集群
2. 集群类型：Elasticsearch
3. 版本：7.10.2（稳定版，与 Spring Boot 生态兼容好）
4. 节点规格：
   • 热节点：ess.spec.m6.large.8（4U32G）× 3
   • 数据盘：超高 I/O，200GB/节点
5. 网络：选业务同 VPC，安全组开放 9200（内网）
6. 开启 Kibana：自动分配访问地址，绑定 EIP 或走 VPN 访问
7. 安全模式：开启 HTTPS + 账号认证

避坑：节点数至少 3 个才能保证主节点选举的高可用。单节点只适合开发测试。

3.2 Spring Boot 应用日志改造

<!-- pom.xml -->
<dependency>
  <groupId>net.logstash.logback</groupId>
  <artifactId>logstash-logback-encoder</artifactId>
  <version>7.4</version>
</dependency>

<appender name="LOGSTASH" class="net.logstash.logback.appender.LogstashTcpSocketAppender">
  <destination>logstash.internal:5000</destination>
  <encoder class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder">
    <providers>
      <timestamp/>
      <logLevel/>
      <message/>
      <loggerName/>
      <threadName/>
      <mdc/>          <!-- 输出 MDC 中的 traceId -->
      <stackTrace/>
      <pattern>
        <pattern>
          {
            "service": "order-service",
            "env": "prod",
            "node_ip": "${HOSTNAME}"
          }
        </pattern>
      </pattern>
    </providers>
  </encoder>
</appender>

<root level="INFO">
  <appender-ref ref="CONSOLE"/>
  <appender-ref ref="LOGSTASH"/>
</root>

// 拦截器中
MDC.put("trace_id", UUID.randomUUID().toString());

{
  "timestamp": "2024-01-15T14:32:10.123Z",
  "level": "ERROR",
  "service": "order-service",
  "env": "prod",
  "trace_id": "a1b2c3d4-1234-5678",
  "message": "Failed to create order: inventory deduction timeout",
  "stack_trace": "..."
}

3.3 Logstash 管道配置

# pipeline/logs.conf
input {
  tcp {
    port => 5000
    codec => json_lines
  }
}

filter {
  # 提取时间戳
  date {
    match => ["timestamp", "ISO8601"]
    target => "@timestamp"
  }

  # 按服务名路由
  mutate {
    add_field => {
      "index_prefix" => "%{service}"
    }
  }

  # 解析异常堆栈为多行
  if [stack_trace] {
    mutate {
      gsub => ["stack_trace", "\n", " | "]
    }
  }
}

output {
  elasticsearch {
    hosts => ["https://css-cluster-endpoint:9200"]
    user => "admin"
    password => "${CSS_PASSWORD}"
    index => "logs-%{service}-%{+YYYY.MM}"
    ssl_certificate_verification => false
  }
}

3.4 索引模板与 ILM 策略

PUT _index_template/logs-template
{
  "index_patterns": ["logs-*"],
  "template": {
    "settings": {
      "number_of_shards": 3,
      "number_of_replicas": 1,
      "refresh_interval": "5s",
      "index.lifecycle.name": "logs-ilm-policy"
    },
    "mappings": {
      "properties": {
        "timestamp": { "type": "date" },
        "level": { "type": "keyword" },
        "service": { "type": "keyword" },
        "env": { "type": "keyword" },
        "trace_id": { "type": "keyword" },
        "message": { "type": "text", "analyzer": "ik_max_word" },
        "stack_trace": { "type": "text" },
        "node_ip": { "type": "ip" }
      }
    }
  }
}

PUT _ilm/policy/logs-ilm-policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_size": "50GB",
            "max_age": "7d"
          }
        }
      },
      "warm": {
        "min_age": "7d",
        "actions": {
          "shrink": { "number_of_shards": 1 },
          "forcemerge": { "max_num_segments": 1 }
        }
      },
      "cold": {
        "min_age": "30d",
        "actions": {
          "freeze": {}
        }
      },
      "delete": {
        "min_age": "90d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

3.5 Kibana 可视化与告警

• 索引模式：logs-*
• 常用查询：
  • level:ERROR AND service:order-service
  • trace_id:"a1b2c3d4-1234-5678" （全链路追踪）
  • message:"OutOfMemory" AND timestamp:>now-1h

• 规则：Error count threshold
• 条件：level:ERROR 在 5 分钟内 > 50 条
• 动作：Webhook 推送到企业微信群

{
  "msgtype": "markdown",
  "markdown": {
    "content": "## 🚨 日志告警\n**服务**：{{context.service}}\n**错误数**：{{context.hits}}\n**时间**：{{context.timestamp}}\n[查看详情]({{context.kibana_url}})"
  }
}

四、验证结果

五、生产避坑清单

1. 所有日志写同一个索引：单索引膨胀到 TB 级，查询慢、分片恢复慢
2. 字段全用 text 类型：text 不分词无法精确聚合，该用 keyword 的用 keyword
3. 不配 ILM 策略：日志无限堆积，磁盘撑满集群只读
4. Logstash 单点：Logstash 挂了日志全丢，至少部署 2 个实例 + Filebeat 持久化
5. JVM 堆内存超过 32GB：ES 禁用压缩指针，反而性能下降
6. 分片数过多：一个节点上千个分片，集群状态更新卡顿
7. 没开慢查询日志：ES 自身慢查询不监控，排查时不知道是 ES 慢还是应用慢
8. Kibana 直接暴露公网：安全风险，应走 VPN 或堡垒机

• 索引按服务 + 月份滚动，单索引控制在 50GB 以内
• mapping 提前设计：日志级别、服务名、trace_id 用 keyword
• ILM 四阶段：热（7天）→ 温（压缩）→ 冷（冻结）→ 删（90天）
• Logstash 至少 2 节点，Filebeat 开持久化队列
• ES 堆内存设物理内存的 50%，不超过 32GB
• 分片数 = 数据节点数 × 1~3，不要过度分片
• 监控 ES 自身：CPU、JVM GC、线程池队列、索引延迟
• Kibana 走内网 + 反向代理鉴权，不直挂公网

六、成本结构

经验：日志量 < 50GB/天 的小集群，3 个 4U32G 节点足够扛住。超过 200GB/天 需要单独规划热温架构。

七、总结与扩展

• 从被动到主动：告警在用户感知前触发
• 从模糊到精确：5 秒定位到哪个节点、哪个接口、哪行代码
• 从孤岛到关联：trace_id 串联全链路，跨服务问题一目了然

1. 接入 APM Trace 数据：把 SkyWalking/Zipkin span 也写入 ES，日志 + 链路统一检索
2. 机器学习异常检测：ES ML 自动学习错误率基线，异常偏离自动告警
3. 安全日志审计：将 WAF、HSS 安全日志也汇入 CSS，做安全事件关联分析
4. 日志即证据：结合 LTS 做合规审计，满足等保日志留存要求
5. Serverless 日志：函数工作流日志自动接入，无服务器架构也有完整可观测性

本文为原创日志平台实践，基于华为云云搜索服务 CSS 整理，操作步骤以当前控制台页面为准。转载请注明出处。