統計メトリック

概要

このページでは、統計表示で利用可能なすべてのメトリックに関する詳細な説明を提供します。これらのメトリックは、過去データから集計され、計算された値を表し、計算方法においてリアルタイムモニタリング値と異なる場合があります。

統計は3つの主要セクションで構成されます：

1. プロジェクト: プロジェクトレベルで集計されたメトリックで、プロジェクト管理者に有用です
2. NetFUNNELサーバーインスタンス: NetFUNNELサーバーインスタンスレベルのメトリックで、サーバー管理者に有用です
3. セグメント: セグメントレベルのメトリックで、セグメント管理者に有用です

メトリック要約表

次の表は、すべての統計メトリックのクイックリファレンスを提供します。各メトリックは以下のセクションで詳細に説明されます。

メトリック	単位	説明	リアルタイム同等項目
プロジェクトおよびセグメントメトリック
全体リクエスト数	TPS	すべてのトラフィック制御API呼び出しの平均TPS	N/A
進入リクエスト	TPS	初期進入リクエストの平均TPS	進入リクエスト量
処理時間	秒	進入からキー返却までの平均時間	処理時間
待機時間	秒	期間中の最大待機時間	待機時間（平均）
待機者	名	期間中の累積待機者数	待機 ユーザー数（現在）
進入許容	-	期間中に構成された容量制限	進入許容数
ユーザー	名	特定の瞬間のアクティブユーザースナップショット	アクティブユーザー数（現在）
完了率(%)	%	明示的な終了の完了率	完了率
迂回	TPS	迂回されたリクエストの速度	N/A
ブロック	TPS	ブロックされたリクエストの速度	N/A
NetFUNNELメトリック
CPU占有率(%)	%	測定瞬間のCPU使用率	N/A
全体リクエスト数	TPS	すべてのAPIリクエストの平均TPS（管理APIを含む）	N/A
セッション	-	完了したセッション数（進入から完了まで）	N/A
ブロック	TPS	繰り返しリクエストブロック機能によってブロックされたリクエストの平均速度	N/A

グローバルメトリックルール

個別のメトリックを確認する前に、統計がどのように計算されるかを理解することが重要です：

ルール1: 1分集計

すべてのメトリックは毎分新しい値で集計されます。これは以下を意味します：

• データが継続的に収集されます
• 毎分新しい集計値が計算されます
• 過去データはこれらの分単位の値を表示します

例:

00:00:00 - 00:01:00: 処理時間 = 2.5秒
00:01:00 - 00:02:00: 処理時間 = 3.1秒
00:02:00 - 00:03:00: 処理時間 = 2.8秒

ルール2: プロジェクトレベル集計

プロジェクトレベルでは、値はすべてのセグメントのメトリック合計です。これは以下を意味します：

• 3つのセグメントがある場合、プロジェクトレベルメトリックは3つのセグメントの合計です
• プロジェクト全体の活動を理解するのに有用です

例:

プロジェクトに3つのセグメントがある:
- セグメントA: 進入リクエスト = 10 TPS
- セグメントB: 進入リクエスト = 15 TPS
- セグメントC: 進入リクエスト = 5 TPS
=> プロジェクト進入リクエスト = 30 TPS (10 + 15 + 5)

プロジェクトおよびセグメントメトリック

これらのメトリックは、プロジェクトおよびセグメントレベルの両方で利用できます。プロジェクトレベルメトリックは、すべてのセグメントメトリックの合計です。

全体リクエスト数

単位: TPS（1秒あたりのトランザクション数）

測定内容: ⚠️ 重要: これはプロジェクト/セグメントレベルの全体リクエスト数メトリックです。NetFUNNELエージェントが作成したトラフィック制御API呼び出しのみを測定します。

1秒あたりのすべてのトラフィック制御API呼び出しが行われる平均速度。これをアプリケーションとNetFUNNELサーバー間の「総トラフィック制御通信量」と考えてください。

