Skip to content
このページは AI で翻訳されており、不正確な表現が含まれる場合があります。GitHub で改善にご協力ください。

パフォーマンス監視 ​

パフォーマンス監視は、ホスト、Gately プロセス、各サイトのパフォーマンスを 1 ページにまとめ、指標がしきい値を超え続けたときに通知センターからアラートを送り、条件が解消すると復旧通知を送ります。管理画面ではサイドバーの「システム」→「パフォーマンス監視」にあります。

「夜中に CPU が張り付いた」「あるサイトの接続数が急増した」「バックエンドが遅くなったのに誰も気付かない」といった場面を想定しており、データはメモリにのみ保持します。24 時間を超える履歴、複数インスタンスの集約、複雑なクエリには Prometheus と Grafana を使ってください。

パフォーマンスパネル ​

ページ右上で 60 秒、1 時間、24 時間を切り替えられます。

ホストと Gately プロセス ​

グラフ内容
ホスト CPUマシン全コアの平均使用率
ホストメモリ / ディスク物理メモリに占める使用中メモリの割合(解放可能なキャッシュを除く)、設定ディレクトリがあるパーティションの使用率
システム負荷1 分間の負荷
Gately プロセス CPUGately プロセスがマシン全体に占める割合。ホスト CPU と同じ基準
Gately プロセスメモリ常駐メモリ(MB)
ファイルディスクリプタ / goroutineプロセスが開いているファイルディスクリプタ数と Go の goroutine 数

バックグラウンドで 5 秒ごとにサンプリングします。60 秒表示はサンプルごとに 1 点、1 時間表示は 1 分ごとに 1 点(その 1 分の平均)、24 時間表示は 5 分ごとに 1 点です。CPU グラフの破線は各点の区間内のピークで、短いスパイクが平均で消えることはありません。グラフにカーソルを合わせると、その時点の値を確認できます。

プラットフォームによっては取得できない指標があり(例:macOS では CPU 使用率なし)、そのグラフには「データなし」と表示されます。

サイト ​

Web サービスモジュールがオンのとき、実行中のすべてのサイト(デフォルトサイトを含む)を表示します。

列説明
処理中サイトが現在処理中のリクエスト数。WebSocket などの長時間接続を含む
リクエスト/秒直近約 60 秒の平均リクエスト/秒
5xx 割合直近約 60 秒で完了したレスポンスに占める 5xx の割合
レイテンシ P95直近約 60 秒の最初のバイトまでの時間の 95 パーセンタイル推定値
バックエンド正常なバックエンド数 / 全バックエンド数と、転送中の接続数

サイトをクリックするとサイト統計が開き、24 時間のリクエスト、エラー、レイテンシの推移を確認できます。

最初のバイトまでの時間 ​

レイテンシは「最初のバイトまでの時間」で、リクエスト到着からレスポンスヘッダー送信までの時間です。バックエンドやサイト自体の応答速度を表します。次のものは含みません。

  • レスポンス本文の転送時間(大きなファイルのダウンロードでレイテンシは上がりません)
  • WebSocket などのプロトコルアップグレードリクエスト
  • アクセス制御で切断されたリクエスト、管理者が切断したリクエスト

各リクエストは所要時間に応じて 50 段階の細かい区間(1 ミリ秒〜60 秒、隣り合う区間の差は約 10%〜25%)に入り、区間ごとに件数と合計時間を累計します。パーセンタイルは該当区間の平均時間で、誤差は区間幅を超えず、個々のリクエストのデータは保存しません。Prometheus に出力する gately_site_request_duration_seconds ヒストグラムはそのうち 13 個の一般的な境界を使います。

アラートルール ​

「アラートルールを追加」をクリックします。新規作成時はテンプレート(ホスト CPU 高負荷、ディスク容量不足、サイト 5xx 多発、サイト応答遅延など)で入力してから調整できます。

