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リポジトリは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の関係
設定ドキュメントによると、形式は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経路から選ぶインストール方法
インストールのドキュメントには、インストーラのスクリプト、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.yamlDockerのページによると、イメージはdebianのほかにalpine・distroless-libc・distroless-staticの4種類です。latestは使わず、版番号つきのタグで固定してください。Helmチャートは何も指定しないとアグリゲーターとして入るので、各ノードで収集するならrole: Agentを必ず書きます。
Nginxログをparse_nginx_logで構造化するvector.yamlの設定
次の設定は、Nginxのcombined形式のログを読み、VRLの組み込み関数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: jsonparse_nginx_logの戻り値はclient・request・status・size・agentなどの項目で、statusは数値型で返ります。Lokiのラベルにはserviceのような値の種類が少ない項目だけを置きます。クライアントIPやパスをラベルにすると索引が膨らむので、本文のJSONに残してクエリ側で絞り込んでください。Lokiの側の設計はGrafana Lokiの仕組みとLogQLの書き方で解説しています。
vector validateとvector testで設定ミスを本番投入前に止める手順
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単体テストのドキュメントは、テストを本体と別ファイルに分け、vector testに複数ファイルを渡す方法も示しています。ログの形式はアプリの改修で変わりやすいので、実際のログから1行ずつテストを足していくと、形式変更による解析漏れをCIで止められます。
VRLでログを変換するときのエラー処理と失敗イベントの退避先の設計
Vectorで運用事故につながりやすいのは、解析できなかったログの行方です。既定の挙動を知らずに書くと、壊れた行がそのまま送られたり、黙って消えたりします。
失敗する関数の!付き呼び出しとdrop_on_errorの組み合わせ方
VRLでは、失敗しうる関数（fallible）を呼ぶときにエラー処理を書かないと設定の読み込み時に弾かれます。parse_nginx_log!のように!を付けると「失敗したら実行時エラーにする」という実行時のエラー処理の宣言です。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の設定ドキュメントは「認証に対応していない」と警告しており、既定の待ち受けは127.0.0.1:8686です。外部から届く0.0.0.0で公開したまま本番運用するのは避けてください。
Kubernetesと複数サーバーのAgent・Aggregator配置とログの耐久性
サーバーが数台を超えると、各ノードから直接送るか、いったん集約するかを決める必要があります。ここではKubernetesでの収集範囲と、ログを失わないための構成を整理します。
kubernetes_logsソースの読み取り範囲とv0.59で上がったクラスタ要件
kubernetes_logsソースは、ノードの/var/log/podsへの読み取り権限を必要とし、kubernetes.pod_name・kubernetes.pod_namespace・kubernetes.container_nameなどのメタデータを各ログに付けます。新しいログファイルを探す間隔（glob_minimum_cooldown_ms）の既定は60,000ミリ秒です。起動直後のPodのログが遅れて届くと感じたら、まずこの値を確かめます。
v0.59.0のアップグレードガイドでは、Kubernetes 1.31のサポートが外れ、APIのバインディングがv1.32に上がりました。クラスタを1.32以上にしてからVectorを上げる順番になります。同じ版では、httpソースの旧名が削除されhttp_serverに一本化されるなど、破壊的変更が6件あります。
分散型・集約型・ストリーム型の3構成とディスクバッファの最小256MiB
配置トポロジーのドキュメントは、各ノードから直接送る分散型、エージェントからアグリゲーターへ集める集約型、間にKafkaを置くストリーム型の3つを示しています。分散型は部品が少ない反面、ホスト上のバッファしか持たず、下流へ小さなリクエストが大量に飛びます。数十ノード規模なら集約型を基本にし、ログの欠損が許されない監査用途だけストリーム型を検討してください。
送信先が止まったときの持ちこたえ方はバッファの設計で決まります。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のドキュメントは、同プロジェクトをFluentd傘下のCNCF卒業サブプロジェクトと位置づけています。Fluent BitのGitHubリポジトリはC言語製で、組み込み機器やコンテナのサイドカーのような小さな環境で使われてきた実績を持つプロジェクトです。製品の詳細はFluent BitとFluentdの違いとAWSでの設定例にまとめています。
Vectorを採用する条件と、Fluent Bitのままにしておく場面
Vectorを採るのは、1つのログを複数の宛先へ違う形で送る、マスキングや項目の付け替えが多い、変換ルールをテスト付きでコード管理したい、の3条件のうち2つ以上に当てはまる場合です。ElasticsearchとS3の両方へ送り分けている現場や、Datadogの費用を抑えるために送る前に間引きたい現場が典型例です。送信先側の設計はElasticsearchのログ収集とインデックス分割やDatadogログ収集の3経路とパイプライン設計も参考にしてください。
一方、Amazon EKSやECSでAWS公式のFluent Bitイメージを使い、CloudWatch Logsへ送るだけの構成なら、置き換える理由はありません。トレースまで同じ部品で扱いたい場合は、Vectorより標準仕様に沿ったOpenTelemetry Collectorが先の候補になります。どの構成でも、収集基盤を入れたあとの監視ルールや障害対応の体制づくりで手が足りない場合は、システムの保守運用・内製化支援で設計から引き受けています。
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の設定ファイルの構成を棚卸しして、使っているプラグインを洗い出してください。
VectorはWindowsサーバーのログも収集できますか？
公式のインストール対象にWindowsが含まれており、MSIのパッケージが用意されています。ファイルに書き出されたアプリのログはfileソースで読めます。ただし対応OSの一覧はLinux系が中心で、Windowsのイベントログを主に集める用途なら、配布元の対応状況を最新のドキュメントで確認してから決めてください。
VRLの書き方を手元で試す方法はありますか？
ブラウザで動くVRL playgroundが公開されており、サンプルのログとVRLのプログラムを入れると変換結果をその場で確認できます。インストール済みの環境ならvector vrlコマンドでも対話的に試すことが可能です。書いた処理は、本文で示したtestsに移して残しておくと、後から変更したときの確認に使えます。
VectorとDatadogのObservability Pipelinesは同じものですか？
別の製品として扱ってください。Vectorは誰でも使えるオープンソースで、設定ファイルを自分で書いて運用します。Observability PipelinesはDatadogの有償製品で、テンプレートからの作成、画面上でのデプロイ、流れているデータの確認（Live Capture）、Terraformへの書き出しといった管理機能を持ちます。製品ページにVectorとの関係は書かれていないため、Datadogの契約が無い現場はVector単体で組むのが現実的です。
関連記事
- Fluent Bitとは？読み方・Fluentdとの違い・AWSでの設定例【v5.1対応】：Vectorと最も比較される軽量エージェントの解説。
- Grafana Lokiとは？仕組み・Alloyでの導入手順とLogQLの書き方【v3.7】：本記事の送信先にしたログ基盤の設計。
- OpenTelemetry Collector Contribとは｜coreとの違いとocbで作る自作distro：トレースまで扱う場合の比較候補。
- オブザーバビリティツール比較｜選定軸と課金モデル・体制別の選び方【2026年8月時点】：収集の先にある監視製品の選び方。
- オブザーバビリティ（可観測性）とは？監視・モニタリング・APMとの違いと使い分けを解説：ログ収集を含む監視領域全体の位置づけ。
