アーカイブ「2016年07月」

muninでMariaDB10.0.4を監視してたら、

情報がほとんどあつまっていなかった。

 

munin自体はepelからインストールしたのだが、

これに内包されている「mysql_」プラグインはMySQL5.1レベルのものまでしかサポートしていないため、

以下にあるファイルで上書きする必要がある。

 

https://github.com/munin-monitoring/munin/blob/8abb3faf7865af125ecc18b4feece35c59c90fd9/plugins/node.d/mysql_.in

 

このファイルで上書き、

1行目の


#!@@PERL@@


#!/usr/bin/perl

に直したら、MariaDB10.0.4でも問題なく動いた。

 

以上

投稿日時:2016年07月29日 23:20   カテゴリー:mariadb, rdb, server   [コメントがあればどうぞ]

remiレポジトリからインストールしたredis3.2でredis-cliを使うと、

コマンドアシスト(ヒント)が効くようだ。

 

たとえば、zrevrageを打ちたいとき、

zとうつと、アシストが出て、タブ押下で補完できる。

 

redisのコマンドって、なかなか覚えられないと思うが、

アシストがあると覚えやすくていいと思う。

 

以上

投稿日時:2016年07月29日 23:11   カテゴリー:redis   [コメントがあればどうぞ]

monitというとプロセス監視をしてくれるだけのイメージがあったが、

深く触ってみると、こいつはすごいなと思った。

基本的にmonitあれば大半のことは事足りると思う。

ちなみに環境は、centos7で、monitはepelレポジトリからインストールしました。

 

monitの便利なところとして、以下があげられる。

  • プロセスの死活監視(ダウンしてくれれば、勝手に起動してくれるし、勝手に起動しない形も可能。DBなんかは勝手に起動して問題あるケースもあるよね?)
  • 閾値と発砲の関連付け
  • SMTPを使った発砲機能(リトライ機能もある)
  • web管理画面

さらに、m/monitをつかえば、情報の集約も可能となる。

(有料だけど、買い切りでそれほど高くないのは、良心的)

 

クラウド環境では、かなりの監視ツールがあるが、

こねたことはできないので(できても意外に金がかかる。。)、

monit(もしくはm/monit)を併用すると、結構安心して夜も眠れる環境が出来そう。

 

どこかで、monitの設定を書いてみようと思う。

 

以上

投稿日時:2016年07月11日 00:46   カテゴリー:server   [コメントがあればどうぞ]

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以下のファイルは以下の通りとなる。

 

  1. servers-service.yml
  2. env-service-production.yml
  3. env-service-production-web.yml
  4. env-service-production-cache.yml
  5. env-service-production-db.yml

 

1のファイルに書かれる設定は、「サービス側共通設定」である。

つまり、環境や種別が変わっても、必ず設定されるべきものである。

例えば、sshの設定などは、比較的このケースにあたるだろう。

(当然、all.ymlでもよい。ただし、all.ymlは、サービス側・管理側での共通設定という位置づけの方がよいと思う)

 

2のファイルに書かれる設定は、「本番環境サービス側共通設定」である。

つまり、本番環境のすべての筐体に設定されるべきものである。

例えば、本番環境のみ監視ツールを入れたい場合などのは、このケースにあたるだろう。

 

3のファイルに書かれる設定は、「本番環境のサービス側webサーバでの共通設定」である。

ここでは、apacheやphpの設定がそれにあたる。

 

どうように、4、5も解釈できるだろう。

 

さらにいうと、dbサーバでは、masterとslaveがわかれるが、

これはhost_varsを使って、さらに筐体ごとに設定をわけてやればよい。

 

ansibleは奥が深い。

設定された変数の適用順番、マージ方法、上書き、予約語(関数)衝突もあり、

なかなかうまくいかないだろうが、

このあたりを抑えておくと、幅が広がる感じがすると思う。

 

管理側については、

省略するが、大筋この流れでかけるはず。

 

以上

投稿日時:2016年07月11日 00:24   カテゴリー:ansible   [コメントがあればどうぞ]