CentOS7でAlertaを使用してZabbixアラートを監視する方法
序章
Alerta は、複数の監視システムからのアラートを統合および重複排除し、単一の画面で視覚化するために使用されるWebアプリケーションです。 Alertaは、Nagios、Zabbix、Sensu、InfluxData Kapacitor、その他多くの有名な監視ツールと統合できます。
このチュートリアルでは、Alertaをセットアップし、Zabbixモニタリングシステムからの通知を表示するように設定します。
前提条件
このチュートリアルに従うには、次のものが必要です。
- CentOS7初期サーバーセットアップガイドに従ってセットアップされた2台のCentOS7サーバー(sudo非rootユーザーとファイアウォールを含む)。
- Zabbixを実行する最初のCentOSサーバーに、次のコンポーネントをインストールします。
- Apache、MySQL、およびPHP、チュートリアル Linux、Apache、MySQL、PHP(LAMP)スタックをCentOS7にインストールする方法に従ってください。
- チュートリアルCentOS7でリモートサーバーを安全に監視するためにZabbixをインストールおよび設定する方法とその設定の前提条件に従ってインストールされたZabbixサーバー。
- このチュートリアルでAlertaをインストールする2番目のCentOSサーバーに、次のコンポーネントをインストールします。
- 手順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をインストールする準備が整います。
まず、Alertaのサーバーを使用してインストールします pip
:
- sudo pip install alerta-server
Alertaサーバーを開発モードで実行して、インストールを確認します。
- sudo alertad
次のように表示されます。
Output * Running on http://0.0.0.0:8080/ (Press CTRL+C to quit)
注: FirewallDを使用している場合は、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インターフェースは、ポートで実行されている開発サーバーAPIと通信するように構成されています。 8080
. Alerta ServerのAPIをで利用できるようにすることで、これを本番環境で使用できるように設定します。 /api
サーバー上のエンドポイントであり、同じドメインからWebコンソールの静的コンテンツを提供します。これにより、CORSの問題やHTTPS混合コンテンツエラーを回避できます。
を開きます config.js
構成ファイル:
- sudo vi /var/www/html/config.js
そして、 endpoint
に /api
:
'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サーバーを使用して実行する必要があります。 このチュートリアルでは、Nginxの背後にプロキシされたuWSGIアプリケーションとしてAlertaを実行します。 http://your_alerta_server_ip/api
.
まず、Pythonパッケージマネージャーを使用してuWSGIアプリケーションサーバーをインストールします。
- sudo pip install uwsgi
次に、を作成します wsgi.py
ファイル。アプリケーションサーバーがアプリケーションとの通信に使用します。 エディターでファイルを開きます。
- sudo vi /var/www/wsgi.py
次の行をファイルに追加します。これは、uWSGIにAlertaアプリケーションを呼び出す方法を指示します。
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と対話するためのソケットオプションとともに、アプリケーションの場所を指定します。
次の行をファイルに追加します。
[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オプションの完全なリファレンスリストは、ドキュメントで確認できます。
次に、このアプリケーションのSystemdユニットを作成して、 systemctl
指図。
- sudo vi /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
最後に、すべてのリクエストをリダイレクトするようにNginxを構成する必要があります your_alerta_server_ip/api
実行中のuWSGIサーバーに接続し、Nginxを使用してWebフロントエンドにサービスを提供します。
デフォルトのNginx構成ファイルを変更するのではなく、Alerta構成を独自のファイルに配置します。
- sudo vi /etc/nginx/conf.d/alerta.conf
以下の内容をファイルに追加します。 の値を必ず置き換えてください server_name
AlertaサーバーのIPアドレスを使用します。
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
次のコードをファイルに追加します。
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
ファイルの最後に次の設定を追加します。
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を入力します。
...
'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
以下をファイルに貼り付けます。
[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-alerta
Zabbixがアラートスクリプトを保存するディレクトリのスクリプト。 あなたはその道を見つけることができます /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統合を構成しましょう。 次の場所でZabbixWebインターフェイスにログインします。 http://your_zabbix_server_ip/zabbix/
.
メインメニューで、管理をクリックし、メディアタイプを選択して、右上隅にあるメディアタイプの作成ボタンをクリックします。
フォームに次の詳細を記入します。
- 名前に次のように入力します
Alerta
. - Type の場合、ドロップダウンからScriptを選択します。
- スクリプト名には、次のように入力します
zabbix-alerta
. - スクリプトパラメータには、次の値を入力します。
{ALERT.SENDTO}
{ALERT.SUBJECT}
{ALERT.MESSAGE}
- 有効チェックボックスがオンになっていることを確認します。
追加ボタンをクリックして、新しいメディアタイプを作成します。
次に、ユーザーアカウントに新しいメディアを追加します。 メインメニューで管理を選択し、ユーザーを選択します。 ユーザー名をクリックし、メディアタブを選択します。 次の詳細を入力します
- 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% ofを超えるファイルを作成するコマンド。これは、アラートをトリガーするのに十分なはずです。
- fallocate -l 16G /tmp/temp.img
数分以内に、Zabbixは空きディスク容量に関するアラートをトリガーし、設定したアクションを実行して、アラートメッセージをAlertaに送信します。 この新しい通知はAlertaダッシュボードに表示されます。
アラートが機能していることがわかったので、作成した一時ファイルを削除して、ディスク領域を再利用できるようにします。
- rm -f /tmp/temp.img
1分後、Zabbixはリカバリメッセージを送信します。 アラートはメインダッシュボードから消えますが、 Closed を選択すると、すべてのクローズされたイベントを表示できます。
イベント行をクリックすると、詳細が表示されます。
結論
このチュートリアルでは、Alertaをインストールして設定し、Zabbixに通知を送信するように設定しました。 その結果、アラートを追跡するための便利なツールが手に入りました。 将来的には、他の通知ソースを追加して、さまざまな監視システムからの情報を統合および一元化することができます。