ELK日志分析平台实战：Filebeat采集与Elasticsearch索引调优方案

ELK（Elasticsearch + Logstash + Kibana）是DevOps实践中应用最广泛的日志分析技术栈。在微服务架构和容器化部署场景下，日志分散在数十甚至数百个节点上，传统文本搜索和grep已无法满足故障定位效率要求。通过Filebeat轻量采集、Elasticsearch索引调优、Kibana可视化展示，可以构建支持PB级日志存储的统一监控告警体系。

Filebeat轻量日志采集配置

Filebeat是Elastic官方推荐的日志采集Agent，相比Logstash更轻量（内存占用约20MB），适合部署在每台生产节点上。Filebeat通过inputs定义日志路径，通过outputs定义发送目标，支持多行合并和字段解析。

# filebeat.yml 配置示例
filebeat.inputs:
  - type: log
    enabled: true
    paths:
      - /var/log/nginx/access.log
      - /var/log/nginx/error.log
    multiline.pattern: '^\d{4}-\d{2}-\d{2}'
    multiline.negate: true
    multiline.match: after
    fields:
      service: nginx
      env: production
    fields_under_root: true

  - type: log
    enabled: true
    paths:
      - /opt/app/logs/*.log
    multiline.pattern: '^\['
    multiline.negate: true
    multiline.match: after
    fields:
      service: app
      env: production

processors:
  - decode_json_fields:
      fields: ["message"]
      process_array: false
      max_depth: 2
      target: json
  - drop_fields:
      fields: ["agent", "ecs", "host"]
  - add_fields:
      target: ""
      fields:
        cluster: "prod-cluster-01"

output.elasticsearch:
  hosts: ["10.0.1.10:9200", "10.0.1.11:9200"]
  index: "app-logs-%{[service]}-%{+yyyy.MM.dd}"
  username: "elastic"
  password: "${ELASTIC_PASSWORD}"

setup.ilm.enabled: false
setup.template.enabled: false

multiline配置处理Java异常堆栈等跨行输出，pattern匹配行首日期或方括号，将后续非匹配行追加到前一条日志。decode_json_fields处理器直接在Agent端完成JSON解析，减少Logstash转发层的CPU消耗。直接输出到Elasticsearch可省去Logstash中间层，降低延迟和维护成本。fields_under_root将自定义字段提升到顶层，便于在Kibana中直接查询。

Elasticsearch索引模板与分片策略调优

Elasticsearch索引性能受分片数量、副本数和刷新间隔影响很大。默认配置不适合高频写入场景，需要为日志索引定制模板。

// 索引模板定义
PUT _index_template/app-logs
{
  "index_patterns": ["app-logs-*"],
  "template": {
    "settings": {
      "number_of_shards": 6,
      "number_of_replicas": 1,
      "refresh_interval": "30s",
      "index.translog.durability": "async",
      "index.translog.sync_interval": "30s",
      "index.codec": "best_compression",
      "index.query.default_field": [
        "message", "json.level", "json.traceId"
      ]
    },
    "mappings": {
      "properties": {
        "@timestamp": { "type": "date" },
        "service": { "type": "keyword" },
        "env": { "type": "keyword" },
        "message": { 
          "type": "text",
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "json.level": { "type": "keyword" },
        "json.traceId": { "type": "keyword" },
        "json.method": { "type": "keyword" }
      }
    }
  }
}

number_of_shards根据数据量设定，每个分片建议控制在30-50GB以内。refresh_interval从默认1s调整为30s，减少segment生成频率提升写入吞吐量。translog.durability设为async后，translog刷盘间隔由sync_interval控制，写入吞吐量可提升2-3倍，代价是宕机最多丢失30秒写入数据。best_compression压缩编码可节省50%以上磁盘空间，适合日志场景。keyword类型字段用于精确匹配和聚合，text类型配合ik分词器支持中文全文检索。

KQL查询与Kibana可视化仪表盘

Kibana提供KQL（Kibana Query Language）进行结构化日志查询，语法简洁直观。复杂查询也可使用Lucene语法或直接发送DSL请求：

// 查询某服务近1小时ERROR级别日志
service: "app" AND json.level: "ERROR" 
  AND @timestamp > "now-1h"

// 按traceId追踪完整调用链
json.traceId: "abc-123-def-456"

// 聚合查询：统计各服务ERROR日志数量
GET app-logs-*/_search
{
  "size": 0,
  "query": {
    "bool": {
      "filter": [
        { "term": { "json.level": "ERROR" } },
        { "range": { 
          "@timestamp": { "gte": "now-1h" } 
        }}
      ]
    }
  },
  "aggs": {
    "errors_by_service": {
      "terms": { "field": "service", "size": 20 },
      "aggs": {
        "recent_errors": {
          "top_hits": {
            "size": 3,
            "sort": [{ "@timestamp": "desc" }],
            "_source": ["message", "json.traceId"]
          }
        }
      }
    }
  }
}

在Kibana Dashboard中创建可视化面板：柱状图展示各服务日志量趋势、饼图展示ERROR分布、数据表展示最近异常。设置Watcher告警规则，当特定服务的ERROR日志量超过阈值时触发通知。Kibana的Lens可视化编辑器可拖拽生成图表，适合非SQL背景的运维和SRE人员使用。traceId字段配合分布式链路追踪系统，可从日志直接跳转到调用链详情。

日志冷热分离与ILM生命周期管理

日志数据有明显的时效性特征，最近7天为热数据（高频查询），7-30天为温数据（偶尔查询），30天以上为冷数据（归档审计）。通过Elasticsearch ILM（Index Lifecycle Management）可实现自动化的冷热分离：

// ILM策略定义
PUT _ilm/policy/app-logs-policy
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": {
            "max_size": "50gb",
            "max_age": "1d"
          }
        }
      },
      "warm": {
        "min_age": "7d",
        "actions": {
          "shrink": { "number_of_shards": 2 },
          "forcemerge": { "max_num_segments": 1 },
          "set_priority": { "priority": 50 }
        }
      },
      "cold": {
        "min_age": "30d",
        "actions": {
          "freeze": {},
          "set_priority": { "priority": 0 }
        }
      },
      "delete": {
        "min_age": "90d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

热节点使用SSD存储、高CPU配置；温节点使用SATA SSD、中配CPU；冷节点使用大容量HDD、低配CPU。freeze操作将索引转为冻结状态，不占用堆内存，查询时按需加载。shrink操作将6分片合并为2分片，减少集群overhead。forcemerge将segment合并为1个，提升查询效率。对于合规审计要求保留超过90天的日志，可在delete阶段之前添加snapshot操作，将索引快照归档到对象存储。