はじめに
システム全体を効率よく管理するには、サーバのハードウェアリソースやネットワーク、OS、アプリケーションなどの状態を常に適切に把握できる監視システムが必要とされています。
監視ツールによって果たせる機能は異なりますが、監視することのメリットとして、障害の検知や原因調査を迅速に行えること、適切なマシンリソースの割り当てを検討するための材料を集めること、特定の条件を満たした際の対応を自動化できることなどが挙げられます。
コラボレーションツールとして社内の情報の基盤となるアトラシアン製品においては、システムの停止が会社の業務に与える影響は大きく、いち早く不具合に気づき監視ツールは有償・無償数多く存在しますが、当社では「Zabbix」を利用してアプリケーションの監視を行っています。Zabbixは、ラトビアのZabbix社が開発している、サーバ・ネットワーク・アプリケーション統合監視のためのオープンソース・ソフトウェアです。フリーでありながら高機能で、かつ導入が容易であることが特徴です。また、Linuxの他にWindowsやMac OS X、商用UNIXなど、さまざまなプラットフォームで動作します。
Zabbixの特徴的な機能のひとつとしてZabbix Agentがあります。多くの監視ツールでは、監視対象となるサーバ上でSNMP（Simple Network Management Protocol）デーモンが動作していることや、監視を行うに際してMIB（Management Information Base）を理解する必要がありますが、ZabbixではZabbix Agentがその代替として機能します。また、必要な監視項目はテンプレートとして提供されているため、MIBで監視に必要な値を特定するといった作業を行うことなく、短時間で監視を行うことができます。（もちろん、SNMPによる監視も可能です）
本記事ではZabbixを利用した、アトラシアン製品の運用における監視について紹介します。
必要な環境
今回は、監視サーバにはZabbix Server 2.2、監視対象となるアプリケーションサーバにはZabbix Agent 2.2をインストールします。
アプリケーションサーバには、アトラシアン製品の中でもよく利用されるアプリケーションである「JIRA Software」（課題管理ソフトウェア）と「Confluence」（Wikiソフトウェア）をインストールし、各アプリケーションのアプリケーションコンテナであるApache TomcatのJMX（Java Management Extensions）による監視にも対応します。
監視サーバ、アプリケーションサーバともに、AWS（Amazon Web Services）上での運用を想定しています。ただし、AWS以外でも運用方法に大きな差はありません。
なお、すでに基本的なセットアップは終了しているものとし、各サーバの構築・セットアップの手順については記載しません。
Zabbixサーバ（監視サーバ）
- CentOS 7.2
- Zabbix Server 2.2
アプリケーションサーバ（監視対象）
- CentOS 6.9
- JIRA Software 7.4.2
- Confluence 6.3.1
- Zabbix Agent 2.2
アトラシアン製品の監視のポイント
アトラシアン製品の監視のポイントは次の通りです。
基本的なサーバリソース監視
- CPU
- メモリ
- ストレージ
- ネットワーク
など。
JMX（Java Management Extensions）監視
- ヒープ・メモリ
- コードキャッシュ
など。
アトラシアン製品は、JavaおよびApache Tomcat上で動作するので、特に、ヒープ・メモリやコードキャッシュ、スレッド数など一般的なJavaの監視項目を抑えることが重要です。
また、ファイルのアップロードが増えるような利用が想定される場合には、CPUやメモリの負荷だけでなくディスク使用率への注意も必要になります。
監視設定
ここまで説明したポイントを踏まえて設定を実施します。基本的にはテンプレートをもとに設定していきます。
テンプレートとは、その名の通り設定の雛形となるもので、関連する設定（主にアイテム、グラフ、トリガー）を1つにグループ化したものです。テンプレートを利用することで、目的に応じた設定をホストに対して一括で割り当てることができます。
今回は、次のテンプレートを監視対象ホストに適用しました。アトラシアン製品の監視におけるポイントとなるものについて紹介しますが、細かなZabbixの設定に関しては説明を省きます。
なお、ここでは「テンプレート名（標準／当社にて作成）」の形で表記し、説明していきます。標準のテンプレートは「Zabbix_Templates/Official_Templates/2.2」からダウンロードして利用します。
OS
Template OS Linux（標準）
Linuxサーバ監視のためのテンプレートです。CPUやメモリといったOSの基本的なデータを取得し監視することができます。
Template App Zabbix Agent（標準）
Zabbix Agent監視のためのテンプレートです。Zabbix Agentの状態を監視することができます。なお、以下の画像では、Template OS Linux（標準）にTemplate App Zabbix Agent（標準）をリンクしています。
DB
Template App DB xxx（当社にて作成）
PostgreSQL monitoring template for Zabbix (pg_monz)をDBMS（PostgreSQL）に合わせてカスタマイズのうえ、DBMSに応じたテンプレートを用意します。主な監視対象は、コネクション数です。
なお、テンプレート名の「xxx」は、pg_monz＋PostgreSQLのバージョンとしています。
Java（Xは各アプリケーションに内包されているJavaのバージョン）
Template JMX Generic Java X（当社にて作成）
Javaの状態を監視（JMX監視）するためのものです。標準で用意されている「Template JMX Generic」をコピーし、利用するJavaのバージョンと運用環境に合わせてカスタマイズします。
なお、テンプレート名の「X」は、Javaのバージョンとしています。
Tomcat（Xは各アプリケーションに内包されているTomcatのバージョン）
Template JMX Tomcat X（当社にて作成）
Tomcatの状態を監視するためのものです。標準で用意されている「Template JMX Tomcat」をコピーし、利用するTomcatのバージョンと運用環境に合わせてカスタマイズします。
ここでは［マクロ］に該当のアプリケーションのポートを指定、［トリガー］の条件式のTomcatのバージョンを監視対象のものに変更し、Thread数が最大Thread数を超過した際にアラートを上げるトリガーを設定しました。アプリケーションやアプリケーションのバージョンによっては、［アイテム欄］の各項目の［キー］の内容の変更が必要になる場合があります。
監視項目を確認しよう
テンプレートを監視対象に適用し、必要に応じたアイテム・トリガーの設定をした後は、監視データを確認します。
ここからは、実際に当社でアプリケーションの運用を行う際に確認している監視項目とグラフについて解説します。
OS
CPUの状態
負荷のかかる機能の使用や、アプリケーション・アドオンの不具合等により、CPU使用率が高くなる場合があります。
また、CPU使用率に加え、ロードアベレージでCPUが処理しきれていない処理が想定以上に発生していないかを確認します。
CPUの状態を確認しながら割り当てているCPUのスペックが適切かを見極めます。
CPU使用率
CPU使用率が高くなり始めた時刻のログを確認することで、原因を特定できる場合があります。
また、負荷の内容（I/O待ちや仮想環境による制限）によりグラフの山を構成する色が異なるため、原因の特定に役立つ場合があります。
以下のグラフでは青い部分が多く、12:25頃からアプリケーションがCPUを多く使う処理が実行されている様子が分かります。
ロードアベレージ
CPU使用率とロードの相関関係が分かります。
下のグラフは、上のCPU使用率のグラフと同時刻のものです。CPU使用率は高いものの、ロードアベレージはそれほど高くないため、処理待ちとなっている状況ではないようです。
メモリの状態
メモリやスワップメモリの割り当てが不足していないことを確認します。
例えば、「Bitbucket」（アトラシアン製のGitリモートリポジトリサーバ）の場合、巨大なリポジトリに対するgit cloneなどの実行により、OSのメモリが大量に消費されることがあります。
以下のグラフでは、11:55頃から利用可能なメモリが減少し、スワップメモリを使用し始めた様子が見て取れます。
ネットワークトラフィック
転送量が大幅に増加するようになった際は、トラフィック増がいつ発生しているか、不正な通信が発生していないことを確認します。
以下のグラフでは青い部分（Out going）が多く、ダウンロードによる転送量が多い様子が見て取れます。
ディスク使用率
ディスクの割り当てが不足していないことを確認します。ディスク使用率を確認することで、ディスク増設の計画を立てやすくなります。
例えば、以下の場合3カ月で20GB増量しているため、3カ月後にはディスク増設が必要になると予測できます。
DB
DBのコネクション数
以下のグラフでは一時的に接続数の上限値（300）に達しているため、上限値の見直しを検討することとなります。
Java
ヒープ・メモリ
以下のグラフでは、ヒープメモリの使用率が上昇し続けている様子が見て取れます。メモリを大量に使用する処理の実行や、メモリリークの可能性が疑われます。
Code Cache
Code Cacheの量の監視です。以下のグラフでは3/3 12:00頃にCode Cacheが上限値に達しています。
Code Cacheが上限値に達すると、コンパイル済みのコードが再利用されず、パフォーマンスの大幅な低下を招きます。
HTTP Conector
JavaへのHTTPリクエスト数を確認することができます。
以下のグラフでは一時的に接続数の上限値（400）に達しているため、上限値の見直しを検討することとなります。
Web監視
設定したURLに対してHTTPでアクセスできない場合にアラートが発生します。これにより、何らかの異常によってアプリケーションへアクセスできないことに気づくことができます。
なお、Web監視はトリガーで設定して利用します。
以下のグラフでは、9/15 22:18～22:38の間、リクエストに対するレスポンスが返ってきていません。そのため、何らかの異常によってアプリケーションへアクセスできない状態となっていることが分かります。
おわりに
以上をご覧いただいてお分かりの通り、適用されている全ての項目を監視しているわけではなく、運用上必要な項目に限定して監視しています。Zabbixのテンプレートには多くの項目がありますが、このようにポイントを抑えて必要な項目に限定して監視を行うことで、運用負荷の軽減につながります。
Zabbixなどの最近の統合監視ツールは、監視項目の検討やしきい値のチューニングとそれに伴う設定、ツールの使い方・値やグラフの読み方等の理解に一手間かかります。しかし、一度導入して運用を開始してしまえばその後の障害時や運用に役立つことは間違いありません。また、Zabbixを導入することで値が可視化されるため、例えばトラブルが発生した際、アプリケーションのバグなのか、大量のアップロードが原因なのか、単純にリソースの割り当てが不十分なのかなど、その原因が値やグラフを読むことで推測しやすくなり、トラブル発生時の原因調査に大いに役立ちます。
なお、ここではZabbixをご紹介しましたが、Zabbix以外でも同様の監視を行うことは可能です。例えば、監視サーバの運用を外部に任せたい（自前で監視環境を持ちたくない）、監視サーバを新たに設置することができないといった場合は、SaaS型の監視サービスを利用するのも良いでしょう。SaaS型のサービスの例として、New RelicやDataDog、Mackerelといったサービスが挙げられます。
今回は、アトラシアン製品の監視ということで、当社の運用で実際に活用しているポイント・監視項目を紹介させていただきました。
快適な監視生活を目指しましょう。
参考
- エージェントレス監視（Zabbixオフィシャル日本語サイト）
- Zabbixオフィシャル日本語サイト
- 監視テンプレート|日本Zabbixユーザー会
- Live Monitoring Using the JMX Interface（Confluence Support）
- PostgreSQL monitoring template for Zabbix (pg_monz)
リックソフトはアトラシアン製品アジアパシフィック売り上げ第1位（2015～2016年）
リックソフト株式会社は、日本でトップレベルのAtlassian Platinum Solution Partnerです。アトラシアン製品の専任技術者が30人以上在籍しており、手厚いサポートを提供しています。また、豊富なライセンス購入特典もご用意しております。
