アプリ指標の参照
On this page:
アプリ監視によって、インスタンスにおけるアプリの動作内容をより深く把握できます。これは、特定のアプリに関する問題のトラブルシューティングを行ったり、アプリが全体的なパフォーマンスや安定性の低下の一因になっているかどうかを判断したりするのに役立ちます。
アプリのパフォーマンス指標の完全なリスト
これは、アプリ監視エージェントによって公開される指標の完全なリストです。これとは別に、アプリケーションによって公開される JMX Bean があります。
|
アプリによってデータベースに保存されているデータの一部をアップグレードする場合の所要時間を測定します。 アップグレード タスクは、アプリの更新時または有効化時に発生します。この間、アプリの機能は利用できなくなり、アップグレード タスクが実行されているデータベースとノードの負荷が一時的に増加する可能性があります。 操作 アップグレード タスクの影響を軽減するには、アプリをオフピーク時にアップグレードすることをご検討ください。大量のデータを保存するアプリにとっては特に重要です。 アップグレード タスクは数分以内で終わるはずなので、1 時間を超える場合はベンダーにお問い合わせください。 サンプル クエリ
|
|
データベース トランザクションに要する時間を測定します。 操作 トランザクションは数秒以内で終わるはずなので、10 分を超える場合はベンダーへの問い合わせをご検討ください。 クエリの例
|
|
レコード上のさまざまなデータベース操作 (作成、検索、削除、DeleteWithSQL、取得、ストリーム、カウント) の期間を測定します。 操作 アプリからの操作に異常に長い時間 (たとえば 10 分超) を要する場合は、操作クエリが長時間実行されている、またはデータベースに負荷がかかっている可能性があります。ベンダーに、長時間実行されるクエリが予想されるかどうかに関する調査をご依頼ください。 クエリの例
name="find" などの name="<operation>" 属性を追加することで、さらに絞り込めます。 |
|
Measures how long a database cluster lock was held. Used by Bitbucket in a clustered environment. 操作 ロック競合が発生すると、パフォーマンスが低下する可能性があります。ロック待ちのスレッドがなければ、スレッドによってロックが長時間保持されるのは一般的です。 ロック待ちのスレッドが存在するかどうかを調べる方法については、 クエリの例
|
|
Measures how long a database cluster lock was waited for. Used by Bitbucket in a clustered environment. 操作 同じロックを待機しているスレッドが多いと、パフォーマンスが低下する可能性があります。問題の報告と調査を担当するベンダーにお問い合わせください。 クエリの例
|
db.sal.transactionalExecutor |
操作 トランザクションには多数の SAL 操作が含められます。問題としては、操作が多すぎる、クエリの実行に時間を要する、またはデータベースに負荷がかかることが考えられます。 クエリの例
|
web.resource.condition |
Web リソース状態に基づいてリソースを表示するかどうかを判断するのにかかる時間を測定します。 操作 Web リソースが低速状態で特にキャッシュされていない場合は、ページの読み込み時間が遅くなる可能性があります。問題の報告と調査を担当するアプリ ベンダーにお問い合わせください。 クエリの例
|
webTemplateRenderer |
Soy テンプレートまたはベロシティ テンプレートの Web パネルのレンダリングに要する時間を測定します。 操作 テンプレート レンダラーの実行には時間を要する場合があります。担当のベンダーに、長時間実行されるクエリが予想されるかどうかの調査をご依頼ください。 クエリの例
|
web.fragment.condition |
Web フラグメント条件に基づいて Web フラグメントを表示するかどうかを判断するのに要する時間を測定します。 操作 Web フラグメント条件によって、ページ上のリンク、メニュー セクションまたはパネルを表示するかどうかが判断されます。Web フラグメント条件が低速状態で特にキャッシュされていない場合は、ページの読み込み時間が遅くなります。問題の報告と調査を担当するアプリ ベンダーにお問い合わせください。 クエリの例
|
cacheManager.flushAll |
アプリによってすべてのキャッシュが消去されていることを示します。この操作は製品の速度低下につながるものであり、外部アプリによってトリガーするべきではありません。 操作
さらに、呼び出された クエリの例
|
cache.removeAll |
1 つのキャッシュからすべてのエントリが削除されたことを示します。これによって、製品やアプリの速度が低下する可能性があります。 操作 このようなキャッシュ削除がどの製品でどのような頻度で発生しているかを確認します。 さらに、 クエリの例
|
cachedReference.reset |
キャッシュ内の 1 つのエントリがリセットされたことを示します。これによって、製品やアプリの速度が低下する可能性があります。 操作 このようなキャッシュ リセットがどの製品でどのような頻度で発生しているかを確認します。 さらに、 クエリの例
|
http.rest.request |
操作 REST リクエストの頻度と期間を確認します。 クエリの例
|
|
操作 HTTP リクエストの頻度と期間を確認します。過度または非常に遅い場合は、アプリ ベンダーに問い合わせのうえ、この問題を報告することをご検討ください。また、オプションの クエリの例
|
|
長時間実行されるタスクに要する時間を測定します。 操作 タスクの期間をチェックして時間がかかりすぎる場合は、 クエリの例
|
|
キュー内のタスクに要する時間を測定します。通常、メール キューまたは短時間実行される特定のタスクに使用されます。 操作 タスクの期間をチェックして時間がかかりすぎる場合は、 クエリの例
|
|
アプリがアップタイム後に有効/無効になった回数を測定します。 操作 一部のキャッシュはアプリを無効または有効にするとクリアされて、パフォーマンスに影響を与える可能性があります。カウント数が多い場合は、UPM またはアプリ ログをチェックして、どのアプリがカウント数の増加に寄与しているかを調査します。 クエリの例
|
推奨されるアラート
アラートを自動化すると、エンド ユーザーからの報告を待たずに問題を早期に特定できます。ほとんどの APM ツールにはアラート機能があります。
次のアラートは、アプリに関する一般的な問題に対する調査に基づいています。ここでは Prometheus と Grafana を使用していますが、他の APM ツール用にもこれらのルールを調整できます。
Prometheus におけるアラートのセットアップ方法については、Prometheus ドキュメントの「Alerting overview」をご参照ください。
ヒープ メモリ使用量
ヒープ メモリを過剰に消費すると、out of memory (メモリ不足) エラー (OOME) が発生することがよくあります。ヒープ メモリ消費量の変動は一般的で想定内のことですが、このメモリを解放せずに消費量が一貫して増加すると問題が発生する可能性があります。ノードの空きヒープ メモリが一定期間 (2 分など) 10% 未満になった際にトリガーされるアラートを作成することをお勧めします。
- alert: OutOfMemory
expr: 100*(jvm_memory_bytes_used{area="heap"}/jvm_memory_bytes_max{area="heap"}) > 90
for: 2m
labels:
severity: warning
annotations:
summary: Out of memory (instance {{ $labels.instance }})
description: "Memory is filling up (< 10% left)"
CPU 使用率
プロセス集中型のジョブ、非効率的なコード (ループ)、メモリ不足など、さまざまな問題に起因して CPU 使用率が一貫して高くなる可能性があります。
CPU 負荷が一定期間 (2 分など) 80% を超えたときにトリガーされるアラートを作成することをお勧めします。
- alert: HighCpuLoad
expr: (java_lang_OperatingSystem_ProcessCpuLoad * 1000 > 80
for: 2m
labels:
severity: warning
annotations:
summary: High CPU load (instance {{ $labels.instance }})
description: "CPU load is > 80%"
フル GC
フル ガベージ コレクション (GC) は、若いヒープ世代と古いヒープ世代の両方が収集されるときに発生します。これには時間がかかり、アプリケーションが一時停止することになります。フル GC が発生する理由はさまざまですが、大きなオブジェクトがメモリに大量に読み込まれると突然のスパイクが発生する可能性があります。
フル GC の数の大幅な増加を監視することをお勧めします。そのための方法は、使用するコレクターのタイプによって異なります。G1 ガベージ コレクター (G1GC) を使用する場合は、java_lang_G1_Old_Generation_CollectionCount
指標を監視します。
ブロックされたスレッド
ブロックされたスレッドまたはスタックされたスレッドの数が多いということは、リクエストを処理できるスレッドが少ないことを意味します。ブロックされたスレッドの増加は問題を示している可能性があります。
ブロックされたスレッドの数が 10% を超えた際にトリガーされるアラートを作成することをお勧めします。
- alert: BlockedThreads
expr: avg by(instance) (rate(jvm_threads_state{state="BLOCKED"}[5m])) * 100 > 10
for: 0m
labels:
severity: warning
annotations:
summary: Blocked Threads (instance {{ $labels.instance }})
description: "Blocked Threads are > 10%"
データベース接続プール
データベース接続プールは、インスタンスのサイズ (ユーザーやプラグインの数など) に合わせて調整する必要があります。また、データベースで許可されている内容に合わせる必要があります。
接続数が一定期間常に最大数近辺にある際にトリガーされるアラートを作成することをお勧めします。
アラートの例
- alert: DatabaseConnections
expr: 100*(<domain>_BasicDataSource_NumActive{connectionpool="connections"}/<domain>_BasicDataSource_MaxTotal{connectionpool="connections"}) > 90
for: 5m
labels:
severity: warning
annotations:
summary: Database Connections (instance {{ $labels.instance }})
description: "Database Connections are filling up (< 10% left)"
<domain> を Product 指標ドメイン (com_atlassian_bitbucket
や com_atlassian_confluence
など) に置き換えます。
アラートへの対応
一時的な問題や自然に解消される問題もあれば、重大なパフォーマンス低下の警告サインとなる問題もあります。
問題の原因を調査する際は、以下のアプリ固有の指標が役立ちます。これらの指標から、ある特定のアプリがより多くの時間を費やしている、または API を頻繁に呼び出していることが明らかになった場合は、そのアプリを無効にしてパフォーマンスが向上するかどうかを確認できます。重要なアプリの場合は、サポート チケットを発行して、監視情報から抽出した関連データをサポート zip に含めます。