1. 为什么需要日志聚合？

想象一下你的服务器每天产生10GB日志，20台机器就是200GB。手工翻查日志如同海底捞针，某个服务突然崩溃时，运维人员可能要花几个小时定位问题。日志聚合技术的本质就是通过「集中收集→结构化处理→智能分析」的流程，让日志变成可观察、可预警的战略资产。

2. 技术选型背后的逻辑

Fluent Bit就像快递小哥，轻量级（仅450KB内存消耗），专为边缘场景优化；ELK Stack则是物流中心（Elasticsearch）+分拣机器人（Logstash）+可视化大屏（Kibana）。组合使用时，Fluent Bit负责「收件」，ELK负责「拆包、上架、展示」。

3. 手把手搭建日志管道（基于CentOS 7）

3.1 Fluent Bit安装与基础配置
curl https://packages.fluentbit.io/fluentbit.key | sudo tee /etc/pki/rpm-gpg/RPM-GPG-KEY-fluentbit
cat <<EOF | sudo tee /etc/yum.repos.d/fluent-bit.repo
[fluent-bit]
name=Fluent Bit
baseurl=https://packages.fluentbit.io/centos/7/\$basearch/
gpgcheck=1
gpgkey=https://packages.fluentbit.io/fluentbit.key
enabled=1
EOF

# 安装并启动
sudo yum install fluent-bit -y
sudo systemctl start fluent-bit
3.2 收集系统日志实战
# /etc/fluent-bit/fluent-bit.conf
[SERVICE]
    flush        5     # 每隔5秒发送数据
    log_level    info  # 日志级别

[INPUT]
    name          tail              # 使用文件追踪模式
    path          /var/log/messages # 监控系统日志文件
    tag           syslog            # 标签用于路由
    parser        syslog-rfc3164    # 使用内置解析器

[OUTPUT]
    name          es                # 输出到Elasticsearch
    match         *                 # 匹配所有标签
    host          192.168.1.100     # ES服务器IP
    port          9200
    index         fluent-bit        # 索引名称

注：parser字段将原始日志转化为JSON格式，自动拆分timestamp、hostname等字段

3.3 Elasticsearch索引模板优化
PUT _index_template/logs_template
{
  "index_patterns": ["fluent-bit-*"],
  "template": {
    "settings": {
      "number_of_shards": 3,
      "number_of_replicas": 1
    },
    "mappings": {
      "dynamic_templates": [
        {
          "strings_as_keyword": {
            "match_mapping_type": "string",
            "mapping": {
              "type": "keyword"
            }
          }
        }
      ]
    }
  }
}

注：强制字符串类型字段存储为keyword，提升聚合查询性能

3.4 Kibana可视化：错误日志监控大屏
# 在Kibana控制台执行以下操作：
1. 进入Management → Index Patterns → Create "fluent-bit-*"
2. 进入Discover → 筛选log字段包含"error"
3. 进入Dashboard → 新建可视化组件：
   - 饼图：错误类型分布
   - 折线图：每小时错误数量趋势
   - 数据表：最近50条错误详情

4. 性能优化黑科技

场景：每秒5000条日志的压力测试中，发现Fluent Bit出现数据积压。

解决方案：

[INPUT]
    name               tail
    buffer_chunk_size  32k   # 每个缓冲区大小
    buffer_max_size    256k  # 内存缓冲区上限
    mem_buf_limit      100MB # 内存溢出保护

[OUTPUT]
    name          es
    retry_limit   5     # 重试次数
    workers       4     # 并发线程数

调整后吞吐量提升3倍，同时设置监控：fluent-bit -m查看内存使用

5. 常见坑位指南

  • 时间戳问题：跨时区日志导致Kibana显示混乱 
    [FILTER]
    name    record_modifier
    record  hostname ${HOSTNAME}
    record  timezone UTC+8
  • 字段爆炸：Nginx日志中的$request参数生成过多字段，需限制： 
    "mapping": {
  "total_fields": {
    "limit": 1000
  }
}

6. 技术栈对比分析

指标 Fluent Bit Logstash
内存占用 <10MB >500MB
插件数量 70+ 200+
吞吐量 10万条/秒 2万条/秒
适用场景 边缘节点采集 中心化处理

结论：资源紧张时用Fluent Bit做采集层，复杂ETL依然需要Logstash

7. 特殊场景解决方案

物联网设备日志收集：

[INPUT]
    name          mqtt
    tag           iot.data
    host          10.0.0.5
    topic         sensors/#

[FILTER]
    name          lua
    script        decrypt.lua  # 自定义解密脚本
    call          process_data

通过Lua插件实现二进制数据解析，满足私有协议需求

8. 总结与展望

通过Fluent Bit+ELK的组合拳，某电商平台实现了：

  • 故障定位时间从2小时缩短到5分钟
  • 存储成本降低40%（通过冷热数据分层）
  • 实现基于日志的用户行为分析

未来可探索的方向：

  1. 结合机器学习做异常检测（如Elastic ML模块）
  2. 边缘节点本地预处理（Fluent Bit的WASM过滤器）
  3. 满足GDPR的日志脱敏方案