4. 日志采集方案选型：DaemonSet vs Sidecar、Fluentd vs Fluent Bit vs Logstash vs Vector

在 Argo CD 与 Kubernetes 的可观测性体系中，日志采集是 Golden Signals 指标（特别是延迟和错误率）回溯分析的基础。采集层的选型直接影响资源开销、数据完整性、运维复杂度以及后续的日志检索效率。本章从部署模式（DaemonSet vs Sidecar）和采集引擎（Fluentd / Fluent Bit / Logstash / Vector）两个维度进行系统性对比，帮助你在不同场景下做出合理决策。

4.1 部署模式对比：DaemonSet 与 Sidecar

Kubernetes 中日志采集的部署模式主要分为两种：DaemonSet（节点级代理）和 Sidecar（Pod 级代理）。两者在资源隔离、配置灵活性、数据完整性方面存在显著差异。

4.2 采集引擎选型：Fluentd vs Fluent Bit vs Logstash vs Vector

在确定部署模式后，需要选择合适的采集引擎。当前主流的开源方案包括 Fluentd、Fluent Bit、Logstash 和 Vector。以下从性能、资源占用、插件生态、配置复杂度等维度进行对比。

4.3 引擎选型决策矩阵

根据 Argo CD 日志检索与 Golden Signals 指标集成的实际需求，以下决策矩阵可以帮助你快速匹配场景与引擎：

4.4 实战配置示例：Fluent Bit DaemonSet + Vector Sidecar

基于上述选型分析，推荐在 Argo CD 环境中采用 Fluent Bit（DaemonSet） 采集标准输出日志，配合 Vector（Sidecar） 处理需要 Golden Signals 指标关联的应用日志。以下为两个核心配置片段。

4.4.1 Fluent Bit DaemonSet 配置（采集 Argo CD 标准输出）

# fluent-bit-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: fluent-bit-config
  namespace: argocd
data:
  fluent-bit.conf: |
    [SERVICE]
        Flush        1
        Log_Level    info
        Parsers_File parsers.conf

    [INPUT]
        Name              tail
        Path              /var/log/containers/*.log
        Parser            cri
        Tag               kube.*
        Mem_Buf_Limit     5MB
        Skip_Long_Lines   On

    [FILTER]
        Name                kubernetes
        Match               kube.*
        Kube_URL            https://kubernetes.default.svc:443
        Kube_CA_File        /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        Kube__File     /var/run/secrets/kubernetes.io/serviceaccount/
        Merge_Log           On
        Merge_Log_Key       log_parsed
        Annotations         Off
        Labels              Off

    [OUTPUT]
        Name                stdout
        Match               *
        Format              json_lines

4.4.2 Vector Sidecar 配置（采集应用日志并生成指标）

# vector-sidecar.toml
[sources.app_logs]
  type = "file"
  include = ["/var/log/app/*.log"]
  read_from = "beginning"

[transforms.parse_json]
  type = "remap"
  inputs = ["app_logs"]
  source = '''
    . = parse_json!(.message)
    .timestamp = now()
    .service = "argocd-app"
  '''

[transforms.log_to_metric]
  type = "log_to_metric"
  inputs = ["parse_json"]
  metrics = [
    { type = "counter", field = "error_count", name = "app_errors_total", tags = { service = "{{ .service }}" } },
    { type = "histogram", field = "response_time_ms", name = "app_response_time_ms", tags = { service = "{{ .service }}" } }
  ]

[sinks.prometheus]
  type = "prometheus_exporter"
  inputs = ["log_to_metric"]
  address = "0.0.0.0:9090"
  default_namespace = "argocd"

[sinks.elasticsearch]
  type = "elasticsearch"
  inputs = ["parse_json"]
  endpoint = "http://elasticsearch:9200"
  index = "argocd-logs-%Y-%m-%d"

4.5 选型总结与避坑指南

• 不要过度设计：如果集群规模小于 50 节点，Fluent Bit DaemonSet 足以覆盖 90% 的日志采集需求，无需引入 Sidecar 增加复杂度。
• 注意日志轮转：DaemonSet 模式依赖容器运行时日志文件，确保 kubelet 的日志轮转策略与采集引擎的 Mem_Buf_Limit 匹配，避免日志丢失。
• 避免 Logstash 在节点级部署：JVM 内存开销在节点数超过 100 时会导致明显的资源争抢，建议仅在中心化处理层使用 Logstash。
• Vector 的 Transform 能力：如果未来需要从日志中提取 Golden Signals 指标，优先选择 Vector，其 remap 和 log_to_metric 功能可以避免引入额外的指标采集组件。
• 测试多行日志：Argo CD 的 Application 事件日志可能包含多行堆栈信息，Sidecar 模式下的 Vector 或 Fluentd 对多行日志的支持更成熟。