3. 日志采集与聚合：日志来源、采集工具与存储

日志这东西，说白了就是系统的「黑匣子」。设备身份治理平台每天处理几百万甚至上千万的设备认证请求，一旦出问题，你连日志都找不到，那就真成了瞎子摸象。我这些年踩过的坑，十有八九都跟日志没管好有关。

这一章我们聊聊日志的三大块：从哪来（日志来源）、怎么收（采集工具）、存哪去（聚合与存储）。

3.1 日志来源：三类日志，缺一不可

设备身份治理平台的日志，我习惯分成三类：系统日志、应用日志和安全日志。这三者各有侧重，但缺了哪一个，排查问题时都会让你抓狂。

3.1.1 系统日志

系统日志记录的是操作系统和基础设施层面的信息。比如 CPU 飙高、磁盘写满、网络断连、内核报错等等。这些日志通常由 syslog、journald 或 Windows 事件查看器产生。

我在项目中遇到过好几次，设备认证突然大面积超时，查了半天应用日志啥问题没有，最后发现是系统日志里报「磁盘 I/O 等待时间超过 30 秒」。嗯，那台机器的 SSD 快挂了。所以系统日志一定要收，而且要设告警。

3.1.2 应用日志

这是最核心的日志。设备身份治理平台的应用日志包括：设备注册请求、证书签发记录、身份认证结果、策略执行日志等等。每一笔设备身份的生命周期变更，都应该有对应的应用日志。

我个人习惯在应用日志里至少包含以下字段：时间戳、设备 ID、操作类型、请求来源 IP、处理结果、耗时。这样后期做链路追踪和性能分析才方便。

3.1.3 安全日志

安全日志是合规审计的命根子。设备身份治理平台如果被攻破，安全日志就是最后的防线。安全日志包括：SSH 登录记录、sudo 执行记录、文件权限变更、防火墙拦截记录、以及平台自身的认证失败记录。

我曾经遇到过一个案例：某天突然发现大量设备证书被异常吊销。查安全日志发现，有人在凌晨 3 点用管理员账号登录了平台，而且登录 IP 来自境外。要不是安全日志保留得完整，这个锅差点甩给开发团队。

3.2 日志采集工具：Filebeat 与 Logstash

日志采集工具的选择，说白了就是「轻量 vs 重量」的权衡。我一般推荐 Filebeat + Logstash 的组合，各司其职。

3.2.1 Filebeat：轻量级采集器

Filebeat 是 Elastic 官方出品的轻量级日志采集器。它占用资源极小（内存几十 MB），适合部署在每台业务服务器上。Filebeat 负责：读取日志文件、简单过滤、发送到 Logstash 或 Elasticsearch。

它的核心优势是「保证至少一次投递」。Filebeat 内部有一个注册表文件，记录每个日志文件的读取位置。即使进程重启，它也能从断点处继续读取，不会丢日志。

# filebeat.yml 核心配置示例
filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/device-auth/*.log
  fields:
    service: device-auth
    env: production

output.logstash:
  hosts: ["logstash01:5044", "logstash02:5044"]
  loadbalance: true

# 注册表文件位置（默认）
# /var/lib/filebeat/registry/filebeat.log

3.2.2 Logstash：强大的数据处理管道

Logstash 是日志处理的中枢。它接收来自 Filebeat 的日志流，然后进行解析、过滤、转换、富化，最后输出到 Elasticsearch。

Logstash 的配置分为三部分：input（输入）、filter（过滤）、output（输出）。我习惯把 filter 阶段做得重一些，因为日志质量决定了后续分析的效率。

# logstash.conf 核心配置示例
input {
  beats {
    port => 5044
    client_inactivity_timeout => 60
  }
}

filter {
  # 解析 JSON 格式日志
  if [fields][service] == "device-auth" {
    json {
      source => "message"
      target => "auth"
    }
    # 添加地理信息（如果包含 IP）
    geoip {
      source => "[auth][client_ip]"
      target => "geo"
    }
  }

  # 解析系统日志
  if [fields][service] == "system" {
    grok {
      match => { "message" => "%{SYSLOGTIMESTAMP:timestamp} %{SYSLOGHOST:hostname} %{DATA:program}: %{GREEDYDATA:log_message}" }
    }
  }
}

output {
  elasticsearch {
    hosts => ["http://es01:9200", "http://es02:9200"]
    index => "logs-%{[fields][service]}-%{+YYYY.MM.dd}"
    user => "logstash_writer"
    password => "${ES_PASSWORD}"
  }
}

3.3 日志聚合与存储：Elasticsearch

日志最终要存到一个能快速查询的地方。Elasticsearch 是目前最主流的日志存储和检索引擎。它基于 Lucene，支持全文检索、聚合分析、分布式扩展。

3.3.1 索引设计原则

Elasticsearch 的索引设计直接影响查询性能和存储成本。我个人的经验是：

• 按时间分索引：每天一个索引（如 logs-device-auth-2025.03.21），方便过期删除和冷热分离。
• 合理设置分片数：每个分片建议 20-40GB，不要超过 50GB。分片太多会导致集群管理开销大。
• 使用别名：查询时用别名指向最近 N 天的索引，避免查询时指定一堆索引名。

# 索引模板示例（自动应用到新索引）
PUT _index_template/logs_template
{
  "index_patterns": ["logs-*"],
  "template": {
    "settings": {
      "number_of_shards": 3,
      "number_of_replicas": 1,
      "refresh_interval": "30s"
    },
    "mappings": {
      "properties": {
        "@timestamp": { "type": "date" },
        "device_id": { "type": "keyword" },
        "service": { "type": "keyword" },
        "message": { "type": "text" },
        "geo": { "type": "geo_point" }
      }
    }
  }
}

3.3.2 生命周期管理

日志不能无限存。Elasticsearch 提供了 ILM（Index Lifecycle Management）来自动管理索引的生命周期：热阶段（Hot）→ 温阶段（Warm）→ 冷阶段（Cold）→ 删除。

3.3.3 查询与可视化

日志存进 Elasticsearch 之后，通常用 Kibana 做可视化和查询。Kibana 的 Discover 页面可以快速搜索日志，Dashboard 可以展示实时监控面板。

我个人习惯在 Kibana 里建几个固定的 Dashboard：

• 设备认证实时看板：展示每分钟认证请求量、成功率、平均耗时。
• 错误日志聚合看板：按错误类型和来源服务聚合，快速定位高频错误。
• 安全事件看板：展示登录失败次数、异常 IP 分布、权限变更记录。