項目説明
名前必須。最大 64 文字で、通知のタイトルに使われる
指標下表を参照
しきい値比較演算子 >、>=、<、<= と値。単位は指標で決まる
継続時間1〜1440 分。条件がこの時間続いた場合にのみアラートを送信し、途中で一度でも下回るとタイマーはリセット
対象サイトサイトとバックエンドノードの指標で指定可能。空欄ですべてのサイト
最小リクエスト数5xx 割合とレイテンシで使用、既定は 20。直近約 60 秒のリクエストがこれ未満のときは判定せず、トラフィックが少ないときに 1、2 件のエラーや遅延でアラートが出るのを防ぐ
アラートレベル警告またはエラー。通知イベントのレベルになる
備考、有効任意
指標単位判定対象
ホスト CPU 使用率%このホスト
ホストメモリ使用率%このホスト
ホストディスク使用率(設定ディレクトリのパーティション)%このホスト
Gately プロセス CPU 使用率%Gately プロセス
Gately プロセス常駐メモリMBGately プロセス
サイトの処理中リクエスト数件各サイト
サイトのリクエスト/秒件/秒各サイト
サイトの 5xx 応答割合%各サイト
サイトの最初のバイトまでの時間 P95ミリ秒各サイト
バックエンドノードの接続数件各バックエンドノード

サイトとバックエンドノードの指標は対象ごとに個別に判定・通知します。たとえば「5xx 割合 > 5%」の 1 つのルールで、2 つのサイトに別々にアラートを出せます。「サイトのリクエスト/秒 < 1」でトラフィックの急な停止を検出できます。

判定と通知 ​

  1. 有効なすべてのルールを 5 秒ごとに評価します。
  2. 条件が成立すると「計測中」になり、継続時間に達すると「発報中」になって perf.alert イベントを発行します。
  3. 発報中の条件が解消すると perf.recovered イベントを発行します。サイトの 5xx 割合とレイテンシは、直近約 60 秒のリクエストが足りないと判定できず、これも解消として扱い、復旧通知にその旨を記します。
  4. サイトが削除または無効化されると、そのアラートは復旧通知なしで消えます。

ページ上部に計測中と発報中の対象、現在値、経過時間を表示します。

ルールの名前・レベル・備考を変更しても計測は継続します。指標・しきい値・継続時間・対象サイト・最小リクエスト数を変更するか、ルールを無効にすると、そのルールの計測とアラート状態はクリアされます。発生済みのアラートには、ルールが削除・無効化・変更されたことを示す復旧通知が送られます。計測とアラート状態はメモリにのみ保持され、再起動後は最初からやり直しです。

アラートは通知センターから送信されます。通知センターで「パフォーマンス監視:アラート発報」と「パフォーマンス監視:アラート復旧」を購読するルールを追加してください(「パフォーマンスアラート」テンプレートが使えます)。追加しない場合、アラートはこのページのログにのみ記録され、ページにもその旨が表示されます。通知センターのサイレンスもパフォーマンスアラートに適用されますが、対象ごとにイベントの送信元が異なるため互いに抑制し合うことはありません。継続時間がすでにチャタリング防止の役割を果たすので、通常サイレンスは不要です。

リソースと制限 ​

  • 履歴はメモリにのみ保持します。ホストとプロセスは 1 分ごとに 1 点を 24 時間分、サイトのレイテンシは 1 分ごとに P50 と P95 を保持し、トラフィックのあるサイトで約 23 KB です。
  • アラートルールは最大 200 件、1 つのルールで指定できるサイトは最大 200 件です。
  • Web サービスモジュールがオンのとき、1 リクエストあたりの追加コストは時刻の取得 1 回とカウンタ更新数回程度です。

監視メトリクス ​

パフォーマンス監視がオンのとき、/api/metrics は直近のサンプルのホストとプロセスの指標、各ルールの発報数も出力します。詳しくは監視メトリクスを参照してください。

API ​

エンドポイント説明
GET /api/perf/overview?range=60s|1h|24hホストとプロセスの履歴
GET /api/perf/sites各サイトの直近約 60 秒の指標
GET /api/perf/alerts計測中と発報中の対象
GET /api/perf/metricsアラートに使える指標
/api/perf/rulesアラートルールの作成・取得・更新・削除、有効化、並べ替え、グループ

読み取りには perf:read、ルールの変更には perf:write 権限が必要です。API トークンを参照してください。

Apache-2.0 ライセンスで公開されています。