ログストリーミング比較：Vector vs Fluent Bit vs OpenTelemetry Collector でログを収集する

📊 モダンな可観測性基盤でのログ・メトリクス・トレース収集。Vector・Fluent Bit・OpenTelemetry Collectorの特徴を徹底比較します。

オブザーバビリティパイプラインとは

アプリケーション・インフラから発生するログ・メトリクス・トレースを収集・変換・転送するデータパイプラインコンポーネントです。

主要ツール比較表

項目	Vector	Fluent Bit	OTel Collector
ライセンス	MPL 2.0	Apache 2.0	Apache 2.0
言語	Rust	C	Go
データ種類	ログ/メトリクス/トレース	ログ/メトリクス	ログ/メトリクス/トレース
メモリ使用	中	超軽量（<1MB）	中
変換処理	◎（VRL）	○（Lua）	◎（Processors）
パフォーマンス	◎	◎	○
エコシステム	独自	CNCF	◎ CNCF
設定形式	TOML	YAML/Conf	YAML
K8s向き	◎	◎	◎

各ツールの特徴

Vector

Datadog社（旧Timber Technologies）が開発したRust製の高性能可観測性パイプライン。VRL（Vector Remap Language）という独自DSLで変換処理が強力です。

主な特徴:

• ログ・メトリクス・トレースを1ツールで統一処理
• VRL（Vector Remap Language）で型安全な変換処理
• バックプレッシャー対応でデータロスを防止
• プロセス負荷が低く高スループット

# vector.toml
[sources.nginx_logs]
type = "file"
include = ["/var/log/nginx/access.log"]

[transforms.parse_nginx]
type = "remap"
inputs = ["nginx_logs"]
source = '''
  . = parse_nginx_log!(string!(.message), "combined")
  .env = "production"
'''

[sinks.loki]
type = "loki"
inputs = ["parse_nginx"]
endpoint = "http://loki:3100"
labels.app = "nginx"

[sinks.elasticsearch]
type = "elasticsearch"
inputs = ["parse_nginx"]
endpoints = ["http://elasticsearch:9200"]

向いているケース: 統合観測性・複雑な変換処理

Fluent Bit

C言語で書かれた超軽量コレクター。Kubernetesのデファクトスタンダードとしてほぼ全てのK8s環境で使われています。

主な特徴:

• メモリ1MB以下で動作
• ARM対応で組み込み・エッジにも適用
• Fluent dプロトコルとの互換性
• Kubernetes DaemonSetとして標準的に利用

# fluent-bit.conf（YAML形式）
pipeline:
  inputs:
    - name: tail
      tag: kube.*
      path: /var/log/containers/*.log
      multiline.parser: docker, cri

  filters:
    - name: kubernetes
      match: kube.*
      kube_url: https://kubernetes.default.svc:443

    - name: nest
      match: kube.*
      operation: lift
      nested_under: kubernetes

  outputs:
    - name: loki
      match: kube.*
      host: loki
      port: 3100
      labels: job=fluentbit,namespace=$kubernetes_namespace_name

    - name: s3
      match: kube.*
      bucket: my-log-bucket
      region: ap-northeast-1
      total_file_size: 50M

向いているケース: Kubernetes・エッジ・IoT・超軽量

OpenTelemetry Collector

OTel標準プロトコル（OTLP）のハブとして機能するCNCFプロジェクト。ベンダー非依存で将来性が最も高いです。

主な特徴:

• OpenTelemetry標準（OTLP）で統一
• 豊富なExporter（Prometheus/Jaeger/Grafana Cloud等）
• Agent/Gateway/Sidecarの3モードで展開
• contrib版で100以上のコンポーネント

# otel-collector-config.yaml
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
  prometheus:
    config:
      scrape_configs:
        - job_name: 'my-app'
          scrape_interval: 30s
          static_configs:
            - targets: ['my-app:8080']

processors:
  batch:
    timeout: 5s
  resource:
    attributes:
      - key: environment
        value: production
        action: insert

exporters:
  otlp:
    endpoint: https://jaeger:4317
  prometheus:
    endpoint: "0.0.0.0:8889"
  loki:
    endpoint: http://loki:3100/loki/api/v1/push

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch, resource]
      exporters: [otlp]
    metrics:
      receivers: [otlp, prometheus]
      processors: [batch]
      exporters: [prometheus]

向いているケース: OpenTelemetry標準・ベンダー非依存・将来性重視

選択ガイド

状況	推奨
統合観測性・複雑な変換	Vector
Kubernetes標準・超軽量	Fluent Bit
OTel標準・ベンダー非依存	OTel Collector

内部リンク

• OSSの監視・アラートツール比較
• OSSの分散トレース比較

外部リソース

• Vector 公式ドキュメント↗
• Fluent Bit 公式ドキュメント↗
• OpenTelemetry Collector ドキュメント↗
• ログ収集ツール比較（The New Stack）↗

FAQ

Q. FluentdとFluent Bitはどう違いますか？

Fluentdはフル機能のRuby製コレクターでメモリを多く使います。Fluent BitはC言語で書かれた軽量版で、K8sのDaemonSetとして最適です。

Q. OpenTelemetryを使い始める場合、SDKとCollectorどちらから？

アプリケーションにSDKを組み込んでOTLPでCollectorに送るのが標準的なフローです。CollectorからベンダーのバックエンドへはCollectorで設定します。

Q. Vectorのバックプレッシャーとは何ですか？

下流（送信先）が遅くなったとき、上流の取り込みも自動的に遅くしてデータロスを防ぐ機能です。Kafkaのようなバッファリングも可能です。

Q. コンテナログをどのツールで集めるのが一般的ですか？

KubernetesではFluent Bitが最もシェアが高いです。OTel Collectorも急速に普及しています。