[OpsJAWS: やってみようシリーズ] AWS Service Health Dashboard × Zabbix連携によるステータス情報監視の実現
Partner SA 酒徳です。やってみようシリーズ Zabbix第３弾です。AWS Service Health Dashbord(SHD)の情報をZabbixに連携させる連携機能のご紹介を頂きます。SHDはCloudWatchでは監視できないため、このような形で統合管理するのは大切ですね。
TIS株式会社の佐藤です。TISから提供しているTISエンタープライズOSSサポートサービスの取り組みの一環として行っている、AWSとZabbixの効果的な連携検証の結果を連載にてご紹介しています。第３回はAWS Service Health Dashboardとの連携です。
１．AWS Service Health Dashboard × Zabbix連携の紹介
Service Health Dashboardとは、各リージョン、アベイラビリティゾーンで提供しているサービスの正常性、性能低下、障害情報、障害復旧の情報を確認できるWebサイト(http://status.aws.amazon.com/)です。以下４種類のステータスが予め用意されており、一目でサービスの状態を確認することができます。
|
1. Service is operating normally |
|
|
2. Performance issues |
|
| 3. Service disruption |
|
|
4. Informational message |
|
このWebサイトは、サービス全体の状態を把握するのに便利なサイトですが、何かイベントが発生した時に通知する機能が備わっていません。最新情報を得るためには、常にこのWebサイトをチェックする、もしくは、RSSリーダやその他ツールなどと連携させて最新情報を得るしかありません。
そこで第３回では、Zabbixの監視機能と連携をさせて、イベントが発生した場合にはプッシュ型でいち早く情報を取得し、重要な情報を見落とさないようにする方法をご紹介します。
2．AWS Service Health Dashboard × Zabbix連携の特徴
AWSは非常に多くのサービスがあり、かつサービスが頻繁に追加されますが、Zabbixと連携させてZabbix Senderやローレベルディスカバリ機能（以降、LLD）の仕組みを利用することで、以下のような統合的な自動監視が可能になります。
・Zabbixのアプリケーション（監視項目を分類する機能）を利用して、各リージョン、アベイラビリティゾーンのサービス情報をグルーピングして一元管理することが可能
・ZabbixのLLDを利用して、各リージョン・アベイラビリティゾーンのサービス状態を監視するアイテムを自動登録、自動同期可能
・Zabbix Senderの機能を利用して、効率よく情報取得が可能
３．AWS Service Health Dashboard × Zabbix連携の設定
＜連携用スクリプトの説明＞
ご紹介する連携用スクリプトは、各サービス・リージョンの監視アイテムをLLDにより自動設定し、RSSフィードの中から直近(時間は任意で設定可能)に発生したイベント情報をZabbix Senderの仕組みを利用して収集します。連携用スクリプトを定期的に実行することで、サービス・リージョンの追加があった場合の監視アイテムの自動追加と、定期的なイベント情報の収集を実現することが可能になります。
LLD用JSONフォーマット
--
{
"data": [
{
"{#REGION}": "ap-southeast-1",
"{#SERVICE.NAME}": "apigateway"
},
{
"{#REGION}": "ap-northeast-1",
"{#SERVICE.NAME}": "apigateway"
},
{
"{#REGION}": "",
"{#SERVICE.NAME}": "cloudfront"
},
{
"{#REGION}": "ap-northeast-2",
"{#SERVICE.NAME}": "cloudsearch"
},
--
＜連携用スクリプトとテンプレートの設定手順＞
以下の3ステップで、連携サンプルスクリプトとテンプレートの設定が可能です。
１．連携用スクリプトの配置
２．Zabbix監視テンプレートのインポート
３．Zabbixの監視ホストとテンプレートの割り当て
※この連携手法の動作確認済み環境は以下となります。
・CentOS7.2もしくはAmazon Linux 2016.03
・Python2.7(CentOS: 2.7.8, Amazon Linux 2016.03: 2.7.10)
・Zabbix2.2系および3.0系
・事前準備
この連携用スクリプトを稼働するには、「feedparser」をインストールする必要があります。pipコマンドが使用できる環境の場合は、以下のようにインストールをします。
コマンド実行例：
# pip install feedparser
１．連携用スクリプトの配置
連携用スクリプトを以下のリンク先からダウンロードします。
ダウンロードした連携用スクリプトを、Zabbix Serverの外部チェックスクリプト用ディレクトリに配置します。外部チェックスクリプト用ディレクトリは、zabbix_server.confの「ExternalScripts」で指定されているディレクトリです。
例：
--
ExternalScripts=/usr/lib/zabbix/externalscripts
--
指定ディレクトリに配置後、配置したスクリプト（AWS_Service_Health_Dashboard.py）をZabbix Server起動ユーザ（デフォルトではzabbix）が実行できる権限を付与します。
コマンド実行例：
chown zabbix:zabbix AWS_Service_Health_Dashboard.py
chmod u+x AWS_Service_Health_Dashboard.py
２．Zabbix監視テンプレートのインポート
次に、Zabbixの管理画面から監視設定のテンプレートを登録します。
テンプレートを以下のリンク先からダウンロードします。
Zabbix2.2用テンプレート
Zabbix3.0用テンプレート
Zabbixの管理画面から[設定] → [テンプレート] → [インポート] と辿り、ダウンロードしたテンプレートを「インポートするファイル」に設定し、インポートを実行します。
これにより以下の監視テンプレートが登録されます。
テンプレート名：Template AWS Service Health Dashboard
３．Zabbixの監視ホストとテンプレートの割り当て
最後に、監視ホストを登録して「手順２．Zabbix監視テンプレートのインポート」でインポートしたテンプレートを割り当てます。Zabbixの管理画面の[設定] → [ホスト] → [ホストの登録]から以下のような情報を登録します。今回はAsia Pacific（AP）を例としてご紹介します。なお、全リージョンの監視をしたい場合、ホストはエリア毎（North America, South America, Europe, Asia Pacific）に４つ作成する必要があります。ホスト名をそれぞれ、NA、SA、EUに変更した設定を作成してください。
[設定項目] [設定内容]
ホスト名 AP
表示名 任意(各エリアと紐付けて確認しやすい表示名にすることをお勧めします)
グループ 任意(最低でも1つのグループに登録が必要です)
インタフェース 任意(本連携ではインタフェース情報は利用しませんが、最低でも1つのインタフェース登録が必要です)
テンプレート Template AWS Service Health Dashboard
設定は以上で終了です。
ディスカバリルールの実行処理（外部チェックスクリプトの実行処理）が走った段階で以下のように、アプリケーション、アイテム、トリガーそれぞれが取得できていることを確認してください。
・Zabbix3.0では、テンプレートのアイテムのプロトタイプ設定でアプリケーションプロトタイプにLLDマクロを設定することが可能です。この機能を利用して、アイテムをリージョンごとのアプリケーションにグループ化し、管理しやすいよう設定しています。
以下はアプリケーションプロトタイプを利用したグループ化の実装例です。
なお、Zabbix2.0系ではアプリケーションプロトタイプの設定がないため、自動的なグループ化ができません。そのため、フィルタ機能で確認したいリージョン名やサービス名などでフィルタをかけ、管理を行ってください。
以下はリージョン名：ap-northeast-1でフィルタをかけた例です。
・ご紹介したテンプレートでは、監視アイテム自動取得のためのディスカバリルールの処理は１時間おきに実行するように設定しています。そのため、変更内容の反映には最大1時間かかります。
・RSSフィードをチェックする外部チェックスクリプトアイテムの実行により、実際に監視アイテムが登録されると、以下のように最新情報を取得することができます。
※1各RSSフィードの情報の処理に時間がかり、場合によっては、Zabbixの監視処理のタイムアウト設定の制限値（デフォルト3秒）を超える恐れがあります。その際は、zabbix_server.confのTimeout設定値のチューニングをお願いします。
※2以下例は、情報取得が可能か確認するために、外部チェックスクリプトのインターバル時間を変更して実行した結果です。実際はAWSの各サービスで障害が発生していなければ監視結果が登録されることはありません。
例：東京リージョンのEC2サービスの情報
４．トリガーによる障害検知
実際にAWS上のサービスの障害発生→復旧を起こすことは困難であるため、疑似的にZabbix Senderコマンドを使用して障害を発生させ、トリガーによる検知を試してみます。
今回ご紹介するテンプレートには以下のトリガーが設定済みです。
・Informational messageを検知して深刻度を「情報」として障害イベントを生成するトリガー
・Performance issuesを検知して深刻度を「警告」として障害イベントを生成するトリガー
・Service disruptionを検知して深刻度を「重度の障害」として障害イベントを生成するトリガー
これにより、どのレベルの障害が発生しているのかを一目でわかるようにし、対処が必要なレベルの障害時のみZabbixのアクション実行（メール送信やリモートコマンド実行等）を設定できるようにしています。
１．Informational messageが東京リージョンのEC2サービスで発生し、障害を検知
以下のように監視データの確認画面で東京リージョンのEC2サービスにInformational messageを受信し、トリガーのステータス画面では、障害を検知しているのが確認できます。
２．サービスが復旧し「Service is operating normally」が発生
障害を検知した時と同じく監視データの確認画面を見ると、リカバリメッセージの受信が確認できます。
トリガーのステータス画面では、先ほどの障害が正常状態となりました。
※今回のサンプルトリガーは、同時に複数のレベル（Informational message, Performance issues, Service disrupt）の障害が発生することを想定した設定とはなっていません。実際に利用される際には、どのような検知が必要かの要件に従ってカスタマイズしてください。もしくは、カスタマイズが必要な場合には当社までご用命ください。
http://www.tis.jp/service_solution/zabbix/
５．まとめ
今回の記事では、AWS Service Health DashboardとZabbixを連携させて、各リージョンでAWSが提供しているサービスのステータス情報を収集し、何かイベントが発生すればZabbixで検知する方法についてご紹介しました。Zabbixと連携させることで、一元管理はもちろん、効率的に情報を収集し、運用管理を行うことが可能になります。また、トリガーの設定次第では、より柔軟に監視することも期待できます。是非、Zabbixと連携をさせた監視を試してみてはいかがでしょうか。
６．参考情報
・[スクリプト・テンプレート公開リポジトリ]
https://github.com/tech-sketch/zabbix_aws_template
※ご紹介したスクリプト・テンプレートはすべてオープンソースとして公開しています。自由にご利用・ご活用ください。ご質問やサポートのご用命については以下7.お問い合わせ先よりご連絡をお願いします。
・[AWS運用管理フォーカスセミナー資料:AWSの便利な監視サービスと Zabbix監視の融合による効果]
７．お問い合わせ先
本記事に関するお問い合わせは以下までお願いします。
TIS株式会社 OSS推進室
メール: [email protected]
電話: 03-5337-4588
◆『TISエンタープライズOSSサポートサービス』
TISでは本記事での紹介内容等も含め様々なノウハウを駆使したOSSのサポートサービスを提供しています。企業にて安心してOSSをご利用いただけるようにするため、設計や構築のご支援(技術コンサルティングサービス)や運用・保守時のトラブル対応のご支援(プロダクトサポートサービス)を提供しています。
◆マネージドサービス『ＭＯＴＨＥＲ』
TISは、クラウドサービスの活用が本格化した時代にあわせ、AWSなどのクラウドはもちろん、企業が持つプライベートクラウドやオンプレミスが組み合わされたマルチプラットフォーム環境の統合管理、障害監視、性能分析、運用自動化などのマネージドサービス『ＭＯＴＨＥＲ』を提供しています。
http://www.tis.jp/service_solution/mother/
****
OpsJAWS メインページはこちら。
クラウド運用にご興味ある方は、こちらからOpsJAWSに登録ください。
コメント