Ansibleでshinkenを入れてみたものの、そんな簡単に監視設定が終わるわけなかった

さまりっか

対お姉ちゃん用監視部隊、通称Shinken隊の話をしようじゃないか。

Shinken: http://www.shinken-monitoring.org/

一応先に結論から言っておくと、対お姉ちゃん用監視部隊としても普通の監視ツールとしても決して使い勝手はよくありません。

Shinken is 何

真剣？マジなの？おこなの？

http://en.wikipedia.org/wiki/Shinken_%28software%29

Python製の監視フレームワークちゃんです。

WebUIおよび切り替え機能付(Thruk, MK Multisite, NagVis or PNP)
カスタマイズダッシュボード有り
影響度可視化画面有り
nagios互換(ダウンタイム設定とかもある)
HA機能有り
pnp4nagios/Graphite連携可
DBは割と選べる(MySQL, Oracle, MsSQL, MongoDB, etc…)

…とまぁ色々だ。
使い込むのは後にして、いんすとーる&ふぁーすといんぷれっしょん。

構成

トポロジ

1

| Ansible | --- | SW | --- | Shinken |

両方ともこれ

1
2
3
4
5


$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04 LTS"

Ansible自体の準備は Ansibleでmunin2を入れるとビスケットが割れたの時と同じ。

インストール

今回のAnsibleクッキングでは、次の要素が組み込まれます。

shinken2系(pip経由。WebUIはpython直なので、apache,nginx等は現時点では含まれません)
localhostを監視するlinux-sshプラグイン(要python-paramiko)
ダッシュボード表示用のsqlite

コンポーネント依存も少なくて案外小さいじゃないですかー（CV.遥そら）

Warning

そう、入れるプラグイン次第でコンポーネント依存はどんどん拡大の一途を辿るのである。ただし胸は大きくならない。

2系と1系があったら最新版を入れたいじゃないですかー（CV.遥そら）

Note

Ubuntu 14.04はaptでshinkenを入れられるんだけど、pip経由で2系を入れます。

私ってどっちかっていうと可愛い系じゃないですかー（CV.遥そら）

Note

可愛い。

光の速さでインストール

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


$ git clone https://github.com/ainoniwa/ansible-playbooks.git
$ cd ansible-playbooks
$ git checkout a9cc4b0e32
$ cd shinken
$ echo "192.168.122.143" > hosts
$ ansible-playbook main.yml -i hosts -k -K
SSH password:
sudo password [defaults to SSH password]:

PLAY [all] ********************************************************************

<中略>

PLAY RECAP ********************************************************************
192.168.122.143            : ok=18   changed=16   unreachable=0    failed=0

Warning

今後、構造等の大きな変更が加わった際に、本文書の修正を回避するために`git checkout`が実施されていますが、基本的には不要のはずです。

説明はPlaybookに任せる（説明を端折るための横着）
実際、下記URLの内容がPlaybookになってるだけです。

で、この場合で言うと http://192.168.122.143:7767/ にアクセスすると、インストールされたShinkenの画面を見ることができると思いますが…どうですかねぇ。

外観

ログイン画面。

Username: admin / Password: admin でログインできます。
デフォルトなので、変更時はこちらの contact_name,password を変更する。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


$ cat /etc/shinken/contacts/admin.cfg
# This is a default admin
# CHANGE ITS PASSWORD!

define contact{
    use             generic-contact
    contact_name    admin
    email           shinken@localhost
    pager           0600000000   ; contact phone number
    password        admin
    is_admin        1
}

ログインすると、IT Problemsのページに飛ぶ。

上のバーからAll画面に移動するとこんな感じ。綺麗。

右端の下矢印をクリックすると、ちょっと広がる（でもそれほど情報量は増えない）

localhostをクリックすると、localhost全体のページに遷移する。

そこから、Servicesに画面遷移すると、そのホストの監視対象ツリーを見ることができる。
このツリーはImpact graphを書くときの監視階層に関係している。

右端のImpact graphに画面遷移すると、監視対象の状態ツリーを確認することができる。

localhostの左側に伸びている/systemをクリックすると、トポロジが変形して健常度合を見ることができる。（さらにホイールスクロールで拡大縮小が可能だ）

上のバーのSystemからShinken Stateを選べば、各デーモンの状態を見ることができる（…っていうかデーモン多くね？）

