InfraGuard
ログイン 今すぐ試す 今すぐ購入

トラフィック（ネットワーク I/O）

server_traffic に蓄積されたサーバー別の受信・送信バイト数とパケットスループットを ECharts の折れ線グラフとして可視化します — レガシーコンソールが収集していながら一度も表示しなかったデータです。

概要 — 何をする画面か

インフラ ▸ 接続とトラフィック ▸ トラフィック（/infra/traffic/net）は、各サーバーの ネットワーク I/O スループット（受信・送信のバイト数とパケット数）を、サーバーカードごとに1つの ECharts 折れ線グラフとして描画する読み取り専用のコンソールです。

ソースはレガシーの server_traffic テーブル（約160万行、legacy_glory 接続）で、レガシーコレクター check_tx.js が書き込みます。このテーブルはサーバー × 方向（受信／送信）ごとに、ウィンドウ単位の デルタのバイト数とパケット数 を蓄積しますが、旧 stats-design の UI が表示していたのは server_status の traffic-out（送信パケットのデルタ1本のみ）だけでした。この画面は、受信／送信 × バイト数／パケット数 という完全なデータセットを初めて可視化します。

3つの姉妹画面（ポート接続、IP接続、トラフィック）は同じ TrafficController と SessionQueryService を共有しますが、トラフィックタブだけはセッションのスナップショット（traffic_session_ct）ではなく server_traffic のスループット時系列 を読み取ります。そのため、他の2画面が使うタイマー（1／5／60分）ではなく レンジ（1h/6h/24h）の窓を使います。

こんなときに使う

画面構成

ヒーロー（上部バー）

要素 説明
メトリクス切り替え bytes | packets — 同じデータをバイト／パケットのスケールで塗り分けます（サーバーへの往復なし）
レンジ切り替え 1h（60）| 6h（360）| 24h（1440）— 表示窓の長さ（分）。選択は localStorage に保存されます
タイムスタンプ 最新ウィンドウの時刻（server_traffic の MAX ＋ 表示タイムゾーンの補正）
更新 即時の再取得（30秒の自動ポーリングとは独立）
全画面 上部ナビを隠してカードグリッドを拡大します（ESC で解除）

KPI ストリップ（流れ: 受信 · 送信 · パケット · 比率 → ホットスポット → 鮮度）

KPI 意味
受信合計 各サーバーの 最新ポイント の受信バイト数の合計
送信合計 各サーバーの最新ポイントの送信バイト数の合計
パケット合計 各サーバーの最後の（受信＋送信）パケット数の合計 · 単位は /window（累積ではありません）
受信:送信 out ÷ in（小数第1位）を 1 : x の形で表示します。受信が 0 のときは —
最大通信量 最新の送信バイト数が最大のサーバー（ホットスポット）
稼働中サーバー 最後のポイントが窓の終端から15分以内に収まるサーバーの数 / total。合計を下回ると警告（黄）になります

スケールの色凡例 + Y軸スケール

線／エリアの色は値の 大きさ を表します（ECharts の visualMap piecewise）。値がしきい値をまたぐと色が変わるので、スケールを色で体感できます。

トーン バイト パケット
info < 1MB < 1K
good 1–10MB 1–10K
warn 10–100MB 10–100K
crit > 100MB > 100K

サーバートラフィックカード

カード1枚＝サーバー1台。ヘッダーにはホスト名と現在の受信／送信バイト数、本体は 200px の <metric-chart>（ECharts、動的インポート）折れ線グラフです。

使い方

  1. レンジを選ぶ — スパイクを追うなら 1h、日次のパターンを見るなら 24h。
  2. メトリクスを切り替える — 帯域の負荷なら bytes、接続／PPS の性格なら packets。
  3. 対数軸 — 受信と送信の差が大きいサーバー（送信 ≫ 受信の Web ノードなど）では、log にすると両方の曲線が見えたままになります。
  4. カードを並べ替える — 注目しているサーバーを先頭にドラッグします（ブラウザーに保存されます）。
  5. ホットスポットを追う — KPI の Top サーバーや crit（赤）の曲線を見つけたら、ポート接続 / IP接続 に移動して、どの IP／ポートがそれを生んだのかを調べます。

