CentOS7でAlertaを使用してZabbixアラートを監視する方法

序章

Alerta は、複数の監視システムからのアラートを統合および重複排除し、単一の画面で視覚化するために使用されるWebアプリケーションです。 Alertaは、Nagios、Zabbix、Sensu、InfluxData Kapacitor、その他多くの有名な監視ツールと統合できます。

このチュートリアルでは、Alertaをセットアップし、Zabbixモニタリングシステムからの通知を表示するように設定します。

前提条件

このチュートリアルに従うには、次のものが必要です。

CentOS7初期サーバーセットアップガイドに従ってセットアップされた2台のCentOS7サーバー（sudo非rootユーザーとファイアウォールを含む）。
Zabbixを実行する最初のCentOSサーバーに、次のコンポーネントをインストールします。チュートリアル「Linux、Apache、MySQL、PHP（LAMP）スタックをCentOS 7にインストールする方法」に従って、Apache、MySQL、およびPHPを実行します。チュートリアル「CentOS7でリモートサーバーを安全に監視するためにZabbixをインストールおよび設定する方法」とその設定の前提条件に従ってインストールされたZabbixサーバー。
このチュートリアルでAlertaをインストールする2番目のCentOSサーバーに、次のコンポーネントをインストールします。チュートリアル「CentOS7にNginxをインストールする方法」に従ってインストールされたNginx。チュートリアル「CentOS7にMongoDBをインストールする方法」に従ってインストールされたMongoDB。
手順6で説明したようにAlertaWebインターフェイスを保護する場合は、GitHub組織の一部であるGitHubアカウントが必要です。このチュートリアルに従って、GitHub組織を作成します。

ステップ1—AlertaのAPIサーバーをインストールする

Alertaは、サーバーとWebインターフェイスで構成されています。 Alertaサーバーは、アラートの保存と処理、およびAPIを介したJSONの提供を担当します。 Alerta Webインターフェースを使用すると、ブラウザーでアラートのリストを表示できるため、JSONを自分で解釈する必要はありません。 MongoDBとNginxをインストールしたサーバーに両方のコンポーネントをインストールします。このチュートリアルでは、このマシンをAlertaサーバーと呼びます。 root以外のユーザーとしてこのマシンにログインします。

ssh sammy@your_alerta_server_ip

Alertaコンポーネントをインストールする前に、pip、Pythonパッケージマネージャー、およびPython開発ファイルをインストールする必要があります。また、GitHubからAlertaのソースコードを取得できるように、Gitをインストールする必要があります。

次のコマンドを実行して、これらのソフトウェアパッケージをインストールします。

sudo yum install python-pip python-devel gcc git

これらのパッケージがインストールされると、Alertaをインストールする準備が整います。

まず、pipを使用してAlertaのサーバーをインストールします。

sudo pip install alerta-server

Alertaサーバーを開発モードで実行して、インストールを確認します。

sudo alertad

次のように表示されます。

Output     * Running on http://0.0.0.0:8080/ (Press CTRL+C to quit)

注： FirewallDを使用している場合は、8080ポートへの接続を許可するように設定してください。

sudo firewall-cmd --zone=public --permanent --add-port=8080/tcp
sudo firewall-cmd --reload

Firewalldの詳細については、 CentOS7でFirewallDを使用してファイアウォールを設定する方法をご覧ください。

これで、ブラウザでhttp://your_alerta_server_ip:8080を開いて、いくつかの使用例を示すAlertaAPIWebページを見ることができます。

サーバーが実行されていることを確認したら、CTRL+Cを押してサーバーを停止します。間もなくサービスとして構成します。

Alerta APIサーバーがインストールされているので、Webコンソールをインストールしましょう。

ステップ2— AlertaWebUIのインストール

Alertaには、ブラウザにメッセージを表示するダッシュボードがあります。アラートメッセージをテーブルに表示するので、簡単に読んだり並べ替えたりできます。ニーズに合わせてビューを構成できます。メッセージをフィルタリングしたり、任意のフィールドで並べ替えたりできます。さらに、各メッセージの詳細情報を表示できます。これは、AlertaAPIサーバーをインストールしたのと同じサーバーにインストールします。