更に、ダッシュボードにアクセスすると最初は何もない。

で + Add a new Widget をクリックすると、右側に選択肢が出るので適当にRelation graphとSystem stateを追加して、適当に並べてみるとこんな感じになる。

Editボタンを押すと、対象を変更できる（今はlocalhostしかいないけど）ので、対象のホストを選択して表示することができる。

更に、Currently（右上の交差している矢印っぽいやつ）をクリックすると、良い感じに監視してる風の画面が出る。

この画面を一日中眺めて、赤くなったら仕事をしよう（提案）

さて。

流石に監視サーバ自身だけ監視してもしょうがない。監視対象を追加したりしないといけないだろう。
設定を追加したり変更したりするにはどこの設定ファイルを触ればいいのかな？
多分 /etc/shinken の中見ればわかるよね？

1
2
3
4
5
6
7


$ ls /etc/shinken/
arbiters       daemons       hosts             realms      servicegroups
brokers        dependencies  modules           receivers   services
certs          dev.cfg       notificationways  resource.d  shinken.cfg
commands       discovery     packs             sample      templates
contactgroups  escalations   pollers           sample.cfg  timeperiods
contacts       hostgroups    reactionners      schedulers

Wow…ファイルガオオクテヨクワカリマセーン…。

アーキテクチャ見よう

ファイルが多くて良く分からないのは、アーキテクチャをよく知らないからだ。構成を知ろう。
既に心が折れそうだなぁ。

shinkenは主に下記の6つの要素（内1つはオプション）で構成されます。
負荷分散を考慮しているため、個々の要素はそれぞれ異なるノードにインストールしてスケールすることが可能です。

Arbiter
- 設定ファイルを読み込んで、対応するデーモンに配布するやつ
- 配布先のデーモンが死んだら別のデーモンに配布しなおす高可用性を管理する
- Livestatus APIとかnagios.cmdでユーザが叩いたコマンドを、適切なデーモンにルーティングする入口の役割を持ちます
Scheduler
- pollerとreactionnerに処理を割り当てるやつ
- 実際の処理はしないけど、チェック結果を一時的に受け取ってプールする
Poller
- 能動的にチェックプラグインを起動するやつ
Reactionner
- チェックプラグインの結果から、メールを投げたりRSS通知をしたりする
- Shinken以外の外部システムに対して能動的に働きかける処理を一元化している
Brocker
- Schedulerから受け取ったチェックプラグインの実データの処理を決定するやつ
- 監視結果、リソース値、ログをデータとして出力する部分
- WebUIはこいつを介してデータにアクセスするので、WebUIプラグインはこいつが管理する
Receiver(optional)
- 受動的にチェック結果を受け取るやつ
- NSCA daemon(nagiosでSNMP Trapを受け取って処理するやつ)とかはここに分類される

公式の出してる画像 http://www.shinken-monitoring.org/wiki/the_shinken_architecture が割と綺麗です。が、若干ふんわりしています。
まぁ、流れはこんな感じで良いんじゃないかな。

設定ファイル読んで設定配る(Arbiter)
スケジューラ(Scheduler)
チェックプラグイン(nagiosプラグインとか)動かす(Poller)
スケジューラ(Scheduler)
データためる(Brocker)
Webアクセスするプラグインを管理してるやつが立ってる(Brocker) <- ここにWebアクセスしてデータ見る

ノードの追加

今回使っているのはlinux-sshプラグインで、監視項目はデフォルトでこんな感じ

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


$ cat /etc/shinken/packs/linux-ssh/commands.cfg | grep name
       command_name     check_ssh_connexion
       command_name     check_ssh_linux_memory
       command_name     check_ssh_linux_cpu_stats
       command_name     check_ssh_linux_disks
       command_name     check_ssh_linux_disks_stats
       command_name     check_ssh_linux_kernel_stats
       command_name     check_ssh_linux_load_average
       command_name     check_ssh_linux_processes
       command_name     check_ssh_linux_tcp_states
       command_name     check_ssh_linux_net_stats
       command_name     check_ssh_ro_filesystem
       command_name     check_ssh_linux_uptime
       command_name    check_ssh_linux_ntp_sync
       command_name    check_ssh_linux_ntp_sync_chrony
       command_name     check_ssh_linux_nfs_stats

