Skip Navigation
Show nav
Dev Center
  • Get Started
  • ドキュメント
  • Changelog
  • Search
  • Get Started
    • Node.js
    • Ruby on Rails
    • Ruby
    • Python
    • Java
    • PHP
    • Go
    • Scala
    • Clojure
    • .NET
  • ドキュメント
  • Changelog
  • More
    Additional Resources
    • Home
    • Elements
    • Products
    • Pricing
    • Careers
    • Help
    • Status
    • Events
    • Podcasts
    • Compliance Center
    Heroku Blog

    Heroku Blog

    Find out what's new with Heroku on our blog.

    Visit Blog
  • Log inorSign up
Hide categories

Categories

  • Heroku のアーキテクチャ
    • コンピューティング (dyno)
      • dyno の管理
      • dyno の概念
      • dyno の動作
      • dyno の参照資料
      • dyno のトラブルシューティング
    • スタック (オペレーティングシステムイメージ)
    • ネットワーキングと DNS
    • プラットフォームポリシー
    • プラットフォームの原則
  • 開発者ツール
    • コマンドライン
    • Heroku の VS Code 拡張機能
  • デプロイ
    • Git を使用したデプロイ
    • Docker によるデプロイ
    • デプロイ統合
  • 継続的デリバリーとインテグレーション
    • 継続的統合
  • 言語サポート
    • Node.js
      • Node.js アプリのトラブルシューティング
      • Heroku での Node.js の動作
      • Node.js の操作
    • Ruby
      • Rails のサポート
      • Bundler の使用
      • Ruby の操作
      • Heroku での Ruby の動作
      • Ruby アプリのトラブルシューティング
    • Python
      • Python の操作
      • Python でのバックグラウンドジョブ
      • Heroku での Python の動作
      • Django の使用
    • Java
      • Heroku での Java の動作
      • Java の操作
      • Maven の使用
      • Spring Boot の使用
      • Java アプリのトラブルシューティング
    • PHP
      • PHP の操作
      • Heroku での PHP の動作
    • Go
      • Go の依存関係管理
    • Scala
    • Clojure
    • .NET
      • Working with .NET
  • データベースとデータ管理
    • Heroku Postgres
      • Postgres の基礎
      • Postgres スターターガイド
      • Postgres のパフォーマンス
      • Postgres のデータ転送と保持
      • Postgres の可用性
      • Postgres の特別なトピック
      • Heroku Postgres への移行
    • Heroku Key-Value Store
    • Apache Kafka on Heroku
    • その他のデータストア
  • AI
    • Vector Database
    • Working with AI
    • Heroku Inference
      • AI Models
      • Inference Essentials
      • Heroku Inference Quick Start Guides
      • Inference API
    • Model Context Protocol
  • モニタリングとメトリクス
    • ログ記録
  • アプリのパフォーマンス
  • アドオン
    • すべてのアドオン
  • 共同作業
  • セキュリティ
    • アプリのセキュリティ
    • ID と認証
      • シングルサインオン (SSO)
    • Private Space
      • インフラストラクチャネットワーキング
    • コンプライアンス
  • Heroku Enterprise
    • Enterprise Accounts
    • Enterprise Team
    • Heroku Connect (Salesforce 同期)
      • Heroku Connect の管理
      • Heroku Connect のリファレンス
      • Heroku Connect のトラブルシューティング
  • パターンとベストプラクティス
  • Heroku の拡張
    • Platform API
    • アプリの Webhook
    • Heroku Labs
    • アドオンのビルド
      • アドオン開発のタスク
      • アドオン API
      • アドオンのガイドラインと要件
    • CLI プラグインのビルド
    • 開発ビルドパック
    • Dev Center
  • アカウントと請求
  • トラブルシューティングとサポート
  • Salesforce とのインテグレーション
  • モニタリングとメトリクス
  • アプリケーション関連の指標

アプリケーション関連の指標

日本語 — Switch to English

最終更新日 2025年04月01日(火)

Table of Contents

  • Web dyno でのみ収集される指標
  • すべての dyno で収集される指標
  • アプリケーションのガイダンス
  • よく使用するアプリに関する指標
  • しきい値アラート

アプリケーションレベルの指標は、開発者が Heroku で実行しているアプリケーションで起きた問題の調査や診断をするときに役立ちます。アプリケーション関連の指標を表示するには、Heroku Dashboard でアプリに移動して、Metrics (指標) タブをクリックします。

