目次
こんにちは。shirota です。
当初、Kubernetes のメトリクス監視をテーマにブログを書こうと思い、考えを巡らせていたところ、以前から気になっていた Vector というツールを思い出しました。
そんなわけで今回は軽量で超高速を謳うオブザーバビリティ・パイプライン構築ツール「Vector」について書きたいと思います！
オブザーバビリティ・パイプラインとは
まずは、オブザーバビリティ・パイプラインについて整理したいと思います。
日本語にしてみたら、「可観測性経路」という言葉になりました。
分かりにくいですね。
ある対象を観測して、その結果を送るための仕組みと考えていいでしょう。
大まかにこんな流れになります。
(1). 対象を観測(収集)する → (2).観測結果を使いやすいように整形する → (3). 保存先に送る
Web アプリケーションを例にすると
(1). 対象はアクセスログ(ログ)とか、Web サーバーの負荷(メトリクス)とか、ユーザーのアクション(トレース)とかを観測(収集)する。
(2). 観測(収集)したデータを使いやすい形に変換する。
(3). 結果をデータベースやストレージに送信する。
今回紹介する Vector も(1)〜(3)の部分を担います。
オブザーバビリティを実現するツールは色々とあるので、観測したい対象の性質に合わせて選ぶことが重要です。
Vector を入れてみる
それでは、Vector に触っていきます！
今回は Google Cloud の Compute Engine に Vector を入れて試していきます。
OS は Rocky Linux9 です。
# vector --version
vector 0.51.1 (x86_64-unknown-linux-gnu 44c8f1c 2025-11-13 15:16:05.303418529)設定ファイルを見てみます。
分かりやすいですね。
# cat /etc/vector/vector.yaml
# __ __ __
# \ \ / / / /
# \ V / / /
# \_/ \/
#
# V E C T O R
# Configuration
#
# ------------------------------------------------------------------------------
# Website: https://vector.dev
# Docs: https://vector.dev/docs
# Chat: https://chat.vector.dev
# ------------------------------------------------------------------------------
# Change this to use a non-default directory for Vector data storage:
# data_dir: "/var/lib/vector"
# Random Syslog-formatted logs
sources:
dummy_logs:
type: "demo_logs"
format: "syslog"
interval: 1
# Parse Syslog logs
# See the Vector Remap Language reference for more info: https://vrl.dev
transforms:
parse_logs:
type: "remap"
inputs: ["dummy_logs"]
source: |
. = parse_syslog!(string!(.message))
# Print parsed logs to stdout
sinks:
print:
type: "console"
inputs: ["parse_logs"]
encoding:
codec: "json"
json:
pretty: true
# Vector's GraphQL API (disabled by default)
# Uncomment to try it out with the `vector top` command or
# in your browser at http://localhost:8686
# api:
# enabled: true
# address: "127.0.0.1:8686"今回は以下の設定でローカルのファイルに出力されたログを別のファイルへ転送する形で動作確認してみます。
sources:
dummy_logs:
type: file
include:
- /var/log/vector_test/source/dummy.log
sinks:
my_sink_id:
type: file
inputs:
- dummy_logs
path: /var/log/vector_test/sink/test.log
encoding:
codec: textログは以下のシェルスクリプトで書き込んでいきます。
#! /bin/bash
INPUT_FILE=/var/log/vector_test/source/dummy.log
i=1
while true; do
echo "$(date '+%Y-%m-%d %H:%M:%S') count: $i" >> "$INPUT_FILE"
i=$((i+1))
done準備完了！実行！
すると、あれ、ログが欠損している …
何をしたかといいますと、
(1). 保存先のファイルに書き込み権限がない状態でログを出力する。
(2). 保存先のファイルに書き込み権限を付与する。(ここでバッファを利用したリトライによって、書き込めていなかったログが書き込まれると思ってました。)
(3). ソースとシンクで指定したファイルの差分を確認する。
差分を確認すると、前半のログが保存先のファイルに出力されていなかったんです。
ログを見ると以下のメッセージが …
Events dropped intentional=false count=1 reason="Unable to open the file.ファイルを開けないために、意図的にイベントを破棄しているとのこと。
ファイルをシンクに指定した場合の仕様については見当たらなかったのですが、HTTP を指定した場合のリトライ・ポリシーに以下の記述がありました。(参考)
Vector は失敗したリクエスト（ステータスコードが[408, 429]、500 以上、かつ 501 以外）を再試行します。 その他の応答は再試行されません。 再試行回数とバックオフ間隔は、request.retry_attempts および request.retry_backoff_secs オプションで制御できます。
クライアント・エラーは
408(Request Timeout)：タイムアウトの発生→リトライする。
429(Too Many Requests)：リクエストが多すぎる→リトライする。
これ以外はリトライしない。
また、サーバー・エラーは
501(Not Implemented )：サーバーが必要な機能に対応していない場合のみリトライしない。
そうすると、今回のように権限が不足していてファイルへ書き込みが出来ない場合にリトライされないのも頷けます。
エラーが一時的なものと考えられない場合は、リトライしない方針のようにも見えます。
実際に動かしてみることが大切だなぁーと改めて感じました。
最後に
公式の Github にはメトリクス(ベータ版)、トレースは Coming soon と記載がありますが、
一部の metrics は安定版、Telemetry はベータ版が提供されており、今後の発展が楽しみです。(参考)
ただ、Vector という名前、検索を工夫しないとなかなか出てこないのが歯痒い。
最後に公式 URL を貼っておきます。
https://vector.dev/
ありがとうございました！
