Muninは舞い降りた～リソース監視を通して、運用現場を変える話～

Muninは舞い降りた
- リソース監視を通して、運用現場を変える話-

Munin has landed.
I’m Not Afraid of Anything Anymore

Munin User Group Japan http://munin.jp/
Masahito Zembutsu @zembutsu
Jan 18, 2013 , Infotalk #50

今日のテーマ
TODAY’S RECEIPE

ZABBIXよ、
これがリソース監視だ。

ZABBIXよ、
まちがい

これがリソース監視だ。

そうじゃなくって。。。
m(__)m
（ごめんなさい、ごめんなさい）

今日の4つのキーワード
TODAY’S FOUR KEYWORDS

西高東低
ARTS
Keywords
武
器
τεχνη 神を殺せ

今日のセミナーで共有したい事。
1.【西高東低】○○の出来ない時代に備える

2.【 Q 】なぜ○○を行うのか？

3.【武器】 ○○○○○で○○○○監視

4.【神を殺せ】 ○人○の排除が、道しるべ

…という話しを、今日は中二病テイストで共有いたします

インフラエンジニアでもだから

監視がしたい！

※背景はMuninのグラフを加工しました

リソース監視で仕事を変えた話…？
気がついてみたら、
仕事の変化を

強いられているんだ！

# 1
予測の出来ない時代に備える。
By the Time We Realized It, It Had Already Begun.
■□□□□

もし、Muninが無かったら、
今の私の業務は成立しません。
The Only Thing I Have Left To Guide Me

＼ /

私は誰？
＼丶 i. | / ./ ／
＼ヽ i. .| / / ／
＼ヽ i | / / ／
＼
-‐
Zembutsu Masahito ー
_＿わたしです --
• 前佛雅人 @zembutsu ￣.
二／￣＼
| ＾o＾ |
＝二
￣
-‐ ＼＿／ ‐-

