アプリ指標の参照
On this page:
アプリ監視によって、インスタンスにおけるアプリの動作内容をより深く把握できます。これは、特定のアプリに関する問題のトラブルシューティングを行ったり、アプリが全体的なパフォーマンスや安定性の低下の一因になっているかどうかを判断したりするのに役立ちます。
アプリのパフォーマンス指標の完全なリスト
これは、アプリ監視エージェントによって公開される指標の完全なリストです。これとは別に、アプリケーションによって公開される JMX Bean があります。
|
この指標は、情報に対してインデックスが再作成されたことを示します。 操作 インデックスを再作成すると、サイトのパフォーマンスが低下する可能性があります。インデックスはピーク時を避けて再作成するのが理想的です。
クエリの例 |
|
検索リクエストの所要時間を測定します。 操作
アプリで大量の検索が実行されている、または検索結果の処理に常に長時間かかる場合は、アプリのベンダーにお問い合わせください。 クエリの例 |
|
アプリによってデータベースに保存されているデータの一部をアップグレードする場合の所要時間を測定します。 アップグレード タスクは、アプリの更新時または有効化時に発生します。この間、アプリの機能は利用できなくなり、アップグレード タスクが実行されているデータベースとノードの負荷が一時的に増加する可能性があります。 操作 アプリによってデータベースに大量のデータが保存されている場合は、Confluence がビジー状態でないときに更新をスケジュールすることをご検討ください。 サンプル クエリ |
|
操作 トランザクションには多数の AO 操作を含められます。問題としては、操作が多すぎること、クエリの実行に時間がかかること、またはデータベースに負荷がかかることが考えられます。 クエリの例 |
|
操作 操作クエリの実行には時間がかかる可能性があります。また、データベースに負荷がかかります。 クエリの例 name="find" などの name="<operation>" 属性を追加することで、さらに絞り込めます。 |
|
データベース クラスター ロックが保持されていた期間を測定します。クラスター環境内で Confluence によって使用されます。 操作 ロック競合が発生すると、パフォーマンスが低下する可能性があります。ロック待ちのスレッドがなければ、スレッドによってロックが長時間保持されるのは一般的です。 ロック待ちのスレッドが存在するかどうかを調べる方法については、 クエリの例 |
|
データベース クラスター ロックの待ち時間を測定します。クラスター環境内で Confluence によって使用されます。 操作 同じロックを待っているスレッドが多いと、パフォーマンスが低下する可能性があります。 クエリの例 |
db.sal.transactionalExecutor |
操作 トランザクションには多数の SAL 操作を含められます。問題としては、操作が多すぎること、クエリの実行に時間がかかること、またはデータベースに負荷がかかることが考えられます。 クエリの例 |
web.resource.condition |
Web リソース状態に基づいてリソースを表示するかどうかを判断するのにかかる時間を測定します。 操作 Web リソースが低速状態にあり、特にキャッシュされていない場合は、ページの読み込み時間が遅くなる可能性があります。 クエリの例 |
plugin.disabled.counter |
アプリが稼働後に無効化された回数を測定します。 操作 一部のキャッシュは、アプリを無効化または有効化するとクリアされます。これはパフォーマンスに影響を及ぼす可能性があります。この数が増えた場合は、UPM またはアプリケーション ログを確認して、この数に寄与しているアプリを調べてください。 クエリの例 |
plugin.enabled.counter |
アプリが稼働後に有効化された回数を測定します。 操作 一部のキャッシュは、アプリを無効または有効にするとクリアされます。これはパフォーマンスに影響を及ぼす可能性があります。この数が増えた場合は、UPM またはアプリ ログをご確認のうえ、この数に寄与しているアプリをお調べください。 クエリの例 |
soyTemplateRenderer |
Soy テンプレート Web パネルのレンダリングの所要時間を測定します。 操作 テンプレート レンダラーの実行には時間がかかる可能性があります。 クエリの例 |
webTemplateRenderer |
アトラシアン テンプレート Web パネルのレンダリングの所要時間を測定します。 操作 テンプレート レンダラーの実行には時間がかかる可能性があります。 クエリの例 |
web.fragment.condition |
Web フラグメント状態に基づいて Web フラグメントを表示するかどうかを判断するのにかかる時間を測定します。 操作 Web フラグメント状態に基づいてページ上のリンクまたはセクションを表示するかどうかを判断します。Web フラグメントが低速状態にあり、特にキャッシュされていない場合は、ページの読み込み時間が遅くなります。 クエリの例 |
cacheManager.flushAll |
アプリによってすべてのキャッシュが消去されていることを示します。この操作は製品の速度低下につながるものであり、外部アプリによってトリガーするべきではありません。 操作
クエリの例 |
cache.removeAll |
1 つのキャッシュからすべてのエントリが削除されたことを示します。これによって、製品やアプリの速度が低下する可能性があります。 操作 このようなキャッシュ削除がどの製品でどのような頻度で発生しているかを確認します。 クエリの例 |
cachedReference.reset |
キャッシュ内の 1 つのエントリがリセットされたことを示します。これによって、製品やアプリの速度が低下する可能性があります。 操作 このようなキャッシュ リセットがどの製品でどのような頻度で発生しているかを確認します。 クエリの例 |
rest.request |
アトラシアンの REST モジュールを使用する REST API の HTTP リクエストを測定します。 操作 REST リクエストの頻度と期間を確認します。 クエリの例 |
推奨されるアラート
アラートを自動化すると、エンド ユーザーからの報告を待たずに問題を早期に特定できます。ほとんどの 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 * 100 > 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)"アラートへの対応
一時的な問題や自然に解消される問題もあれば、重大なパフォーマンス低下の警告サインとなる問題もあります。
問題の原因を調査する際は、以下のアプリ固有の指標が役立ちます。これらの指標から、ある特定のアプリがより多くの時間を費やしている、または API を頻繁に呼び出していることが明らかになった場合は、そのアプリを無効にしてパフォーマンスが向上するかどうかを確認できます。重要なアプリの場合は、サポート チケットを発行して、監視情報から抽出した関連データをサポート zip に含めます。