---
title: "Vectorでログ収集する手順：VRLでの変換・Kubernetes配置とFluent Bitとの選び分け【v0.59対応】"
url: "https://www.issoh.co.jp/tech/details/18405/"
published: 2026-10-16
updated: 2026-10-16
categories: ["監視・オブザーバビリティ"]
publisher: "株式会社一創"
---

# Vectorでログ収集する手順：VRLでの変換・Kubernetes配置とFluent Bitとの選び分け【v0.59対応】

Vectorは、ログ・メトリクス・トレースを集めて加工し、LokiやElasticsearch、S3などへ送るRust製のデータパイプラインです。この記事では、インストールからNginxのアクセスログを構造化してLokiへ送る設定、単体テストでの検証、変換に失敗したログの逃がし方までを設定例付きで示します。後半ではKubernetesでの配置と2026年10月6日公開のv0.59.0で変わった要件を整理し、Fluent Bitとどちらを選ぶかの判断基準を言い切ります。

## まとめ：Vectorを選ぶのは変換処理が重い現場、軽さ優先ならFluent Bit

Vectorの強みは、VRL（Vector Remap Language）という専用言語でログの解析・整形・振り分けを書け、その変換を`vector test`で単体テストできる点にあります。複数の宛先へ形を変えて送る、個人情報を落としてから保管するといった加工が多い現場では、設定ファイルの見通しが良くなります。

反対に、ログを集めてそのまま1か所へ送るだけなら、Fluent Bitのほうが実績と情報量で勝ります。Vectorは版番号がまだ0.x系で、2026年は約6週間ごとに新しい版が出ており、10月6日のv0.59.0には破壊的変更が6件含まれていました。導入するなら、版を固定し、アップグレードガイドを読んでから上げる運用を最初から組み込んでください。

## Vectorのログ収集をsources・transforms・sinksでつなぐ仕組み

Vectorの設定は「どこから読むか」「どう変えるか」「どこへ送るか」の3種類の部品を、名前で数珠つなぎにするだけの構造です。最初にこの関係をつかむと、公式ドキュメントの膨大な部品一覧も読みやすくなります。

### Rust製・MPL-2.0のVectorとDatadogが保守する開発体制の実情

