HAProxy でスティッキーセッションするメモ

CentOS 7 の yum でさくっとインストールできるバージョンで試しています。

  • haproxy-1.5.14-3.el7.x86_64

appsession

アプリケーションが発行する cookie の値とサーバとの対応表のテーブルを HAProxy が保持する。

appsession PHPSESSID len 32 timeout 30m request-learn

この例だと PHPSESSID という名前のクッキーの値の先頭 32 バイトを用いてテーブルを作成する。有効期限は 30 分で有効期限が切れるとテーブルから削除される。

request-learn を付けると、HAProxy はリクエストの Cookie からもテーブルに追加する。request-learn がない場合、次のようなケースで問題になる。

  • サイトにアクセス
    • クライアントの Cookie なし
      • HAProxy は Cookie の値が対応表にないのでランダムに振り分ける
    • サーバが Set-Cookie を返す
      • HAProxy が Cookie の値を記録する
  • サイトにアクセス
    • クライアントが Cookie を送る
      • HAProxy が Cookie の値で対応表を引いて振り分けるサーバを決定する
    • サーバは Cookie を発行済みなので Set-Cookie を送らない
  • HAProxy を再起動する
  • サイトにアクセス
    • クライアントが Cookie を送る
      • HAProxy は Cookie の値が対応表にないのでランダムに振り分ける
    • サーバは Cookie を発行済みなので Set-Cookie を送らない
  • サイトにアクセス
    • クライアントが Cookie を送る
      • HAProxy は Cookie の値が対応表にないのでランダムに振り分ける
    • サーバは Cookie を発行済みなので Set-Cookie を送らない

PHP のセッションはクライアントが Cookie を送るとサーバは Set-Cookie を送らないので (session_regenerate_id とかしなければ) 、request-learn を指定しておくと無難。

prefixmode も指定できるけどあんまり使わなさそう。

この方法は対応表のテーブルを保持するために HAProxy でメモリを消費する。

ボットとか死活監視とかのセッションの必要がないリクエストは ignore-persist で除外しておけば、それらのリクエストによって appsession のテーブルが大きくなることを防止できる。

appsession PHPSESSID len 64 timeout 30m request-learn
acl ab hdr_sub(User-Agent) -i ApacheBench
ignore-persist if ab

cookie insert

HAProxy 自身が Cookie を発行する。

cookie HAPROXY insert nocache indirect preserve httponly secure maxidle 30m maxlife 8h
server ap01 192.168.33.21:80 check cookie ap01
server ap02 192.168.33.22:80 check cookie ap02

この例だと HAPROXY=ap01 のような Cookie が発行される。

nocache を指定すると、レスポンスヘッダに Cache-control: private を追加することでプロキシサーバがキャッシュしないようにする。スティッキーのための Cookie をプロキシに覚えさせるわけにはいかないので、nocache かもしくは後述の postonly を指定しておくのが無難。

indirect を指定すると、クライアントが送信した Cookie (上の例だと HAPROXY=ap01) は HAProxy が削除するので、サーバに Cookie の値は渡らない。

preserve を指定すると、サーバで setcookie('HAPROXY', '', time()-3600) とかで Cookie 削除のためのレスポンスを返すことができる。逆に、指定していなければ、サーバがそのようなレスポンスを送っても HAProxy が削除する。

httponlysecure はそのままの意味、domain も指定できる。

maxidle 30m は、指定した時間以上未アクセスだと無効になるように Cookie を発行する。

maxlife 8h は、Cookie を最初に発行してから指定時間以上経過すると無効になるように Cookie を発行する。

maxidlemaxlife は Cookie に HAPROXY=ap01|VwNGp|VwNGl のようなタイムスタンプに基づく値を付与することで実現される。

postonly を指定すれば POST リクエストのレスポンスにのみ Set-Cookie が発行されるようになる。 大抵のアプリではログイン画面の POST リクエストからがセッションの始まりになるので、postonly を指定しても良いかもしれない。

appsession とは異なり、Cookie の値から直接振り分け先が導出されるので、対応表のために余分なメモリを消費することはない。

cookie prefix

アプリケーションが発行するクッキーの値の先頭に HAProxy が追記する。

cookie PHPSESSID prefix
server ap01 192.168.33.21:80 check cookie ap01
server ap02 192.168.33.22:80 check cookie ap02

この例だと、アプリケーションが PHPSESSID=xyz123 という Cookie を発行したら、HAProxy がそれを PHPSESSID=ap01~xyz123 のように書き換える。

cookie rewrite

prefix とほとんど同じだけど、先頭に追記じゃなくてただの書き換えになる。

cookie HAPROXY rewrite
server ap01 192.168.33.21:80 check cookie ap01
server ap02 192.168.33.22:80 check cookie ap02

この例だと、アプリケーションが HAPROXY=hoge のように Cookie を発行したら、HAProxy がそれを HAPROXY=ap01 のように書き換える。 PHPSESSID のようなアプリケーションのセッション用 Cookie を指定してしまうと HAProxy がその値を書き換えてしまうので、セッションの維持ができない。

参考

HAProxy のログのメモ

CentOS 7 の yum でさくっとインストールできるバージョンで試しています。

  • haproxy-1.5.14-3.el7.x86_64

ログの宛先の設定

chroot しない場合

chroot しない場合は /dev/log を指定すれば簡単でした。

/etc/haproxy/haproxy.cfg

global
    log /dev/log local2
    #chroot /var/lib/haproxy
    :

chroot する場合で UDP を使う

chroot すると /dev/log が haproxy から見えなくなってしまいます。ので、UDP にします。

CentOS 7 の rsyslog はデフォだと UDP でリッスンしていないので、下記のように設定を変更して UDP を有効にします。

/etc/rsyslog.d/udp.conf

$ModLoad imudp
$UDPServerRun 514

haproxy.cfg でログの宛先に 127.0.0.1 を指定するのですが、このとき log-send-hostname も指定しなければログのホスト名が localhost になってしまったので、これも一緒に指定します。

/etc/haproxy/haproxy.cfg

global
    log 127.0.0.1 local2
    log-send-hostname
    chroot /var/lib/haproxy
    :

chroot する先に /dev/log を mount する

chroot した先で /dev/log が見えればいいので・・うーん、mount --bind で作っておく?

sudo mkdir -p /var/lib/haproxy/dev/
sudo touch /var/lib/haproxy/dev/log
sudo mount --bind /dev/log /var/lib/haproxy/dev/log

/etc/haproxy/haproxy.cfg

global
    log /dev/log local2
    chroot /var/lib/haproxy
    :

うーん、これはちょっと無いかな・・

chroot する先に rsyslog にリッスンさせる

chroot する先で rsyslog がリッスンするように設定します。

/etc/rsyslog.d/haproxy.conf

$AddUnixListenSocket /var/lib/haproxy/dev/log

ディレクトリを作成します。あと、↑で mount --bind したままなら解除しておきます。

sudo umount /var/lib/haproxy/dev/log
sudo rm -f /var/lib/haproxy/dev/log
sudo mkdir -p /var/lib/haproxy/dev/

/etc/haproxy/haproxy.cfg

global
    log /dev/log local2
    chroot /var/lib/haproxy
    :

ログを別ファイルに出力

↑の設定をしただけだとログが /var/log/messages に出てしまうので、rsyslog で別ファイルに書かれるように設定します。

/etc/rsyslog.d/haproxy.conf

:programname, isequal, "haproxy" /var/log/haproxy.log
& stop