eco​ dyno を使用しているアプリではアプリケーション関連のメトリクスを使用できません。すべての dyno タイプでアプリケーション関連の指標のすべての機能を利用できるとは限りません。利用できる機能に違いがある場合は記載されています。

 

Fir 世代のアプリ​で dyno の負荷​チャートが CPU に変更されました。再起動に関するイベント​と一部の Heroku エラーコード​は、Fir アプリではまだ利用できません。Fir のオブザーバビリティに関連する変更について通知を受け取るには、changelog​ の受信登録を行ってください。

一般設定

アプリケーション関連の指標の設定メニューでは、タイムゾーンの切り替え、グラフのレイアウト (縮小または完全)、データ更新とデータラグ (オン / オフ) の設定にアクセスできます。 メトリクスの設定

Fir​ 世代のアプリでは、言語固有のメトリクス​の表示はまだ利用できません。

デフォルトでは凡例に最新の指標が表示されますが、グラフ上の特定の時点にカーソルを合わせると、その時点の指標 (下図の緑のボックス) が表示されます。サマリー指標は、特に記載されていない限り、選択中の時間枠を表します (下図の紫のボックス)。 プロットの凡例

個々の指標は、プロセスタイプ​ごとに収集されます。ページの左上隅にあるプロセスタイプセレクタを使用して、表示するプロセスタイプを変更できます。

プロセスセレクタ

データの単位

