メインコンテンツまでスキップ

可観測性パイプラインツールVectorの紹介

· 約6分
Daichi Sato

佐藤です。

今回は、個人的に気になっている可観測性パイプラインツールのVectorを紹介します。

vector_log

Vectorとは​

Vectorは、ログやメトリクスなどの可観測性データを収集・加工・送信するRust製のツールです。

元々はTimber Technologiesという会社が主に開発していたようですが、2021年にDatadogが買収して以降はDatadogが主にメンテナンスしています。

同様のツールにはFluentdやFilebeatなどがありますが、パフォーマンス・正確性・機能の数で他のツールよりも優れていると紹介されています。

https://github.com/vectordotdev/vector#comparisons

設定ファイル​

v0.32.2まではデフォルトの設定言語がTOMLでしたが、v0.33.0からはYAMLに切り替わりました。

https://vector.dev/releases/0.33.0/

こちらの設定ファイルに、以下に紹介するコンポーネントやVRLを記述していきます。

コンポーネント​

https://vector.dev/components/

Sources -> Transforms -> Sinks の順にデータを処理していきます。

SourcesとSinksは多くのサービスに対応しており、例えば以下のようなものと連携が可能です。

  • Amazon S3やGCP Cloud Storageなどのオブジェクトストレージ
  • Amazon SQSやGCP PubSubなどのメッセージングシステム
  • OpenTelemetlyやFluentd、Datadogなど、他の可観測性ツール

また、Transformsも多くの機能がありますが、その中でも特徴的なVector Remap Language (VRL)について紹介します。

Vector Remap Language (VRL)​

VRLは、可観測性データ（ログ、メトリクス、トレース）を処理するためのスクリプト言語です。

jqライクにデータを操作することが出来るほか、多くの関数が用意されています。

詳細は以下を参照してください。

デプロイ時のアーキテクチャー​

デプロイ時のアーキテクチャーとしては、以下のパターンが紹介されています。

  • Agentとして各クライアントノードから直接ダウンストリームサービスと通信するパターン
  • Agentから一度Aggregatorにデータを集約し加工してから、ダウンストリームサービスと通信するパターン

この辺りはFluentdやFluent Bitと同様のアーキテクチャーを取ることが多くなると考えられます。

https://vector.dev/docs/setup/deployment/topologies/

Quickstart​

以下のページで紹介されている内容を基に、ローカル環境で動作確認を行いました。

https://vector.dev/docs/setup/quickstart/

まずは以下のコマンドでバイナリをインストールします。

curl --proto '=https' --tlsv1.2 -sSfL https://sh.vector.dev | bash

設定ファイルを作成します。

sources:
  in:
    type: "stdin"

sinks:
  out:
    inputs:
      - "in"
    type: "console"
    encoding:
      codec: "text"

以下のコマンドで実行します。

デフォルトでは/etc/vector/vector.yamlの設定ファイルを参照してしまうようなので、--config (-c)オプションで設定ファイルを指定します。

❯ echo 'Hello world!' | vector --config vector.yaml
・・・・・・・・・・
Hello world!

上記の結果となりました。

今回は標準入力で受け取ったデータを標準出力にそのまま出力するだけの設定ファイルを作成しましたので、特にデータの加工は行われていません。

次は、以下のような設定ファイルを作成します。

sources:
  generate_syslog:
    type: "demo_logs"
    format: "syslog"
    count: 2

transforms:
  remap_syslog:
    inputs:
      - "generate_syslog"
    type: "remap"
    source: |
      structured = parse_syslog!(.message)
      . = merge(., structured)

sinks:
  emit_syslog:
    inputs:
      - "remap_syslog"
    type: "console"
    encoding:
      codec: "json"

前回と同様に、設定ファイルを指定して実行します。

今回はsourcesが標準入力ではなくdemo_logsですので、echoは不要です。

❯ vector --config vector.yaml
・・・・・・・・・・
{"appname":"devankoshal","facility":"cron","hostname":"make.xn--flw351e","message":"We're gonna need a bigger boat","msgid":"ID632","procid":3876,"service":"vector","severity":"warning","source_type":"demo_logs","timestamp":"2023-12-21T06:41:45.661Z","version":1}
{"appname":"AnthraX","facility":"local6","hostname":"up.luxe","message":"#hugops to everyone who has to deal with this","msgid":"ID389","procid":120,"service":"vector","severity":"alert","source_type":"demo_logs","timestamp":"2023-12-21T06:41:46.662Z","version":2}
・・・・・・・・・・

上記の結果となりました。

詳細は割愛しますが、transformsでsyslog形式のデータをパースしてJson形式に変換し、sinksで標準出力にJson形式で出力されました。

所感と注意点​

個人的には設定ファイルが分かりやすいことと、コンポーネントが最初から含まれていることが気に入りました。

例えばFluentdの場合、データの取得元や送信先によってはプラグインをインストールした上でコンテナイメージをビルドする必要があります。

プラガブルなアーキテクチャであることは余分な機能を削げるという面では良いのですが、気軽に使えるという点では初めから機能が揃っているVectorの方が優れていると感じました。

注意点として、ブログ執筆時点で最新バージョンはv0.34.1であり、v1にはまだ達していません。

また、特定のコンポーネントはステータスがベータであることに注意が必要です。

現在は検証段階ですので、実際に運用を開始した後に別途記事を作成します。