Data Center の監視を開始する
この記事では、Data Center インスタンスの健全性の監視に関する基本的なガイドラインをいくつか提供します。2 種類のメトリックを監視する必要があります。
用途
これらのメトリックは、組織が Data Center 製品をどのように使用しているか (ユーザー数、ページ数 (Confluence)、課題数 (Jira) など) を反映します。また、Jira インスタンスが使用するカスタム フィールドの数など、カスタマイズを数値化できるケースについても説明します。
インフラストラクチャ
ユーザーが製品で行うすべての操作で負荷が発生します。その負荷の影響は、Data Center 製品のカスタマイズ/構成方法によって変わります。インフラストラクチャ メトリックは、Data Center 製品がホストされている環境に負荷が与える影響を反映します。
大きな組織では、Data Center アプリケーションの管理タスク、依存コンポーネント、および基盤インフラストラクチャが様々な役割に分散されている場合があります。使用率とインフラストラクチャ メトリックの違いを理解することは、各メトリックをどこで追跡するか、およびそれらの追跡や管理を誰が担当するかを判断するのに役立ちます。
使用率のメトリック
使用率のメトリックは、製品の管理ユーザーのインターフェイスまたはデータベースから追跡できます。このセクションでは、Jira または Confluence の基本的なガイダンスを提供します。
使用率の傾向を追跡し、長期間での成長率を観察します。これらの成長傾向を使用すると、負荷がどのように変化するかを予測することに役立ちます。以下のリストは、Jira と Confluence の両方で追跡する必要がある基本的なメトリックです。
Jira
アプリケーションの使用状況
次の項目の合計数を定期的に追跡:
- 課題
- 添付ファイル (合計サイズを含む)
- プロジェクト
- プロジェクトの中間生成物
- ワークフロー
- カスタム フィールド
また、プラグインの誤作動やその他の問題 (課題の合計数が過去 24 時間で 10 % 増加した場合など) を示す場合があるため、使用率の急激な増加も確認する必要があります。
Confluence
アプリケーションの使用状況
次の項目の合計数を定期的に追跡:
- 既存のページ
- 添付ファイル (合計サイズを含む)
- すべてのスペース
- サイト スペース
- 個人用スペース
- すべてのコンテンツ アイテム
- 現在のコンテンツ アイテム (ページ、ブログ投稿など)
- 過去 (現在より前のバージョン) のコンテンツ アイテム
データベース使用率
- データベースのテーブル サイズ
- 1 日あたりの作成されたコンテンツ
- 1 日あたりの編集コンテンツ数
このデータの取得方法については、以下をご覧ください。
- システム情報の表示 (Jira)
- データベース接続使用率の監視 (Jira)
データベース使用率
- 1 日あたりの作成コンテンツ数 (作成されたページの平均数)
- 1 日あたりの編集コンテンツ数
このデータの取得方法については、以下をご覧ください。
- システム情報の表示 (Confluence)
関連情報については、「Data Center アプリケーションの監視用ツール」を参照してください。
その他のリソース
Dynatrace は、プラットフォーム上で Jira および Confluence を管理する方法に関する概要も提供します。詳細は、「Dynatrace で Atlassian JIRA および Confluence の生産性を最適化する」を参照してください。
インフラストラクチャのメトリック
インフラストラクチャのメトリックでは一般的に、追跡のためのサードパーティ製ツールが必要となります。特に、1 クラスター内の複数のノードのパフォーマンスを追跡する場合 (単一ホストの場合と対照的に) はこれが必要になります。使用可能なツールの例については、「Data Center 監視を開始する」を参照してください。
次のインフラストラクチャ メトリックは、あらゆる監視戦略の基礎となります。デプロイメントの各サーバーでこれらを定期的に追跡してください。
アプリケーション サーバー
- 平均 CPU 負荷
- 1 分あたり
- 5 分あたり
- RAM 使用率
- ディスク使用率 (すべてのマウント)
- 1 秒あたりの Apache リクエスト (5 分平均)
データベース サーバー
追跡が必要となる最も重要なデータベース メトリックは、オープンな接続の数 (5 分平均) です。数が大きい場合 (50 など) は、ボトルネックがあり、調査が必要なことを示します。
また、定期的な間隔 (4 時間毎など) で次のデータベース メトリックの合計数を追跡する必要があります。
- 追加
- 更新
- ロック
- 変更を確認できる「コミット」
- 削除
- バッファー ヒット
お使いのデータベース サーバーが専用サーバー上でホストされている (推奨) と想定し、以下も同様に追跡します。
- 平均 CPU 負荷
- 1 分あたり
- 5 分あたり
- RAM 使用率
- ディスク使用率
Java 仮想マシン
アトラシアンのアプリは Java ベースであるため、Java 仮想マシン内に組み込まれた複数の監視ポイントを使用して、インスタンスの健全性に関する詳細情報を得ることができます。特に次のメトリックに注目してください。
- 利用可能なプロセッサーの数
- ヒープ スペース
- ガベージ コレクターのアクティビティ: 関連情報については、「ガベージ コレクション (GC) チューニング ガイド」（Jira）を参照してください。
また、JMX (Java Monitoring eXtensions) を使用してアプリケーションをリアルタイムで監視することもできます。JMX は MBean (Managed Bean) と呼ばれるオブジェクトを使用してアプリケーションのデータとリソースを公開します。次の記事は、特定の製品での JMX の使用に関する詳細を提供します。
- JMX インターフェイスを使用したライブ モニタリング (Jira)
- JMX インターフェイスを使用したライブ モニタリング (Confluence)
パフォーマンスの監視に JMX カウンターを有効化する (Bitbucket)
傾向とアラート
組織の使用とインフラストラクチャの負荷に関する十分なデータが集まったら、以下の特定に役立つパターンを探します。
- ピーク時/ピーク時以外の使用量
- 成長傾向
可能なタイミングで、さらに調査が必要なメトリックにアラートを設定します。次のようなケースがあります。
- オープン データベース接続数が 5 分間で 50 を超える
- JVM ヒープ スペース (Java で使用される RAM の量) が利用可能な容量の 80 % を超える
管理者とステークホルダーが簡単にアクセスできるアラート システムを使用します。また、アラート システムには監視ツールとの互換性も必要です。アプリケーションを Stride ルームやダイレクト メッセージと連携する方法の詳細については、アプリの追加 (Stride) を参照してください。
Atlassian が提供するサービス
この記事では、パフォーマンス監視計画を作成するお客様向けに、アトラシアン Advisory Service が提供する一般的なアドバイスについて説明します。Advisory Service は、お客様がインスタンスの健全性を追跡するための正しいツールと方法を選択できるよう、戦略的なガイダンスを提供します。