重要な理由: このメトリックは、全体のトラフィック制御通信負荷を理解するのに役立ちます。リクエストタイプに関係なく、トラフィック制御システムがどれだけ忙しいかを示します。

含まれる内容（トラフィック制御API呼び出しのみ）: NetFUNNELエージェントは、NetFUNNELサーバーに4種類のトラフィック制御呼び出しを作成します：

1. 初期進入リクエスト: 最初のキー発行リクエスト（ユーザーが進入しようと試みる）
2. 再進入リクエスト: 待機室からの進入リクエスト（待機後に再試行するユーザー）
3. Alive Noticeリクエスト: 区間制御中のアクティブ状態通知（セッション維持）
4. 完了リクエスト: キー返却リクエスト（ユーザー完了、キー返却）

含まれない内容:

• データクエリAPIリクエスト（統計、モニタリングダッシュボード用）
• 管理APIリクエスト
• その他の非トラフィック制御APIリクエスト

実際の例:

1分間:
- 100個の初期進入リクエスト
- 50個の再進入リクエスト
- 200個のAlive Noticeリクエスト
- 100個の完了リクエスト
合計: 60秒間で450個のトラフィック制御リクエスト = 7.5 TPS

重要な注意事項: このメトリックはリアルタイムモニタリングでは表示されません。統計でのみ利用可能で、トラフィック制御通信の過去分析に有用です。

NetFUNNELレベル全体リクエスト数との違い:

• このメトリック（プロジェクト/セグメント）: トラフィック制御API呼び出しのみ（上記の4種類）
• NetFUNNELレベル全体リクエスト数: データクエリ、管理APIなどを含むすべてのAPIリクエスト

使用時:

• トラフィック制御通信負荷の理解
• トラフィック制御運用のための容量計画
• 異常なトラフィック制御パターンの識別

進入リクエスト

単位: TPS（1秒あたりのトランザクション数）

測定内容: 1秒あたりの初期キー発行リクエストの平均速度。1秒あたり何人の新しいユーザーがサービスに進入しようとしているかを示します。

重要: リアルタイムモニタリング進入量とは異なります

⚠️ リアルタイムモニタリングの「進入量」と混同しないでください！ 両方とも「進入」という名前を使用しますが、異なるものを測定します：

側面	統計進入リクエスト	リアルタイムモニタリング進入量
測定内容	初期進入リクエスト（需要）	実際にサービスに進入するリクエスト（実際の負荷）
該当項目	リアルタイムモニタリングの進入リクエスト量	リアルタイムモニタリングの進入量
含まれる	最初の進入試行のみ	PASSを受けたすべてのリクエスト（直接進入 + 待機室からの再進入）
意味	何人のユーザーが進入しようとしているか	何人のユーザーが実際に進入したか

統計進入リクエストの意味:

• 需要を示します: 何人のユーザーが進入しようとしているか
• 試行を測定します: 最初の進入リクエスト
• 一部は待機室に行き、一部は直接進入できます
• 過去平均: 現在値ではない

リアルタイムモニタリング進入量の意味:

• 実際の負荷を示します: 実際にサービスに進入するリクエスト
• 成功した進入を測定します: PASSを受けたリクエスト
• 直接進入と待機室からの再進入の両方を含む
• 現在値: 今起こっていることを示します

実際の例:

1分間（60秒）:
- 1-10秒: 5個の初期進入リクエスト
- 11-20秒: 8個の初期進入リクエスト
- 21-30秒: 12個の初期進入リクエスト
- 31-40秒: 10個の初期進入リクエスト
- 41-50秒: 7個の初期進入リクエスト
- 51-60秒: 9個の初期進入リクエスト

合計: 60秒間で51個の初期進入リクエスト
統計進入リクエスト = 51 ÷ 60 = 0.85 TPS

注意: この51個のリクエストがすべて即座に進入したわけではありません。
一部は待機室に行き、一部は直接進入しました。
実際のサービス負荷はリアルタイムモニタリング進入量に表示されます。

