わたしは普段システムの監視にzabbixを使っているのですが、ずっと不満点がありました。
ディスカバリで生成される大量のグラフ項目のせいで、目的のグラフが見つけられないという問題です。
zabbixの管理画面では、アイテムやトリガーなどは絞り込み検索ができるのですが、グラフだけは絞り込みができず、表示される最大件数の1000件を超えてしまうことがありました。
この1000件制限を緩和したく調べてみたところ、データベースのconfigテーブルのsearch_limitカラムに記録されていました。
パフォーマンス的な理由で制限が掛けられているのだと思いますが、わたしのところでは増やしても問題は感じませんでした。
これWebUIから変更できないんですよね。
アカウントの設定画面にあった「ページあたりの表示行数」を増やしても、1ページの表示件数が増えるだけで1000件制限は変わらず最大ページ番号が縮むだけでした。
2020/01/10
2019/03/03
システム稼働状況ページを作った
Service status osa-p.net を作った話。
元々、zabbixでシステムの状況はモニタリングしているのだが、それを外部に公開する仕組みを用意していなかった。zabbixのページをそのまま公開したくなかったので、必要な情報だけ抽出して表示できる仕組みが欲しかった。
SNSでつぶやいてみると
UptimeRobotというサービスを紹介してもらえた。
早速設定してみたところ、格好良い稼働状況ページが出来上がったのだが、うちのシステム上、ウェブサーバとデータベースが分離しており、データベースを使う処理は動かないが、ウェブサーバだけで完結する処理は動くという状況があり得て、その表示がしにくいなと感じた。
そこで、やはり自前で処理を作るかと、ついでに使ったことのなかったVueも試しに取り入れてみた。普段仕事でもまだまだjQueryを使うことが多く、また思い付いたサービスを個人で作るときにも早く公開したくて慣れているjQueryを使ってしまうことが多い。今回は急ぐものでもなかったので、サンプル程度しか動かしたことのなかったVueを使ってみた。といっても、やはりサンプルの継ぎはぎではあるのだけど。
処理自体は問題無くできて、さて公開するかというところで問題があった。
稼働状況ページは、自分が管理しているシステムの中で動かしてしまうと、一緒に落ちたときに肝心の状況が見えなくなってしまうので、公開ページは別のサービスで動かしたかった。まず最初に選んだのがS3で、ここでは静的サイトを公開する情報も整っていたので簡単に設定して公開。あとはネームサーバとして使っているCloudflareでCNAMEを張ってやれば動くだろうと考えていた。
実際に公開してみたところ、httpでは繋がるのだが、httpsでは接続ができなかった。S3の公開では、「https://S3ドメイン/バケット名/」だとhttpsが使えるのだが「https://バケット名.s3ドメイン」ではhttpsが使えない。Cloudflare側でHTTP Proxyを有効にしていたら、オリジンサーバーがhttpでも使えたような記憶があったのだけど、どうも上手く行かないので間にCloudFrontを挟んでhttpsでも繋がるようになった。
しかし別の問題が発生した。ページの作りとしては、zabbixから出力したSLAの情報をS3に5分毎にアップロードし、静的ページ側でそれを読み込んで表示する。CloudFrontは読み込んだ情報をキャッシュしてしまうので、いつまでも古い情報が表示されてしまうのだ。もちろんCloudFrontの設定にも用意されているので、TTLの設定を5分にしてみたり、クエリが付いていたらキャッシュしない設定にしたり、キャッシュをクリアしてみたりしたのだが、どうにも解消できなかった。
結局Netlifyで静的ページ部分を配信しつつ、データはS3から読み込むという仕組みで解決した。このやり方ならGitHub Pagesでも大丈夫だろうが、最初すべてをGitHub Pagesで配信しようと考えてしまい、5分毎にコミットとプッシュをしたら怒られそうだなと思って頭の中からGitHubを使うことを取り除いてしまっていた。
ひとまず大枠の仕組みが完成したので、これを応用して、zabbixに入力したメンテナンス情報を各サービスで表示したり、自動でメンテモードに切り替えたりもできるだろう。今はデータベースを止めるメンテナンスがあるときに、各サービスのcronを止めたり、フラグを立てたりと手動で処理してアクセスが止んだのを確認してから作業したりしているので、この辺りも自動化してしまいたいと考えている。
元々、zabbixでシステムの状況はモニタリングしているのだが、それを外部に公開する仕組みを用意していなかった。zabbixのページをそのまま公開したくなかったので、必要な情報だけ抽出して表示できる仕組みが欲しかった。
SNSでつぶやいてみると
UptimeRobotというサービスを紹介してもらえた。
早速設定してみたところ、格好良い稼働状況ページが出来上がったのだが、うちのシステム上、ウェブサーバとデータベースが分離しており、データベースを使う処理は動かないが、ウェブサーバだけで完結する処理は動くという状況があり得て、その表示がしにくいなと感じた。
そこで、やはり自前で処理を作るかと、ついでに使ったことのなかったVueも試しに取り入れてみた。普段仕事でもまだまだjQueryを使うことが多く、また思い付いたサービスを個人で作るときにも早く公開したくて慣れているjQueryを使ってしまうことが多い。今回は急ぐものでもなかったので、サンプル程度しか動かしたことのなかったVueを使ってみた。といっても、やはりサンプルの継ぎはぎではあるのだけど。
処理自体は問題無くできて、さて公開するかというところで問題があった。
稼働状況ページは、自分が管理しているシステムの中で動かしてしまうと、一緒に落ちたときに肝心の状況が見えなくなってしまうので、公開ページは別のサービスで動かしたかった。まず最初に選んだのがS3で、ここでは静的サイトを公開する情報も整っていたので簡単に設定して公開。あとはネームサーバとして使っているCloudflareでCNAMEを張ってやれば動くだろうと考えていた。
実際に公開してみたところ、httpでは繋がるのだが、httpsでは接続ができなかった。S3の公開では、「https://S3ドメイン/バケット名/」だとhttpsが使えるのだが「https://バケット名.s3ドメイン」ではhttpsが使えない。Cloudflare側でHTTP Proxyを有効にしていたら、オリジンサーバーがhttpでも使えたような記憶があったのだけど、どうも上手く行かないので間にCloudFrontを挟んでhttpsでも繋がるようになった。
しかし別の問題が発生した。ページの作りとしては、zabbixから出力したSLAの情報をS3に5分毎にアップロードし、静的ページ側でそれを読み込んで表示する。CloudFrontは読み込んだ情報をキャッシュしてしまうので、いつまでも古い情報が表示されてしまうのだ。もちろんCloudFrontの設定にも用意されているので、TTLの設定を5分にしてみたり、クエリが付いていたらキャッシュしない設定にしたり、キャッシュをクリアしてみたりしたのだが、どうにも解消できなかった。
結局Netlifyで静的ページ部分を配信しつつ、データはS3から読み込むという仕組みで解決した。このやり方ならGitHub Pagesでも大丈夫だろうが、最初すべてをGitHub Pagesで配信しようと考えてしまい、5分毎にコミットとプッシュをしたら怒られそうだなと思って頭の中からGitHubを使うことを取り除いてしまっていた。
ひとまず大枠の仕組みが完成したので、これを応用して、zabbixに入力したメンテナンス情報を各サービスで表示したり、自動でメンテモードに切り替えたりもできるだろう。今はデータベースを止めるメンテナンスがあるときに、各サービスのcronを止めたり、フラグを立てたりと手動で処理してアクセスが止んだのを確認してから作業したりしているので、この辺りも自動化してしまいたいと考えている。
2015/12/21
移動するサーバのzabbixエージェントを登録する(Zabbix Advent Calendar 2015)
Zabbix Advent Calendar 2015の21日目です。
zabbix便利ですね。
監視と通知と表示と対応がこれ一つでできるので、 何かと重宝しています。
悩みをツイートすると、的確なアドバイスが返ってくるのもすごいです。
本当はフォーラムあたりに投稿して、情報を集積するべきなんでしょうけど、すいません。
さて、わたしの環境では 自宅サーバでzabbix-serverを起動し、他の自宅サーバやEC2、VPSのagentから情報を集めています。
EC2だと固定IPを登録していないなら起動する度にIPアドレスが変わりますし、スポットインスタンスなどを使えば起動していない時間帯もあります。
このようなサーバもzabbixで管理したいと思い試行錯誤してみたらうまく行ったのでご紹介。
通常、同一ネットワークに管理対象サーバが居れば、ディスカバリ機能を使ってagentを見つけてくれますが、さすがにグローバルIPアドレス宛で、範囲が決まっているとは言えEC2などでは広大な範囲が指定されているので難しいものがあります。
ですので、agent側から起動時にserverへIPアドレスの変更を通知します。
わたしの場合は、サーバが落ちていることも検知したかったので、インスタンス終了時には敢えてサーバの登録解除はせず、あらかじめ登録しておいたサーバのIPアドレスを変更する手法を採っています。
数の決まっていないサーバを登録・解除する場合は、以下の方法のIP変更命令を、サーバの登録にして、インスタンス終了時に登録解除の命令を送れば大丈夫かと思います。
zabbixには、JSONRPCで用意されているAPIを叩くと、様々な情報を取得したり、更新したりできます。
この機能を利用します。このスクリプトは、zabbixサーバに設置します。
ユーザー名、パスワード、zabbix設置アドレスをそれぞれの環境に合わせて書き換えてください。
あと、jqコマンドを使いますので入れておいてください。
このスクリプトではuser.loginメソッドでログイントークンを取得し、以後のメソッド呼び出しに使っています。
IPアドレスを変更する対象サーバを見つけるために、DNS情報を利用しています。
hostinterface.getにて、指定のDNSを持つサーバのインターフェースIDを取得し、そのインターフェースのIPアドレスをhostinterface.updateメソッドで更新しています。
EC2側では、agentの起動スクリプト内で
ここで使っている
${instance_name} と ${ec2_public_ipv4} は、別途
分けてあると、色々と使い回しができて便利です。
このスクリプトでは、EC2の高度な詳細にあるユーザーデータにドメイン名を指定します。
jsonrpcで操作できる項目は多種に渡るため、一度どんなメソッドが用意されているか見ておくだけでも楽しいです。基本的にはWebUIから設定できる物は全部できるっぽいですね。
何か自動化したくなったときに、いろいろと役立つかもしれません。
zabbix便利ですね。
監視と通知と表示と対応がこれ一つでできるので、 何かと重宝しています。
悩みをツイートすると、的確なアドバイスが返ってくるのもすごいです。
本当はフォーラムあたりに投稿して、情報を集積するべきなんでしょうけど、すいません。
さて、わたしの環境では 自宅サーバでzabbix-serverを起動し、他の自宅サーバやEC2、VPSのagentから情報を集めています。
EC2だと固定IPを登録していないなら起動する度にIPアドレスが変わりますし、スポットインスタンスなどを使えば起動していない時間帯もあります。
このようなサーバもzabbixで管理したいと思い試行錯誤してみたらうまく行ったのでご紹介。
通常、同一ネットワークに管理対象サーバが居れば、ディスカバリ機能を使ってagentを見つけてくれますが、さすがにグローバルIPアドレス宛で、範囲が決まっているとは言えEC2などでは広大な範囲が指定されているので難しいものがあります。
ですので、agent側から起動時にserverへIPアドレスの変更を通知します。
わたしの場合は、サーバが落ちていることも検知したかったので、インスタンス終了時には敢えてサーバの登録解除はせず、あらかじめ登録しておいたサーバのIPアドレスを変更する手法を採っています。
数の決まっていないサーバを登録・解除する場合は、以下の方法のIP変更命令を、サーバの登録にして、インスタンス終了時に登録解除の命令を送れば大丈夫かと思います。
zabbixには、JSONRPCで用意されているAPIを叩くと、様々な情報を取得したり、更新したりできます。
この機能を利用します。このスクリプトは、zabbixサーバに設置します。
ユーザー名、パスワード、zabbix設置アドレスをそれぞれの環境に合わせて書き換えてください。
あと、jqコマンドを使いますので入れておいてください。
#!/bin/bash
# json2zabbix
json_auth='{"jsonrpc":"2.0","method":"user.login","params":{"user":"ユーザー名","password":"パスワード"},"id":1}'
rpc_url='http://zabbix設置アドレス/api_jsonrpc.php'
ZABBIX_TOKEN=`curl -s -XGET -H "Content-Type:application/json-rpc" -d $json_auth $rpc_url | jq -r '.result'`
echo "####### TOKEN = $ZABBIX_TOKEN"
if [ $1 ]; then
json='{"jsonrpc": "2.0","method":"hostinterface.get","params":{"filter":{"dns":"##DNS##"}},"id":2,"auth":"##TOKEN##"}'
json=`echo $json | jq '.' -c | sed -e s/##DNS##/$1/ -e s/##TOKEN##/$ZABBIX_TOKEN/ `
echo $json
interfaceid=`curl -s -XGET -H "Content-Type:application/json-rpc" -d $json $rpc_url | jq -r '.result[0].interfaceid'`
json='{"jsonrpc": "2.0","method":"hostinterface.update","params":{"interfaceid":"##INTERFACEID##","ip":"##IP##"},"id":3,"auth":"##TOKEN##"}'
json=`echo $json | jq '.' -c | sed -e s/##INTERFACEID##/$interfaceid/ -e s/##IP##/$2/ -e s/##TOKEN##/$ZABBIX_TOKEN/ `
echo $json
curl -s -XGET -H "Content-Type:application/json-rpc" -d $json $rpc_url
else
echo "JSON to ZABBIX Request"
echo "Usage: json2zabbix.sh ip dns"
fi
jsonrpcのメソッドについてはこちらを参照してください。バージョン2.4へのリンクですが、ロゴの下でバージョンが切り替えられます。このスクリプトではuser.loginメソッドでログイントークンを取得し、以後のメソッド呼び出しに使っています。
IPアドレスを変更する対象サーバを見つけるために、DNS情報を利用しています。
hostinterface.getにて、指定のDNSを持つサーバのインターフェースIDを取得し、そのインターフェースのIPアドレスをhostinterface.updateメソッドで更新しています。
EC2側では、agentの起動スクリプト内で
sudo -u サーバにSSH接続できるユーザ名 ssh ユーザ名@サーバアドレス -p SSHポート "json2zabbix.sh ${instance_name} ${ec2_public_ipv4}"
を呼び出します。ここで使っている
${instance_name} と ${ec2_public_ipv4} は、別途
#!/bin/sh
# get instance data
url_prefix=http://169.254.169.254/latest
ec2_instance_id=`/usr/bin/curl ${url_prefix}/meta-data/instance-id/ --stderr /dev/null`
ec2_region=`/usr/bin/curl ${url_prefix}/meta-data/public-hostname --stderr /dev/null | awk -F . '{print $2}'`
ec2_public_ipv4=`/usr/bin/curl ${url_prefix}/meta-data/public-ipv4 --stderr /dev/null`
ec2_user_id=`/usr/bin/curl ${url_prefix}/dynamic/instance-identity/document --stderr /dev/null | awk -F : '/accountId/ {n=split($2,a,"\"");print a[2]}'`
instance_name=`/usr/bin/curl -q ${url_prefix}/user-data --stderr /dev/null`
local_ipv4=`/usr/bin/curl ${url_prefix}/meta-data/local-ipv4 --stderr /dev/null`
というようなスクリプトを用意して読み込ませておくと良いでしょう。分けてあると、色々と使い回しができて便利です。
このスクリプトでは、EC2の高度な詳細にあるユーザーデータにドメイン名を指定します。
jsonrpcで操作できる項目は多種に渡るため、一度どんなメソッドが用意されているか見ておくだけでも楽しいです。基本的にはWebUIから設定できる物は全部できるっぽいですね。
何か自動化したくなったときに、いろいろと役立つかもしれません。
2011/12/03
zabbixで外部チェックアイテムを作る
(この記事はzabbix 1.8を対象としたものです。2.0以降では、下記パラメータの1番目にホスト名というのがありません)
サーバの状態監視にはzabbix!
便利すぎます。結構負荷高いのが難点だけど、余裕があったら監視用サーバを立てるのもありかなと思う。
普段はテンプレートをそのまま適用して、動いていないサービスのアイテムだけ解除していく使い方をしているのだけど、テンプレートで用意されていない物を監視したいときに、外部チェックアイテムを作成して対応した。
アイテムのタイプ:外部チェック
キー:get_queue_count.sh[fav_queue]
などとする。
このとき、zabbix_server.confのExternalScriptsに、キーで指定したスクリプトのパスを書いておく。
そしてスクリプト側。[ ]で括られた部分がパラメータとして渡されるのだけど、パラメータの1番目にホスト名が自動的に付けられる。
上の例だと、実際に呼ばれるコマンドは
get_queue_count.sh hostname fav_queue
みたいに。
なので、スクリプト側では、それを考慮しておく必要がある。
#/bin/bash
/usr/bin/mongo --quiet --eval="db.$2.count()" favlook
という感じで、ホスト名は無視した。
サーバの状態監視にはzabbix!
便利すぎます。結構負荷高いのが難点だけど、余裕があったら監視用サーバを立てるのもありかなと思う。
普段はテンプレートをそのまま適用して、動いていないサービスのアイテムだけ解除していく使い方をしているのだけど、テンプレートで用意されていない物を監視したいときに、外部チェックアイテムを作成して対応した。
アイテムのタイプ:外部チェック
キー:get_queue_count.sh[fav_queue]
などとする。
このとき、zabbix_server.confのExternalScriptsに、キーで指定したスクリプトのパスを書いておく。
そしてスクリプト側。[ ]で括られた部分がパラメータとして渡されるのだけど、パラメータの1番目にホスト名が自動的に付けられる。
上の例だと、実際に呼ばれるコマンドは
get_queue_count.sh hostname fav_queue
みたいに。
なので、スクリプト側では、それを考慮しておく必要がある。
#/bin/bash
/usr/bin/mongo --quiet --eval="db.$2.count()" favlook
という感じで、ホスト名は無視した。
登録:
投稿 (Atom)