– Solutions Engineer ( 萌えるSE ) ／
/ ヽ＼
• インフラエンジニア的な仕事メイン／
• 株式会社リンク at+link サービス開発部 ( http://www.at-link.ad.jp/ ) 丶＼
／ / / | i, 丶＼
• “技術者に安心と休息を” 提供するホスティング事業者のサポート対応／ / / | i, 丶＼

– オープンソース系・クラウド系コミュニティ活動
• http://pocketstudio.jp/log3/

– 主な職歴
• 2000年 4月～ホスティングのサポート、はじめました。
• 2012年10月～サービス開発部だけど、データセンタ内で色々(ry
『オンプレだけどioDriveさえあれば関係ないよねっ』
• 2013年1月～気がついたら、一次監視や一次対応も行っていたという話 ←New!

鯖を捌く
Ops的、何か
DevOps!

―Don't forget. always, somewhere,
someone is fighting for you.
―As long as you remember her.
Operation you are not alone.

運用
忘れないで、いつもどこかで誰かがあなたの為に戦っている。
彼女を覚えている限り、あなたは一人じゃない。
（出典：魔法少女まどかマギカ最終話「わたしの、最高の友達」）

Monitoring

監視

A HUMAN WORK

ホスティングサービス業務
サーバの形、心の形。見知らぬ、仕様書。光、そして影。
クラウド、来日。変わる業界。まごころを、お客様へ。
DECISIVE BATTLE

障害対応
鳴り止まない電話。静止したデータセンタの中で。
優先度の選択を。電源停止に至る病、そして。
営業、侵入。客先訪問、魂の座。嘘と沈黙。涙。
You can advance.

次世代ニーズに向けた挑戦
特科サポート部隊、誕生。奇跡の価値は。せめて人間らしく。

日本Muninユーザ会
ABOUT MUNIN USER GROUP JAPAN

Munin.jp
• Munin User Group Japan
– http://munin.jp/
• Wiki
– http://munin.jp/wiki/
• Demo
– http://demo.munin.jp/
• メーリングリスト
– http://munin.jp/mailing-list/

WEST-HIGH EAST-LOW
西
高
東
低
低
高

西

WEST-HIGH EAST-LOW
高高
低東
低
1/14(月) 東京都江東区の様子。どこの雪国？
関東平野部は雪降らないはずじゃ…(;´Д`)

なぜ天気予報が当たらないのか
Weather break.

天気予報とは？
参考文献：
『数値予報の歴史、現状、課題』元気象庁気象研究所増田善信
http://www.metsoc.or.jp/kyoikuhukyu/resume/Masuda.pdf

• 天気予報とは
– 天候状態（晴曇雨雪）と、気温、湿度、風向、風速など
– これらの量や状態の時間経過を含めて予測、発表する事

• 正確な天気予報を出すための条件
– 正確な天気図を持つこと
– 天気予報図から正確に天気に翻訳すること

天気予報の歴史
参考文献：
『天気予報の歴史』
http://www.nowden.co.jp/info/tips/infobox018.html

• 天気諺時代（16世紀以前）
• 気象計器時代(17世紀～）温度計・湿度計の発明
• 地上天気図時代(1820年初の地上天気図作成)
• 高層天気図時代(1927年気球による観測成功)
• 数値天気予報時代(現代)

現代の天気予報は万能か？
数値計算の発達により、短
• 1ヶ月以上の長期天気予報は不可能期の天気予報の制度は上が
りました。あくまで短期。
現代の科学を駆使しても、
– ローレンツのバタフライ効果
長期の予報は難しいのです。
『予測可能性-ブラジルでの蝶の羽ばたきは
テキサスでトルネードを引き起こすか』

– 大気運動はカオスであり1ヶ月以上の記憶を持たない

※バタフライ効果（バタフライこうか、butterfly effect）とは、カオス力学系において、通常なら無視できると思われる
ような極めて小さな差が、やがては無視できない大きな差となる現象のことを指す。カオス理論を端的に表現した思
考実験のひとつ、あるいは比喩である。

参考文献：「長期予報はなぜ当たらないか？」
http://wwwoa.ees.hokudai.ac.jp/people/yamazaki/papers/Kohkai2005.pdf

カオス
CHAOS

(」・ω・)」うー!(/・ω・)/にゃー!

仮説
気象観測とサーバ監視は類似
UNDER COMPLUSION OF MONITORING METHOD

現代のカオス

SNS を通して情報が【拡散】され、
まったくピークの読めない時間帯
にアクセスが殺到してしまう環境
が整ってしまいました。

サーバ監視の現在

• アラートで検出できないケースが急増
– SNS向けサービス提供事業者様やWeb系サービス
– 閾値を超えた時には、時既におそし

• 迅速な対応へのニーズ
– 1分あたりの損失が、ケタ違い

• 問題が起こったら、今すぐ対応しなくてはいけない

不幸な事に、事故や機会損失…
• なぜ、障害発生に気がつかない
– アラートが上がらないケース

– 閾値の設定が難しいケース

– アラートが上がったら
もうｵﾜﾀなケース

1.【西高東低】予測の出来ない時代に備える


3.【武器】 ○○○○○で○○○○監視


# 2
何故、監視を行うのか？
This Just Can't Be Right.
■■□□□

なぜ監視を行うのか？
• 異常値の把握
テレホーダイというサービス
（規定時間内のアクセスは子
通話料金が固定）があった頃、
ウェブサーバへのアクセス
ピークは殆どが深夜に集中し
ていました。

これは、とある社内メール
なぜ監視を行うのか？
サーバのトラフィック推移。
【平日の日中】にアクセスが
集中しているというパターン
が分かります。
• 異常値の把握
※もちろん Munin のグラフ。

なぜ迅速な対応を行うのか？
• サービスの安定稼働のため
– ユーザ環境の変化
• SNSやモバイルデバイスの普及により、
意図せぬアクセスのピークが発生しうる

– インフラ環境の変化
• クラウド・コンピューティング技術の普及により、
短時間で多くのリソース常用を把握する必要性

アラートが上がった時
リソース監視があればリソース監視がなければ
• グラフを見るだけで、複数台 • とりあえずログイン
のサーバを同時に状況判断 • ログの調査
• コマンド投入時にログイン • コマンド投入(ps, dstat 等々)

…を、サーバ台数分繰り返し

予測が難しいから、リソース監視
• ピークの見込みが難しい
– アラート設定は意味があるのかどうか、真剣に考えた方が良い。

• アラート処理が目的化していないだろうか
– インシデントに対応するだけの仕事になっていないだろうか？
– 本当にサービスは復旧しているのか？

• 何かあった時、迅速に対応するツール（武器）はあるか？
– リソース監視ツールの有無は重要
– サービスレベルをも左右しうる。


2.【 Q 】なぜ監視を行うのか？

3.【武器】 ○○○○○で○○○○監視


# 3
Muninでリソース監視
Can You Face Your True Server Resoruces?
■■■□□

迅速な状況把握の為に
I Won't Rely On Anyone Anymore

リソース監視とは
サーバ内外におけるリソース情報（CPUやメ
• 変化を記録するモリ、ディスク使用率）は、sar コマンドで
取得出来ます。※要sysstatパッケージ
– sysstat もある種の監視

• さらに、グラフを生成する。通知する。
– 視認性の向上
– 何かが起こった時に、把握できるようになる。
サーバにログインし、ログを確認する前に
「どの時点」で異常が発生したか、推測を
たてることが出来ます。

Munin
Networked Resource Monitoring Tool
http://munin-monitoring.org/
http://munin.jp/

Munin
シャキーン(`･ω･´)

• http://munin-monitoring.org/
– リソース監視ツール
• トレンドの変化を解析できる
• “何が性能を殺しているのか？”が分かる
– プラグアンドプレイな設計
• 標準で、多くのグラフを表示できる
Munin is a networked resource monitoring tool that can help analyze resource trends and
"what just happened to kill our performance?" problems. It is designed to be very plug and
play. A default installation provides a lot of graphs with almost no work.

demo
• http://demo.munin.jp/

• 状況を知るのに便利
– リソース一覧

– ズーミング機能

一覧性

∩＿∩ 人人人人人人人人人人人人人人人人人人人人人人人人人人人人人
／＼／＼＜すごい一体感を感じる。今までにない何か熱い一体感を。＞
| （゜）=（゜） | ＜風・・・なんだろう吹いてきてる確実に、着実に、俺たちのほうに。. ＞
| ●_● | ＜中途半端はやめよう、とにかく最後までやってやろうじゃん。＞
/ ヽ＜ネットの画面の向こうには沢山のサーバがいる。決して一人じゃない。＞
| 〃 ------ ヾ | ＜信じよう。そしてともに戦おう。＞
＼＿＿二＿＿ノ＜障害や過負荷はあるだろうけど、絶対に流されるなよ。＞
ＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹ

敢えて言おう、
リソース監視ツールであると。
Munin is a networked resource monitoring tool.

シンプルかつパワフルな設計思想
• Perl5
• OS
– Linux
• Source code ( version 2.0.10 )
• Binary Package
– Red Hat Enterprise Linux 系 ( EPEL )
– Debian
– openSUSE
– MacOS X
– Windows
• RRDTool

Muninの、すごく単純な構造
Architecture of Munin

比較的単純な構成
• クライアント・サーバーモデル
– cronを使った定期処理
– RRDtoolによるデータ管理・グラフ生成
– munin-nodeがデータを介在

• プラグインでデータ取得
– サーバのシステム・ネットワーク・アプリケーション
– Perl or シェルスクリプト
– 比較的セットアップが簡単

ユーザ視点

サーバ上のHTML&グラフを参照します。
ただそれだけの、シンプルなもの。

もう少し詳しくみてみましょう。

これが、先ほどのデータです。

これが本体(Muninマスタ)の構成です。
Crondによって、データ取得・閾値チェック・
HTML&グラフ生成のプログラムを、逐次実行します。

これは、エージェントである
munin-nodeです。

データ取得は、munin-updateが、
TCP Port 4949 を通して、munin-
nodeと通信します。

munin-nodeでプラグインを呼
び出します。プラグインが、
様々なデータを取得します。

RRDtoolに格納されたデータ(.rrd)を元に、
グラフやHTMLを生成します。
これが、5分に1回実行されます。設定変
更により、1分など任意指定も可です。

Muninの構成
master ( サーバ ) munin-node ( エージェント )
• Perl Libs • Perl Libs
– Munin::Common – Munin::Common
• munin-cron • munin-node
– munin-update – config: munin-node.conf
– munin-limits – Plugins
– munin-html • Tools
– munin-graph – munin-node-configure
• config: munin.conf – munin-cron

データ収集の基本
• munin-node が、プラグイン単位で収集
– Port 4949(TCP) に対するアクセス
– Munin プロトコル
• LIST
• CONFIG

(T_T)4949
• FETCH
• VERSION
• QUIT

データ格納、グラフ生成はRRDtool
• データは rrd 形式 (round robin database)
– /var/lib/munin/<ホスト名>/プラグイン名.rrd
-rw-r--r-- 1 munin munin 50612 10月 18 2010 localhost-cpu-idle-d.rrd
-rw-r--r-- 1 munin munin 50612 10月 18 2010 localhost-cpu-iowait-d.rrd
-rw-r--r-- 1 munin munin 50612 10月 18 2010 localhost-cpu-irq-d.rrd
-rw-r--r-- 1 munin munin 50612 10月 18 2010 localhost-cpu-nice-d.rrd
-rw-r--r-- 1 munin munin 50612 10月 18 2010 localhost-cpu-softirq-d.rrd
-rw-r--r-- 1 munin munin 50612 10月 18 2010 localhost-cpu-steal-d.rrd
-rw-r--r-- 1 munin munin 50612 10月 18 2010 localhost-cpu-system-d.rrd
-rw-r--r-- 1 munin munin 50612 10月 18 2010 localhost-cpu-user-d.rrd

• RRDファイルは、１つにつき約50KByte
– 1プラグインあたり 200KB～必要
– munin-nodeあたり、デフォルトで150～250個前後
(合計8～15MB程度)

Muninが持つ、様々なプラグイン
• システムリソース
– CPU、メモリ、Load Average、ディスク関連
• ネットワーク
– トラフィック、SNMP、HTTP 読み込み時間
• ミドルウェア・アプリケーション
– Apache, Nginx, Sendmail, Postfix, MySQL,
PostgreSQL, MongoDB, memcached, PHP… etc

例: Load Average取得プラグイン
• /etc/munin/plugins/load
– 5分間平均のデータを取得
– シンボリックリンク
• 実体は /usr/share/munin/plugin/load
– シェルスクリプト
echo -n "load.value "
cut -f2 -d' ' < /proc/loadavg
load .value 3.22

トラブルシュート！
TROUBLESHOOTING

Muninは標準で色々取れます
• システムリソース
– CPU使用率、メモリ、Swap、ディスク使用率、IOPS、ディスクのレ
イテンシ、Load Average、スレッド数、vmstat、温度、等々
• ネットワーク
– パケット数、トラフィック、TCP、UDP、netstat、等々
• アプリケーション・データベース
– Apache、Nginx、Tomcat、MySQL、PostgreSQL、sendmail、
Postfix、BIND、等々
サーバにログインすることなく、何が起こっているかが把握できる所がポイントです。

トラブルシュートに役立つ項目
• forks
• processes / threads
• entropy

※予測不能なトラブルや障害発生・攻撃時の
原因切り分けにも役立ちます。

自鯖が不正アクセスを受けた
という話
CRACKER’S ATTACK

とある障害対応事例
• メール増加、サーバの負荷上昇
– これはSendmail が原因と特定

• 直接原因は、とあるCMSに対する攻撃が原因
– 同時に、DNSに対する不正利用も判明

• 状況へ対処
– そして、トラフィックの収束へ
– 対応が正しかったかどうか、グラフから評価

※これら一連の対応に、Muninは欠かせませんでした。

1. Gmailへのメール転送エラー多発
• 普段のメールは、Gmail に転送
– しかし、突然メールが転送されなくなる
• Postmaster宛の、大量エラーメールに気づく

大量のメール配信を行ってい
るため、Gmail側によって規制
されたという内容。

2. Muninで状況確認を開始
• まずはメールの配送状況を確認
キューが24万件に
到達しているのを確認。
通常はあり得ない
事象：2013年1月4日
Sendmailのキュー数
（配送待ちのメール）
が上昇し始める。

同時に fork
rate(プロセスが
フォークした時の
カウント＝プロセ
スの推移変化を見
るときの参考にな
る)が上昇開始。

threads(スレッド
＝１つのプロセス
の中での並列処理
も上昇)
キュー数が増え
た時点で、通常
よりも多いメー
ルの流通が発生
プロセス数に対する
大きな変化は、後日

3.影響範囲の確認 CPUのiowaitが
急上昇(紫部)

Load Average 上昇

HDDのIOPs(秒
あたりInput・
HDDアクセスが Output)上昇
100%

root 4274 0.0 0.0 10500 984 ? Ss 2012 5:05 sendmail: accepting connections
root 14312 0.1 0.3 11336 3352 ? D 06:00 0:28 ¥_ sendmail: ./r06NCFxj021942 from queue

4. 暫定対処
root 9038 0.1 0.6 16024 6452 ? D 07:00 0:21 ¥_ sendmail: running queue: /var/spool/mqueue
root 30906 0.0 0.2 10672 2616 ? S 10:45 0:00 ¥_ sendmail: server localhost [127.0.0.1] cmd read
root 30992 0.0 0.2 10672 2612 ? S 10:45 0:00 ¥_ sendmail: server localhost [127.0.0.1] cmd read
root 31726 0.0 0.2 10676 2600 ? D 10:45 0:00 ¥_ sendmail: r071jQD3031726 localhost [127.0.0.1]: DATA
root 31727 0.0 0.2 10676 2600 ? D 10:45 0:00 ¥_ sendmail: r071jQwf031727 localhost [127.0.0.1]: DATA

• ここで始めてサーバに SSH ログイン
root 31728 0.0 0.2 10676 2592 ? D 10:45 0:00 ¥_ sendmail: r071jQqF031728 localhost [127.0.0.1]: DATA

うえへ。。(;´Д`)
– Sendmail によるサーバ負荷が原因→停止
• sendmai l を停止(killall -9 sendmail)
• /var/spool/queue/ と /var/spool/clientmqueue/ を別名にして、
キューを消す
– ログからは、不正中継の形跡は見られない
• apache ユーザ権限でメール配送が行われている（？）

• どうしてこうなった・・？
＿＿＿ ♪ ∧__,∧.∩
/ ||￣￣|| ｒ（＾ω＾）ﾉどうしてこうなった！
|.....||＿＿|| └‐、ﾚ´｀ヽどうしてこうなった！
|￣￣＼三 /￣￣￣/ノ´｀ ♪
| | ( ./ /

5. 更に状況調査なぜかESTABLISED
が急増

• 再びMuninで確認
– メールの流通量増大、
Apacheのアクセス増
TCP (ESTABLISHED)が
同時に発生(緑実線)

Apacheアクセス数
• 推測
– CGIか何かのアプリが
暴走？（フォームとか）

6. 再びログイン＆対処
• sendmailの状況は、明らかに変
– Apacheのアクセスログ調査原因は、不正設置されたファイル経由
でメール送信が試みられていた模様。
– “find /home –mtime -4”
• (異常発生した 4 日前に変更のあったファイルの検索）

– ファイル除去
アクセス制限
• 全POST禁止

7. 更なる特定へ MySQL
クエリ

Apacheアクセス数

MySQL
• 1月4日の現象発生（点線）
スループット
より前にApacheやMySQLに
対する通常とは異なる挙動
• 前後のApacheログより、
あるCMSに対する攻撃を
試みていたことがわかる→対処

8. それでも収まらないトラフィック
トラフィック推移

CPUやfork数の
異常も見受けら
メールは止めたのに… れないのに、
どうして…？

対応時刻対応時刻

9. 改めて調査 t1 t2
• 週の推移グラフ
「トラフィックとトラフィック推移
メール送信の間に
時差がある！」
– t1 … 1月3日 12時頃
メール転送量
• トラフィック上昇
– t2 …1月4日 00時頃
• メール送信開始
• t1に何が起こった？

10. 原因はDNSの外部参照→対処
トラフィック推移
t1 t2

DNS推移と連動！

対応時刻

11. 推移観察 t3 t4
外部からの
• 原因再帰問い合
わせを拒否
– 1. CMSのセキュリティホール
– 2. DNS の外部参照
_, ,_
(＾Д＾) ﾌﾟｷﾞｬｰ • 参照元は世界各地のCIDRから。。
m9 ヽ) • ネームサーバなのでポート閉じれず
/ ﾉ俺涙目wwww orz
(,/＾ヽ) 動的に
iptabelsで
Port
• 最終的な対処 53(UDP)
– Iptables で、動的に遮断を遮断して
• BIND のログから、短期間にANY 収束
リクエストを大量に送ってくる環境を
自動的に遮断する仕組みを導入

一般的にも、使えるシーン
例えば、Load Average上昇
CASE: A

事象：
Load Average 急上昇

物理メモリ不足の兆候

原因：
sendmail の大量
CPUの負担増加のキュー発生

BINDへのクエリ
CASE: B

普段とは異なる状況から、
不正アクセスや攻撃の疑い

事象：
MySQLの処理が頭打ち？
原因はどこに？

ディスクのスループットは問題なし。
CPUの処理にも負担なし。
→ MySQL のチューニング余地を検討

不正アクセス検出
CASE: D

事象：
Postmaster宛のエラーメールが急増。
httpdの動作ユーザ権限によるもの。
Muninで見ると、キュー数が急増
通常とは異なったアクセス兆候。
当該時間の httpd のログを調査し、
不正アクセスを発見→直ちに対処

AWS の料金表示プラグインを
書いてみました。API 経由で
データを取得し、Munin に取
り込みグラフ化します。

https://github.com/zembutsu/AWS-EstimateCharge

とある電子書籍媒体の冊数を数
えることも出来ます。Muninは
数値化されたものなら、何でも
簡単にグラフ化できます。

こちらは、とある電力会社の総
発電量と供給量のグラフです。

ディスクの使用率が 100% に達
する見込みも立てられます。

プラグインを自作する
How to make plugins

httpingプラグインを作ってみた
• http://www.vanheusden.com/httping/

• httping は、HTTPサーバの応答時間を ping コマンドのよ
うに計測できるツール。
• オプションで –S (大文字)を付与すると、サーバ接続時間
と、応答時間を分けて取得できるのが便利。
$ httping -S http://210.239.46.254/
PING 210.239.46.254:80 (http://210.239.46.254/):
connected to 210.239.46.254:80 (380 bytes), seq=0 time=0.10+0.69=0.79 ms
Got signal 2
--- http://210.239.46.254/ ping statistics ---
4 connects, 4 ok, 0.00% failed

Plugin: httping_
#!/bin/sh
#
# Plugin to monitor HTTP response (httping)

#%# family=auto
#%# capabilities=autoconf

URL=${URL:-"http://localhost/"}
COUNT=${COUNT:-"5"}
httping_bin=$(which httping)
これがプラグインの実体です。
if [ "$1" = "autoconf" ]; then
echo yes
Config部分と、実際にデータを取得する部分
fi
exit 0
グラフの定義を定義するだけです。割とシンプルなシェル
if [ "$1" = "config" ] ; then
スクリプトで行けます。PerlやrubyやPHPで
echo "graph_args -r --lower-limit 0 ";
echo "graph_title http response $URL";
も構いません。
echo "graph_category httping";
echo "graph_info httping response time: $URL";
echo 'graph_vlabel msec'

echo "connect.label connect time"
echo "connect.draw AREA"
echo "connect.type GAUGE"
echo "processing.label processing time"
echo "processing.draw STACK"
echo "processing.type GAUGE"
exit 「xxx.Value ***」の形式で出力
fi

# format for httpiing 1.5.3 http://www.vanheusden.com/httping/
$httping_bin -c $COUNT -G -S $URL | tr '+|=' ' ' | awk '{connect+=$9; processing+=$10} END{print "connect.value",connect/'$COUNT'"¥n""processing.value",processing/'$COUNT'}'

シェルスクリプトがキモ
• logtail2 ( logrotate に対応した log viewer )
• awk logtail パッケージは、yum install logtail
この中に logtail と logtail2 があります。
• cut 基本機能はどちらも同じですが、logtail2 はロ
• sort グのローテートに対応しています。

• uniq

これらの組み合わせで、様々な解析が容易に

まずApacheのログを読み込みます。ログの

例：awk 10番目の要素を変数”traffic”に格納し積算。
最後は、bps に変換
（300秒で割る)&(byte->bit換算で*8）

• Apache の VirtualHost 毎のトラフィックをグラフ化する！
– logtail2 $LOGFILE |
awk '{traffic+=$10} END{print traffic/300*8}‘

kd111099116218.ppp-bb.dion.ne.jp - -
[07/Jan/2013:23:44:11 +0900] "GET
/info.php?=PHPE9568F34-D428-11d2-A769-00AA001ACF42
HTTP/1.1" 200 2524 ここがバイト数
"http://pocketstudio.jp/info.php?union+select"
"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0)
Gecko/20100101 Firefox/17.0"

例：awk
あとは、VirtulHost毎
に集計して、Muninプ
ラグインに取り込むと、
どのサイトに対してア
クセスが集まっている
か、把握出来ます
。
※ログには、ファイル
転送した時点での書き
込みなので、あまり正
確ではない場合もあり
ます。

例：cut , sort, uniq
• syslog_detail
– /usr/sbin/logtail2 -f /var/log/messages | ¥
-o/var/lib/munin/plugin-state/syslog_detail-messages.offset | ¥
awk ‘{ print $5 }' | cut –d¥[ -f1 | sort | uniq –c

/var/log/messages ファイル
の集計も、これらコマンドを
使えばお手のものです。

※プラグインは後日公開予定

コマンドを組み合わせて、フィルタ
• more /var/log/messages | awk {'print $5'}
snmpd[502]:
snmpd[502]:
snmpd[502]: |cut –d¥[ -f1 |sort | uniq -c
snmpd[502]:
snmpd[502]: snmpd
snmpd
snmpd
snmpd
6 snmpd
xinetd[2129]:
xinetd[23261]: snmpd snmpd 3 xinetd
xinetd[2129]: snmpd snmpd
snmpd[502]: snmpd snmpd
xinetd snmpd
xinetd xinetd
xinetd xinetd
snmpd xinetd

リソース監視ツールの仲間達 ‐-､ｨ-‐､
| ‐-⊂⊃-‐ }⌒ヽ_ﾉ|r､ /
＞´￣￣ヽー'､＿＿ノ＼二ﾆ─‐ﾆ´＿_／
/＿＿＿＿_ ヽ
ハノ＼

＜´＿＿＿_ノ､ヽ
>─､

l r-､ r-､＼_r-| / r-､ r-､＼r-}
| ⌒ ) l ⌒ )
Some Fascinating Monitoring tools. ＼(´￣￣⊃ 厂＼ (´￣￣フﾉ´
＞二二＜´ ＞⊂ﾛ⊃＜
〈_,ｨ o ﾄ､〉､ <_,ｨ o ﾄ､_>
/ / ﾉ o ( '､ヽ / / |＿o＿| | |
mn∠＿＿＿＼ nm ﾚｍ（＿r-,＿) ﾚｍ
＼‐∨‐／＼∨／
⊂-┴-⊃ ⊂-┴-⊃
土 | 干二､ /)⌒) ⌒ゝ丶／ | ‐┼`` ‐─ｧ``
rﾉ､ l rﾉ､ _ノ .ﾚノ､＿ (＿_ .l rﾉ､（_

た～のし～いな～かま～が

リソース監視系の比較

http://www.munin-monitoring.org/ http://oss.oetiker.ch/rrdtool/ http://oss.oetiker.ch/mrtg/
snmpd

http://www.zabbix.com/

http://ganglia.info/
http://www.cacti.net/ http://www.nagios.org/
C

主要ツール(リソース系)の比較表
ツール種別データの管理設定方法管理画面(WebUI) 通知機能

Munin リソース監視 RRDTool CUI △ (参照のみ) △
Cacti リソース監視 RRDToolとMySQL CUI/GUI ○ ○
MRTG リソース監視独自形式 CUI △ (参照のみ) ×
Zabbix 統合監視 MySQLやPostgreSQL等 GUI ○ ○
Nagios 統合監視 MySQLかPostgreSQL CUI/GUI ○ ○
Hinemos 統合監視 PostgreSQL GUI ○ ○
特定のツールが優れているかどうかではなく、用途に応じた使い分け・共存が可能なのです。



3.【武器】Ｍｕｎｉｎでリソース監視


# 4
属人性の排除こそが、道しるべ
I wan’t rely on anyone anymore.
■■■■□

スーパーハカー（神）は死んだ
I Won't Rely On Anyone Anymore

スーパーハカー

リソース監視は

もう貴方が
ログインする必要は無いわ。
Munin is a networked resource monitoring tool.

僕にログインさせて、トラブルシュートさせてください！障害ですよね！？
シンクロ率0.00000000%（公開鍵認証的な意味で）
ログインだけはせんといてくださいよ！

様々なデータを瞬時に把握出来る
• グラフを通した視認性の高さ
– 短時間で複数台の状況を把握できる。異常値(スパイク)の把握が容易。
– 得られるもの：迅速な対応
• 属人性の排除、少人数での対応を実現ログをいきなり読む方法もあ
りますが、未知の状況や障害
– ○○さんが居なくても、だいたい分かるに対して、スムーズに闘う為
の武器として、リソース監視
– 得られるもの：迅速な対応は有用と考えています。
• 過去データの蓄積
– 傾向を手軽に分析できる（過去1年分まで)
– 得られるもの：迅速な対応

機会損失を抑え、迅速な復旧のために
• “神は死んだ”
– ベテランでも、切り分けに時間を要する場合がある
• 例：LB のノードダウンが発生したけれど…

• 障害発生後のトラブルシューティングが容易に
– 短時間で対応できる

– 少人数で対応できる

Fugin Munin
“thought” “memory”

思考記憶
This Photo is under creative commons license
http://en.wikipedia.org/wiki/File:Odin hrafnar.jpg

エージェントである
munin-node は、
開発段階の名称が
“munin-eye”でした。

リソース監視により、インフラを見通す”神の視点”(munin-eye)が手に入るとも言えるでしょう。

もう障害対応も怖くない
I'm Not Afraid of Anything Anymore

Muninが変えた、障害対応の流れ
• ツールにたよらない場合
– 各種ログの調査、コマンド実行(sysstat等)
– 人の手が掛かり、時間もかかる←致命的

• Munin があれば…
– サーバにログインしなくとも、状況把握
– 視覚的に比較できるので、異常値検出が用意
– 迅速な対応が可能
• 障害対応の Plan-Do-Check-Action (PDCA)
• グラフを見た瞬間「この障害対応のエンディングが見えたッ！」

とあるホスティングの場合
• Muninはマジで仕事に欠かせません。
– とにかく入れる
– 片っ端から入れる
– 無駄に入れる

/ヽ /ヽ
/ ヽ / ヽ
＿＿＿＿＿＿ / ヽ＿＿/ ヽ

Plan
| ＿＿＿＿／ :::::::::::::::＼
障害状況の把握 ||
||
/／
| ● ●
＼ :::::::::::::::|
::::::::::::::| 何このアラート・・・
/つ_∧ || .| :::::::::::::|
計画 || | （__人__丿 .....:::::::::::::::::::/
/つ_,∧ 〈（ﾟдﾟ） | |＿＿＿＿ヽ .....:::::::::::::::::::::::<
└＿＿＿／￣￣ :::::::::::::::::::::::::|
＼ｷﾀｰ／ |（ﾟдﾟ）ヽ ⊂ニ) まじっすか！ |＼ | :::::::::::::::::::::::|
＼＼＼＿＿＿ ::::::::::::::::::::::::|
∧＿∧ ￣||ヽ、ヽ__と/￣￣￣/ | 障害個所推測
（） ||＿| ￣＼/＿＿＿/
（＿＿つ三_ | ｶﾀｶﾀ
/＿＿ヽ） || || ｶﾀｶﾀ
障害対応PDCA Do
＿||＿J || || 円環の理＿＿＿ｸﾙｯ… ／￣￣￣￣￣￣￣￣￣￣￣
実行

の予感！！
Action
/ ||￣￣|| ＜⌒ヽ )) ＜ >>Munin はてさて、
| ||＿＿|| ＜丿 | どこが障害ポイントなんだ？
,. -‐‘’‘’‘“”¨¨¨ヽ |￣￣＼三⊂/￣￣￣/ , ＼＿＿＿＿＿＿＿＿＿＿＿
ﾉ）
(.＿＿_,,,... -ｧァﾌ| あ…ありのまま今 Munin で見た事を話すぜ！ | ( ./
| /
改善 |i i| }! }} /／| ﾉ)ノ,(ノi
|l､{ j} /,,ｨ//｜『おれはfontentの鯖でnginxを確認していたと ( (ノし
i|:!ヾ､_ﾉ／ u {:}//ﾍ思ったらいつのまにかバックエンドのMySQLをみてた』
|ﾘ u' } ,ﾉ _,!V,ﾊ | ┐) ∧,∧ ﾉ
コマンド実行／´fト､_{ﾙ{,ィ'ｅﾗ , ﾀ人な… 何を言ってるのかわからねーと思うが ..|( ( ....:::::::) (
/' ヾ|宀| {´,)⌒`/ |<ヽﾄiゝ

Check
おれも何をされたのかわからなかった…
,ﾞ／ )ヽ iLﾚ u' | | ヾｌﾄﾊ〉￣⊂/￣￣7 ) ヽ lヽ,,lヽ
|／_／ﾊ !ニ⊇ '／:} V:::::ヽ頭がどうにかなりそうだった… （/ 川口 /ﾉ ( ）やめて！
/／二二二7'T'' ／u' __ /:::::::/｀ヽ
/'´r -―一ｧ‐ﾞＴ´ '"´ ／::::／-‐ ＼ ioDriveだとか超スピードだとか￣TT￣と、ﾞi
/ // 广¨´ /' ／:::::／´￣｀ヽ ⌒ヽそんなチャチなもんじゃあ断じてねえ評価
ﾉ ' / ノ:::::`ー-､___／:::::／/ ヽ }
_／｀丶 /::::::::::::::::::::::::::￣`ー-{:::... ｲもっと恐ろしいものの片鱗を味わったぜ… グラフやサービス状況確認

実際の運用では…（こういう場合も）
• 障害発生から復旧までの時間短縮のために
– アラート検出間隔の短縮
– 閾値は、とりあえず設定しない。意味が無い。

• レイヤ毎に異なる監視
– サーバの死活監視と、リソース監視は別
– ロードバランサの管理画面
– 実機による確認

• はじめからピークが予測される場合 ←ここはナントカし
– 待機！たい。イケてない。
本当に改善したい。
– 人間による各種目視確認とリアルタイム対応

# 5
今日のまとめ。
Its new ideas based on the past.
■■■■■

1.【西高東低】○○の出来ない時代に備える


3.【武器】 ○○○○○で○○○○監視

4.【神を殺せ】 ○人○の排除こそが、道しるべ



3.【武器】Ｍｕｎｉｎでリソース監視

4.【神を殺せ】属人性の排除こそが、道しるべ

(業務で)もし、
Muninでやれと言われたら？

僕は、リソース監視が出来るなら、Zabbbix でも何でもいいと思います。
これから始めるのであれば、Munin の導入・運用コストは少なくオススメです。

僕からのお願い。
• もし、今日セッションでMuninが気になったら
まずは、リソース監視を試してみませんか？

• きっと、そこには、
まだ誰も知らない運用のありかた（未来）が
あるのかもしれません。

今日、
リソース監視をはじめます。

今までなかったドキドキを。

http://munin.jp

http://munin.jp
Questions?
• もう少しkwsk訊きたい所はありますか？
／￣＼
| |
＼＿／
|
／￣￣＼
／＼／＼
／ ⌒ ⌒ ＼よくぞ訊いてくれた
| （__人__） | 褒美としてオプーナを買う権利をやる
＼｀ ⌒´ ／ ☆
/ヽ､--ー､＿＿,-‐´ ＼─／
／ > ヽ▼●▼<＼ ||ｰ､
/ ヽ､＼ i |｡| |/ ヽ (ニ､｀ヽ
.l ヽ l |｡| | ｒ-､y ｀ﾆﾉ＼
l | |ー─ | ￣ l ｀~ヽ＿ノ＿＿＿_
／￣￣￣￣ヽ-'ヽ--' ／オプーナ／|
.|￣￣￣￣￣￣|／| |￣￣￣￣￣￣|／| ＿＿＿＿＿＿
／￣オプーナ／| ￣|__」／_オプーナ／|￣|__,」＿＿_ ／|
|￣￣￣￣￣|／オプーナ￣／￣￣￣￣|／オプーナ／| ／ .|
|￣￣￣￣￣|￣￣￣￣￣|／l￣￣￣￣|￣￣￣￣￣|／ | ／
|￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣|

Reference
『ウェブオペレーション』
サイト運用管理の実践テクニック

O’REILLY JAPAN

John Allspaw、Jesse Robbins 編
角征典訳
2011年05月発行
278ページ

ISBN978-4-87311-493-4

Reference
『私がMuninに恋する理由』
インフラエンジニアでも監視がしたい！

http://www.slideshare.net/zembutsu/this-is-the-reason-why-i-choose-munin-20121211distribution

Reference
『Muninで始める実戦★リソース監視』
俺のサーバがこんなに重いはずが無い、を乗り切るために

http://www.slideshare.net/zembutsu/practical-resource-monitoring-with-munin

References
• Munin • Magazine
– http://munin-monitoring.jp/
– Software Design 2012年11月号
– 第二特集 Muninが手放せない理由
• Munin User Group Japan – p.77-110
– http://munin.jp/
– http://munin.jp/wiki/

• Slideshare
– http://slideshare.net/zembutsu/

Muninは舞い降りた～リソース監視を通して、運用現場を変える話～

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

More from Masahito Zembutsu

More from Masahito Zembutsu (20)