リアルタイムモニタリングとの関係:

• 統計進入リクエストはリアルタイムモニタリングの進入リクエスト量に対応します（需要側面）
• リアルタイムモニタリング進入量はリアルタイムモニタリングの進入量に対応します（実際の負荷側面）

統計は現在値ではなく、過去平均値を表示します。

使用時:

• 過去の需要パターンの理解
• 異なる期間間の需要比較
• 過去の需要に基づく容量計画

処理時間

単位: 秒

測定内容: ユーザーがサービスを積極的に使用する平均時間で、進入（PASS受信）からキーを返却するまでです。これは実際のサービス使用期間を表します。

重要な理由: 処理時間は、ユーザーが実際にサービスを使用する時間を教えてくれます。より長い時間は以下を意味する可能性があります：

• サービスがより多くの作業を実行している
• サーバーが負荷状態（処理速度の低下）
• ユーザーがサービスでより多くの時間を過ごしている

計算方法: システムは1分間のすべての処理時間の平均を計算します。

計算例:

1分間（00:00:00 ~ 00:01:00）:
- ユーザーA: 00:00:10に進入、00:00:11にキー返却 → 1秒
- ユーザーB: 00:00:15に進入、00:00:17にキー返却 → 2秒
- ユーザーC: 00:00:20に進入、00:00:26にキー返却 → 6秒
- ユーザーD: 00:00:30に進入、00:00:32にキー返却 → 2秒
- ユーザーE: 00:00:45に進入、00:00:46にキー返却 → 1秒

平均処理時間 = (1 + 2 + 6 + 2 + 1) ÷ 5 = 2.4秒

実際のシナリオ:

シナリオ1: 高速サービス（例: シンプルなAPI呼び出し）

処理時間: 0.5 - 1.5秒
→ サービスが迅速に応答し、ユーザーが迅速に完了する

シナリオ2: 通常サービス（例: ページロード）

処理時間: 2 - 5秒
→ 正常なページ読み込み時間

シナリオ3: 低速サービス（例: 重い計算）

処理時間: 10秒以上
→ サービスが負荷状態であるか、複雑な作業を実行中である可能性がある

処理時間に影響を与える要因:

• 環境特性: サーバーパフォーマンス、ネットワーク速度
• サービスタイプ: シンプルなAPI vs 複雑なページ vs 重い計算
• 統合実装: nfStart()およびnfStop()呼び出し方法

使用時:

• 一般的なサービス使用期間の理解
• 時間に伴うパフォーマンス低下の識別
• 異なる期間間の処理時間比較

待機時間

単位: 秒

測定内容: 1分間の期間中、すべてのユーザーが経験した最長の待機時間。これは最悪のユーザー体験を示します - 最も不運なユーザーが待機しなければならなかった時間。

重要な理由: 平均待機時間は一般的な体験を教えてくれますが、最大待機時間は最悪の体験を教えてくれます。これは以下を理解するのに役立ちます：

• ピーク期間のユーザー体験
• 一部のユーザーが長すぎる時間待機しているかどうか
• 容量調整が必要かどうか

計算方法: システムは、その分中に待機したすべてのユーザーの中で、単一の最長待機時間を見つけます。

計算例:

1分間（00:00:00 ~ 00:01:00）:
- ユーザーA: 00:00:10から00:00:11まで待機 → 1秒待機
- ユーザーB: 00:00:15から00:00:17まで待機 → 2秒待機
- ユーザーC: 00:00:20から00:00:26まで待機 → 6秒待機（最長！）
- ユーザーD: 00:00:30から00:00:32まで待機 → 2秒待機

待機時間 = 6秒（最大値）

実際のシナリオ:

シナリオ1: 低い待機時間（良好）

待機時間: 1-3秒
→ ユーザーが長く待機しない、良好なユーザー体験

シナリオ2: 通常の待機時間（許容可能）

待機時間: 5-10秒
→ 一部待機するが、ほとんどのユーザーにとって許容可能