Vectorの[GitHubリポジトリ](https://github.com/vectordotdev/vector)はMPL-2.0ライセンスで公開され、READMEには「DatadogのCommunity Open Source Engineeringチームが保守している」と明記されています。1つのバイナリでエージェント（各サーバーで収集する役）とアグリゲーター（集約して送る役）の両方を担える点が設計の特徴です。

READMEは「同分野のどの代替より最大10倍速い」とうたっていますが、同じページの比較表では正規表現での解析処理でFluent Bit（20.5MiB/s）がVector（13.2MiB/s）を上回っています。性能は提供元の計測なので、選定の決め手にはせず、自社のログで測ってください。

### 設定1枚でつなぐsources・transforms・sinksとinputsの関係

[設定ドキュメント](https://vector.dev/docs/reference/configuration/)によると、形式はYAML・TOML・JSONに対応し、推奨はYAMLです。Linuxのパッケージで入れた場合の既定パスは`/etc/vector/vector.yaml`になります。`sources`に読み取り元、`transforms`に加工、`sinks`に送信先を書き、後段の部品が`inputs`で前段の名前を指定します。

1つのsourceを複数のsinkが`inputs`で参照すれば、同じログを検索用のLokiと長期保管用のS3へ別々の形で送れます。ファイルの読み取り位置などの状態は`data_dir`に保存されるため、ここを永続ディスクに置かないと再起動のたびに読み直しや取りこぼしが起きます。

## Vectorをインストールしてファイルのログを収集し変換するまでの検証手順

ここからは、Nginxのアクセスログを読み、項目ごとに分解してGrafana Lokiへ送る最小構成を作ります。手元のDockerで再現できる形にしてあります。

### シェルスクリプト・Docker・Helmの3経路から選ぶインストール方法

[インストールのドキュメント](https://vector.dev/docs/setup/installation/)には、インストーラのスクリプト、APT・RPM・Homebrew・MSI等のパッケージ、Docker、Helmが並んでいます。サーバーへ直接入れるならスクリプトかパッケージ、検証ならDocker、KubernetesならHelmを選びます。

```
# サーバーへ直接入れる（対話なしで実行する場合は bash -s -- -y）
curl --proto '=https' --tlsv1.2 -sSfL https://sh.vector.dev | bash

# Dockerで試す（版を固定したタグを使う）
docker run -d \
  -v $PWD/vector.yaml:/etc/vector/vector.yaml:ro \
  -p 8686:8686 \
  --name vector \
  timberio/vector:0.59.0-debian

# Kubernetesへ入れる（エージェントとして各ノードに配置）
helm repo add vector https://helm.vector.dev
helm repo update
printf 'role: Agent\n' > values.yaml
helm install vector vector/vector -n vector --create-namespace -f values.yaml
```

[Dockerのページ](https://vector.dev/docs/setup/installation/platforms/docker/)によると、イメージは`debian`のほかに`alpine`・`distroless-libc`・`distroless-static`の4種類です。`latest`は使わず、版番号つきのタグで固定してください。Helmチャートは何も指定しないとアグリゲーターとして入るので、各ノードで収集するなら`role: Agent`を必ず書きます。

### Nginxログをparse\_nginx\_logで構造化するvector.yamlの設定

次の設定は、Nginxのcombined形式のログを読み、VRLの[組み込み関数](https://vector.dev/docs/reference/vrl/functions/)`parse_nginx_log`で分解してLokiへ送ります。解析に失敗した行は捨てずに別の出力へ回します。

```
data_dir: /var/lib/vector

sources:
  nginx_access:
    type: file
    include:
      - /var/log/nginx/access.log
    read_from: end

transforms:
  parse_nginx:
    type: remap
    inputs: [nginx_access]
    drop_on_error: true
    reroute_dropped: true
    source: |
      . |= parse_nginx_log!(.message, "combined")
      del(.message)

sinks:
  loki:
    type: loki
    inputs: [parse_nginx]
    endpoint: http://loki:3100
    encoding:
      codec: json
    labels:
      service: nginx
      source: vector
  parse_failed:
    type: console
    inputs: [parse_nginx.dropped]
    encoding:
      codec: json
```

`parse_nginx_log`の戻り値は`client`・`request`・`status`・`size`・`agent`などの項目で、`status`は数値型で返ります。Lokiのラベルには`service`のような値の種類が少ない項目だけを置きます。クライアントIPやパスをラベルにすると索引が膨らむので、本文のJSONに残してクエリ側で絞り込んでください。Lokiの側の設計は[Grafana Lokiの仕組みとLogQLの書き方](https://www.issoh.co.jp/tech/details/9570/)で解説しています。

### vector validateとvector testで設定ミスを本番投入前に止める手順

[CLIリファレンス](https://vector.dev/docs/reference/cli/)によると、`vector validate`は設定を検査して終了し、`--deny-warnings`を付けると警告も失敗として扱います。`vector test`は設定ファイル内の`tests`を実行します（ドキュメント上は実験的な機能の扱い）。先ほどの`parse_nginx`へ1行のログを入れて、結果を確かめるテストは次のとおりです。

```
tests:
  - name: nginx_combined_parse
    inputs:
      - insert_at: parse_nginx
        type: log
        log_fields:
          message: '203.0.113.10 - - [16/Oct/2026:10:00:00 +0900] "GET /healthz HTTP/1.1" 200 2 "-" "curl/8.5.0"'
    outputs:
      - extract_from: parse_nginx
        conditions:
          - type: vrl
            source: |
              assert_eq!(.status, 200)
              assert_eq!(.request, "GET /healthz HTTP/1.1")
              assert!(!exists(.message))

# 実行（CIでも同じコマンドを使う）
# vector validate --deny-warnings /etc/vector/vector.yaml
# vector test /etc/vector/vector.yaml
```

[単体テストのドキュメント](https://vector.dev/docs/reference/configuration/unit-tests/)は、テストを本体と別ファイルに分け、`vector test`に複数ファイルを渡す方法も示しています。ログの形式はアプリの改修で変わりやすいので、実際のログから1行ずつテストを足していくと、形式変更による解析漏れをCIで止められます。

## VRLでログを変換するときのエラー処理と失敗イベントの退避先の設計

Vectorで運用事故につながりやすいのは、解析できなかったログの行方です。既定の挙動を知らずに書くと、壊れた行がそのまま送られたり、黙って消えたりします。

### 失敗する関数の!付き呼び出しとdrop\_on\_errorの組み合わせ方

VRLでは、失敗しうる関数（fallible）を呼ぶときにエラー処理を書かないと設定の読み込み時に弾かれます。`parse_nginx_log!`のように`!`を付けると「失敗したら実行時エラーにする」という実行時のエラー処理の宣言です。[remapのドキュメント](https://vector.dev/docs/reference/configuration/transforms/remap/)によると、実行時エラーが起きたイベントは、それまでの変更を破棄した元の形で後段へ送られます。

つまり`drop_on_error`が既定の`false`のままだと、解析できなかった生の行がLokiへ混ざります。項目が揃っている前提でダッシュボードを組むなら、`drop_on_error: true`にして後段へ流さない設定が安全です。失敗を許容して次の書式を試したいときは、`parse_nginx_log(.message, "combined") ?? parse_nginx_log(.message, "main")`のように`??`でつなぎます。

### reroute\_droppedで変換失敗ログを別の出力へ逃がす構成

`drop_on_error: true`だけでは、失敗した行は消えてしまいます。`reroute_dropped: true`を併用すると、捨てる代わりに`parse_nginx.dropped`という名前の出力へ回るため、先の設定例のように別のsinkで受ける構成が可能です。検証中は`console`で画面に出し、本番ではS3や別のLokiテナントへ送ると、解析ルールの漏れを後から拾えます。

流れているイベントを確かめるには`vector tap`と`vector top`が便利です。どちらも`api.enabled: true`で有効になるAPIに接続します。[APIの設定ドキュメント](https://vector.dev/docs/reference/configuration/api/)は「認証に対応していない」と警告しており、既定の待ち受けは`127.0.0.1:8686`です。外部から届く`0.0.0.0`で公開したまま本番運用するのは避けてください。

## Kubernetesと複数サーバーのAgent・Aggregator配置とログの耐久性

サーバーが数台を超えると、各ノードから直接送るか、いったん集約するかを決める必要があります。ここではKubernetesでの収集範囲と、ログを失わないための構成を整理します。

### kubernetes\_logsソースの読み取り範囲とv0.59で上がったクラスタ要件

[kubernetes\_logsソース](https://vector.dev/docs/reference/configuration/sources/kubernetes%5Flogs/)は、ノードの`/var/log/pods`への読み取り権限を必要とし、`kubernetes.pod_name`・`kubernetes.pod_namespace`・`kubernetes.container_name`などのメタデータを各ログに付けます。新しいログファイルを探す間隔（`glob_minimum_cooldown_ms`）の既定は60,000ミリ秒です。起動直後のPodのログが遅れて届くと感じたら、まずこの値を確かめます。

v0.59.0の[アップグレードガイド](https://vector.dev/highlights/2026-10-05-0-59-0-upgrade-guide/)では、Kubernetes 1.31のサポートが外れ、APIのバインディングがv1.32に上がりました。クラスタを1.32以上にしてからVectorを上げる順番になります。同じ版では、`http`ソースの旧名が削除され`http_server`に一本化されるなど、破壊的変更が6件あります。

### 分散型・集約型・ストリーム型の3構成とディスクバッファの最小256MiB

[配置トポロジーのドキュメント](https://vector.dev/docs/setup/deployment/topologies/)は、各ノードから直接送る分散型、エージェントからアグリゲーターへ集める集約型、間にKafkaを置くストリーム型の3つを示しています。分散型は部品が少ない反面、ホスト上のバッファしか持たず、下流へ小さなリクエストが大量に飛びます。数十ノード規模なら集約型を基本にし、ログの欠損が許されない監査用途だけストリーム型を検討してください。

送信先が止まったときの持ちこたえ方は[バッファの設計](https://vector.dev/docs/architecture/buffering-model/)で決まります。sinkの既定はメモリ上に500イベントで、満杯になると空くまで待つ（`block`）動作です。再起動やクラッシュをまたいで保持したいなら`type: disk`を指定しますが、ディスクバッファには約256MiBの最小サイズがあり、それより小さい容量は確保できません。

## Fluent Bitと比べたVectorの採用条件と見送るべき運用環境の線引き

ログ収集エージェントの選定でVectorと並べられるのは、Fluent Bit、Fluentd、OpenTelemetry Collectorです。ここでは最も比較されるFluent Bitとの違いから、どちらを採るかを決めます。

### 実装言語・ライセンス・プロジェクト体制で並べるVectorとFluent Bit

次の表は、2026年10月16日時点の各リポジトリと公式ドキュメントの記載をまとめたものです。

| 比較項目          | Vector           | Fluent Bit             |
| ------------- | ---------------- | ---------------------- |
| 実装言語          | Rust             | C                      |
| ライセンス         | MPL-2.0          | Apache-2.0             |
| プロジェクト体制      | Datadogが保守       | CNCF卒業プロジェクトFluentdの傘下 |
| 最新版（10月16日時点） | v0.59.0（10月6日）   | v5.1.4（10月16日）         |
| 変換の書き方        | VRLで手続きを書く       | フィルタ部品の組み合わせ・Lua       |
| 設定の単体テスト      | vector testで標準対応 | 標準の仕組みなし               |

[Fluent Bitのドキュメント](https://docs.fluentbit.io/manual)は、同プロジェクトをFluentd傘下のCNCF卒業サブプロジェクトと位置づけています。[Fluent BitのGitHubリポジトリ](https://github.com/fluent/fluent-bit)はC言語製で、組み込み機器やコンテナのサイドカーのような小さな環境で使われてきた実績を持つプロジェクトです。製品の詳細は[Fluent BitとFluentdの違いとAWSでの設定例](https://www.issoh.co.jp/tech/details/12612/)にまとめています。

### Vectorを採用する条件と、Fluent Bitのままにしておく場面

Vectorを採るのは、1つのログを複数の宛先へ違う形で送る、マスキングや項目の付け替えが多い、変換ルールをテスト付きでコード管理したい、の3条件のうち2つ以上に当てはまる場合です。ElasticsearchとS3の両方へ送り分けている現場や、Datadogの費用を抑えるために送る前に間引きたい現場が典型例です。送信先側の設計は[Elasticsearchのログ収集とインデックス分割](https://www.issoh.co.jp/tech/details/17017/)や[Datadogログ収集の3経路とパイプライン設計](https://www.issoh.co.jp/tech/details/16595/)も参考にしてください。

一方、Amazon EKSやECSでAWS公式のFluent Bitイメージを使い、CloudWatch Logsへ送るだけの構成なら、置き換える理由はありません。トレースまで同じ部品で扱いたい場合は、Vectorより標準仕様に沿った[OpenTelemetry Collector](https://www.issoh.co.jp/tech/details/16572/)が先の候補になります。どの構成でも、収集基盤を入れたあとの監視ルールや障害対応の体制づくりで手が足りない場合は、[システムの保守運用・内製化支援](https://www.issoh.co.jp/service/system/maintenance/)で設計から引き受けています。

### v0.x系のまま続く破壊的変更と本番環境のアップグレード運用の負担

GitHub Releasesを見ると、v0.57.0が7月14日、v0.58.0が8月26日、v0.59.0が10月6日と、約6週間おきに新しい版が出ています。v0.59.0だけでも破壊的変更が6件あり、Avroのスキーマ解析の厳格化や`vector` sinkの`compression`で真偽値が使えなくなる変更が含まれます。

この速さに追従する体制が無いなら、Vectorは見送るべきです。版を上げずに放置すると、Kubernetesを上げた時点で要件を満たさなくなります。採用するなら、版をタグで固定し、アップグレードガイドの確認と`vector test`の実行を四半期ごとの定例作業に組み込んでください。

## Vectorのログ収集でよくある質問：料金・Fluentd移行・Windows対応

Vectorの導入を検討するときによく出る疑問に、公式ドキュメントの記載をもとに答えます。

### Vectorは無料で使えますか？

本体はMPL-2.0のオープンソースで、ライセンス費用はかかりません。MPL-2.0はファイル単位のコピーレフトなので、Vectorのソースを改変して配布する場合は、改変したファイルのソースを公開する義務が生じる点だけ注意してください。設定ファイルを書いて使うだけなら、自社の設定やアプリのコードを公開する義務は生じません。

### FluentdからVectorへ移行できますか？

移行はできますが、設定の自動変換の仕組みは用意されていません。Fluentdのinput・filter・outputを、Vectorのsources・transforms・sinksへ1つずつ書き直す作業になります。プラグインに依存した独自の処理はVRLで書き直すことになるため、移行の前に[Fluentdの設定ファイルの構成](https://www.issoh.co.jp/tech/details/17743/)を棚卸しして、使っているプラグインを洗い出してください。

### VectorはWindowsサーバーのログも収集できますか？

公式のインストール対象にWindowsが含まれており、MSIのパッケージが用意されています。ファイルに書き出されたアプリのログは`file`ソースで読めます。ただし対応OSの一覧はLinux系が中心で、Windowsのイベントログを主に集める用途なら、配布元の対応状況を最新のドキュメントで確認してから決めてください。

### VRLの書き方を手元で試す方法はありますか？

ブラウザで動く[VRL playground](https://playground.vrl.dev/)が公開されており、サンプルのログとVRLのプログラムを入れると変換結果をその場で確認できます。インストール済みの環境なら`vector vrl`コマンドでも対話的に試すことが可能です。書いた処理は、本文で示した`tests`に移して残しておくと、後から変更したときの確認に使えます。

### VectorとDatadogのObservability Pipelinesは同じものですか？

別の製品として扱ってください。Vectorは誰でも使えるオープンソースで、設定ファイルを自分で書いて運用します。[Observability Pipelines](https://www.datadoghq.com/product/observability-pipelines/)はDatadogの有償製品で、テンプレートからの作成、画面上でのデプロイ、流れているデータの確認（Live Capture）、Terraformへの書き出しといった管理機能を持ちます。製品ページにVectorとの関係は書かれていないため、Datadogの契約が無い現場はVector単体で組むのが現実的です。

## 関連記事

- [Fluent Bitとは？読み方・Fluentdとの違い・AWSでの設定例【v5.1対応】](https://www.issoh.co.jp/tech/details/12612/)：Vectorと最も比較される軽量エージェントの解説。
- [Grafana Lokiとは？仕組み・Alloyでの導入手順とLogQLの書き方【v3.7】](https://www.issoh.co.jp/tech/details/9570/)：本記事の送信先にしたログ基盤の設計。
- [OpenTelemetry Collector Contribとは｜coreとの違いとocbで作る自作distro](https://www.issoh.co.jp/tech/details/16572/)：トレースまで扱う場合の比較候補。
- [オブザーバビリティツール比較｜選定軸と課金モデル・体制別の選び方【2026年8月時点】](https://www.issoh.co.jp/column/details/16502/)：収集の先にある監視製品の選び方。
- [オブザーバビリティ（可観測性）とは？監視・モニタリング・APMとの違いと使い分けを解説](https://www.issoh.co.jp/column/details/3077/)：ログ収集を含む監視領域全体の位置づけ。

---

出典: [Vectorでログ収集する手順：VRLでの変換・Kubernetes配置とFluent Bitとの選び分け【v0.59対応】](<https://www.issoh.co.jp/tech/details/18405/>)（株式会社一創）