クラウド
Data Center 9.2
バージョン

アプリ指標の参照

アプリケーション パフォーマンスを監視する

このページの内容

関連コンテンツ

  • 関連コンテンツがありません

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

On this page:

アプリ監視によって、インスタンスにおけるアプリの動作内容をより深く把握できます。これは、特定のアプリに関する問題のトラブルシューティングを行ったり、アプリが全体的なパフォーマンスや安定性の低下の一因になっているかどうかを判断したりするのに役立ちます。

アプリ監視の設定方法を確認する

アプリのパフォーマンス指標の完全なリスト

これは、アプリ監視エージェントによって公開される指標の完全なリストです。これとは別に、アプリケーションによって公開される JMX Bean があります。 

indexing.field.addIndex

カスタム フィールド インデクサーが特定のカスタム フィールドの値 0 のインデックスを作成するのに要する時間を測定します。

操作

カスタム フィールド インデクサーは、インデックス作成とインデックス再作成の時間に影響します。特定のフィールド インデクサーに時間がかかりすぎる場合は、アプリ ベンダーに調査をご依頼ください。fromPluginKey タグによって、どのアプリがインデクサーを担当しているかを確認できます。

カスタム フィールド ID によってカスタム フィールドの使用状況と詳細情報を調べる方法については、「Find my custom field ID number in Jira (Jira でカスタム フィールド ID 番号を見つける)」を参照してください。

クエリの例

com_atlassian_jira_metrics_Mean
  {
   name="addIndex", 
   category01="field"
  }

indexing.field.isFieldIndexableForIssue

カスタム フィールド インデクサーがフィールドのインデックス作成を行うかどうかを判断するのに要する時間を測定します。

操作

カスタム フィールド インデクサーは、インデックス作成とインデックス再作成の時間に影響します。フィールドのインデックス作成の決定に時間がかかりすぎる場合は、アプリ ベンダーに調査をご依頼ください。fromPluginKey タグによって、どのプラグインがインデクサーを担当しているかを確認できます。

カスタム フィールド ID によってカスタム フィールドの使用状況と詳細情報を調べる方法については、「Find my custom field ID number in Jira (Jira でカスタム フィールド ID 番号を見つける)」を参照してください。

クエリの例

com_atlassian_jira_metrics_Mean
  {
   name="isFieldIndexableForIssue", 
   category01="field"
  }

search.index

Lucene インデックス検索の実行に要する時間を測定します。

操作

アプリが量や期間が異常な検索をトリガーした場合は、アプリ ベンダーに調査をご依頼ください。invokerPluginKey タグによって、どのアプリがインデックス検索を担当しているかを確認できます。

クエリの例

com_atlassian_jira_metrics_Mean
  {
   category00="search",
   name="index"
  }

issue.reindexing

課題のインデックス再作成を実行するまでに要する時間を測定します。

操作

アプリが量や期間が異常な課題のインデックス再作成をトリガーした場合は、アプリ ベンダーに調査をご依頼ください。invokerPluginKey タグによって、どのアプリが課題のインデックス再作成を担当しているかを確認できます。

クエリの例

com_atlassian_jira_metrics_Mean
  {
   name="reindexing", 
   category00="issue"
  }

comment.reindexing

コメントのインデックス再作成の実行までに要する時間を測定します。

操作

アプリが量または期間に異常なコメントのインデックス再作成をトリガーした場合は、アプリ ベンダーに調査をご依頼ください。invokerPluginKey タグによって、どのアプリがコメントのインデックス再作成を担当しているかを確認できます。

クエリの例

com_atlassian_jira_metrics_Mean
  {
   name="reindexing", 
   category00="comment"
  }

db.core.executionTime

SQL ステートメントが提供されてから結果を提供するまで、データベース クエリの実行に要する時間を測定します。

これは Jira のすべてのデータベース操作を支えます。つまり、db.ao と db.sal の各指標はサブセットです。

操作

アプリが量や期間が異常な SQL クエリをトリガーした場合は、アプリ ベンダーに調査をご依頼ください。invokerPluginKey タグは、データベース クエリを実行する処理を行っているアプリを示します。

オプションのタグ SQL を有効にすると、データベース クエリが正確に何であるかをデバッグするために使用できます。メモリ消費量が急速に増加するため、本番環境でこのオプション タグを有効にすることはお勧めしません。

クエリの例

com_atlassian_jira_metrics_Mean
  {
   name="executionTime", 
   category00="db", 
   category01="core"
  }

db.ao.upgradetask

アプリによってデータベースに保存されているデータの一部をアップグレードする場合の所要時間を測定します。

アップグレード タスクは、アプリの更新時または有効化時に発生します。この間、アプリの機能は利用できなくなり、アップグレード タスクが実行されているデータベースとノードの負荷が一時的に増加する可能性があります。

