muninでMariaDB10.0.4を監視してたら、
情報がほとんどあつまっていなかった。
munin自体はepelからインストールしたのだが、
これに内包されている「mysql_」プラグインはMySQL5.1レベルのものまでしかサポートしていないため、
以下にあるファイルで上書きする必要がある。
このファイルで上書き、
1行目の
#!@@PERL@@
を
#!/usr/bin/perl
に直したら、MariaDB10.0.4でも問題なく動いた。
以上
アーカイブ「2016年07月」
remiレポジトリからインストールしたredis3.2でredis-cliを使うと、
コマンドアシスト（ヒント）が効くようだ。
たとえば、zrevrageを打ちたいとき、
zとうつと、アシストが出て、タブ押下で補完できる。
redisのコマンドって、なかなか覚えられないと思うが、
アシストがあると覚えやすくていいと思う。
以上
monitというとプロセス監視をしてくれるだけのイメージがあったが、
深く触ってみると、こいつはすごいなと思った。
基本的にmonitあれば大半のことは事足りると思う。
ちなみに環境は、centos7で、monitはepelレポジトリからインストールしました。
monitの便利なところとして、以下があげられる。
- プロセスの死活監視（ダウンしてくれれば、勝手に起動してくれるし、勝手に起動しない形も可能。DBなんかは勝手に起動して問題あるケースもあるよね？）
- 閾値と発砲の関連付け
- SMTPを使った発砲機能（リトライ機能もある）
- web管理画面
さらに、m/monitをつかえば、情報の集約も可能となる。
（有料だけど、買い切りでそれほど高くないのは、良心的）
クラウド環境では、かなりの監視ツールがあるが、
こねたことはできないので（できても意外に金がかかる。。）、
monit（もしくはm/monit）を併用すると、結構安心して夜も眠れる環境が出来そう。
どこかで、monitの設定を書いてみようと思う。
以上
ansibleのベストプラクティスを理解するのに時間がかかったが、
実案件の構築を通して、なんとなくわかってきた。
個人的な所感を表現すると、
「環境・特性・筐体ごとに役割を分割し、変数を割り当てる」
ということになる。
言葉で表すと、若干意味不明なので、例を書いてみる。
＜例＞
あるWEBサイトを作る場合、
サービス側と管理側でシステムが分かれるケースが多いだろう。
その場合、サービス側ではアクセスが多く、
参照が多いのであれば、DBに加えて、様々なキャッシュも併用する。
同時にwebサーバではkeepaliveを強くしたり、画像のキャッシュを行うこともあるだろう。
反対に、管理側では、アクセス人数が限られていることもあり、
キャッシュは使わないし、正確なデータ提供が求められる。
＜サービス側の構成＞
例えば、
- webサーバ2台 → apache,phpが必要
- cacheサーバ2台 → memcachedが必要
- dbサーバ2台（master、slave） → mysqlが必要
というようなケースを考えてみよう。
そして、
- 本番環境（production）
- 確認環境（staging）
- テスト環境（test）
という環境があるとする。
という状況において、
本番のインベントリファイルは以下のようになる。
inventry-service-production.ini
# ---------- # servers # ---------- [servers-service-web] service-production-web01 service-production-web02 ### ↑のセクションは、webサーバとしてのグルーピング [servers-service-cache] service-production-cache01 service-production-cache02 ### ↑のセクションは、cacheサーバとしてのグルーピング [servers-service-db] service-production-db01 service-production-db02 ### ↑のセクションは、dbサーバとしてのグルーピング # ---------- # grouping # ---------- [servers-service:children] servers-service-web servers-service-cache servers-service-db ### ↑のセクションは、全体のグルーピング # ---------- # environment # ---------- [env-service-production:children] servers-service-web servers-service-cache servers-service-db ### ↑のセクションは、本番環境全体のグルーピング [env-service-production-web:childeren] servers-service-web ### ↑のセクションは、本番環境webサーバのグルーピング [env-service-production-cache:childeren] servers-service-cache ### ↑のセクションは、本番環境cacheサーバのグルーピング [env-service-production-db:childeren] servers-service-db ### ↑のセクションは、本番環境dbサーバとしてのグルーピング
この状態において、
必要なgroup_vars以下のファイルは以下の通りとなる。
- servers-service.yml
- env-service-production.yml
- env-service-production-web.yml
- env-service-production-cache.yml
- env-service-production-db.yml
1のファイルに書かれる設定は、「サービス側共通設定」である。
つまり、環境や種別が変わっても、必ず設定されるべきものである。
例えば、sshの設定などは、比較的このケースにあたるだろう。
（当然、all.ymlでもよい。ただし、all.ymlは、サービス側・管理側での共通設定という位置づけの方がよいと思う）
2のファイルに書かれる設定は、「本番環境サービス側共通設定」である。
つまり、本番環境のすべての筐体に設定されるべきものである。
例えば、本番環境のみ監視ツールを入れたい場合などのは、このケースにあたるだろう。
3のファイルに書かれる設定は、「本番環境のサービス側webサーバでの共通設定」である。
ここでは、apacheやphpの設定がそれにあたる。
どうように、4、5も解釈できるだろう。
さらにいうと、dbサーバでは、masterとslaveがわかれるが、
これはhost_varsを使って、さらに筐体ごとに設定をわけてやればよい。
ansibleは奥が深い。
設定された変数の適用順番、マージ方法、上書き、予約語（関数）衝突もあり、
なかなかうまくいかないだろうが、
このあたりを抑えておくと、幅が広がる感じがすると思う。
管理側については、
省略するが、大筋この流れでかけるはず。
以上