シナリオ3: 高い待機時間（注意が必要）

待機時間: 30秒以上
→ ユーザーが長すぎる時間待機中、進入許容の増加を検討

運用インサイト: 統計の高い待機時間は、需要に対して進入許容が低すぎる設定の期間を示す可能性があります。持続的に高い待機時間が見られる場合、以下を検討できます：

• 進入許容の増加（サーバー容量が許容する場合）
• 容量をより適切に計画するために需要パターンのレビュー

リアルタイムモニタリングとの関係: これはリアルタイムモニタリングの待機時間と類似していますが、統計は現在平均ではなく、過去最大値を表示します。

使用時:

• 最悪のユーザー体験の理解
• 長い待機があるピーク期間の識別
• 容量調整計画

待機者

単位: 名

測定内容: 1分間の期間中、待機室に進入したユーザーの累積数。これは総待機需要を示し、現在の待機者数ではありません。

重要な区別:

• 統計待機者: 期間中に待機したすべてのユーザーの累積数
• リアルタイム待機 ユーザー数: 今待機中のユーザーの現在数

重要な理由: このメトリックは以下を理解するのに役立ちます：

• 何人のユーザーが待機を経験したか
• 期間中の総待機需要
• 待機が一般的な体験かどうか

計算方法: システムは1分間の期間中、待機室に進入したすべてのユーザーを計算します。

計算例:

1分間（00:00:00 ~ 00:01:00）:
- 00:00:05: ユーザーAが待機室に進入
- 00:00:12: ユーザーBが待機室に進入
- 00:00:18: ユーザーCが待機室に進入
- 00:00:25: ユーザーDが待機室に進入
- 00:00:35: ユーザーEが待機室に進入
- 00:00:48: ユーザーFが待機室に進入

待機者 = 6名（累積数）

実際のシナリオ:

シナリオ1: 待機なし

待機者: 0名
→ すべてのユーザーが即座に進入、待機室が不要

シナリオ2: 軽い待機

待機者: 分あたり10-50名
→ 一部のユーザーが待機するが多くない

シナリオ3: 重い待機

待機者: 分あたり100名以上
→ 多くのユーザーが待機を経験している、高い需要

リアルタイムモニタリングとの関係: これはリアルタイムモニタリングの待機 ユーザー数と類似していますが、統計は現在値ではなく、過去累積値を表示します。

使用時:

• 待機需要パターンの理解
• 異なる期間間の待機比較
• ピーク待機期間の識別

進入許容

単位: -（無次元数、単純な数字）

測定内容: 1分間の期間中、管理者コンソールで構成された進入許容値。これはその時間に許可された最大容量を表します。

重要な理由: 進入許容は「容量ゲート」です - 同時にアクティブ化できるユーザー数を制御します。これを実際の使用量（ユーザーメトリック）と比較すると、以下を見ることができます：

• 容量が適切に設定されているか
• 未使用の容量があったか
• 容量が低すぎたか（待機者の発生）

実際の例:

1分間:
- 進入許容: 100名
- ユーザー（実際）: 95名
→ 5名の容量未使用（5%余裕）

別の1分間:
- 進入許容: 100名
- ユーザー（実際）: 100名
→ 容量完全活用（0%余裕）

さらに別の1分間:
- 進入許容: 100名
- ユーザー（実際）: 100名
- 待機者: 50名
→ 容量満杯、ユーザー待機中（増加が必要な可能性がある）

解釈方法:

• 進入許容 > ユーザー: 未使用の容量がある
• 進入許容 = ユーザー: 容量が完全に活用されている
• 進入許容 < 需要: ユーザーが待機室に配置される（待機者メトリックを確認）

リアルタイムモニタリングとの関係: これはリアルタイムモニタリングで使用される進入許容数設定に対応します。

使用時:

• 過去の容量設定のレビュー
• 待機者が形成された理由の理解（進入許容が低すぎたか）
• 過去のパターンに基づく将来の容量設定計画