操作

アップグレード タスクの影響を軽減するには、アプリをオフピーク時にアップグレードすることをご検討ください。大量のデータを保存するアプリにとっては特に重要です。

アップグレード タスクは数分以内で終わるはずなので、1 時間を超える場合はベンダーにお問い合わせください。

サンプル クエリ

com_atlassian_jira_metrics_Value
  {
   category00="db",
   category01="ao",
   name="upgradetask"
  }

db.ao.executeInTransaction

データベース トランザクションに要する時間を測定します。

操作

トランザクションは数秒以内で終わるはずなので、10 分を超える場合はベンダーへの問い合わせをご検討ください。

クエリの例

com_atlassian_jira_metrics_Value
  {
   category00="db",
   category01="ao",
   name="executeInTransaction"
  }

db.ao.entityManager

レコード上のさまざまなデータベース操作 (作成、検索、削除、DeleteWithSQL、取得、ストリーム、カウント) の期間を測定します。

操作

アプリからの操作に異常に長い時間 (たとえば 10 分超) を要する場合は、操作クエリが長時間実行されている、またはデータベースに負荷がかかっている可能性があります。ベンダーに、長時間実行されるクエリが予想されるかどうかに関する調査をご依頼ください。

クエリの例

com_atlassian_jira_metrics_95thPercentile
  {
   category00="db",
   category01="ao",
   category02="entityManager"
  }


name="find" などの name="<operation>" 属性を追加することで、さらに絞り込めます。

cluster.lock.held.duration

データベース クラスター ロックが保持されていた期間を測定します。クラスター環境で Jira によって使用されます。

操作

ロック競合が発生すると、パフォーマンスが低下する可能性があります。ロック待ちのスレッドがなければ、スレッドによってロックが長時間保持されるのは一般的です。

ロック待ちのスレッドが存在するかどうかを調べる方法については、db.cluster.lock.waited.duration をご参照ください。

クエリの例

com_atlassian_jira_metrics_Value
  {
   category00="cluster",
   category01="lock",
   category02="held"
  }

cluster.lock.waited.duration

データベース クラスター ロックの待ち時間を測定します。クラスター環境で Jira によって使用されます。

操作

同じロックを待機しているスレッドが多いと、パフォーマンスが低下する可能性があります。問題の報告と調査を担当するベンダーにお問い合わせください。

クエリの例

com_atlassian_jira_metrics_Value
  {
   category00="cluster",
   category01="lock",
   category02="waited"
  }
db.sal.transactionalExecutor

DefaultTransactionalExecutor 内で共有アプリケーション レイヤー (SAL) トランザクションを実行する場合の所要時間を測定します。

操作

トランザクションには多数の SAL 操作が含められます。問題としては、操作が多すぎる、クエリの実行に時間を要する、またはデータベースに負荷がかかることが考えられます。 

クエリの例

com_atlassian_jira_metrics_Value
  {
   category00="db",
   category01="sal",
   name="transactionalExecutor", 
   statistic="active"
  }
web.resource.condition

Web リソース状態に基づいてリソースを表示するかどうかを判断するのにかかる時間を測定します。

操作

Web リソースが低速状態で特にキャッシュされていない場合は、ページの読み込み時間が遅くなる可能性があります。問題の報告と調査を担当するアプリ ベンダーにお問い合わせください。

クエリの例

com_atlassian_jira_metrics_95thPercentile
  {
   category00="web",
   category01="resource",
   name="condition"
  }
webTemplateRenderer

Soy テンプレートまたはベロシティ テンプレートの Web パネルのレンダリングに要する時間を測定します。

操作

テンプレート レンダラーの実行には時間を要する場合があります。担当のベンダーに、長時間実行されるクエリが予想されるかどうかの調査をご依頼ください。

クエリの例

com_atlassian_jira_metrics_95thPercentile
  {
   name="webTemplateRenderer",
   templateRenderer="velocity"
  }
web.fragment.condition

Web フラグメント条件に基づいて Web フラグメントを表示するかどうかを判断するのに要する時間を測定します。

操作

Web フラグメント条件によって、ページ上のリンク、メニュー セクションまたはパネルを表示するかどうかが判断されます。Web フラグメント条件が低速状態で特にキャッシュされていない場合は、ページの読み込み時間が遅くなります。問題の報告と調査を担当するアプリ ベンダーにお問い合わせください。 

クエリの例

com_atlassian_jira_metrics_95thPercentile
  {
   category00="web", 
   category01="fragment", 
   name="condition"
  }
cacheManager.flushAll

アプリによってすべてのキャッシュが消去されていることを示します。この操作は製品の速度低下につながるものであり、外部アプリによってトリガーするべきではありません。

操作

invokerPluginKey タグによって、フラッシュを呼び出したアプリを特定します。アプリ ベンダーにお問い合わせのうえ、この問題を報告してください。

