アプリケーション関連の指標
最終更新日 2022年11月28日(月)
すべての主なアクティブベータ機能が無事に GA の状態に達したため、アプリケーション関連の指標のベータ画面は無効になり、ダッシュボードから削除されています。共有できる新しいベータ機能ができ次第、ベータ画面を復活させます。それまでは、ダッシュボードの右上隅の Metrics (指標) タブにある Preferences (環境設定) メニューから、既存の言語関連の指標のベータ機能へのアクセスをリクエストできます。
アプリケーションレベルの指標は、開発者が Heroku で実行しているアプリケーションで起きた問題の調査や診断をするときに役立ちます。アプリケーション関連の指標を表示するには、Heroku Dashboard でアプリに移動して、Metrics (指標) タブをクリックします。
アプリケーション関連の指標は、basic、Professional (standard-1x、standard-2x、performance)、または Private の dyno を使用しているアプリでのみ利用可能です。すべての dyno タイプでアプリケーション関連の指標のすべての機能を利用できるとは限りません。利用できる機能に違いがある場合は記載されています。
一般設定
アプリケーション関連の指標の設定メニューでは、タイムゾーンの切り替え、グラフのレイアウト (縮小または完全)、データ更新とデータラグ (オン / オフ) の設定にアクセスできます。
デフォルトでは凡例に最新の指標が表示されますが、グラフ上の特定の時点にカーソルを合わせると、その時点の指標 (下図の緑のボックス) が表示されます。 サマリー指標は、特に記載されていない限り、選択中の時間枠を表します (下図の紫のボックス)。
個々の指標は、プロセスタイプごとに収集されます。ページの左上隅にあるプロセスタイプセレクタを使用して、表示するプロセスタイプを変更できます。
データの単位
アプリケーション関連の指標には、4 レベルのデータ単位があります。
- 1 分 (直近 2 時間)
- 10 分 (72 ～ 48 時間前、48 ～ 24 時間前、直近 24 時間)
- 1 時間 (直近 72 時間)
- 2 時間 (直近 7 日間)
値は、サンプリング対象期間のデータポイントのロールアップを表します。Basic dyno では、24 時間分の 10 分単位のデータにしかアクセスできません。リソースの使用状況の値は、プロセスタイプ当たりの最大または平均を表します。
表示する時系列グラフを変更する
個々の時系列グラフは、グラフタイトルの横にある [V] アイコンで非表示にしたり、表示したりできます。
表示する指標を変更する
個々の指標の凡例項目をクリックすると、グラフ上でその指標を非表示にしたり、表示したりできます。 残りの表示データに合わせて Y 軸のスケールが再変更されます。
Web dyno でのみ収集される指標
次の指標は、web プロセスタイプでのみ収集されます。
Response Time (応答時間)
- Median (中央値): 指定したサンプリング期間内 (10 分または 1 分) の 中央値 (50 パーセンタイル) の HTTP リクエストの応答時間。つまり、アプリケーションの Web リクエストの 50% がそれより短い時間内で完了し、50% がそれより長い時間内で完了したことを示します。
- 95th Percentile (95 パーセンタイル): 指定したサンプリング期間内の 95 パーセンタイルの HTTP リクエストの応答時間。つまり、アプリケーションの Web リクエストの 95% がそれより短い時間内で完了し、5% がそれより長い時間内で完了したことを示します。この指標は、想定する応答時間の上限 (最大ではなく) を指定するときに役立ちます。
- 99th Percentile (99 パーセンタイル): 指定したサンプリング期間内の 99 パーセンタイルの HTTP リクエストの応答時間。
- Max (最大): 指定したサンプリング期間内のすべての HTTP リクエストの最大応答時間。
応答時間のサマリー指標 (中央値 (50 パーセンタイル) の応答時間の平均、95 パーセンタイルの最小と最大を含む) も、選択した時間間隔で表示されます。
Throughput (スループット)
「Throughput」 (スループット) グラフには、HTTP ステータスコード (1XX、2XX、3XX、4XX、5XX) で停止したリクエストの数が表示されます。このスループット (指標の環境設定で RPS と RPM を切り替え可能) は、凡例の各ステータスコードにも表示されます。5XX ステータスコードになったリクエストは、失敗したリクエストと見なされます。
すべての dyno で収集される指標
次の指標はすべてのプロセスタイプで収集され、特定のアプリケーションの当該プロセスタイプの dyno の指標の平均を示します。
Memory Usage (メモリー使用量)
最大全体メモリー使用量が最大 RSS と最大スワップメモリーを合わせた 1 つの積み重ね棒グラフとして表示され、10 分または 1 分単位で報告されます。 平均合計メモリー (RSS + スワップ) は青い線で表示されます。メモリーの割り当てはグレーの点線で示され、メモリー違反があった場合は赤のフラグが付きます。 選択した期間 (24 時間など) の最新、平均、および最大のメモリー使用率 (%) が raw 値と共に表示されます。
- Memory Quota (メモリー割り当て): 選択した dyno タイプに使用可能な最大 RAM サイズ。このサイズを超えると、R14 メモリーエラーが発生します。
- Total Memory (合計メモリー): 平均合計メモリーは、メモリーのうちユーザーが最適化できる部分を表し、10 分または 1 分単位で計測される、すべての dyno の平均の RSS とスワップの合計が表示されます。
- RSS: RAM に格納されている、特定のプロセスタイプのすべての dyno のメモリーのサイズ (MB)。最大 RSS は、10 分または 1 分ごとの間隔で報告されます。
- Swap (スワップ): dyno のメモリーのうち、ディスクに保存されている部分 (MB)。アプリで 1 dyno 当たり数メガバイトのスワップを使用するのは普通です。ただし、スワップレベルが高い場合は、dyno のサイズと比較してメモリーの使用量が多すぎることを示している可能性があります。応答時間が遅くなる可能性があるため、このような状況は避ける必要があります。最大スワップは、10 分または 1 分ごとの間隔で報告されます。
この例では、メモリー割り当ての増加は dyno のサイズが 1X から 2X に変わったことによるものです。
Dyno Load (dyno の負荷)
負荷の値は、現在 CPU で実行されているか、または CPU での実行を待機している実行可能タスク (プロセスまたはスレッド)、それ以外の場合は、実行するために必要なすべてのリソースを備えた実行可能タスクを示しています。負荷の値には、IO を待機しているタスクは含まれません。次に例を示します。
アプリケーションに 4 つの物理コアがあり、4 つの並列スレッドを実行している場合、負荷の値には 4 が表示されます。この値がシステム上の物理コア数よりも大きくなるにつれて、1 つ以上の物理コアで競合が発生することを示しています。
アプリケーションに、データベースの結果を待機している 2 つの並列スレッドがあり、CPU に制約されるタスクを実行している 3 つの並列スレッドがある場合、負荷の値は 3 となります。
- 1m Load Average (1 分間の負荷平均): 10 分のサンプリング期間について、各 10 分間の 1 分当たりの負荷平均の平均が表示されます。1 分間の時間枠で、1 分当たりの負荷平均が直接表示されます。負荷平均には、直近 30 分の急激に減少する平均として表示される CPU タスクの数が反映されます。
- 1m Load Max (1 分間の最大負荷): 10 分間の時間枠について、その期間中の 1 分当たりの負荷平均の最大値が示されます。1 分おきに、20 秒のサンプリング期間の最大負荷平均が表示されます。
Events (イベント)
「Events」 (イベント) の表には、Heroku のエラー と、アプリケーションのヘルスに影響するユーザー起動のイベントが表示されます。現在追跡中のユーザーアクティビティには、デプロイ、設定変更、再起動があります。アクティビティのイベント (デプロイや設定変更など) は、青で表示されます。各期間中に発生したイベントタイプのマーカーは 1 期間当たり最大で 1 つしか表示されないため、各タイプのイベントの相対数が色のグラデーションで示されます。特定のイベントの上にカーソルを合わせると、詳細情報が表示されます。 表示される詳細情報には、エラーの説明と、ユーザー起動のイベントについては変更を行った人と発生した処理が含まれます。
エラー
重要なエラーは赤、警告レベルのエラーはオレンジ、情報としてのエラーはグレーで表示されます。
プラットフォームの状態に関するイベント
インシデント (黄色) と定期メンテナンス (グレー) の 2 種類のプラットフォームステータスイベントが表示されます。 お住まいの地域に該当するイベントのみ表示されます。
環境設定の変更に関するイベント
環境設定に対する変更もイベントとして取り込まれ、変更された変数もイベントの詳細に表示されます。
デプロイに関するイベントとマーカー
デプロイも 「Events」 (イベント) グラフに表示されます。デプロイのアクティビティはデプロイマーカーとして指標のグラフに展開され、ユーザーがアプリケーションのヘルスに対するデプロイのインパクトを視覚的に理解するのに役立ちます。
スケールに関するイベント
スケールに関するイベントは、dyno の水平方向か垂直方向、またはその両方のスケールのアクティビティを表します。
再起動に関するイベント
「Events」 (イベント) グラフに表示される再起動関連のイベントには、次の 3 つのカテゴリがあります。
- ユーザー起動 (手動による再起動とデプロイに関連する再起動を含む)、設定変更、dyno タイプの変更
- プラットフォームによる起動、1 日に 1 回の定期的な dyno の再起動 (日次再起動としてログに表示される)
- 予期しないランタイムクラッシュ後のプラットフォームによる再起動 (リロケーションとしてログに表示される)
アプリケーションのガイダンス
生の指標に加え、Heroku では、アプリケーションの問題の兆候を示している可能性がある特定の状況が発生した場合に、オンライン通知を受け取ることができます。問題の修正方法に関する推奨事項を参照できるように、Dev Center の関連記事へのリンクが含まれています。該当する場合は、言語固有のガイダンスも提供されます。 提供されるアラートのリストはアプリケーションの動作に関する追加データの収集に伴い常に進化していますが、例として、メモリーエラー、リクエストのタイムアウト、応答時間の遅延などの通知があります。
よく使用するアプリに関する指標
よく使用する各アプリについて、24 時間のサマリー Web 指標とスパークラインがデフォルトの Heroku Dashboard 画面に表示されます。サマリー指標には、dyno とルーターエラーの合計数、および 10 分単位での最新の 95 パーセンタイルの応答時間とスループットの値があります。Web dyno があるアプリのみ表示されます。アプリに関するほかの基本情報 (Dyno formation や dyno の場所、最新のデプロイ、言語など) も表示されます。
しきい値アラート
Professional プランの dyno (standard-1x、standard-2x、performance) で実行しているアプリでは、しきい値アラート機能を使用できます。この機能を使用すると、Web dyno の応答時間の 95 パーセンタイルの上限と失敗したリクエスト (5XX ステータスコードを返すリクエスト) の割合を指定でき、これらの上限を超えるとアラートが発行されます。メール、PagerDuty、ダッシュボードでの通知に対応しています。
アラートを設定するには、Configure Alerts (アラートの設定) を選択して Alert Setup (アラートの設定) ダイアログを開きます。
アラートの設定
監視する指標 (Response Time (応答時間) や Failed Responses (失敗した応答)) を選択します。必要に応じて、しきい値と感度を調整します。応答時間の最小しきい値は 50 ミリ秒です。感度にはエラー状態の継続時間を指定し、その時間を超えるとアラートが起動されるようにします。「Alert Simulation」 (アラートのシミュレーション) には、選択した設定を使用した場合にそのアプリで直近 24 時間に発生した可能性のあるアラートの数が表示されます。
アラートの設定と状態のサマリーが対応する指標グラフの下に表示され、既存の設定を編集するためのオプションも表示されます。
PagerDuty と追加メールの設定 (オプション)
デフォルトでは、メール通知は、非組織のアカウントの場合はアプリの所有者と共同作業者、Heroku Enterprise 組織のアカウントの場合は管理者に配信されます。メールベースの PagerDuty 統合の場合は、最初に、PagerDuty の指示 に従って、適切なエスカレーションポリシーで新規 PagerDuty サービスを作成 (または既存の PagerDuty サービスを使用) します。使用するメールアドレスを入力します。このメールアドレスは、PagerDuty でインシデントの作成に使用され、また Heroku でメール通知に使用されます。アラートのメール通知を解析するために、次の PagerDuty ルールを設定します。
次のステップは、PagerDuty 統合の場合も、追加メールの設定の場合も同じです。Add Email for Alert Notifications (アラート通知用のメールを追加) を選択して、PageDuty または追加メールを入力します。 確認のために、PageDuty インシデントまたは追加メールにコードが送信されます。 このコードを Alerting Setup (アラートの設定) に入力して、続行します。 1 件のアラート監視当たり最大 5 個の追加メールを使用できます。
メールプラットフォームには、1 ユーザーにつき 1 日当たり 5 個のメール追加までという上限があるため、複数の監視に渡ってメールを追加する場合は、アラート監視当たりの最大制限に達する前に 1 日の上限に達してしまう可能性があります。 複数のアドレスに対応してはいますが、ご使用のメールプラットフォームでエイリアスを作成し、アラート通知フレームワーク外でグループメンバーを管理することをお勧めします。
通知の配信
メール通知 (デフォルトまたは PageDuty/ 追加メール) を受け取るかどうかを指定し、受け取る場合は、アクティブなアラートの通知頻度を指定します。 両方のボックスにチェックが入っていない場合、通知はサイレント (ダッシュボードのみ) になります。
通知のアクティベーション
最後に、通知をアクティベートして、Confirm (確認) を選択します。
アラート通知
ダッシュボードのアラート通知は、次のように Heroku Dashboard の複数の場所に表示されます。
- Metrics Events (指標イベント) 表
- 対応する指標グラフ
- アプリのリスト
- パイプライン
- アプリのヘッダー
アラート発生中のアプリのアイコンには、赤いダイヤ記号が表示されます。
メール通知の場合は、アラートが起動されると最初のメールが送信されます。アクティブなアラートについては、配信設定で指定された頻度でメールが送信されます。エラー状態が解決されたときに、最後のアラート通知が送信されます。
アクセス
Heroku Enterprise Teams のユーザーがアプリケーション関連の指標で設定や通知の表示を行うには、操作許可が必要です。