ユーザー

単位: 名

測定内容: 特定の瞬間のアクティブユーザースナップショット。アクティブユーザーは、キーを受け取ったがまだ返却していないユーザーです - 現在サービスを使用中です。

重要: これはスナップショットであり、平均ではありません！

• 特定の瞬間の数を示します（例: 00:00:01）
• 累積値ではありません（時間にわたって合計されない）
• 平均ではありません（複数の測定値の平均ではない）

重要な理由: これは、その瞬間にサービスを積極的に使用中のユーザー数を教えてくれます。部屋の写真を撮って、その中に何人いるかを数えるのと同じです。

実際の例:

00:00:01（スナップショット瞬間）:
- ユーザーA: キー保持、サービス使用中
- ユーザーB: キー保持、サービス使用中
- ユーザーC: キー保持、サービス使用中
- ユーザーD: キー保持、サービス使用中
- ユーザーE: キー保持、サービス使用中

ユーザー = 5名（スナップショット数）

00:01:01（次のスナップショット）:
- ユーザーA: キー返却（もはやアクティブではない）
- ユーザーB: まだキー保持
- ユーザーC: まだキー保持
- ユーザーD: キー返却（もはやアクティブではない）
- ユーザーE: まだキー保持
- ユーザーF: キー受信直後（新しくアクティブ化）

ユーザー = 4名（新しいスナップショット）

進入許容との比較:

進入許容: 100名
ユーザー（スナップショット）: 95名
→ 5名の容量利用可能

進入許容: 100名
ユーザー（スナップショット）: 100名
→ 容量満杯、新しいユーザーは待機室に配置される

リアルタイムモニタリングとの関係: これはリアルタイムモニタリングのアクティブユーザー数と類似していますが、統計は現在値ではなく、過去スナップショットを表示します。

使用時:

• 特定の瞬間の同時使用量の理解
• 実際の使用量と容量制限の比較
• ピーク使用量瞬間の識別

完了率(%)

単位: %（比率）

測定内容: サービスに進入し、明示的にキーを返却した（適切に完了した）ユーザーの割合。これは統合状態を示します - ユーザーがセッションを適切に完了しているか？

重要な理由: 高い完了率(%)は、ユーザーがセッションを適切に完了していることを意味します。低い比率は以下を示す可能性があります：

• コードにnfStop()呼び出しの欠落
• 統合問題
• ユーザーがセッションを放棄した

計算方法: システムは以下を計算します: （明示的にキーを返却したユーザー） ÷ （進入したユーザー） × 100

計算例:

1分間（00:00:00 ~ 00:01:00）:
進入したユーザー: 10名
- ユーザーA: 進入してキー返却 ✅
- ユーザーB: 進入してキー返却 ✅
- ユーザーC: 進入してキー返却 ✅
- ユーザーD: 進入したがキー返却しない（タイムアウト） ❌
- ユーザーE: 進入してキー返却 ✅
- ユーザーF: 進入してキー返却 ✅
- ユーザーG: 進入したがキー返却しない（タイムアウト） ❌
- ユーザーH: 進入してキー返却 ✅
- ユーザーI: 進入してキー返却 ✅
- ユーザーJ: 進入してキー返却 ✅

明示的にキーを返却したユーザー: 8名
完了率(%) = (8 ÷ 10) × 100 = 80%

実際のシナリオ:

シナリオ1: 優れた統合（良好）

完了率(%): 90-100%
→ ほぼすべてのユーザーがセッションを適切に完了する
→ 統合が正常に機能している

シナリオ2: 良好な統合（許容可能）

完了率(%): 70-89%
→ ほとんどのユーザーが適切に完了する
→ 一部はタイムアウトする可能性があるが許容可能

シナリオ3: 悪い統合（注意が必要）

完了率(%): <70%
→ 多くのユーザーが適切に完了しない
→ nfStop()呼び出しの欠落または統合問題の可能性
→ 調査して修正する必要がある

完了率(%)が低い場合にすべきこと:

1. 即座: 容量を迅速に解放するためにタイムアウト値を減少
2. 調査: nfStop()が適切に呼び出されているか確認
3. 長期的: キー返却の欠落を引き起こす統合問題の修正

リアルタイムモニタリングとの関係: これはリアルタイムモニタリングの完了率に対応しますが、統計は過去平均を提供します。

使用時:

• 時間に伴う統合状態のモニタリング
• 統合問題がある期間の識別
• 異なる期間間の完了率比較

迂回

単位: TPS（1秒あたりのトランザクション数）

測定内容: 1秒あたりのBYPASS応答を受けたリクエストの平均速度。これらはNetFUNNEL待機室を完全に迂回したリクエストです。

発生理由: 通常、ユーザーが進入しようとすると、NetFUNNELは以下で応答します：

• WAIT: 待機室に移動
• PASS: 即座に進入

しかし、セグメントまたはプロジェクトが無効化されると、NetFUNNELは以下を送信します：

• BYPASS: 待機室を完全に迂回（NetFUNNELが有効化されていないかのように）

実際の例:

シナリオ: セグメントが無効化された
- ユーザーAが初期進入リクエスト送信 → BYPASS受信
- ユーザーBが初期進入リクエスト送信 → BYPASS受信
- ユーザーCが再進入リクエスト送信 → BYPASS受信

1分間: 30個のBYPASS応答
迂回 = 30 ÷ 60 = 0.5 TPS

迂回が見られる場合:

• セグメントが無効化された
• プロジェクトが無効化された

解釈:

• 迂回 > 0: 一部のリクエストが待機室を迂回している（セグメント/プロジェクトが無効化された）
• 迂回 = 0: すべてのリクエストが正常なNetFUNNELフローを通過している

使用時:

• セグメントが無効化された時期の理解
• メンテナンス/テスト期間のレビュー
• トラフィック制御が有効化されているか確認

ブロック

単位: TPS（1秒あたりのトランザクション数）

測定内容: 1秒あたりのBLOCK応答を受けたリクエストの平均速度。これらは進入がブロックされたリクエストです。

発生理由: 通常、ユーザーが進入しようとすると、NetFUNNELは以下で応答します：

• WAIT: 待機室に移動
• PASS: 即座に進入

しかし、リクエストがブロックされる場合（BLOCK受信）：

• セグメントブロックモード: セグメントがブロックモードに設定された（意図的なブロック）

注意: 繰り返しリクエストブロック機能によってブロックされたリクエスト（302ステータスコード返却）は、このブロックメトリックに含まれません。繰り返しリクエストブロック統計は、NetFUNNELサーバーインスタンスレベルで別途追跡されます。

実際の例:

シナリオ: セグメントがブロックモードに設定された
- ユーザーAが初期進入リクエスト送信 → BLOCK受信（セグメントがブロックモード）
- ユーザーBが初期進入リクエスト送信 → BLOCK受信（セグメントがブロックモード）
- ユーザーCが初期進入リクエスト送信 → BLOCK受信（セグメントがブロックモード）
- ユーザーDが初期進入リクエスト送信 → BLOCK受信（セグメントがブロックモード）

1分間: 20個のBLOCK応答
ブロック = 20 ÷ 60 = 0.33 TPS

注意: 繰り返しリクエストブロックがトリガーされた場合（302応答）、それらはここでは計算されません。

ブロックが見られる場合:

• セグメントが意図的にブロックモードに設定された
• ボット防止保護がトリガーされた
• 悪用防止保護がトリガーされた
• 疑わしいリクエストパターンが検出された

重要: このメトリックは、繰り返しリクエストブロック（302応答）によってブロックされたリクエストを含みません。繰り返しリクエストブロック統計については、NetFUNNELサーバーインスタンスレベルブロックメトリックを参照してください。

解釈:

• ブロック > 0: 一部のリクエストがブロックされている（セキュリティ/悪用防止が動作中）
• ブロック = 0: ブロックされたリクエストなし

