動作要件
Yagra は、1 台のホストの上で Docker のコンテナ群として動きます。機能の一覧から受ける印象より、 ずっと軽いです。任意の機能をすべて有効にしたフルスタックでも、メモリは 1.0〜1.4 GB です。
この数字を動かすのは、監視するノードの数ではありません。どの任意ストアを動かすかと、 何系列のメトリクスをどれだけの期間残すかです。
以下の表では、実際に測った値と、測っていない値を区別しています。推定にはその旨を書いています。
推奨ホストスペック
Section titled “推奨ホストスペック”| ノード数 | vCPU | RAM | ディスク | 根拠 | |
|---|---|---|---|---|---|
| 最小 — 評価用 | 〜50 | 2 | 4 GB | 20 GB | 実測。既定のインストールでメモリ 1.0〜1.4 GB、イメージ約 2.3 GB |
| 推奨 — フルスタック、全機能有効 | 〜500 | 4 | 8 GB | 100 GB | 全機能を有効にした 4 vCPU / 7.6 GiB ホストで実測 |
| 中規模 | 〜5,000 | 8 | 16 GB | 500 GB 〜 1 TB 以上 | 推定。 ディスクを決めるのはノード数ではなく収集するインターフェース数です。後述の計算式を使ってください |
| 大規模 | 〜50,000 | 16 | 32 GB | 1 TB 以上 | 推定（core 自体を除く。後述） |
実測なのはメモリとディスクの列で、ノード数の列は実測ではありません。 上 2 行のメモリとディスクは、
その規模のホストで docker stats と docker images を実行して得た値です。一方でノード数の上限は、
どの行も外挿です。継続して動かしているフリートで最大のものは 32 ノードであり、後述の 50,000 ノードの
数値も、実際にポーリングしたフリートではなく合成データのリプレイによるものです。
ですからノード数の列は出発点として扱い、あとは Settings ▸ Yagra health を見てください。core と 各ポーラーの実際の CPU、ロードアベレージ、メモリ、ファイルシステムごとの使用量が出ます。
動作条件は、Docker と Docker Compose プラグインが動く x86-64 / ARM64 のホストであることです。
Linux では NET_RAW ケーパビリティが必要です。ポーラーが raw ソケットで ICMP を送るためです。
同梱の Compose ファイルが、これを付けます。
既定のインストールが実際に起動するもの
Section titled “既定のインストールが実際に起動するもの”docker-compose.deploy.yml には Compose のプロファイルが 1 つも定義されていません。ですから
docker compose up -d は、ClickHouse も VictoriaLogs も IP→ASN アップデータも含めて、すべての
サービスを起動します。任意ストアは opt-in ではなく opt-out です。要らない場合は、そのサービスを
ファイルから削除してください（あわせて core 側の対応する URL の設定も外します）。
つまりこのファイルを編集していない限り、見積もりの基準は「すべて有効」の行 — メモリ 1.0〜1.4 GB、 イメージ約 2.3 GB — であって、必須サービスだけの小計ではありません。
コンテナ別メモリ使用量（実測）
Section titled “コンテナ別メモリ使用量（実測）”稼働中の v0.3.3 デプロイ 2 台に対して docker stats --no-stream で実測しました。どちらも監視ノード
32 件、オプション機能はすべて有効です。ホスト A は 4 vCPU / 7.6 GiB、ホスト B は 8 vCPU / 7.8 GiB:
| コンテナ | ホスト A | ホスト B | 役割 |
|---|---|---|---|
clickhouse |
872 MiB | 696 MiB | トラフィックフロー（NetFlow/IPFIX/sFlow） — 任意。既定で起動する |
core |
141 MiB | 111 MiB | 必須 — オーケストレーション、スケジューラ、API |
victoriametrics |
104 MiB | 117 MiB | 必須 — メトリクスストア |
victorialogs |
98 MiB | 11 MiB | 受動イベント（syslog、トラップ） — 任意。既定で起動する |
poller |
58 MiB | 62 MiB | 必須 — ICMP/SNMP/API による監視 |
postgres |
48 MiB | 39 MiB | 必須 — 設定、ユーザー、アラート履歴 |
nats |
17 MiB | 6 MiB | 必須 — core⇄poller のバス |
yagra-updater |
7 MiB | 1 MiB | 同梱 — インプレースアップグレード |
web |
6 MiB | 8 MiB | 必須 — WebUI（nginx） |
redis |
6 MiB | 3 MiB | 同梱 — ポーラーの死活と割り当て |
ipasn-updater |
5 MiB | 8 MiB | フロー向け IP→ASN 補完 — 任意。既定で起動する |
2 つの列はバージョンも監視対象も同じです。ですからこの幅は、サービスの種類による違いではなく、
そのサービスが何をしているかによる違いです。いちばん幅が大きいのは victorialogs で、これは中身が
ほぼキャッシュであり、取り込み量と検索量に応じて増えます。低いほうの数字を前提に計画しないで
ください。
合計すると:
| 構成 | メモリ |
|---|---|
| 必須サービスのみ — Compose ファイルから他を削除した場合 | 約 0.4 GB |
| ＋受動イベント監視 | 約 0.4〜0.5 GB |
| すべて有効 — 既定のインストールで動くのはこれ | 約 1.0〜1.4 GB |
ClickHouse だけで、スタック全体の半分以上を占めます。 トラフィックフローを集めないのであれば、 これを外すのが、メモリと CPU の両面でいちばん効く削減です。
規模が大きくなったとき、最初に別ホストへ切り出すべきサービスでもあります。I/O とページキャッシュを
多く使うからです。切り出しに必要な変更は、YAGRA_CLICKHOUSE_URL だけです。
これまで測ったどの規模でも、CPU が制約になったことはありません。
上の 32 ノードのデプロイ 2 台では、Yagra のコンテナ全体で 1 コアの 6% と 38% でした
（docker stats の瞬間値）。どちらのホストでも、その 70% 以上は ClickHouse と VictoriaLogs の
後片付けです。後述の 50,000 ノードのテストでも、core の平均は 1 コアの 11.8% です。
ですからサイジングは、RAM とディスクを基準に行ってください。CPU は、ポーリングの一時的な集中と レポート生成に足りる余裕があれば十分です。計画の軸にする数字ではありません。
ディスク使用量を決めるのは、ノード数ではなく メトリクスの系列数 × 保持期間 です:
バイト数 ≈ 系列数 × (86400 ÷ 収集間隔秒) × 保持日数 × 1 サンプルあたり約 1 バイト上の 2 台で実測すると、1 サンプルあたりの費用はインデックス込みで 0.72 バイトと 0.78 バイトでした。サンプルのデータ本体だけなら 0.39〜0.41 バイトまで圧縮されます。残りは 転置インデックスで、この 2 台ではディスク上のバイト数の 46〜48% を占めています。ですから 「1 サンプルあたり 1 バイト」は今も安全側の上限ですが、その余裕を作っているのは圧縮率ではなく インデックスぶんの取り置きです。（この 2 台は系列の入れ替わりが多いラボ機で、インデックスの比率が 大きめに出ます。安定運用のフリートではもっと小さくなるはずです。）
ノード 1 台は何系列か
Section titled “ノード 1 台は何系列か”収集対象ごとの実測値です:
| 対象 | 系列数 | 内訳 |
|---|---|---|
| ICMP チェック（応答があるノード） | 2 | icmp_loss_pct と icmp_rtt_ms。応答が無いノードは loss だけが残る |
| SNMP ノードの基本 | 約 4 | snmp_up、snmp_neighbor_count、snmp_l3_address_count、snmp_routing_adjacency_count |
| 収集するインターフェース 1 本ごと | 11 | admin/oper ステータス、HC in/out オクテット、HC in/out ユニキャストパケット、in/out エラー、in/out 破棄、リンク速度 |
| …光モジュール対応の場合 | +2 | if_rx_power_dbm、if_tx_power_dbm |
ベンダー固有の健全性メトリクス（CPU、メモリ、温度）が、ノードごとにさらに数本加わります。
派生値（使用率、bps、パケットレート）は問い合わせ時に計算していて、どこにも保存していません。 ですから系列は 1 本も消費しません。
インターフェース 1 本は、それがぶら下がっているノード 1 台より高くつきます。 計画の軸にすべき 数字はこれです。
出荷時の既定 — 60 秒間隔・VictoriaMetrics の保持 12 か月 — での試算を 2 つ挙げます:
| フリート | 系列数 | メトリクスのディスク |
|---|---|---|
| ICMP のみのノード 50,000 件 | 約 100,000 | 約 53 GB |
| SNMP ノード 5,000 件 × 収集インターフェース 24 本 | 約 1,350,000 | 約 710 GB |
2 行目はノード数が 10 分の 1 なのに、ディスクは 13 倍以上です。ここが要点です。ディスクを埋めるのは ノードの数ではなく、インターフェースや表の監視です。 メトリクスの保持期間を 24 か月に延ばすと、 どちらの数字も 2 倍になります。
系列の種類の多さには注意してください。上限のないラベルは、ボリュームを埋めるいちばんの近道です。
これに加えて次のぶんを見込んでください:
- コンテナイメージ — v0.3.3 での実測。Yagra の 3 イメージで 620 MB、基盤側のイメージがさらに
910 MB（PostgreSQL 424 MB、アップデータが使う
dockerCLI 291 MB、Redis 58 MB、 VictoriaMetrics 54 MB、VictoriaLogs 42 MB、NATS 41 MB）。ClickHouse を動かす場合はさらに 807 MB。既定のインストールで取得するのは合計 約 2.3 GB です。 - アップグレードの余裕 — インプレースアップグレードは、ロールバック用に旧イメージを残したまま 新しいイメージ一式を取得します。2 GB の空きを確保してください。
- 受動イベント — VictoriaLogs の既定保持期間は 30 日、ClickHouse のフローデータは 30 日で 失効します。（90 日という数字は、PostgreSQL に残すアラート紐付きイベント行のほうの既定値で、 ログストアの話ではありません。）
- リモートポーラー — core に到達できない間、結果をディスクにバッファします。上限 512 MB、 空き容量が 1 GB を切った時点で書き込みを止めます。
保持期間の設定場所は 1 か所ではありません。 Settings ▸ System で設定できるのは、Yagra 自身が
削除するもの — アラート紐付きイベント（90 日）、未マッチのイベント（24 時間）、レポートの実行結果
（90 日）、診断（90 日）、フローデータ（30 日）です。Victoria 系の 2 つのストアは別です。どちらも
実行時に保持期間を変更する API を持たないため、--retentionPeriod フラグは Compose ファイルの中に
あり、Settings ▸ System はその値を読み取り専用で表示し、その旨の注記を出します。上の表を動かしている
メトリクスの保持期間は、このフラグを編集してコンテナを作り直すことで変えます。
スケールするもの、しないもの
Section titled “スケールするもの、しないもの”core は 50,000 ノード のフリートに対して実測しています:
| 実測値 | |
|---|---|
| core メモリ（平均） | 183 MiB |
| core メモリ（最大） | 245 MiB |
| core CPU（平均） | 1 コアの 11.8% |
| 取り込み遅延 | 約 1.0 秒 |
つまり 5 万ノードを抱える core の費用は、数十ノードを抱える core より少し高いだけです。
ですからサイジングの対象は、core ではなくストア側です。VictoriaMetrics の系列数と ClickHouse の フロー量を基準に計画してください。core とポーラーは、ほぼ固定費として扱ってかまいません。
リモートポーラーのホスト
Section titled “リモートポーラーのホスト”拠点に置くポーラーは、小さくて済みます。以下の数値は実測値になりました。別ホストの core に 接続した、v0.3.3 の拠点ポーラー 2 台で測っています:
| 実測値 | 推奨値 | |
|---|---|---|
| メモリ | 28 MiB と 34 MiB（常駐） | 1 GB |
| CPU | 1 コアの 0.2% | 1 vCPU |
| ディスク | 使用 2.0 GB、バッファは空 | 4 GB |
どちらも作業集合は小さく、チェック仕様で 59 本と 68 本でした。ですからこの数値は上限ではなく 下限として読んでください。推奨値がこれよりかなり大きいのは、ポーラーのサイズを実際に決めるのが store-and-forward のバッファだからです。このバッファは、ディスクへ書き出す前に最大 20,000 件の 結果をメモリに持ち、書き出しファイルは上限 512 MB、空き容量 1 GB を下限としてそれ以上は使いません。
ディスクの推奨値は、ポーラーのイメージ（132 MB）に、その上限と下限を足したものです。
ポーラーは、このバッファ以外に消えては困る状態を持ちません。ですからいつでも安全に作り直せます。
これらの数値の測定方法
Section titled “これらの数値の測定方法”コンテナごとのメモリと CPU は、全機能を有効にして動いている v0.3.3 のデプロイ 2 台（どちらも監視
ノード 32 件）に対する docker stats --no-stream の出力です。イメージサイズは、同じホストでの
docker images の出力です。
対象ごとの系列数は、同じデプロイで VictoriaMetrics 自身の /api/v1/status/tsdb から取りました。
1 サンプルあたりのバイト数は、vm_data_size_bytes を vm_rows で割ったもので、ストレージと
インデックスの両方を含みます。
50,000 ノードの数値は、合成の結果ジェネレータで動かしたフリートに対して測りました。5 分待って 落ち着かせたあと、20 分の窓でサンプリングしています。
リモートポーラーの数値は、拠点側ホスト 2 台での docker stats と、ポーラー自身の /metrics から
取りました。
試算表のディスク量は、実測ではありません。上の計算式から出したものです。推定にはそのつど、その旨を 書いています。