_stats がついてるものがリソース測定用で、そうでないものがプロセス監視用ぽい。
shinkenのWebUIからはノード追加用の設定は出来ないので、こんな感じで追加します。
linux-sshはsshログインが必須なので公開鍵登録をして、設定ファイルを書きます

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# su - shinken
$ ssh-copy-id -i ~/.ssh/id_rsa.pub test@192.168.122.149
$ echo "define host{
        use                     linux-ssh,generic-host
        contact_groups          admins
        host_name               test
        address                 192.168.122.149
        _SSH_USER               test
        }" > /etc/shinken/hosts/test.cfg
$ exit
# service shinken-arbiter restart

Note

アクセス先にtestユーザがいると仮定しています。ここは適切な（ログインしてコマンド操作が可能な）ユーザに読み替えてください
Arbiterだけを再起動すれば、設定ファイルの変更は適用されます（アーキテクチャの通り）
_SSH_USER などの変数は、例えばlinux-sshを使用する場合は /etc/shinken/packs/linux-ssh/templates.cfg で定義されています。
shinkenユーザの公開鍵はインストール時にplaybookに書いておいたから、最初から使えるよ！やったね！

これで新しいホストが追加されて、監視がスタートします。

これで監視ノードが増えた時、どうやってカタカタすれば良いかは分かった。

チェックプラグインの追加

Warning

現時点ではかなりつらいです。色々と。

linux-sshしか使えないのもあれだし、SNMPのチェックとかしたくなったらどうすればいいんだろう。
あ、それ linux-snmp を入れれば良さそう。

1
2
3
4
5
6
7


# su - shinken
$ shinken install linux-snmp
$ ls /etc/shinken/packs/linux-snmp/
commands.cfg  discovery.cfg  linux-snmp.pack  services  templates.cfg
$ cat /etc/shinken/resource.d/snmp.cfg
# default snmp community
$SNMPCOMMUNITYREAD$=public

Note

shinken search all とかすると、対応しているプラグインがだばーっと出ます。vmwareとかwindowsとかciscoとかhpとか色々あるっぽいです。

ふむふむ。さっきと同じパターンで、監視ホストに設定を入れればいいんだな。
COMMUNITYはとりあえずpublicらしいので動作確認しておこう。
で、チェックプラグインを起動して

1
2
3


$ /var/lib/shinken/libexec/check_snmp_load.pl
Can't locate Net/SNMP.pm in @INC (you may need to install the Net::SNMP module) (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl .) at /var/lib/shinken/libexec/check_snmp_load.pl line 16.
BEGIN failed--compilation aborted at /var/lib/shinken/libexec/check_snmp_load.pl line 16.

Oh…。
どうせnagiosプラグインに関するものは必要になるので、とりあえず一式入れとく。

1
2
3
4


# apt-get install nagios-plugins
$ /var/lib/shinken/libexec/check_snmp_load.pl
Can't locate utils.pm in @INC (you may need to install the utils module) (@INC contains: /usr/local/nagios/plugins /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl .) at /var/lib/shinken/libexec/check_snmp_load.pl line 22.
BEGIN failed--compilation aborted at /var/lib/shinken/libexec/check_snmp_load.pl line 22.

何だよもう！更にプラグインにパスを追加して動作確認

1
2
3
4
5
6
7
8


$ grep -n "lib" /var/lib/shinken/libexec/check_snmp_load.pl
21:use lib "/var/lib/shinken/libexec";
22:use lib "/usr/lib/nagios/plugins";
$ /var/lib/shinken/libexec/check_snmp_load.pl
Usage: /var/lib/shinken/libexec/check_snmp_load.pl [-v] -H <host> -C <snmp_community> [-2] | (-l login -x passwd [-X pass -L <authp>,<privp>])  [-p <port>] -w <warn level> -c <crit level> -T=[stand|netsl|netsc|as400|cisco|cata|nsc|fg|bc|nokia|hp|lp|hpux] [-f] [-t <timeout>] [-V]
$ /var/lib/shinken/libexec/check_snmp_load.pl -H 192.168.122.156 -C public -w 90 -c 95
Argument "v6.0.1" isn't numeric in numeric lt (<) at /var/lib/shinken/libexec/check_snmp_load.pl line 686.
Can't find CPU usage information : UNKNOWN

Note