まず、Githubからソースコードを取得します。

git clone https://github.com/alerta/angular-alerta-webui.git

次に、アプリケーションファイルをWebサーバーディレクトリにコピーします。

sudo mkdir -p /var/www/html/
sudo cp -r angular-alerta-webui/app/* /var/www/html/

デフォルトでは、AlertaのWebインターフェースは、ポート8080で実行されている開発サーバーAPIと通信するように構成されています。サーバーの/apiエンドポイントでAlertaServerのAPIを利用できるようにすることで、これを本番環境で使用できるように設定し、同じドメインからWebコンソールの静的コンテンツを提供します。これによりの問題を回避できます。 CORS 、またはHTTPS混合コンテンツエラー。

config.js構成ファイルを開きます。

sudo vi /var/www/html/config.js

そして、endpointを/apiに設定します。

/var/www/html/config.js

    'use strict';
    
    angular.module('config', [])
      .constant('config', {
        'endpoint'    : "/api",
        'provider'    : "basic", // google, github, gitlab, keycloak or basic
    ...

他のオプションはデフォルト値のままにします。これらの一部は、このチュートリアルの後半でOAuth認証を構成するときに変更します。

これで、必要なすべてのAlertaコンポーネントがインストールされました。一緒に動作するように設定する必要があります。

ステップ3—Nginxの背後にあるuWSGIを使用してAlertaを実行します。

alertad開発サーバーをいくつかの簡単なテストに使用できますが、本番環境での使用には適していないため、修正しましょう。 AlertaはPythonで記述されているため、WSGIサーバーを使用して実行する必要があります。このチュートリアルでは、http://your_alerta_server_ip/apiでNginxの背後にプロキシされたuWSGIアプリケーションとしてAlertaを実行します。

まず、Pythonパッケージマネージャーを使用してuWSGIアプリケーションサーバーをインストールします。

sudo pip install uwsgi

次に、wsgi.pyファイルを作成します。このファイルは、アプリケーションサーバーがアプリケーションとの通信に使用します。エディターでファイルを開きます。

sudo vi /var/www/wsgi.py

次の行をファイルに追加します。これは、uWSGIにAlertaアプリケーションを呼び出す方法を指示します。

/var/www/wsgi.py

from alerta.app import app

次に、uWSGIサーバー自体を構成する必要があります。 uWSGIがソケットファイルを保存できるディレクトリを作成し、Nginxプロセスがそれにアクセスできることを確認します。

sudo mkdir /var/run/alerta
sudo chown -R nginx.nginx /var/run/alerta/

次に、構成ファイル/etc/uwsgi.iniを作成し、エディターで開きます。

sudo vi /etc/uwsgi.ini

このファイルは、Nginxと対話するためのソケットオプションとともに、アプリケーションの場所を指定します。

次の行をファイルに追加します。

/etc/uwsgi.ini

[uwsgi]
chdir = /var/www
mount = /api=wsgi.py
callable = app
manage-script-name = true

master = true
processes = 5
logger = syslog:alertad

socket = /var/run/alerta/uwsgi.sock
chmod-socket = 664
uid = nginx
gid = nginx
vacuum = true

die-on-term = true

uWSGIオプションの完全なリファレンスリストは、ドキュメントで確認できます。

次に、systemctlコマンドを使用して制御できるように、このアプリケーション用のSystemdユニットを作成します。

sudo vi /etc/systemd/system/alerta-app.service

このユニットファイルには、ユニットを記述し、その動作を定義するいくつかの構成ディレクティブが必要です。次の行をファイルに追加します。

/etc/systemd/system/alerta-app.service

[Unit]
Description=uWSGI service for Alerta
After=syslog.target

[Service]
ExecStart=/usr/bin/uwsgi --ini /etc/uwsgi.ini
RuntimeDirectory=uwsgi
Restart=always
KillSignal=SIGQUIT
Type=notify
StandardError=syslog
NotifyAccess=all

[Install]
WantedBy=multi-user.target

これらの設定とSystemdユニットの操作方法の詳細については、このSystemdチュートリアルを参照してください。

これで、uWSGIサービスを実行できます。

sudo systemctl start alerta-app

次のコマンドを実行してステータスを確認できます。

systemctl status alerta-app

次の出力が表示されます。

Output    ● alerta-app.service - uWSGI service for Alerta
       Loaded: loaded (/etc/systemd/system/alerta-app.service; disabled; vendor preset: disabled)
       Active: active (running) since Fri 2017-04-07 12:15:21 EEST; 2min 25s ago
     Main PID: 15935 (uwsgi)
       Status: "uWSGI is ready"
       CGroup: /system.slice/alerta-app.service
               ├─15935 /usr/bin/uwsgi --ini /etc/uwsgi.ini
               ├─15946 /usr/bin/uwsgi --ini /etc/uwsgi.ini
               ├─15947 /usr/bin/uwsgi --ini /etc/uwsgi.ini
               ├─15948 /usr/bin/uwsgi --ini /etc/uwsgi.ini
               ├─15949 /usr/bin/uwsgi --ini /etc/uwsgi.ini
               └─15950 /usr/bin/uwsgi --ini /etc/uwsgi.ini

ご覧のとおり、サービスはデフォルトで無効になっています。つまり、サービスは自動的に開始されません。有効にする：

sudo systemctl enable alerta-app

最後に、your_alerta_server_ip/apiに対するすべてのリクエストを実行中のuWSGIサーバーにリダイレクトし、NginxでWebフロントエンドにサービスを提供するようにNginxを構成する必要があります。

デフォルトのNginx構成ファイルを変更するのではなく、Alerta構成を独自のファイルに配置します。

sudo vi /etc/nginx/conf.d/alerta.conf

以下の内容をファイルに追加します。 server_nameの値をAlertaサーバーのIPアドレスに置き換えてください。

/etc/nginx/conf.d/alerta.conf

server {
    listen  80;
    server_name  your_alerta_server_ip;

    location /api { try_files $uri @api; }
    location @api {
    include uwsgi_params;
        uwsgi_pass unix:/var/run/alerta/uwsgi.sock;
        proxy_set_header Host $host:$server_port;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    location / {
        root /var/www/html;
    }

    error_page  500 502 503 504  /50x.html;
    location = /50x.html {
        root  /usr/share/nginx/html;
    }
}

Nginxサーバーブロックの詳細については、このチュートリアルを参照してください。

ファイルを保存して、エディターを終了します。

次に、Nginx構成をテストして、タイプミスや構成ミスがないことを確認します。

sudo nginx -t

構成にエラーがない場合は、次の出力が表示されます。

Output    nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
    nginx: configuration file /etc/nginx/nginx.conf test is successful

何か別のものが表示された場合は、エラーに対処して再試行してください。

これで、Nginxをリロードして新しい設定を適用できます。

sudo nginx -s reload

ブラウザでhttp://your_alerta_server_ipリンクを開き、Alertaダッシュボードを表示します。

公的にアクセス可能なサーバーにAlertaをインストールする場合は、認証を要求するようにサーバーを構成する必要があります。それを行うためのいくつかの方法を見てみましょう。

ステップ4—基本認証によるAlertaの保護

デフォルトでは、Alertaサーバーのアドレスを知っている人なら誰でもメッセージを表示できます。テスト環境では許容できますが、本番環境では許容できません。認証を実施するには、alertad.conf構成ファイルを開きます。

sudo vi /etc/alertad.conf

次のコードをファイルに追加します。

/etc/alertad.conf

AUTH_REQUIRED = True
SECRET_KEY = 'secret_key'

SECRET_KEYを任意のランダムな文字列に設定します。ファイルを保存し、エディターを終了して、uWSGIサービスを再起動します。

sudo systemctl restart alerta-app

Alerta Web UI Webページをリロードし、メニューでLoginリンクを選択します。「続行するにはログインしてください」というメッセージが表示されます。 アカウントの作成リンクをクリックして、新しいアカウントを作成します。プロセスを完了すると、Alertaダッシュボードにアクセスできるようになります。

認証を有効にしたら、AlertaAPIにアクセスするためのAPIキーが必要になります。構成メニューを選択し、APIキーを選択します。

APIへのアクセスが必要なアプリケーションの名前を入力します。このチュートリアルでは、zabixと入力します。次に、ドロップダウンから読み取り/書き込みを選択し、新しいAPIキーの作成ボタンをクリックします。新しいキーが作成され、その詳細が表示されます。このキーをコピーします。後で必要になります。

または、OAuth認証を設定し、GitHubまたはGoogleのクレデンシャルを使用してAlertaユーザーインターフェイスにログインすることもできます。基本認証で十分な場合は、次の手順をスキップできます。

ステップ5— OAuthでAlertaを保護する（オプション）

AlertaのWebUIは、Google、GitHub、Gitlab、およびKeycloakのOAuth認証をサポートしています。 GitHub アカウントを介してログインを構成するため、続行するにはアカウントが必要です。

まず、GitHubに新しいアプリケーションを登録します。 GitHubアカウントにログインし、新しいアプリケーションページに移動します。

フォームに次の詳細を記入します。

アプリケーション名にAlertaまたは適切な説明的な名前を入力します。
ホームページのURLは、http://your_alerta_server_ip/を使用してください。
認証コールバックURLにhttp://your_alerta_server_ip/を入力します。
アプリケーションの登録をクリックして設定を保存します。
次の画面に表示されるクライアントIDとクライアントシークレットの値をコピーします。

次に、Alerta構成を編集して、OAuth認証を有効にします。構成ファイルを開きます。

sudo vi /etc/alertad.conf

ファイルの最後に次の設定を追加します。

/etc/alertad.conf

OAUTH2_CLIENT_ID = 'your_github_client_id'
OAUTH2_CLIENT_SECRET = 'your_github_client_secret'
ALLOWED_GITHUB_ORGS = ['your_github_organization']

これらの値には、それぞれGitHubクライアントID、GitHubクライアントシークレット、GitHub組織を使用します。

警告：コマンドからGitHub編成オプションを省略すると、すべてのGitHubユーザーがAlertaダッシュボードにログインできるようになります。 GitHub組織を作成し、適切なユーザーを組織に追加してアクセスを制限します。

ファイルを保存し、エディターを終了して、uWSGIサービスを再起動します。

sudo systemctl restart alerta-app

次に、Webインターフェイスの認証プロバイダーを変更します。構成ファイルを編集します。

sudo vi /var/www/html/config.js

次のセクションを見つけて、プロバイダーをbasicからgithubに変更し、GitHubクライアントIDを入力します。

/var/www/html/config.js

    ...
        'provider'    : "github",
        'client_id'   : "INSERT-CLIENT-ID-HERE",
    ...

http://your_alerta_server_ipを開いて、AlertaWebUIにアクセスします。今回は「ログインして続行してください」というメッセージが表示されます。 ログインボタンをクリックしてログインすると、アプリケーションにGitHubアカウントへのアクセスを許可するように求められます。アクセスを許可すると、ログインします。

これで、簡単なテストを実行して、Alertaが正しくセットアップされ機能しているかどうかを確認できます。

ステップ6—テストメッセージの送信

Alertaの統合コマンドラインツールを使用して、テストアラートを送信します。まず、コマンドラインクライアントをインストールします。

sudo pip install alerta

次に、使用するAPIキーとともに、前に構成したAlertaAPIエンドポイントを定義する構成ファイルを作成します。エディターで新しいファイルを作成します。

vi ~/.alerta.conf

以下をファイルに貼り付けます。

〜/ .alerta.conf

[DEFAULT]
endpoint = http://your_alerta_server_ip/api
key=your_alerta_api_key

手順4で設定したAPIキーをkeyオプションに使用します。

これで、テストアラートを送信できます。

alerta send --resource webserver01 --event down --environment Production --service Website01 --severity major --text "Web server 01 is down." --value ERROR

次のような出力が表示されます。

Output1015fca2-eff6-441d-8c66-6abf9368b830 (indeterminate -> major)

ブラウザでhttp://your_alerta_server_ipにアクセスすると、ダッシュボードに次の図のようなメッセージが表示されます。

メッセージをクリックすると詳細が表示されます。

Alertaサーバーが起動し、新しいメッセージを待機しています。 Alertaにアラートを送信するようにZabbixモニタリングシステムを設定しましょう。

ステップ7—Zabbix-Alertaゲートウェイのインストール

このステップでは、Zabbixモニタリングシステムを変更して、Alertaに通知メッセージを送信します。

root以外のユーザーとしてZabbixサーバーマシンにログインします。

ssh sammy@your_zabbix_server_ip

デフォルトでは、Zabbixは電子メール、SMS、またはJabberメッセージで通知を送信できますが、スクリプトを使用して新しい通知ハンドラーを追加できます。 Alerta開発者は、既製の通知スクリプトを提供します。インストールするには、 zabbix-alerta リポジトリのクローンを作成し、インストールスクリプトを使用してインストールします。

git clone https://github.com/alerta/zabbix-alerta.git
cd zabbix-alerta
sudo python setup.py install

次に、Zabbixがアラートスクリプトを保存するディレクトリにzabbix-alertaスクリプトのシンボリックリンクを作成します。そのパスは、/etc/zabbix/zabbix_server.conf構成ファイルにあります。

sudo grep -e '^AlertScriptsPath' /etc/zabbix/zabbix_server.conf

次のような出力が表示されます。

OutputAlertScriptsPath=/usr/lib/zabbix/alertscripts

デフォルトでは、Zabbixは/usr/lib/zabbix/alertscriptsでスクリプトを検索します。次のコマンドを実行して、シンボリックリンクを作成します。

sudo ln -s `which zabbix-alerta` /usr/lib/zabbix/alertscripts

Alerta統合を構成しましょう。 http://your_zabbix_server_ip/zabbix/でZabbixWebインターフェイスにログインします。

メインメニューで、管理をクリックし、メディアタイプを選択して、右上隅にあるメディアタイプの作成ボタンをクリックします。

フォームに次の詳細を記入します。

Name に、Alertaと入力します。
Type の場合、ドロップダウンからScriptを選択します。
スクリプト名には、zabbix-alertaと入力します。
スクリプトパラメータには、次の値を入力します。

有効チェックボックスがオンになっていることを確認します。

追加ボタンをクリックして、新しいメディアタイプを作成します。

次に、ユーザーアカウントに新しいメディアを追加します。メインメニューで管理を選択し、ユーザーを選択します。ユーザー名をクリックし、メディアタブを選択します。次の詳細を入力します

Type には、Alertaを選択します。
[送信先]にhttp://your_alerta_server_ip/api;your_api_keyと入力します。

手順4で作成したAPIキーを使用します。

更新ボタンをクリックして設定を保存します。

次に、メッセージを送信するアクションを構成します。メインメニューで構成を選択し、アクションを選択します。 アクションの作成ボタンをクリックします。

アクションタブで、名前フィールドの値をForward to Alertaに設定します。

[操作]タブで、次のオプションを設定します。

デフォルトの件名を{TRIGGER.STATUS}: {TRIGGER.NAME}に設定します

デフォルトメッセージには、次のテキストを入力します。

Default messageresource={HOST.NAME1}
event={ITEM.KEY1}
environment=Production
severity={TRIGGER.SEVERITY}
status={TRIGGER.STATUS}
ack={EVENT.ACK.STATUS}
service={TRIGGER.HOSTGROUP.NAME}
group=Zabbix
value={ITEM.VALUE1}
text={TRIGGER.STATUS}: {TRIGGER.NAME}
tags={EVENT.TAGS}
attributes.ip={HOST.IP1}
attributes.thresholdInfo={TRIGGER.TEMPLATE.NAME}: {TRIGGER.EXPRESSION}
type=zabbixAlert
dateTime={EVENT.DATE}T{EVENT.TIME}Z

Zabbixは、問題を検出すると、指定された形式でメッセージを送信します。中括弧内の式が対応する値に置き換えられます。 Alertaがアラートを受信して正しく表示するには、これらすべてのフィールドが必要です。

次に、操作フィールドの新規をクリックして、新しい操作を作成します。次の値をフォームに入力します。

ユーザーに送信に、Your user nameと入力します。
' にのみ送信する場合は、ドロップダウンボックスから'Alertaを選択します。

次に、リカバリ操作タブを選択し、デフォルトメッセージを次のように変更します。

Recovery operationsresource={HOST.NAME1}
event={ITEM.KEY1}
environment=Production
severity={TRIGGER.SEVERITY}
status={TRIGGER.STATUS}
ack={EVENT.ACK.STATUS}
service={TRIGGER.HOSTGROUP.NAME}
group=Zabbix
value={ITEM.VALUE1}
text={TRIGGER.STATUS}: {ITEM.NAME1}
tags={EVENT.RECOVERY.TAGS}
attributes.ip={HOST.IP1}
attributes.thresholdInfo={TRIGGER.TEMPLATE.NAME}: {TRIGGER.EXPRESSION}
attributes.moreInfo=<a href="http://x.x.x.x/tr_events.php?triggerid={TRIGGER.ID}&eventid={EVENT.RECOVERY.ID}">Zabbix console</a>
type=zabbixAlert
dateTime={EVENT.RECOVERY.DATE}T{EVENT.RECOVERY.TIME}Z

このメッセージは前のメッセージと似ています。このメッセージは、問題が解消されたときに送信されます。

追加ボタンをクリックして設定を完了してください。

ZabbixはAlertaにアラートを送信する準備ができています。生成しましょう。

ステップ8—ZabbixとAlertaの統合を検証するためのテストアラートの生成

すべてが接続されていることを確認するためのテストアラートを生成しましょう。デフォルトでは、Zabbixはサーバーの空きディスク容量を追跡します。 Zabbixのファイルシステム使用状況アラートをトリガーするのに十分な大きさの一時ファイルを作成します。

まだ接続していない場合は、Zabbixサーバーにログインします。

次に、サーバーにある空き容量を確認します。 dfコマンドを使用して、以下を確認できます。

df -h

次のような出力が表示されます。

Output    Filesystem      Size  Used Avail Use% Mounted on
    /dev/vda1        20G  1.5G   18G   9% /

空き容量に関心があります。この場合、空き容量は18GBです。空き容量が異なる場合があります。

fallocateコマンドを使用して、使用可能なディスク容量の80 % o fを超えるファイルを作成します。これは、アラートをトリガーするのに十分なはずです。

fallocate -l 16G /tmp/temp.img

数分以内に、Zabbixは空きディスク容量に関するアラートをトリガーし、設定したアクションを実行して、アラートメッセージをAlertaに送信します。この新しい通知はAlertaダッシュボードに表示されます。

アラートが機能していることがわかったので、作成した一時ファイルを削除して、ディスク領域を再利用できるようにします。

rm -f /tmp/temp.img

1分後、Zabbixはリカバリメッセージを送信します。アラートはメインダッシュボードから消えますが、 Closed を選択すると、すべてのクローズされたイベントを表示できます。

イベント行をクリックすると、詳細が表示されます。

結論

このチュートリアルでは、Alertaをインストールして設定し、Zabbixに通知を送信するように設定しました。その結果、アラートを追跡するための便利なツールが手に入りました。将来的には、他の通知ソースを追加して、さまざまな監視システムからの情報を統合および一元化することができます。