haproxy をインストールしたときに下記のようなログローテートも設定されていたので /var/log/haproxy.log に出力しておけばローテートも行われます。

/etc/logrotate.d/haproxy

/var/log/haproxy.log {
    daily
    rotate 10
    missingok
    notifempty
    compress
    sharedscripts
    postrotate
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
        /bin/kill -HUP `cat /var/run/rsyslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript

systemd のユニットファイルに書かれている /usr/sbin/haproxy-systemd-wrapper からもログが出力されるようなのですが、↑の設定だとそのログは /var/log/messages に書かれるままです。

haproxy-systemd-wrapper というタグで出力されるので、下記のようにすればそのログも /var/log/haproxy.log に出力されます。

/etc/rsyslog.d/haproxy.conf

:programname, isequal, "haproxy" /var/log/haproxy.log
& stop
:programname, isequal, "haproxy-systemd-wrapper" /var/log/haproxy.log
& stop

もしくは、startswith でも良いと思います。

:programname, startswith, "haproxy" /var/log/haproxy.log
& stop

さいごに

うーん、どの方法が良いのだろうか。。ググった感じでは UDP にしているのが多いっぽいけど。

keepalived を使ってみたメモ

いまさらだけど keepalived を使ってみたメモ。LVS ではなく HAProxy の冗長化に使用するつもりなので LVS 関係の設定はありません。

CentOS 7 に yum で入れたバージョンで試しています。

  • keepalived-1.2.13-7.el7.x86_64

vrrp_script と track_script

vrrp_script でチェックスクリプトを定義して、

vrrp_script chk_haproxy {
    script "systemctl is-active haproxy"
    interval 3 # スクリプトが実行されるインターバル
    fall 3     # 非ゼロの終了コードが 3 回続いたら成功から失敗に遷移する
    rise 2     # 非ゼロの終了コードが 2 回続いたら失敗から成功に遷移する
}

vrrp_script chk_http_port {
    script "< /dev/tcp/127.0.0.1/80"
    interval 3
    fall 3
    rise 2
}

vrrp_instancetrack_script で VRRP インスタンスに設定する。

vrrp_instance VI_1 {

    :

    track_script {
      chk_haproxy
      chk_http_port # 複数指定できる
    }
}

vrrp_script の weight

vrrp_sync_group を設定していてかつ weight も設定しているとチェック自体が実行されなくなる。

vrrp_sync_group を設定していなければ weight の値によって次のように動作する。

  • weight が未設定
    • スクリプトが失敗ると FAULT になる
  • weight が正数
    • スクリプトが成功するとプライオリティが指定値だけ上がる
  • weight が負数
    • スクリプトが失敗するとプライオリティが指定値だけ下がる

weight を指定している場合に、nopreempt も指定しているとスクリプトが失敗してもフェールオーバーしない(MASTER が FAULT にならないかぎりフェイルオーバーしないため)。

smtp_alert

global_defs で通知先やメールサーバを設定し、vrrp_sync_groupvrrp_instancesmtp_alert を指定すると、ステートの変化時にメールで通知できる。

global_defs {
    notification_email {
        ore@example.com
    }
    notification_email_from keepalived@example.com
    smtp_server 127.0.0.1
    smtp_connect_timeout 10

    :
}

vrrp_sync_group VG_1 {
    :
    smtp_alert
}

vrrp_instance VI_1 {
    :
    smtp_alert
}

送信されるメールの内容は次のようなもの。

Sublect: [192.168.33.11] VRRP Group VG - Entering BACKUP state
Body: => All VRRP group instances are now in BACKUP state <=
Sublect: [192.168.33.11] VRRP Instance VIP - Entering BACKUP state
Body: => VRRP Instance is nolonger owning VRRP VIPs <=

MASTER や BACKUP になったときは通知されるけど FAULT になったときは通知されない。

notify

vrrp_sync_groupvrrp_instance でステートの変化時に実行するスクリプトを指定することができる。

vrrp_sync_group VG_1 {
    :
    notify        "/vagrant/notify.sh"
    notify_master "/vagrant/notify.sh master"
    notify_backup "/vagrant/notify.sh backup"
    notify_fault  "/vagrant/notify.sh fault"
}

vrrp_instance VI_1 {
    :
    notify        "/vagrant/notify.sh"
    notify_master "/vagrant/notify.sh master"
    notify_backup "/vagrant/notify.sh backup"
    notify_fault  "/vagrant/notify.sh fault"
    notify_stop   "/vagrant/notify.sh stop"
}

notify は指定した値がそのまま実行可能ファイル名だと認識されるので引数を指定することはできない。

notify "/vagrant/notify.sh"     # OK
notify "/vagrant/notify.sh arg" # NG

その他のスクリプトは引数を指定することができる。

notify_master "/vagrant/notify.sh master"
notify_backup "/vagrant/notify.sh backup"
notify_fault  "/vagrant/notify.sh fault"
notify_stop   "/vagrant/notify.sh stop"

notify は次のように引数が付けられて実行される。

notify.sh GROUP VG_1 MASTER 0
notify.sh INSTANCE VI_1 MASTER 100
notify.sh GROUP VG_1 BACKUP 0
notify.sh INSTANCE VI_1 BACKUP 100
notify.sh GROUP VG_1 FAULT 0
notify.sh INSTANCE VI_1 FAULT 100

最後の数字は優先度で GROUP のときは優先度とか無いので常に 0 になる。

その他のスクリプトは引数はつかない(設定で指定した引数がそのまま渡される)。

notify_stopvrrp_instance にのみ設定することができて、 VRRP インスタンスのシャットダウン時に実行される。

iptables や tcpdump で VRRP パケットを操作

iptables を有効にする。

sudo yum install -y iptables-services
sudo systemctl start iptables.service
sudo systemctl enable iptables.service
sudo iptables -F
sudo service iptables save

プロトコルには vrrp を指定する。

iptables -A INPUT -p vrrp -j DROP

tcpdump でも vrrp を指定できる。

tcpdump -nn -i any vrrp

vrrp のタイムアウト

vrrp のタイムアウト(MASTER が停止したと判断される時間)は advert_int の 3 倍で、変更できない。

unicast

自分自身に unicast しても届かないので、次のように2台で同じ値を設定しても多分大丈夫。

unicast_peer {
    192.168.33.10
    192.168.33.11
}

ログ

/etc/rsyslog.d/keepalived.conf 辺りで次のようにしておけば、ログを /var/log/keepalived.log に出力することができる(デフォだと /var/log/messages に出る)。

/etc/rsyslog.d/keepalived.conf

:programname, startswith, "Keepalived" /var/log/keepalived.log
& stop

:programname, startswith, "keepalived" /var/log/keepalived.log
& stop

ログローテートも必要。

/etc/logrotate.d/keepalived

/var/log/keepalived.log {
    daily
    rotate 10
    missingok
    sharedscripts
    postrotate
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
}

これだと1回のローテートで rsyslogd に複数回 HUP される気がするので /etc/logrotate.d/syslog に追記するほうが良いかもしれない。

/etc/logrotate.d/syslog

/var/log/cron
/var/log/maillog
/var/log/messages
/var/log/secure
/var/log/spooler
/var/log/keepalived.log
{
    missingok
    sharedscripts
    postrotate
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
}

参考

daemontools とか supervisor とか pm2 とか forever とか foreman とか systemd で同じコマンドを複数のプロセスでサービスにする

これまでスクリプトをデーモン化するために daemontools をよく使っていたのですが、同じコマンドを複数プロセス起動させたいときに煩雑というか、そもそもこのやりかたあってんの? って思ったので、代替になりそうなものをいくつか試しました。

例として、w1.shw2.sh の 2 つのサービスを、w1.sh は 2 プロセス、w2.sh は 3 プロセス起動したいものとします。

daemontools

  • http://cr.yp.to/daemontools.html
  • 定番
  • 下記の SRPM から入れるとインストールが簡単
  • 1サービス=1プロセスが基本
    • 複数プロセスを起動したければその数だけサービスを定義する必要がある
    • もしくはサービスとして起動したプロセスでさらにプロセスマネージャーみたいにするか
# インストール
sudo yum -y install rpm-build
wget http://mirrors.qmailtoaster.com/daemontools-toaster-0.76-1.3.6.src.rpm
rpmbuild --rebuild daemontools-toaster-0.76-1.3.6.src.rpm
sudo rpm -ivh ~/rpmbuild/RPMS/x86_64/daemontools-toaster-0.76-1.3.6.x86_64.rpm

# systemd のユニットファイル
sudo tee /etc/systemd/system/daemontools.service <<EOS
[Unit]
Description = daemontools
After = network.target

[Service]
ExecStart = /command/svscanboot
Restart = always
Type = simple

[Install]
WantedBy = multi-user.target
EOS

# daemontools を起動
sudo systemctl daemon-reload
sudo systemctl start daemontools
sudo systemctl status daemontools
sudo systemctl enable daemontools

# サービスの設定
sudo mkdir /service/.w1-1
sudo mkdir /service/.w1-2
sudo mkdir /service/.w2-1
sudo mkdir /service/.w2-2
sudo mkdir /service/.w2-3

sudo ln -sf /vagrant/w1.sh /service/.w1-1/run
sudo ln -sf /vagrant/w1.sh /service/.w1-2/run
sudo ln -sf /vagrant/w2.sh /service/.w2-1/run
sudo ln -sf /vagrant/w2.sh /service/.w2-2/run
sudo ln -sf /vagrant/w2.sh /service/.w2-3/run

sudo touch /service/.w1-1/down
sudo touch /service/.w1-2/down
sudo touch /service/.w2-1/down
sudo touch /service/.w2-2/down
sudo touch /service/.w2-3/down

sudo ln -sf .w1-1 /service/w1-1
sudo ln -sf .w1-2 /service/w1-2
sudo ln -sf .w2-1 /service/w2-1
sudo ln -sf .w2-2 /service/w2-2
sudo ln -sf .w2-3 /service/w2-3

# サービスを開始する
sudo svc -u /service/*

# サービスの一覧表示
sudo svstat /service/*

# サービスの再起動
sudo svc -t /service/*

# サービスを停止する
sudo svc -d /service/*

# サービスを無効にする
sudo svc -d /service/* && sudo svc -x /service/* && sudo rm /service/*

supervisor

  • http://supervisord.org/
  • 定番
  • epel から yum でインストールできる
  • 設定ファイルの numprocs でプロセス数を指定可能
# インストール
sudo yum -y install supervisor

# supervisor 起動
sudo systemctl start supervisord.service
sudo systemctl status supervisord.service
sudo systemctl enable supervisord.service

# サービスの設定
sudo tee /etc/supervisord.d/app.ini <<EOS
[program:w1]
command=/vagrant/w1.sh
process_name=%(program_name)s-%(process_num)d
numprocs=2
autostart=false

[program:w2]
command=/vagrant/w2.sh
process_name=%(program_name)s-%(process_num)d
numprocs=3
autostart=false
EOS

# 反映
sudo supervisorctl update

# サービスの開始
sudo supervisorctl start all

# サービスの再起動
sudo supervisorctl restart all

# サービスの停止
sudo supervisorctl stop all

pm2

  • http://pm2.keymetrics.io/
  • 基本的には Node.js のアプリ用
    • だけど Node.js 以外にも使える
  • 設定ファイルの instances でプロセス数を指定可能
  • モニタとかデプロイ?とか多機能?
    • 使わなさそう
  • 一般ユーザーで pm2 コマンド実行するとデーモンが立ち上がってしまう
    • ~/.pm2 が pm2 のデータディレクトリになっているため
# インストール
sudo yum install nodejs npm
sudo npm install -g pm2

# systemd のユニットとして登録
sudo pm2 startup systemd

# サービスの設定
cat <<'EOS'> app.json
[
  {
    "name"      : "w1",
    "script"    : "w1.sh",
    "exec_mode" : "fork_mode",
    "instances"  : "2"
  },
  {
    "name"      : "w2",
    "script"    : "w2.sh",
    "exec_mode" : "fork_mode",
    "instances"  : "3"
  }
]
EOS

# サービスの登録と開始
sudo pm2 start app.json

# サービスの一覧表示
sudo pm2 list

# サービスの停止
sudo pm2 stop all

# サービスの開始
sudo pm2 start all

# サービスの再起動
sudo pm2 restart all

# サービスの削除
sudo pm2 delete all

forever

  • https://github.com/foreverjs/forever
  • 基本的には Node.js のアプリ用
    • だけど Node.js 以外にも使える
  • 1サービス=1プロセスが基本
    • 複数プロセスを起動したければその数だけサービスを定義する必要がある
    • もしくはサービスとして起動したプロセスでさらにプロセスマネージャーみたいにするか
# インストール
sudo yum install nodejs npm
sudo npm install -g forever

# サービスの設定
cat <<'EOS' > forever.json
[
  {
    "command": "/bin/bash",
    "script": "w1.sh"
  },
  {
    "command": "/bin/bash",
    "script": "w1.sh"
  },
  {
    "command": "/bin/bash",
    "script": "w2.sh"
  },
  {
    "command": "/bin/bash",
    "script": "w2.sh"
  },
  {
    "command": "/bin/bash",
    "script": "w2.sh"
  }
]
EOS

# サービスの開始
sudo forever start forever.json

# サービスの一覧表示
sudo forever list

# サービスの再起動
sudo forever restartall

# サービスの停止
sudo forever stopall

foreman

  • https://ddollar.github.io/foreman/
  • 他の類似ツールの設定ファイルをエクスポートできる
    • supervisord とか upstart とか systemd とか
  • コマンドラインオプションでプロセス数を指定可能
  • respawn はしない
    • 複数プロセスのどれかが死ぬと全部死ぬ
# インストール
sudo yum -y install ruby rubygems
sudo gem install foreman

# サービスの設定
cat <<EOS> Procfile
w1: ./w1.sh
w2: ./w2.sh
EOS

# サービスの開始(Ctrl+C で終了)
foreman start -c -m w1=2,w2=3

# いろいろなサービス管理ツールの設定にエクスポート
foreman export -c w1=2,w2=3 supervisord ./supervisord
foreman export -c w1=2,w2=3 systemd ./systemd
foreman export -c w1=2,w2=3 upstart ./upstart

systemd

  • systemd でもテンプレートユニットを使えば同じコマンドを複数プロセス起動できそう
sudo tee /etc/systemd/system/app.target <<EOS
[Unit]
StopWhenUnneeded = true
Wants = \
  w1.target \
  w2.target

[Install]
WantedBy = multi-user.target
EOS

sudo tee /etc/systemd/system/w1.target <<EOS
[Unit]
StopWhenUnneeded=true
PartOf = app.target
Wants = \
  w1@1.service \
  w1@2.service
EOS

sudo tee /etc/systemd/system/w2.target <<EOS
[Unit]
StopWhenUnneeded=true
PartOf = app.target
Wants = \
  w2@1.service \
  w2@2.service \
  w2@3.service
EOS

sudo tee /etc/systemd/system/w1@.service <<EOS
[Unit]
Description = w1
After=network.target
PartOf = w1.target

[Service]
ExecStart = /vagrant/w1.sh
Restart = always
Type = simple

[Install]
WantedBy = multi-user.target
EOS

sudo tee /etc/systemd/system/w2@.service <<EOS
[Unit]
Description = w2
After=network.target
PartOf = w2.target

[Service]
ExecStart = /vagrant/w2.sh
Restart = always
Type = simple

[Install]
WantedBy = multi-user.target
EOS

sudo systemctl daemon-reload

# サービスの開始
sudo systemctl start app.target

# サービスの一覧
sudo systemctl list-units "w[12]@*"

# w1 だけ再起動
sudo systemctl restart w1.target

# サービスを停止
sudo systemctl stop app.target

まとめ

  • daemontools はたくさん設定するのが辛い
  • supervisor は良さそう
  • pm2 と forever は Node.js って感じある
    • Node.js 以外でも使えるけどあんまり使われてなさそうな、雰囲気を感じる
  • foreman は respawn しないのが辛そう
    • systemd が foreman を respawn するにせよ
    • 1 プロセス死んだだけで全部が再起動されるのは過剰では?
    • そもそも他とくらべてツールの系統が違う
      • foreman はシステムに 1 つのサービスマネージャーってわけではない
      • 他はシステムに 1 つのサービスマネージャーって感じ
      • 次のような複数の foreman を起動する構成を考えるとこれはこれでありかも?
        • systemd
          • foreman (serviceA) -> serviceA
          • foreman (serviceB) -> serviceB
      • 他のツールだと次のようになって systemd から見ると 1 つのサービスに見える
        • systemd
          • supervisor
            • serviceA
            • serviceB
  • systemd でできるなら systemd でもいいんじゃないか?
    • テンプレートユニットや PartOf や Wants を使えばなんとかなりそう
    • プロセスの数だけ Wants に羅列する必要があるのは辛いか

ほかのツールみたいなおもしろ機能なないけれども(WebUI とか)、どうせ systemd は居るわけなので、systemd でやるのがよいだろうか。

Munin で PING 監視する

Munin マスターで次のようにプラグインのシンボリックリンクを作成します。

sudo ln -s /usr/share/munin/plugins/ping_ /etc/munin/plugins/ping_192.168.33.10

プラグインを実行してみます。

munin-run ping_192.168.33.10

パケットロスト率と応答時間が結果として得られます。

packetloss.value 0
ping.value 0.000605

なお、100% ロストすると ping.value が結果に現れませんでした。

packetloss.value 100

プラグインのコンフィグ確認します。

munin-run ping_192.168.33.10 config

次のように結果が得られます。

graph_title IPv4 ping times to 192.168.33.10
graph_args --base 1000 -l 0
graph_vlabel roundtrip time (seconds)
graph_category network
graph_info This graph shows ping RTT statistics.
ping.label 192.168.33.10
ping.info Ping RTT statistics for 192.168.33.10.
packetloss.label packet loss
packetloss.graph no

パケットロスト率はグラフ無しのようです。また、hostname が含まれていないため、このままだと Munin マスターの localhost への監視として表示されてしまうので、プラグインのコンフィグ(/etc/munin/plugin-conf.d/)で次のようにホスト名を指定します。

[ping_192.168.33.10]
host_name web-ping
env.ping_args -c 3 -w 5
env.packetloss_critical 50

さらに、マスターの設定(/etc/munin/conf.d/)で、↑で指定したホストの設定を追加します。

# 内部監視
[example;web]
address 192.168.33.10
use_node_name yes

# 外形監視
[example;web-ping]
address 127.0.0.1
use_node_name no

このとき、もともと設定している内部監視のホスト名(↑の例では web)とは異なる名前にする必要があります。

munin-node をリスタートして反映します。

sudo systemctl restart munin-node.service

これで PING 監視も行われるようになりますが、内部監視と外形監視を別々のホストとして設定しているので Munin の画面上でも別々にされてしまいます。

01.png

あるいは、次のようにグラフ無しにしてしまう?

[example;web-ping]
address 127.0.0.1
use_node_name no
graph no

が、これだと Web 画面から直近の結果すら確認できないし、アラートが発生しても Problems のところに何も表示されなくて不便です。


なんとなく、これまで Nagios で 1 つのホストに対して外形監視と内部監視をまとめて設定するようにしてきたので(check_nrpecheck_pingcheck_http が 1 つのホストの設定に混在)、Munin で別々のホストとして表示されてしまうことに違和感があるのですが・・・むしろ外形監視は特定のホストには紐つかないものとして、例えば external のような仮のホストへの監視、みたいにすると良いのでしょうか。

設定ファイル的には次のような感じ。

/etc/munin/plugin-conf.d/

[ping_192.168.33.*]
host_name external
env.ping_args -c 3 -w 5
env.packetloss_critical 50

/etc/munin/conf.d/

[example;external]
address 127.0.0.1
use_node_name no

画面的には次のような感じ。

02.png

あるいは、そもそも Munin で PING 監視とかはせずに Nagios とかと併用するのが良いような気もする。

Munin をさらに触ってみた

社内で使っているサーバに munin-node を入れてリソース監視するようにしてみたときのメモ。

最初にちょっと触ってみたときの内容は↓こちら。

Munin マスターの設定ファイルはなるべく小さくした

Munin マスターの設定ファイルには監視対象の Munin ノードの情報を記述する必要がありますが、下記のように、グループ・ノード名、IP アドレス、などの、どうしても必要そうなものだけを記述しました。

[are-servers;sore-server]
use_node_name yes
address 192.0.2.123

通知の閾値は、後述の通り Munin ノード側のプラグインの設定で指定することができます。

通知先は、Munin マスターの設定ファイルのグローバルセクションで contact を登録しているだけです。

contact.mail-ore.command mail -s "Munin ${var:group}::${var:host}" -r sys+munin@example.com ore@example.com
contact.mail-ore.max_messages 10
contact.mail-ore.always_send critical

デフォルトの通知先は登録されている contact すべてなので、ノードごとやグループごとに通知先を変えたりしないのであれば、これだけで大丈夫です。

がしかし、実際のプロジェクトではグループで通知先を変える必要がありそうです。

[are-servers;]
contacts mail-ore

[are-servers;sore-server]
use_node_name yes
address 192.0.2.123

あと、warningcritical で通知先を変更したりはできないものなの?(ググるとよく出てくる always_send はそういう意味の設定じゃないはず)

Munin ノードの設定ファイルで通知の閾値を指定

通知の閾値の指定は、ググると大抵 Munin マスターの設定ファイルで指定している例が出てくるのですが、Munin ノードのプラグイン設定ファイルでも指定できます。

/etc/munin/plugin-conf.d/zz-misc.conf

[load]
env.load_warning 3
env.load_critical 6

Munin ノードでプラグインを config で実行すると、この値が確認できます。

munin-run load config | grep -E '(warning|critical)'
#=> load.warning 3
#=> load.critical 6

Munin マスターで同じフィールドに閾値を指定していなければ、この値が閾値として使用されます(マスターで閾値を指定するとそっちが優先されます)。

メモリ使用量の閾値を設定する項目

Cacti の SNMP での監視と比べると、メモリ使用量のグラフが細かく、積み上げグラフと折れ線グラフが一緒になっているため、どれに閾値を設定すれば良いのか判りにくいです。

vim /usr/share/munin/plugins/memory 曰く、データソースは /proc/meminfo で、積み上げグラフの計算式とその意味は次の通り。

  • apps
    • MemTotal - MemFree - Buffers - Slab - PageTables - SwapCached
  • page_tables
    • PageTables
  • swap_cache
    • SwapCached
  • slab_cache
    • Slab
  • cache
    • Cached
  • buffers
    • Buffers
  • unused
    • MemFree
  • swap
    • SwapTotal - SwapFree

unused だとページキャッシュでいずれ 0 に近づいてしまうだろうし、swap も頻繁にスワップイン/アウトしているならともかく単にスワップしているだけなら問題ないこともあるだろうので、閾値を設定するとしたら apps が一番それぽいでしょうか?

また、メモリ使用量の閾値は % でも指定することができます。swap の場合は SwapTotal に対するパーセンテージで、その他は MemTotal に対するパーセンテージです。

env.apps_warning 80% # 80% 以下を正常値とする
env.swap_warning 50% # 50% 以下を正常値とする

なお、Web 画面や通知のメールの中ではバイト数に計算されたものになるので、とても判りにくいです。

MySQL と nginx の監視

MySQL や nginx のメトリクスもデフォで対応しています。

MySQL の監視を有効にするためには perl の DBD::MySQLCache::Cache が必要です。

yum install perl-DBD-MySQL perl-Cache-Cache

nginx の監視を有効にするためには /nginx_statusstub_status を有効にする必要があります。

location /nginx_status {
    stub_status on;
    access_log off;
    allow 127.0.0.1;
    deny all;
}

プラグインの自動有効化

munin-node-configure で、インストールされているプラグインの一覧を表示したり、利用可能なプラグインを表示したり、利用可能なプラグインを有効にするためのコマンドを一覧表示することができます。

インストールされているプラグインと有効/無効を表示

$ munin-node-configure
Plugin                     | Used | Extra information
------                     | ---- | -----------------
acpi                       | no   |
 :
cpu                        | yes  |
 :
if_                        | yes  | eth1
if_err_                    | no   |
 :

利用可能かどうかも一緒に表示する

$ munin-node-configure --suggest
Plugin                     | Used | Suggestions                            
------                     | ---- | -----------                            
acpi                       | no   | no [cannot read []
 :
cpu                        | yes  | yes
 :
if_                        | yes  | yes (+eth0 -eth1)
if_err_                    | no   | yes (+eth0)

プラグインを利用可能にするコマンドを表示する

$ munin-node-configure --shell
ln -s '/usr/share/munin/plugins/if_' '/etc/munin/plugins/if_eth0'
ln -s '/usr/share/munin/plugins/if_err_' '/etc/munin/plugins/if_err_eth0'

--remove-also を付けると利用不可能になったプラグインの削除もできます。

$ munin-node-configure --shell --remove-also
ln -s '/usr/share/munin/plugins/if_' '/etc/munin/plugins/if_eth0'
ln -s '/usr/share/munin/plugins/if_err_' '/etc/munin/plugins/if_err_eth0'
rm -f '/etc/munin/plugins/if_eth1'

プラグインのファミリ

munin-node-configure--families で対象となるプラグインの種類をしていできます。

families には次のようなものがあります(参考)。

  • auto
    • munin-node-configure で自動で有効にできるプラグイン
  • snmpauto
    • --snmp オプション付きで自動で有効にできるプラグイン
  • manual
    • 手動で有効にするプラグイン
  • contrib
    • いわゆる contrib なプラグイン

未指定の場合は、他に指定されているオプションによって対象となる種類が変わります。

  • なし
    • auto,contrib,manual
  • --suggest--shell
    • auto
  • --snmp
    • snmpauto

つまり、--families は指定しなくても概ね良きに計らってくれます。

プロセス監視

プロセス監視には ps_multips が使えますが、どちらも微妙な感じでした。

  • multipspgrep -f -l <name> | grep <regex> | wc -l の結果がメトリクス
    • がしかし pgrep -f -l の結果が CentOS 6 と CentOS 7 で違う
    • CentOS 6 なのか CentOS 7 なのか意識して設定しなければならない
  • ps_family=auto なプラグイン
    • munin-node-configure --shell --remove-also で自動で追加/削除される
    • と言いたいところだが ps_ は未対応
    • そのため、手動で配置しても munin-node-configure で消されてしまう
    • family=manual の間違いなのでは?
    • あるいは autoconf=no なら --remove-also の対象外になるべきなのでは?
    • munin-node-configure 使わずに個別に追加/削除すればいいのだけどうーん

その他

  • Munin ノードのセットアップは Ansible だけで余裕
    • サーバがたくさんあっても自動化で楽勝
    • Munin マスターも同じインベントリに入れれば、マスターへの監視対象の追加も自動化余裕ですが・・・
      • 監視サーバを複数のプロジェクトで共用する文化なので同じインベントリに含めるのは難しそう
  • Zabbix や Sensu なら監視対象の自動登録もできるのでちょっと楽
    • ただまあオートスケールとかでぼこぼこ増えたり減ったりするんじゃないなら Munin でも十分かな
  • やっぱり Cacti と比べてグラフの閲覧がしょぼい感
    • /var/lib/munin/datafile とかをどうにかして自前で閲覧画面は作れないかな?

Munin を触ってみた

Mackerel のような SaaS のリソース監視サービスが流行ってそうな中、あえていまさら Munin を触ってみました。

ところで Munin のドキュメント、公式っぽいものが下記の 2 箇所にあるっぽいんですけど、どういうことなの?

Attention: All content still relevant for Munin 2.x will be moved from here to Munin Guide. Pages that are in transit or have already moved, will get an info box on top (like here), be set to "Read only" and later will be archived or purged.

移行中? らしいです。とりあえず後者の方が新しいっぽいです。

用語とか

  • Munin マスター
    • 監視する側
    • Munin ノードから定期的にメトリクスを取得して RRD に保存
    • 閾値をチェックして必要なら通知する
    • 閲覧用の Web 画面
  • Munin ノード
    • 監視される側
    • エージェントとして munin-node が動く
  • Munin プラグイン
    • Munin ノードでメトリクスを取得するスクリプト
    • SNMP だと別のホストの SNMP エージェントからメトリクスを取得することもある

とりあえず使ってみる

Vagrantfile

とりあえず使ってみるために、次のような Vagrant 環境を使います。

Vagrant.configure(2) do |config|
  config.vm.box = "bento/centos-7.1"
  config.vm.define "web" do |config|
    config.vm.hostname = "web"
    config.vm.network "private_network", ip: "192.168.33.10", virtualbox__intnet: "munin"
  end
  config.vm.define "munin" do |config|
    config.vm.hostname = "munin"
    config.vm.network "forwarded_port", guest: 80, host: 1234
    config.vm.network "private_network", ip: "192.168.33.11", virtualbox__intnet: "munin"
  end
  config.vm.provision "shell", inline: <<-SHELL
    sudo yum -y install vim-enhanced mailx nc
  SHELL
  config.vm.provider :virtualbox do |v|
    v.linked_clone = true
  end
end

Munin ノード

監視される側です。munin-node を epel からインストールします。

sudo yum -y install epel-release
sudo yum -y install munin-node

設定ファイルを編集します。

sudo vim /etc/munin/munin-node.conf

下記を追記して監視する側(Munin マスター)からのアクセスを許可します。

cidr_allow 192.168.33.11/32

munin-node を開始します。

sudo systemctl enable munin-node
sudo systemctl start  munin-node
sudo systemctl status munin-node

試しにロードアベレージを取得してみます。munin-run コマンドでローカルの munin-node から情報を取得できます。

munin-run load

次のようにロードアベレージの値が表示されます。

load.value 0.30

TCP の 4949 ポートでもアクセスできるはずなので試してみます。

echo "fetch load" | nc localhost 4949

次のようにロードアベレージの値が表示されます。

# munin node at localhost.localdomain
load.value 0.30
.

Munin マスター

監視する側です。munin と Web 画面のために Apache もインストールします。

Apache を先にインストールしないと cgi がログの書き込みでパーミッションエラーになったので、同時にインストールしないほうが良いです。

sudo yum -y install epel-release
sudo yum -y install httpd
sudo yum -y install munin

マスターでも munin-node を開始します。munin-node は監視対象のホストで実行するものですが、マスターそのもののリソース監視も行いたいのと、後述する SNMP 監視も試すので、munin-node をマスターでも実行します。

sudo systemctl enable munin-node
sudo systemctl start  munin-node
sudo systemctl status munin-node

Apache を開始します。

sudo systemctl enable httpd
sudo systemctl start  httpd
sudo systemctl status httpd

Basic認証の ID/PW を設定します。

sudo htpasswd -bc /etc/munin/munin-htpasswd munin pass

設定ファイルを作成します。

sudo vim /etc/munin/conf.d/example.conf

このディレクトリに置いた設定ファイルは自動的に読み込まれます(/etc/munin/munin.confincludedir /etc/munin/conf.d のように指定されています)。

次のように監視対象のノードを追記します。

[example;web.example.com]
address 192.168.33.10
use_node_name yes

TCP 経由で監視対象ノードから監視項目の値が取れることを確認します。 もし、値が取れなければ何かが間違っています。

echo "fetch load" | nc 192.168.33.10 4949

手動で munin-cron を実行します。

sudo -u munin munin-cron

ブラウザで http://localhost:1234/munin/ を開くと Basic 認証が聞かれるので munin:pass を入力すると Munin の画面が表示されます。

通知

監視項目に閾値を設定して、閾値を超えらたメールで通知されるように設定してみます。

Munin マスターで監視の設定を変更します。

sudo vim /etc/munin/conf.d/example.conf

次のように変更します。

contact.ore-no-mail.command mail -s "Munin ${var:group}::${var:host}" -r munin@example.com ore@example.com
contact.ore-no-mail.always_send critical

[example;web.example.com]
address 192.168.33.10
use_node_name yes
cpu.user.critical 50
contacts ore-no-mail

Munin ノードでCPU使用率を高めてみます。

while :; do :; done

しばらく待つと次のような通知が飛んできます

example :: web.example.com :: CPU usage
    CRITICALs: user is 100.00 (outside range [:50]).

Munin マスターの Web 画面でも Critical として表示されます。


監視の設定をざっくり説明します。

contact.ore-no-mail.command mail -s "Munin ${var:group}::${var:host}" -r munin@example.com ore@example.com
  • ore-no-mail という名前で通知先を設定します
  • mail から先は通知時に実行するコマンドです
  • ${var:host} のような変数名が使用可能です
contact.ore-no-mail.always_send critical
  • 常に通知する障害レベルを指定します
  • この例では critical のみが常に通知されます
  • 前回と状態が変わっていなくても通知するという意味です
  • つまり閾値を超えている間、通知され続けます
  • デフォルトは未設定です
  • ググると出てくる日本語の説明は間違っているものが多い気がします
[example;web.example.com]
:
cpu.user.critical 50
  • このノードの cpu プラグインの user フィールドの critical の閾値を 50 にします
[example;web.example.com]
:
contacts ore-no-mail
  • このノードの通知先として ore-no-mail を設定します
  • デフォルトは contact で設定されている通知先全部です

SNMP で監視

Munin ノードに net-snmp をインストールします。

sudo yum -y install net-snmp net-snmp-utils

それっぽく設定します。

sudo tee <<'EOS' /etc/snmp/snmpd.conf
com2sec s_default default oreore
group g_all_ro v1  s_default
group g_all_ro v2c s_default
view v_all included .1
access g_all_ro "" any noauth exact v_all none none
load 12 14 14
EOS

snmpd を起動します。

sudo systemctl enable snmpd.service
sudo systemctl start snmpd.service

Munin マスターに net-snmp-utils を入れます。

sudo yum -y install net-snmp-utils

マスターからノードの snmpd にアクセスできることを確認します。

snmpwalk -v1 -c oreore 192.168.33.10 la

/etc/munin/plugin-conf.d/zzz-snmp に SNMP のコミュニティ名などを設定します。 このディレクトリのファイルは自動で全部読まれるのでファイル名はなんでもいいです。

sudo tee <<'EOS' /etc/munin/plugin-conf.d/zzz-snmp
[snmp_192.168.33.10_*]
env.community oreore
env.version 1
EOS

この後 Munin マスターの /etc/munin/plugins/ にプラグインのシンボリックリンクを作るのですが、munin-node-configure を使うと設定可能な項目を一覧表示できます。

munin-node-configure --snmp 192.168.33.10 --snmpcommunity oreore
Plugin                     | Used | Suggestions
------                     | ---- | -----------
snmp__cpuload              | no   | yes (+192.168.33.10)
snmp__df                   | no   | yes (+192.168.33.10)
snmp__df_ram               | no   | yes (+192.168.33.10)
snmp__fc_if_               | no   | no
 :

--shell オプションを付けると /etc/munin/plugins/ へシンボリックリンクを作成するためのコマンドが表示されます。

munin-node-configure --snmp 192.168.33.10 --snmpcommunity oreore --shell
ln -s '/usr/share/munin/plugins/snmp__cpuload' '/etc/munin/plugins/snmp_192.168.33.10_cpuload'
ln -s '/usr/share/munin/plugins/snmp__df' '/etc/munin/plugins/snmp_192.168.33.10_df'
ln -s '/usr/share/munin/plugins/snmp__df_ram' '/etc/munin/plugins/snmp_192.168.33.10_df_ram'
 :

これを bash にパイプすればシンボリックリンクが作成されます。

munin-node-configure --snmp 192.168.33.10 --snmpcommunity oreore --shell | sudo bash -x

munin.conf を編集します。

sudo vim /etc/munin/conf.d/example.conf

次のように追記します。マスターから見てローカルの munin-node が SNMP で監視対象のノードから情報を取得するので address127.0.0.1 です。セクションの 192.168.33.10 が SNMP で接続する先です。

[example;192.168.33.10]
address 127.0.0.1

マスターの munin-node を再起動します。

sudo systemctl restart munin-node

munin-cron を手動で実行します。

sudo -u munin munin-cron

ブラウザで見てみると snmp で取得した項目が増えています。

この手順だと 192.168.33.10 という名前の名前で Munin の画面上で表示されますが、次のように設定すると任意の名前にできます。

/etc/munin/plugin-conf.d/zzz-snmp

[snmp_192.168.33.10_*]
env.community oreore
env.version 1
host_name web-by-snmp

/etc/munin/conf.d/example.conf

[example;web-by-snmp]
address 127.0.0.1

SNMP の監視で通知を設定するときは、プラグイン名の ._ に読み替えて記述します。例えば、ロードアベレージなら次のように指定します。

[example;web-by-snmp]
address 127.0.0.1
snmp_192_168_33_10_load.load.critical 3
contacts ore-no-mail

snmp_192_168_33_10_load という名前は、Munin の Web 画面でそのグラフを表示したときの URL に、load の方は、その画面の下の方にあるテーブルの Internal name です。

Native SSH Transport

Munin マスターからノードへの接続を SSH にすることができます。

Munin マスターから Munin ノードへ munin アカウントでログインすることになるのですが、パッケージインストール時のデフォだと munin アカウントのログインシェルが /sbin/nologin になっていて SSH でのログインが不可能です。

なので、Munin ノードの munin アカウントのログインシェルを chsh で適当なシェルに変更します。

sudo chsh -s /bin/bash munin

Munin ノードで公開鍵を配置するディレクトリを作成してそれっぽくパーミッションやオーナーを設定します。

sudo mkdir /var/lib/munin/.ssh
sudo touch /var/lib/munin/.ssh/authorized_keys
sudo chmod 700 /var/lib/munin/.ssh
sudo chmod 600 /var/lib/munin/.ssh/authorized_keys
sudo chown -R munin. /var/lib/munin/.ssh

Munin マスターで鍵ペアを作成して公開鍵を Munin ノードに転送します。

sudo -u munin -H ssh-keygen
sudo cat /var/lib/munin/.ssh/id_rsa.pub |
  ssh vagrant@192.168.33.10 sudo -u munin tee /var/lib/munin/.ssh/authorized_keys

Munin マスターからノードにログインできることを確認します。

sudo -u munin -H ssh 192.168.33.10 uname -n

Munin マスターでノードへの接続設定を変更します。

sudo vim /etc/munin/conf.d/example.conf

次のように変更します。

[example;web.example.com]
address ssh://192.168.33.10 /bin/nc 127.0.0.1 4949
use_node_name yes

Munin マスターで munin-cron を手動で実行します。

sudo -u munin munin-cron

Munin ノードでログを確認してみます。

tail /var/log/munin-node/munin-node.log

ローカルホストからの接続になっています。

2015/04/23-21:39:06 CONNECT TCP Peer: "[127.0.0.1]:49566" Local: "[127.0.0.1]:4949"

.

うーん? SSH しかポートが空いてないとか、中継サーバを経由しないとアクセスできないとかの場合に使うものなのでしょうか。

監視間隔を変更

デフォだと監視間隔は 5 分なので 1 分に縮めてみます。

Munin マスターの設定を変更します。

sudo vim /etc/munin/munin.conf

次のように追記します。

update_rate 60

cron の設定も変更します

sudo vim /etc/cron.d/munin

元は 5 分ごとになっているので、1 分ごとに変更します

*/1 * * * *     munin test -x /usr/bin/munin-cron && /usr/bin/munin-cron

crond をリロードして設定を反映します。

sudo systemctl reload crond.service

これで 1 分ごとに監視されるようになりました。

と、言いたいところですが、1回でも munin-cron を実行したことがあると変更しても意図したとおりにはならなさそうです。

どうしても変更したければ rrd ファイルの変換が必要なようです。

update_rate は man しても出てこないので使えないのかなと思ったのですが、このような事情によりアンドキュメントなのかもしれません(適当)。

監視項目の削除

/etc/munin/plugins にあるシンボリックリンクが、そのホストの監視項目(プラグイン)です。

なので /etc/munin/plugins にあるシンボリックリンクを削除すると、その項目は監視されなくなります。

プラグインの実体は /usr/share/munin/plugins/ にあります。

例えば Postfix の監視を削除してみます。

sudo rm /etc/munin/plugins/postfix_mail*
sudo systemctl restart munin-node

これで、Postfix に関する監視は行われなくなります。

もしくは /etc/munin/munin-node.confignore_file で無視するプラグインを指定できます。

sudo vim /etc/munin/munin-node.conf

次のように正規表現で指定します。

ignore_file ^postfix_

ファイル名がアンスコで終わるプラグインは、リンク名が引数として使用されます。

例えば /usr/share/munin/plugins/if_/etc/munin/plugins/if_enp0s3 という名前のシンボリックリンクになっていますが、この場合 enp0s3 がプラグインの引数として用いられます。

また、SNMP 関連のプラグインは、プラグイン名にアンスコが 2 つ含まれており、その部分に SNMP エージェントのホスト名や IP アドレスが入ります。

例えば、/usr/share/munin/plugins/snmp__cpuloadsnmp_192.168.33.10_cpuload のようにリンクされます。

プラグインの作成

自分でプラグインを作ってみます。Munin ノードで次のようにスクリプトを作成します。

sudo vim /usr/local/bin/ore.sh
#!/bin/bash
if [ "$1" = "autoconf" ]; then
    echo yes
    exit 0
fi

if [ "$1" = "config" ]; then
    echo 'graph_title ore no title'
    echo 'graph_args --base 1000 -l 0'
    echo 'graph_vlabel ore'
    echo 'graph_scale no'
    echo 'graph_category oreore'
    echo 'are.label are'
    echo 'are.min 0'
    echo 'are.draw AREA'
    echo 'are.type GAUGE'
    exit 0
fi

echo "are.value 25"

プラグインのディレクトリにシンボリックリンク作成します。

sudo chmod +x /usr/local/bin/ore.sh
sudo ln -s /usr/local/bin/ore.sh /etc/munin/plugins/ore

munin-run でプラグインを実行してみます。

munin-run ore

次のように値が得られます。

are.value 25

ノードの munin-node を再起動します。

sudo systemctl restart munin-node.service

しばらく待ってから Munin マスターをブラウザで表示すると項目が増えています。

テンプレートを変更

Bootstrap ベースのテンプレートに差し替えます。Munin マスターで munin-monitoring/contrib をダウンロードします。

mkdir /tmp/munin-contrib
wget https://github.com/munin-monitoring/contrib/archive/master.tar.gz -O - |
  tar xzf - -C /tmp/munin-contrib --strip-components=1

テンプレートと静的ファイルを Munin のディレクトリに上書きします。

sudo rsync -av /tmp/munin-contrib/templates/munstrap/templates/ /etc/munin/templates/
sudo rsync -av /tmp/munin-contrib/templates/munstrap/static/    /etc/munin/static/

既に作成されているファイルを削除して munin-cron を手動実行します。

sudo rm -rf /var/www/html/munin/*
sudo -u munin munin-cron

Munin マスターをブラウザで表示すると見た目が Bootstrap 風になっています。

CGI

デフォでは munin-cron の実行時に HTML やグラフ画像が作成されています。

ll /var/www/html/munin/example/web.example.com

監視対象が増えてくるととても重いので、CGI でオンデマンドに HTML やグラフ画像が作成されるように変更します。

まず、Munin マスターに munin-cgi をインストールします。

sudo yum -y install munin-cgi

Apache を再起動します。

sudo systemctl restart httpd

Munin の設定を変更します。

sudo vim /etc/munin/munin.conf

下記の箇所を変更します。cron ではなく cgi でグラフや html を作る、という意味です。

graph_strategy cgi
html_strategy cgi

生成されている HTML ファイルを削除して munin-cron を手動で実行します。

sudo rm -fr /var/www/html/munin/*
sudo -u munin munin-cron

生成されたファイルを確認してみると static しかないことがわかります。

ll /var/www/html/munin/

ブラウザで http://localhost/ を開くと(http://localhost/munin/ ではなく)、Munin の画面が表示されます。

雑感

お手軽に使えるのが良いですね。

  • インストールが簡単
    • epel から yum で入れられる
    • Cacti も yum で入れれるけど MySQL とかも必要だし
  • 監視サーバの設定が簡単
    • 監視サーバには設定ファイルを置くだけ
    • 逆に GUI での設定は無いけど困らない
    • Cacti だと GUI なのでかなり辛い(CLI もあるけど使いにくい)
  • 監視対象のサーバの設定も簡単
    • munin-node をインストールしてプラグインへのシンボリックリンクを作成するだけ
    • Cacti でも snmpd をインストール&設定するだけなので簡単といえば簡単
  • カスタム監視項目が簡単
    • 簡単なスクリプト1個で項目を追加できる
    • Cacti だと監視項目の追加がとてもつらい
  • SNMP にも対応
    • 既存のサーバやネットワーク機器の監視にも導入しやすい
  • 閾値によるアラートをデフォで対応
    • Cacti でもプラグインでできるけどとても面倒です

ただ、Cacti と比べると閲覧画面の機能がかなり劣っているようにも感じました。

例えば Cacti だと次のようなことが出来たのですが、静的に出力するのが基本な Munin ではそういうのができなさそうです。

  • 表示するグラフの一覧を設定としてあらかじめ作成しておけたり
  • ホスト名の部分一致で条件指定してグラフをずらーっと並べたり
  • さらに任意の時間幅を指定してグラフをずらーっと並べたり

もうちょい突っ込んだ説明

munin.conf

munin.conf は下記の3種類のセクションを記述します。

  • 1つのグローバルセクション
  • ゼロ以上のグループのセクション
  • 1つ以上のホストのセクション

設定ファイルの構成は例えば次のようになります。

# グローバルセクション

[localhost]
# localhost グループの localhost ホストのセクション

[foo.example.com]
# example.com グループの foo.example.com ホストのセクション

[example.com;bar.example.com]
# example.com グループの bar.example.com ホストのセクション
# ↑と同じだがグループを明示的に指定している

[groupname;]
# groupname グループのセクション
# このグループすべてに適用される設定を記述できる

[groupname;baz.example.com]
# groupname グループの baz.example.com ホストのセクション

グループのセクションやホストのセクションには、次の3種類のディレクティブが記述できます。

  • ノードのディレクティブ
  • プラグインのディレクティブ
  • フィールドのディレクティブ

ノードのディレクティブは、これまでの例で書いてきた address とか use_node_name とかです。

プラグインのディレクティブは PLUGIN.DIRECTIVE <VALUE> の形式で記述します。例えば cpu.contacts ore-no-mail のように特定のプラグインで通知の宛先を指定することができます。

フィールドのディレクティブは PLUGIN.FIELD.DIRECTIVE <VALUE> の形式で記述します。例えば cpu.user.critical 50のように特定のプラグインの特定のフィールドの閾値を指定できます。

詳細は下記。

munin-node.conf

munin-node.confmunin-node (Munin のエージェント) の設定ファイルです。

アクセス制御とか無視するプラグインとかを設定できます。

詳細は下記。

plugin-conf.d

/etc/munin/plugin-conf.d にはプラグインの設定ファイルを設置します。

ここにはパッケージからインストールされたファイルが幾つか配置されています。それらのファイルを編集するとアップデートで上書きされてしまうかもしれないため、その代わりに zzz-myconf のようなファイルで設定を上書きします(ファイルはアルファベット順で読まれる)。

設定ファイルは[plugin-name] の形式でプラグインごとにセクションを記述します。プラグイン名の先頭または終端はワイルドカード * にすることができます(両方や中間は不可)。

上の例で行ったように、特定のホストの SNMP のコミュニティ名などを一括で設定したい場合は下記のようにワイルドカードで指定します。

[snmp_192.168.33.10_*]
env.community oreore
env.version 1

設定可能な項目は下記のガイドを参照してください。

env.var <variable content> でプラグインの環境変数を設定できます。どのようなものが設定できるかはプラグインによって異なります。詳細はプラグインのドキュメントで確認できます。

munindoc snmp__cpuload

Please see 'perldoc Munin::Plugin::SNMP' for further configuration information. とのことなので、

perldoc Munin::Plugin::SNMP

snmp 関連のプラグインの共通の情報が表示されました。

munin-cron

munin-cron は下記の 4 つのスクリプトを実行します。

  • /usr/share/munin/munin-update
    • メトリクス値を取得して保存
  • /usr/share/munin/munin-limits
    • 閾値をチェック
  • /usr/share/munin/munin-html
    • html を生成
    • html_strategycgi なら何もしません
  • /usr/share/munin/munin-graph --cron
    • グラフを生成
    • graph_strategycgi なら何もしません

munin-node が返すホスト名

1つの munin-node は複数のホストの情報を提供することができます。例えば↑で設定したような構成だと、Munin マスターで実行されている munin-nodelocalhost.localdomainweb-by-snmp の2つのホストの情報を提供しています。

$ echo nodes | nc localhost 4949 | tail -n +2
localhost.localdomain
web-by-snmp
.

この名前はプラグインに config を付けて実行すると host_name で得られます。

$ munin-run snmp_192.168.33.10_cpuload config | grep host_name
host_name 192.168.33.10

しかし snmp ではない普通のプラグインだと host_name が含まれません。

$ munin-run cpu config | grep host_name

この場合は munin-node そのものの名前になるのですが、その値は /etc/munin/munin-node.conf で指定されています。

host_name localhost.localdomain

もし未設定なら自動的にローカルホストの名前が解釈されます。

Munin マスターが munin-node から取得するデータのホスト名

Munin マスターの設定ファイルで次のように設定したとします。

[localhost]
address 127.0.0.1
use_node_name yes

[example;web.example.com]
address 192.168.33.10
use_node_name yes

[example;web-by-snmp]
address 127.0.0.1

角括弧 [...] で指定しているものは、Munin の Web 画面で表示されるグループ名やホスト名です。

address で指定しているものは、Munin マスターが接続する munin-node のアドレスです。

munin-node は複数のホストの情報を提供するので、Munin マスターが Munin ノードに接続した後、どのホストの情報が欲しいのかを指定する必要があります。

デフォルトでは角括弧 [...] で指定しているホスト名(セミコロン ; の右側)ですが、use_node_name yes の場合は munin-node への接続時に munin-node が名乗った名前をそのまま使います。

なので、

[localhost]
address 127.0.0.1
use_node_name yes

127.0.0.1munin-node に接続して、munin-node が名乗ったホスト名のデータを取得します。 取得したデータは localhost グループの localhost のものとして記録されます。

[example;web.example.com]
address 192.168.33.10
use_node_name yes

192.168.33.10munin-node に接続して、munin-node が名乗ったホスト名のデータを取得します。 取得したデータは example グループの web.example.com のものとして記録されます。

[example;web-by-snmp]
address 127.0.0.1

127.0.0.1munin-node に接続して、web-by-snmp のデータを取得します。 取得したデータは example グループの web-by-snmp のものとして記録されます。

参考になるリンク