これに関してはログ取った時は出たんだけど、今は出ないかもしれません。

またか…決してShinkenが悪いわけではないと思うのだが、もう既に調査だけでお腹一杯になってる。
いや待て、パッケージングされたスクリプトが修正しないと動かないの、Shinkenが悪いだろ。

1
2
3


$ sed -i 's/Net::SNMP->VERSION < 4/Net::SNMP->VERSION lt 4/g' /var/lib/shinken/libexec/check_snmp_load.pl
$ /var/lib/shinken/libexec/check_snmp_load.pl -H 192.168.56.15 -C public -w 90 -c 95
1 CPU, load 1.0% < 90% : OK

Note

check_snmp_mem.pl, check_snmp_storage.plも同様に対応する。

これでプラグインの一部は動くことが確認できた。
後は、さっきと同様に設定を変更して再起動。

1
2
3
4
5
6
7
8
9


# su - shinken
$ echo "define host{
        use                     linux-snmp,generic-host
        contact_groups          admins
        host_name               test
        address                 192.168.122.149
        }" > /etc/shinken/hosts/test.cfg
$ exit
# service shinken-arbiter restart

Note

192.168.122.149ではCOMMUNITYがpublicでSNMPアクセスできるという設定です。

動いた。

何でUNKNOWNなんですか！値取れてるじゃないですか！もう！
割に合わねぇ。

Note

ちなみに、プラグインの動作に必要な対応は、大体ここに書いてある通りでした。 https://wiki.icinga.org/display/howtos/check_snmp

localhostの時は表示されなかったけど、SNMPを使っていると、ホストの画面で見た目が無駄にカッコいいリソースダイアグラムを見ることができます。
カッコいい（真顔）

っていうか Warning: This plugin must be either run as root or setuid root. ってなんだよ！SNMPプラグインだぞちょっと待てよ！
ま、それはさておき。
新しくMIBを指定して監視するには、

/etc/shinken/packs/linux-snmp/services/ で *.cfg を書く
/etc/shinken/packs/linux-snmp/command.cfg にコマンドを定義する

の順で設定可能だと思うのだが、見る限りSNMPを手厚くする気が無いように見えるんですよね。

1
2
3
4


$ ls -l /var/lib/shinken/libexec/*snmp*
-rwxr-xr-x 1 shinken shinken 22955 Jun 20 21:47 /var/lib/shinken/libexec/check_snmp_load.pl
-rwxr-xr-x 1 shinken shinken 18673 Jun 20 21:47 /var/lib/shinken/libexec/check_snmp_mem.pl
-rwxr-xr-x 1 shinken shinken 23965 Jun 20 21:47 /var/lib/shinken/libexec/check_snmp_storage.pl

nagios-plugins入れたんだから /usr/lib/nagios/plugins/check_snmp でも使えば？と言うことですか。そんな馬鹿な。
っていうか全編通して設定が非常に面倒なんですけど、これどうにかならないんですか…Livestatus APIでも入れたら楽になるんですか…？

グラフ欲しい！んだけど…

「グラフが無いとか耐えられない！」からの「耐えて別のリソースグラフツール探すか」の流れ。
ヤバい、無限に調査範囲が広がるし、割とどこに着地できない、ヤバい。
あぁ、Shinkenはグラフツール(Graphite/PNP4Nagios)との連携ができるんですよ。

ただその、ちょっと疲れてしまって。
気が向いたらグラフ連携も書きましょうね。
そうだね、向きそうにないね。

もう終わりにしよう

自宅ラボライフを快適にするには、監視を簡単かつ的確に設定できる必要があることは言うまでもない。自動的に監視が始まろうもんならお昼寝生活待ったなしですよ。
一応Shinkenと呼ばれる監視ソフトウェアも抑えておく必要があるかと思って、割とちゃんと調査しようと思っていたんですよ。

あー…途中までは。

確かに見た目は割と良いし、インストール自体はそう難しくもないし、プラグインをshinken.ioが配ってるってのは良いと思うんですよ。
でもちょっとそれ以外がつらい。全体的につらい。
恐らくこれならZabbixやCentreonやPandoraFMSと向き合った方が良い。
とりあえずはこんなところで幕引きにしたい。
僕がベストプラクティスに沿ってないからだとか、もっとちゃんと調査したいという人は是非よろしくお願い致します。