使用時:

• セキュリティ/悪用防止効果の理解
• ブロックされたリクエストパターンのレビュー
• ブロック機能が動作しているか確認

NetFUNNELサーバーインスタンスレベルメトリック

これらのメトリックは、NetFUNNELサーバーインスタンスレベルで確認されます。これらはNetFUNNELサーバー自体のメンテナンスメトリックです。

マネージドサービス顧客の場合

NetFUNNELをマネージドサービスとして使用する場合、通常、これらのメトリックをモニタリングする必要はありません。サーバーインストールを管理するNetFUNNELサーバー管理者またはエンジニアに有用です。

CPU占有率(%)

単位: %（比率）

測定内容: 測定瞬間のNetFUNNELサーバーCPU使用率で、比率（0-100%）で表現されます。

重要な理由: 高いCPU使用率は以下を示す可能性があります：

• サーバーが重い負荷状態
• パフォーマンス問題
• サーバー拡張の必要性

実際の例:

00:00:01: CPU占有率 = 45%
→ サーバーがCPU容量の45%使用中
→ 55%容量利用可能

00:01:01: CPU占有率 = 85%
→ サーバーがCPU容量の85%使用中
→ 15%容量利用可能（高くなっている）

使用時:

• サーバーリソース使用率のモニタリング
• パフォーマンスボトルネックの識別
• サーバー容量計画

全体リクエスト数（NetFUNNELレベル）

単位: TPS（1秒あたりのトランザクション数）

測定内容: ⚠️ 重要な区別: これはプロジェクト/セグメント「全体リクエスト数」メトリックと完全に異なります！

このメトリックは、NetFUNNELサーバーに対するすべてのタイプのAPIリクエストを含み、トラフィック制御リクエストのみではありません。すべてのサーバー活動の包括的なビューです。

含まれる内容（すべてのAPIリクエスト）:

1. トラフィック制御APIリクエスト（プロジェクト/セグメントレベルと同じ4種類）:
   • 初期進入リクエスト
   • 再進入リクエスト
   • Alive Noticeリクエスト
   • 完了リクエスト
2. データクエリAPIリクエスト: 統計データ、モニタリングダッシュボード、レポートリクエスト
3. 管理APIリクエスト: サーバー管理、構成、管理作業
4. その他のAPIリクエスト: NetFUNNELサーバーに対するその他のすべてのタイプのAPI呼び出し

主な違い:

側面	プロジェクト/セグメント全体リクエスト数	NetFUNNELレベル全体リクエスト数
範囲	トラフィック制御API呼び出しのみ	すべてのAPIリクエスト
含まれる	4種類のトラフィック制御呼び出し	トラフィック制御 + データクエリ + 管理 + その他
目的	トラフィック制御負荷の理解	総サーバー負荷の理解
使用事例	トラフィック制御容量計画	サーバー容量計画

実際の例:

1分間:
トラフィック制御リクエスト（プロジェクト/セグメントレベルと同じ）:
- 100個の初期進入リクエスト
- 50個の再進入リクエスト
- 200個のAlive Noticeリクエスト
- 100個の完了リクエスト
小計: 450個のリクエスト

追加リクエスト（プロジェクト/セグメントレベルにはない）:
- 50個の統計クエリリクエスト（ダッシュボード更新）
- 10個の管理APIリクエスト（構成変更）
- 5個のその他のAPIリクエスト

合計: 60秒間で515個のリクエスト
全体リクエスト数 = 515 ÷ 60 = 8.58 TPS

重要な理由:

• プロジェクト/セグメント全体リクエスト数: アプリケーションのトラフィック制御活動を示します
• NetFUNNELレベル全体リクエスト数: 管理作業、ダッシュボードクエリなどを含む総サーバー負荷を示します

使用時:

• 総サーバー負荷の理解（すべてのAPIタイプを結合）
• NetFUNNELサーバーインフラ容量計画
• 異常なサーバー活動の識別（管理作業を含む）
• サーバーリソース計画および拡張決定