さらに、呼び出された CacheManager の実装を参照する className タグも役に立つ場合があります。

クエリの例

com_atlassian_jira_metrics_Count
  {
    category00="cacheManager",
    name="flushAll"
  }
cache.removeAll

1 つのキャッシュからすべてのエントリが削除されたことを示します。これによって、製品やアプリの速度が低下する可能性があります。

操作

このようなキャッシュ削除がどの製品でどのような頻度で発生しているかを確認します。pluginKeyAtCreation タグによって、キャッシュを作成したアプリを特定します。  

さらに、Cache の実装を参照する className タグも役に立つ場合があります。頻度が多すぎる場合は、アプリ ベンダーに問い合わせてこの問題を報告することをご検討ください。

クエリの例

com_atlassian_jira_metrics_Count
  {
   category00="cache",
   name="removeAll",
   invokerPluginKey!="undefined"
  }
cachedReference.reset

キャッシュ内の 1 つのエントリがリセットされたことを示します。これによって、製品やアプリの速度が低下する可能性があります。

操作

このようなキャッシュ リセットがどの製品でどのような頻度で発生しているかを確認します。pluginKeyAtCreation タグによって、キャッシュを作成したアプリを特定します。 

さらに、CachedReference の実装を参照する className タグも役に立つ場合があります。頻度が多すぎる場合は、アプリ ベンダーに問い合わせてこの問題を報告することをご検討ください。

クエリの例

com_atlassian_jira_metrics_Count
  {
   category00="cachedReference",
   name="reset",
   invokerPluginKey!="undefined"
  }
rest.request

atlassian-rest モジュールを使用する REST API の HTTP リクエストを測定します。

操作

REST リクエストの頻度と期間を確認します。 

クエリの例

com_atlassian_jira_metrics_95thPercentile
  {
   category00="http", 
   category01="rest", 
   name="request"
  }

http.sal.request

atlassian-sal モジュールを使用する一意の URL の HTTP リクエストを測定します。

操作

HTTP リクエストの頻度と期間を確認します。過度または非常に遅い場合は、アプリ ベンダーに問い合わせのうえ、この問題を報告することをご検討ください。また、オプションの URL タグを有効にして、問題の原因となっている URL を特定できます。そのためには、atlassian.metrics.optional.tags.http.sal.request=url のようにシステム変数を設定します。

クエリの例

com_atlassian_jira_metrics_95thPercentile
  {
   category00="http", 
   category01="sal", 
   name="request"
  }

longRunningTask

長時間実行されるタスクに要する時間を測定します。

操作

タスクの期間をチェックして時間がかかりすぎる場合は、taskClass と pluginKey を探してソースを特定のうえ、アプリ ベンダーにお問い合わせて問題をご報告ください。

クエリの例

com_atlassian_jira_metrics_95thPercentile
  {
   name="longRunningTask",
   taskName=myLongRunningTask"
  }

task

キュー内のタスクに要する時間を測定します。通常、メール キューまたは短時間実行される特定のタスクに使用されます。

操作

タスクの期間をチェックして時間がかかりすぎる場合は、queueName と pluginKey を探してソースを特定のうえ、アプリ ベンダーにお問い合わせて問題をご報告ください。

クエリの例

com_atlassian_jira_metrics_95thPercentile
  {
   name="task",
   taskName=myEmailQueue"
  }

plugin.enabled.counter / plugin.disabled.counter

アプリがアップタイム後に有効/無効になった回数を測定します。

操作

一部のキャッシュはアプリを無効または有効にするとクリアされて、パフォーマンスに影響を与える可能性があります。カウント数が多い場合は、UPM またはアプリ ログをチェックして、どのアプリがカウント数の増加に寄与しているかを調査します。

クエリの例

com_atlassian_jira_metrics_Count
  {
   category00="plugin",
   category01="enabled",
   name="counter"
  }

推奨されるアラート

アラートを自動化すると、エンド ユーザーからの報告を待たずに問題を早期に特定できます。ほとんどの 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_jira や com_atlassian_confluence など) に置き換えます。

アラートへの対応

一時的な問題や自然に解消される問題もあれば、重大なパフォーマンス低下の警告サインとなる問題もあります。

問題の原因を調査する際は、以下のアプリ固有の指標が役立ちます。これらの指標から、ある特定のアプリがより多くの時間を費やしている、または API を頻繁に呼び出していることが明らかになった場合は、そのアプリを無効にしてパフォーマンスが向上するかどうかを確認できます。重要なアプリの場合は、サポート チケットを発行して、監視情報から抽出した関連データをサポート zip に含めます。

最終更新日 2023 年 7 月 12 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する

関連コンテンツ

  • 関連コンテンツがありません
Powered by Confluence and Scroll Viewport.