ツールチップには HH:MM のヘッダーと各系列の値（受信／送信）が表示されます。カードの幅が狭くても、時間軸のラベルは重なりを避けて自動的に間引かれます（hideOverlap）。

データソース

server_traffic（legacy_glory · 読み取り専用）

カラム 用途
server_name, server_index サーバーの識別
time_window_start 収集ウィンドウの開始時刻（約300秒＝5分間隔）
direction inbound | outbound
delta_bytes_count このウィンドウのバイト数のデルタ
delta_packet_count このウィンドウのパケット数のデルタ

ソースクエリ（TrafficRepository::serverTraffic）は、パラメータバインドを用いて 狭い窓 のみをスキャンします（ハードコードも文字列補間もありません）:

SELECT server_name, server_index, time_window_start, direction,
       delta_packet_count, delta_bytes_count
FROM   server_traffic
WHERE  time_window_start >= :since   -- （最新ウィンドウ）− レンジ
ORDER  BY time_window_start
LIMIT  6000;

基点は MAX(time_window_start)（インデックスの効く MAX → 低コスト）。since = anchor − range minutes です。

分バケットへの正規化（のこぎり波の修正）

コレクター check_tx.js はループ内で受信と送信に 別々の new Date() を用いてタイムスタンプを打つため、同じ5分サイクル内でも time_window_start の値が1〜2秒ずれます（例: 受信 :02 / 送信 :03）。厳密なタイムスタンプでグループ化すると、各時点で受信・送信のどちらか一方しか拾えず、もう一方が 0 のままになり、のこぎり波のグラフ が生じます。

修正: SessionQueryService::reshapeNet がタイムスタンプを 分バケット（round(ts/60)*60）に丸めるため、受信と送信が1つの点に統合されます。ウィンドウの間隔（300秒）はバケット（60秒）よりはるかに大きいので、隣接するウィンドウが衝突することはありません。

表示タイムゾーンの補正

レガシー DB の保存時刻は表示時刻と異なることがあるため（約9時間のずれを観測）、値は OpsPolicy::trafficTzOffsetSec() によって 表示のためだけに シフトされます（タイムスタンプ、時間軸、系列のタイムスタンプ）。SQL の境界（min/max）はシフトされません — クエリはレガシーの生の時刻を使います。

キャッシュ · ポーリング

アクセス権限

トラブルシューティングと FAQ

Q. 「トラフィックのサンプルがありません」しか表示されません。 server_traffic に最近のウィンドウが1件もないという意味です。コレクター check_tx.js が動作しているか、legacy_glory 接続が有効かを確認してください。latestTrafficWindow()（MAX）が null の場合、カードは空になり KPI は 0 を表示します。

Q. あるサーバーが左端に短い断片しか描画しません。 これは意図した動作です。時間軸は共有の窓に固定されるため、収集が遅延しているサーバーは最後の観測時点までを 左端の断片 として正直に描画します。また、Active servers KPI では非稼働として数えられます（最後のポイントが窓の終端から15分の範囲外にある）。

Q. 片方の方向の曲線がのこぎり波に見えます。 分バケットへの正規化でほとんどの場合は解消しますが、収集ウィンドウ自体が不規則な場合は、のこぎり波が多少残ることがあります。log 軸に切り替えると滑らかになります。

Q. 値は累積ですか。 いいえ。delta_* は ウィンドウ（約5分）ごとの増分 です。Total packets KPI に /window と表記されているのはそのためです。累積カウンターではありません。

Q. 時刻が数時間ずれています。 表示タイムゾーンは OpsPolicy の traffic_tz_offset 設定で補正します（運用ポリシー を参照）。

関連項目

네트워크 I/O 추이
네트워크 I/O 추이