セッション

単位: -（無次元数、単純な数字）

測定内容: NetFUNNELサーバーで完了したセッション数。セッションは、サーバーで進入（初期リクエスト）から完了（キー返却）までの1つの完全なユーザージャーニーを表します。

重要な理由: このメトリックは以下を理解するのに役立ちます：

• サーバーが処理した総ユーザーセッション数
• 完了したユーザー相互作用の観点からのサーバー作業量
• 全体のサーバー活動レベル

計算方法: システムは、測定期間中に完了した各セッション（進入からキー返却まで）を計算します。統計では、この値は選択した期間に応じて集計されます：

• 日表示: 分あたりのセッション合計
• 月表示: 時間あたりのセッション合計
• 年表示: 日あたりのセッション合計

実際の例:

1分間（00:00:00 ~ 00:01:00）:
- ユーザーA: 00:00:10に進入、00:00:15に完了 → 1セッション
- ユーザーB: 00:00:20に進入、00:00:25に完了 → 1セッション
- ユーザーC: 00:00:30に進入、00:00:35に完了 → 1セッション

セッション = 3セッション（総数）

使用時:

• 完了したセッションの観点からの総サーバー活動の理解
• 異なる期間間のサーバー作業量比較
• セッションボリュームに基づくサーバー容量計画

ブロック（NetFUNNELレベル）

単位: TPS（1秒あたりのトランザクション数）

測定内容: ⚠️ 重要: これはプロジェクト/セグメントレベルブロックメトリックとは異なるNetFUNNELサーバーインスタンスレベルブロックメトリックです。

NetFUNNELサーバーレベルで繰り返しリクエストブロック機能によって1秒あたりにブロックされたリクエストの平均速度。このメトリックは、繰り返しリクエストブロック機能によってブロックされたリクエストを計算します（例: 時間内リクエスト制限を超過するクライアントのブロックまたは永続的にブロックされたクライアント）。

重要な理由: このメトリックは以下を理解するのに役立ちます：

• サーバーレベルで繰り返しリクエストブロック機能によってブロックされるリクエスト数
• サーバーレベル悪用防止効果
• ブロックされたリクエストによるサーバー負荷

計算方法: システムは、測定期間中に繰り返しリクエストブロック機能によってブロックされたリクエストを計算し、1秒あたりの平均速度を計算します。統計では、この値は選択した期間に応じて集計されます：

• 日表示: 分あたりのブロックされたリクエスト合計、その後TPSで平均化
• 月表示: 時間あたりのブロックされたリクエスト合計、その後TPSで平均化
• 年表示: 日あたりのブロックされたリクエスト合計、その後TPSで平均化

実際の例:

1分間（00:00:00 ~ 00:01:00）:
- リクエストA: ブロックされた（繰り返しリクエストブロック） → 計算される
- リクエストB: ブロックされた（繰り返しリクエストブロック） → 計算される
- リクエストC: 許可された（正常） → 計算されない
- リクエストD: ブロックされた（繰り返しリクエストブロック） → 計算される

合計: 60秒間で3個のブロックされたリクエスト
ブロック = 3 ÷ 60 = 0.05 TPS

プロジェクト/セグメントレベルブロックとの違い:

• このメトリック（NetFUNNELレベル）: サーバーレベルで繰り返しリクエストブロック機能によるブロック
• プロジェクト/セグメントレベルブロック: セグメントブロックモードまたは繰り返しリクエストブロックによるブロック

使用時:

• サーバーレベル繰り返しリクエストブロック機能効果のモニタリング
• サーバー悪用防止活動の理解
• サーバーインフラレベルでブロックされたリクエストパターンのレビュー

メトリック参照

各メトリックがトラフィックフローコンテキストで何を表すかに関する詳細な説明については、メトリッククイックリファレンスを参照してください。概念は同じですが、統計はリアルタイムスナップショットではなく、過去集計値を提供します。