アプリケーション関連の指標には、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 パーセンタイルの最小と最大を含む) も、選択した時間間隔で表示されます。 ![応答時間のグラフ](https://devcenter3.assets.heroku.com/article-images/1517350235-Screen-Shot-2018-01-30-at-2.10.00-PM.png)

Throughput (スループット)

「Throughput​」 (スループット) グラフには、HTTP ステータスコード (1XX、2XX、3XX、4XX、5XX) で停止したリクエストの数が表示されます。このスループット (指標の環境設定で RPS と RPM を切り替え可能) は、凡例の各ステータスコードにも表示されます。5XX ステータスコードになったリクエストは、失敗したリクエストと見なされます。 ![スループットのグラフ](https://devcenter3.assets.heroku.com/article-images/2167-imported-1502436564-29098368-4a10bccc-7c5c-11e7-8cbf-3abaed17a7f3.png)

すべての dyno で収集される指標

次の指標はすべてのプロセスタイプで収集され、特定のアプリケーションの当該プロセスタイプの dyno の指標の平均を示します。

Memory Usage (メモリ使用量)

Kubernetes バックエンドではメトリクスが利用できないため、Fir​ 世代のアプリではスワップメモリは報告されません。

最大全体メモリ使用量が最大 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 分ごとの間隔で報告されます。

memoryPlot

Dyno Load (dyno の負荷)

Cedar 世代のアプリ

Cedar​ 世代のアプリの負荷の値は、現在 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 秒のサンプリング期間の最大負荷平均が表示されます。

負荷のグラフ

CPU Usage (CPU 使用率)

Fir​ 世代のアプリの場合、Heroku には負荷平均ではなく CPU 使用率が表示されます。プロットには次の CPU 使用率指標が含まれます。

  • Max Usage (最大使用率)​: 最大使用率は、選択した解決ロールアップと期間で特定された最大 CPU 使用率の値です。
  • Average Usage (平均使用率)​: 平均使用率は、選択した解決ロールアップと期間全体で計算された平均 CPU 使用率です。

CPU チャート

Events (イベント)

「Events」 (イベント) の表には、Heroku のエラー​ と、アプリケーションのヘルスに影響するユーザー起動のイベントが表示されます。現在追跡中のユーザーアクティビティには、デプロイ、設定変更、再起動があります。アクティビティのイベント (デプロイや設定変更など) は、青で表示されます。各期間中に発生したイベントタイプのマーカーは 1 期間あたり最大で 1 つしか表示されないため、各タイプのイベントの相対数が色のグラデーションで示されます。特定のイベントの上にカーソルを合わせると、詳細情報が表示されます。表示される詳細情報には、エラーの説明と、ユーザー起動のイベントについては変更を行った人と発生した処理が含まれます。

エラー

一部のエラーコード​は Fir 世代のアプリではまだ利用できません。

重要なエラーは赤、警告レベルのエラーはオレンジ、情報としてのエラーはグレーで表示されます。

エラーの詳細ドロップダウン

プラットフォームの状態に関するイベント

インシデント (黄色) と定期メンテナンス (グレー) の 2 種類のプラットフォームステータスイベントが表示されます。お住まいの地域に該当するイベントのみ表示されます。 ステータスイベントの色分け

環境設定の変更に関するイベント

環境設定に対する変更もイベントとして取り込まれ、変更された変数もイベントの詳細に表示されます。 強調表示された環境設定の変更

デプロイに関するイベントとマーカー

デプロイも 「Events」 (イベント) グラフに表示されます。デプロイのアクティビティはデプロイマーカーとして指標のグラフに展開され、ユーザーがアプリケーションのヘルスに対するデプロイのインパクトを視覚的に理解するのに役立ちます。 強調表示されたデプロイに関するイベント

スケールに関するイベント

スケールに関するイベントは、dyno の水平方向か垂直方向、またはその両方のスケールのアクティビティを表します。 強調表示されたスケールに関するイベント

再起動に関するイベント

再起動に関するイベントは Fir 世代のアプリではまだ利用できません。

「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​) とすべての Fir dyno​ で実行しているアプリでは、しきい値アラート機能を使用できます。この機能を使用すると、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 統合の場合も、追加メールの設定の場合も同じです。Add Email for Alert Notifications (アラート通知用のメールを追加) を選択して、PageDuty または追加メールを入力します。確認のために、PageDuty インシデントまたは追加メールにコードが送信されます。このコードを Alerting Setup (アラートの設定) に入力して、続行します。1 件のアラート監視あたり最大 5 個の追加メールを使用できます。

メールプラットフォームには、1 ユーザーにつき 1 日あたり 5 個のメール追加までという上限があるため、複数の監視にわたってメールを追加する場合は、アラート監視あたりの最大制限に達する前に 1 日の上限に達してしまう可能性があります。複数のアドレスに対応してはいますが、ご使用のメールプラットフォームでエイリアスを作成し、アラート通知フレームワーク外でグループメンバーを管理することをお勧めします。

通知の設定フォーム

通知の配信

メール通知 (デフォルトまたは PageDuty/ 追加メール) を受け取るかどうかを指定し、受け取る場合は、アクティブなアラートの通知頻度を指定します。両方のボックスにチェックが入っていない場合、通知はサイレント (ダッシュボードのみ) になります。

通知のアクティベーション

最後に、通知をアクティベートして、Confirm (確認) を選択します。

アラート通知

ダッシュボードのアラート通知は、次のように Heroku Dashboard の複数の場所に表示されます。

  • Metrics Events (指標イベント) 表
  • 対応する指標グラフ
  • アプリのリスト
  • パイプライン
  • アプリのヘッダー

アラート発生中のアプリのアイコンには、赤いダイヤ記号が表示されます。 アラートアイコンのあるブレッドクラムメニュー​

メール通知の場合は、アラートが起動されると最初のメールが送信されます。アクティブなアラートについては、配信設定で指定された頻度でメールが送信されます。エラー状態が解決されたときに、最後のアラート通知が送信されます。

アクセス

Heroku Enterprise Teams のユーザーがアプリケーション関連の指標で設定や通知の表示を行うには、操作許可が必要です。

関連カテゴリー

  • モニタリングとメトリクス

Information & Support

  • Getting Started
  • Documentation
  • Changelog
  • Compliance Center
  • Training & Education
  • Blog
  • Support Channels
  • Status

Language Reference

  • Node.js
  • Ruby
  • Java
  • PHP
  • Python
  • Go
  • Scala
  • Clojure
  • .NET

Other Resources

  • Careers
  • Elements
  • Products
  • Pricing
  • RSS
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku Blog
    • Heroku News Blog
    • Heroku Engineering Blog
  • Twitter
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku
    • Heroku Status
  • Github
  • LinkedIn
  • © 2025 Salesforce, Inc. All rights reserved. Various trademarks held by their respective owners. Salesforce Tower, 415 Mission Street, 3rd Floor, San Francisco, CA 94105, United States
  • heroku.com
  • Legal
  • Terms of Service
  • Privacy Information
  • Responsible Disclosure
  • Trust
  • Contact
  • Cookie Preferences
  • Your Privacy Choices