諸君、私は運用が大好きだ！私がZabbixを導入した根本的な理由

諸君、私は運用が大好きだ！

監視が好きだ　監視設計が好きだ　アラートが好きだ
パトランプが好きだ　データセンタの入館申請が好きだ
Muninも好きだ　Zabbixも大好きだ
トラブルシュートが好きだ　報告書作成が好きだ

データセンタで　オフィスで　公園で　映画館のロビーで
この地上で行われる　ありとあらゆる運用が大好きだ

――とある運用担当者の手記より。作者は不明である。

本稿は、Zabbix アドベントカレンダー 2015 の、12月9日分の投稿です。想定している読者は、Zabbix や運用・監視といったキーワードに興味をお持ちの方です。

■ 概要（はじめに、運用があった）

先日、Zabbix Conference Japan 2015 で登壇の機会をいただきました。その発表内容の前半、「そもそも、わたしは何故 Zabbix を導入したのか」を、改めて文章として紹介したいと思っています。いわゆる「Zabbixを使ってみた」系の話。少々文章は長くなりましたが、要約すると次の３行です。

監視と運用の対象の増加は、社会からの要請だった
コンピュータシステムの運用業務は、人間の医療や救急救命医療と似ている
Zabbix には私が欲しかった機能があった

今回の投稿は、いわゆる手順書や運用・監視設計書には書かれない「裏側」の意図を、自分の中の整理も兼ねて文章にしたものです。皆さんの考えるヒントなり、きっかけになっていただければ嬉しいです。

障害対応・運用におけるトリアージ的対応とZabbixの活用 from Masahito Zembutsu

■ 時代の変化

ペットから家畜へ

「ペット vs 牛」（Pets vs. Cattle）という言葉を耳にしたことはないでしょうか。これは、システムなりサーバに対する比喩です。２年前くらいから開発・運用における手法の文脈で出てきています。かつて、サーバはペットのような存在でした。ペットであれば、大切に可愛がりますし、名前も付けます。でも、家畜（動物）なら米国であれば番号で管理するでしょうし、愛着もわかないと思います。

今では、クラウド上で仮想サーバを作っても、都度、ホスト名を割り振らなくても（あるいはIDのようなもので識別されても）違和感は無いと思います。また、躊躇なくサーバを停止・破棄することも。これこそが、サーバを家畜のように扱っていると言えるでしょう。

このサーバ家畜化という考えは、実は今に始まったわけではありません。それは、クラウドや仮想化がと言うよりは、おそらく日本ではインターネットが商用解放された20年ほど前に遡ると思われます。

誰もがネットを使う時代

私が初めて勤めた会社は、データセンタでのホスティング業をしていました。物理サーバやネットワーク機器を月単位・年単位で貸し出し、それを運用・保守するサービスです。いろいろな会社さんや個人・団体のサーバをお預かりしました。ちょうどまだ、テレホーダイと呼ばれる、夜間～早朝にかけて電話通話料金が一定になるサービスが流行していた頃。

ある時期、急にお預かりする＝管理するサーバ台数が急激に増え始めます。2000年代初頭、ブロードバンドの常時接続や、携帯電話を使った SNS の普及により、いわゆる「普通の人」がインターネットを使うようになりました。

今から思うと意外かもしれませんが、前世紀末、インターネットやコンピュータは、仕事や趣味のためのもの。ごくごく、一部の限られた人のためのシステムだったとも思います。それが、一気に多くの人に利用されるようになったのです。

そうなると、一気に管理するサーバやネットワーク機器が増えました。先ほどの家畜というキーワードこそが、当時の状態を表すのにふさわしいでしょう。お客さまは１台１台のサーバに名前をつけています。

一方で、運用・保守する立場としては日々増える４桁台の物理サーバに対しては、家畜的に見ていたのかもしれないなと思われます。サーバはシリアルが割り振られ、データベースで管理されていました。サーバが故障したら、機械的に入れ替えるのですから。

このあたりの経緯は、２年前のブログへの投稿をお読みいただければと思います。

僕がホスティングサービスで学び考え、取り組んだこと。 | Pocketstudio.jp log3
http://pocketstudio.jp/log3/2013/12/19/more_vivid_than_today/

時に、西暦2015年

その後に登場した、サーバの仮想化技術。そして、クラウドコンピューティングという概念は多くの人に受け入れられ、今では当たり前な選択肢の１つになったように思います。

そして、また新しい管理対象が出てきそうな雰囲気です。コンテナ技術を用いたシステムです。もしかしたら、それは Docker コンテナかもしれませんし、あるいは違う技術かもしれません。しかし Docker がもたらした概念は広まるように感じています。簡単にアプリケーションをどこでも動かし実行する。そのためにコンテナ技術を使うのだと。

コンテナ化されたシステムが普通になった場合、運用業務や監視はどのようになるのでしょう。仮想化やクラウド環境であれば、ホスト名で何とか管理していたかもしれません。ですが、コンテナであれば、どのように管理・運用していけばよいのでしょうか。

これまで通り、コンテナにも名前をつける手法もあります。しかし、人間がコンテナを管理したいがために、コンテナの利点（速さや手軽さ）を犠牲にしてしまうのは本末転倒です。

そこで、もしかしたら、かつての管理対象サーバが急増したときの手法が役に立つのでは。そのように思っています。その手法が、サーバを「物」ではなく「人」に例える方法です。

■ 監視ツールの変遷、独自→Nagios/MRTG→Munin(Zabbix) へ

独自監視ツールの限界

少し時代を遡ります。私はいきなり Zabbix を使い始めたわけではありませんし、当時 Zabbix は存在していませんでした。

2000年代初頭、業務でサーバやネットワークの監視に使っていたのは、独自ツールと、Nagios（https://www.nagios.org/）とMRTG（http://oss.oetiker.ch/mrtg/）でした。これを使い、各種のサーバ（主に Linux）とネットワーク機器のトラフィックを監視していました。

独自ツールは、現在で言うところの死活・外形監視と呼ばれるもの。監視サーバから監視対象の IP アドレスおよび任意ポートに対して、応答状況を確認するものです。エラーが発生すると、管理用のメールアドレスに通知する仕掛けです。

ただ、あくまで外からしか状況が分かりません。そのため、PINGなどは応答しているはずなのに、実際には何も応答していない場合や、外から分からないプロセスの稼働状況を確認できない課題が出てきました。

そこで採用したのが Nagios です（正確には当時、Netsaint と呼ばれていました）。Nagios はサーバ・クライアント型のシステムです。監視対象のサーバの中にエージェントを入れると、サーバの中からプロセスの状況を調べることができるようになりました。あわせて、サーバ上のリソース、CPU・メモリ・HDD 容量も分かるようになったのです。

当時多かった障害の１つに、気づかないうちにディスク容量が 100% を越えるケースがありました。モノによっては停止してしまうこともあり、あわてて不要なファイルなりログを消す作業が必要になります。そこに、Nagios があれば、あらかじめディスク容量 90% を超過すると、アラートを出すことができるようになります。とても重宝しました。

Nagios は万能ではなかった

原因特定は面白い仕事です。様々な要因と可能性を考え、システムを復旧する作業。下手なゲームよりも面白い、と、当時の私は思っていました。

Nagios が問題発生を通知してくれるのは有り難いものです。ですが、現実問題として、何かしらアラートが起こったときには障害が発生中であり、直ちに障害対応（原因特定のトラブルシューティング）が必要となります。

ですが、流石に日々障害対応が続くと、私も、他のメンバーの現場も疲れてきます。何より、状況調査のためには、ログを見たり、あるいは Nagios のアラートの発生時刻などから、手探りでログやシステム状況を調べなくてはいけません。

これが単なるサーバ数台レベルならまだしも、SNS やウェブ系サービスの裏側では、２桁ぐらいの環境もあたりまえになってきます。そんなとき、障害が起こると――楽しいはずのトラブルシューティングも、苦行です。

何が苦しかったのか？　それは、過去の経緯が分からない場合です。ログが残っていれば、時間の特定が可能な場合も有ります。ですが、ログを調査すべき対象のサーバが停止している場合、あるいはログが消失した場合、そもそも確認すらできません。

時系列監視、そして Munin・Zabbix へ

そんな状況で知って採用したのが、Munin （http://munin-monitoring.org/）でした。Munin もサーバ・クライアント型であり、サーバ内のエージェントがリソース状況を取得し、サーバに通知します。サーバは取得したデータを時系列で記録し、様々なグラフを自動生成します。

（今から思えば Zabbix の機能でも良かったのですが、当時は単に Zabbix のことを理解していませんでした。）なぜ Munin が良かったのか、理由は２つあります。

複数台の環境とリソースを、１画面で瞬時に鳥瞰できる
時系列の推移がグラフ化されるため、原因の特定がしやすい

これはトラブルシューティングの速度を劇的に向上しました。画面を見ると一瞬だからです。メモリを使い切った時刻を特定したり、Load Average が高いときは、その原因が何なのか（ディスク I/O なのか、その他の要因なのか）一瞬で分かります。対象のサーバが停止していても、サーバ側にデータは蓄えられていますから、停止前の状況もある程度把握できます。

そこで気が付きました。障害対応を迅速化するために Munin を入れましたが、これは平時にも使えるのではないかと。

■ 監視の必要性を考えたのが、サーバを人体に例えるきっかけ

攻めの運用に、サーバを擬人化するモデル

運用は守りの立場と言われるのは、おそらく、事前設計に基づく決まり切った対応「しか」しないからです。「運用でカバー」という例外もありますが、あちらは攻めてるパターンです。

攻めの運用とは、障害発生やアラートをトリガとしてチームが動くのではなく、障害発生が起こる前に、対処することです。例えば、アラートの閾値を越えていなくても「なんとなくシステムの応答が不安定」であったり、本来の性能を出せていないと疑われるケースが出てきます。

そんな時に、Munin のように、時系列でリソース推移を監視できるようになると、アラートが起こる前の事前予防的な対処が可能となります。もしシステムの能力不足であれば、サーバを増やす必要性も、グラフを通して把握しやすくなったのです。

これは、よくよく考えると、サーバも人も同じではないでしょうか。何かしら不調があれば、必ず原因を調べます。サーバであればログを見たりリソース状況を把握するのと同じように、人間であれば診察をして原因を特定します。調べもせずに原因特定なんて、できません。

このように、障害対応を迅速に導入する目的から、平時の監視にも時系列のリソース監視は有用なものとなりました。監視システムとしては、Nagios と Munin を併用する時代が続きます。

対応の優先度付け

当時、業務の中心にあったのはメールでした。障害発生や復帰を伝えるメールのアラートをトリガとして、人間が復旧対応に当たります。実は、これには致命的な欠陥がありました。

監視対象は様々な項目が設定されています。例えば１台のサーバに、PING・SSH・HTTP と３つの監視項目を設定しているとします。もしもサーバが停止すると、PING・SSH・HTTP の３つのアラートメールが届きます。

PING の通知が届けば、SSH と HTTP が止まっているのは、自明ではないでしょうか。本来確認する必要が無いメールが届きます。これは、運用担当が混乱します。先に HTTP のアラートが届いた場合、その HTTP 向けの確認手順を進めますが、そのあと PING のアラートが届くと、HTTP の確認手順が無駄になってしまいます。

更に困るのは大規模な障害です。複数台のサーバで同時に障害が発生したときを考えてみます。３つの監視設定をしているサーバが10台あると仮定します。もし10台で障害が発生すると、30通のメールが届きます。これがネットワーク障害になると、数百、数千のメールが届くことになります。

これを何とか解決する方法がないのか、より迅速に対応できる方法は無いのか？　答えは、ありました。それが再び人体の救急救命を目的とした、トリアージの考え方です。

トリアージで優先度付け

トリアージ（triage）は、救急救命時の手法です。例えば大規模な事故・災害で、多くの死傷者がでたとします。このとき、現場でより多くの人を救うために、患者ごとに対応するレベルを「区分」する方式のことです。

例えば、目の前に１０人の患者と、１人の医師がいると仮定します。軽傷（かすり傷程度）の患者と、出血が酷い患者がいたら、通常、出血が酷い患者を救おうとするかもしれません。ですが、出血の酷い患者（以下A)に加え、瀕死の患者（B)もいたら、どうしたらよいでしょう。

患者Bに時間を費やしている間に、患者Aが死んでしまうかもしれません。あるいは、かすり傷の患者を治療していると、A・B両方死ぬかもしれません。

結果としてBという患者を（言い方は悪いのですが）見すてることになるかもしれませんが、死にかけの患者に貴重な治療リソースを使うよりは、確実に助かるAの治療に着手すべきだと分かります（心理的には抵抗がありますが）。

このように、より多くの命を救うための優先度付けが、トリアージと呼ばれるもので、そのとき、状況を判断して患者の腕などにくくるのが、トリアージ・タッグ（タグ）です。

この考えは、実際の運用現場でも役に立ちました。通常の障害であれば、複数のアラートが発生したとき、優先度の高い順に対応するというフローが作れます。ネットワーク機器の障害の時も同様、まずスイッチやルータ周辺を確認すべき、といった判断も容易になります。

ただし、当時はこれをアナログ（Excel に手打ち）で管理していたので、非常に面倒なものでした。かつ、トリアージを行うように、何を優先すべきかの判断は手順化しづらいところもあり、属人的になりがちです。

そして Zabbixへ

このように、監視の優先度付けは可能になったのですが、管理が煩雑になりがちという課題が出てきます。更に、携帯電話を使ったサービスやゲーム環境が登場してくると、監視対象は更に増え、障害発生時は、より迅速な状況把握と対応が求められてきます。

そして、ようやく Zabbix の導入に至ります。

■ Zabbix でトリアージを自動化し、サービス品質向上へ

先ほどのトリアージを迅速にするための仕組み――ないものか？――ありました。Zabbix です。Zabbix はサーバやネットワーク機器の監視が可能なツールです。監視対象にアラートを設定できるのは、他のツールも同様です。

私が注目したのは、Zabbix にアラートの深刻度設定と、依存関係を設定できることでした。深刻度とは、監視項目毎に深刻度（重要度）を設定できます。例えば次のようなものです。

深刻度（高） PING 疎通不可
深刻度（中） SSH 応答不可、HTTP 応答不可
深刻度（低）ディスク容量残り 70%

この深刻度に応じて、どのように通知するか、個々の条件を設定できます。更に、監視項目間に依存関係（dependency）を設定しておくと、より重度なアラートが発生中、下位の通知を出さないといった応用も可能です。

つまり、トリアージ・タッグが Zabbix の「深刻度」設定であり、自動トリアージとしての「依存関係」機能です。サーバを、あたかも人のようにトリアージする。そんな運用が実現できました。

Zabbix の監視機構

Zabbix の特徴は、データの取得部（アイテム設定）、評価部（トリガ設定）、通知部（アクション）が分かれている点です。これは一見すると Zabbix が難しいような印象を受けてしまいます。しかし、私は逆に、とても高い自由度が得られると思っています。

データ取得部のアイテムとは、PING・SSH・HTTP といった監視項目を設定（監視対象のサービスと、監視間隔など）するものです。これは、ホスト毎に設定できますし、テンプレートを使えば数十台の設定を同時に変更するのも容易です。

更に、評価部（トリガ設定）は、取得していたデータを個々に評価するものです。ここで先ほどのトリアージと同じような概念で、深刻度を設定できます。Zabbix のユニークなところは、１つのアイテムに対して、複数のトリガを設定できます。

例）

ディスク容量90%：深刻度高
ディスク容量80%：深刻度中
ディスク容量70%：深刻度なし

深刻度を割り当てると、次にアクション（通知）の処理が行われます。通知のアクション設定では、この深刻度だけでなく、ホスト名・グループ・発生時間などを条件付けが可能です。反応がなければメールをエスカレーションする仕組みも可能です。メール以外にもパトランプを点等し警報も鳴らせます。

また、監視通知のメンテナンス・フリーを実現しました。障害発生時は自動で通知の停止、回復時は自動で監視の再開（正確には通知の再開）も容易です。アクションでは、ステップ毎に通知時間・繰り返しを指定できるためです。この機能を使えば、長時間の障害が発生してアラートを止めてしまい、そのまま監視設定再開を忘れてしまうのを防止します。

そしていざアラートが多発している時は、GUI 上でトリガの一覧を監視できます。深刻度順にソートしたり、あるいは時系列順でソートし直したり、状況の迅速な把握が可能になったのです。その一覧から、対象サーバの詳細情報も確認できます。ホスト毎のインベントリに、物理的なサーバの場所（ラックやスイッチ）を記載しておけば、物理的な原因特定もスムーズです。

更に障害対応を強力にするのが「依存関係」機能です。

優先度付けをトリガの依存関係で定義

依存関係とは、明らかに対応する必要にないトリガを抑止する機能です。トリガ毎に設定できます。次の図は、PING の深刻度を高くし、その下に、ICMP・SSH・HTTP をぶら下げたものをイメージしています。

このように設定をしておくと、PING のトリガ発生中、階層化のトリガに対するアクションは処理しません（GUIのトリガ画面からは、依存関係を確認可能です）。これもトリアージの考え方に基づいています。

PING の応答がなければ、HTTP や SSH の障害が予想され得るので、何らかのアラートを送っても、対応する意味は少ないです。それよりも、なぜ PING が到達しないか確認すべきでしょう。

ほかにも、いわゆる「誤アラート」問題に、この依存関係が使えます。Zabbix は１つのアイテムに対して、複数のトリガが設定可能です。たとえば、SSH のアラートであれば次のように明らかな障害と、それ以外を切り分ける設定も可能になります。

深刻度（高）… 直近５分間に SSH の障害がなく、かつ、３回以上のエラー発生時に発動
深刻度（低）… SSH のポートが応答しない場合に、トリガ発動

このような設定を入れると、トリガ画面でも、次のように依存関係を確認できます。

その他、Zabbix の良かったところ

このように、効率的な障害対応を行うために Zabbix は手放せないものとなります。機能を組み合わせることにより、様々なシステムにあわせて、監視設定を工夫することができたのです。障害時、どこを見るべきかは属人的になりがちですが、それを Zabbix の機能でカバーできました。

他にも便利な機能がいくつかあります。

ローレベル・ディスカバリ機能（Low Level Discovery）… ネットワーク機器の監視設定を省力化しました。新しいスイッチを追加するときも、SNMP の設定を追加するだけで、全てのポートの疎通状態や、トラフィック、パケットを自動的に Zabbix に登録できました。詳細はこちらの投稿をご覧ください。

【ZABBIX】やっぱりLLD(ローレベルディスカバリ)は最高だぜ！ | Pocketstudio.jp log3
http://pocketstudio.jp/log3/2013/07/08/howto-zabbix-low-level-discovery/

・ホスト・インベントリ機能 … ラックや上位のネットワーク機器の情報を登録しておくと、障害発生のアラートメールに、その情報を含めました。同じネットワークでアラートが頻出した場合、複雑な階層では上位の原因特定がスムーズに。

・メールのスレッド化 … Zabbix のアラートメールは障害発生時・復帰時に届きます。しかし、同時多発的にアラートが発生すると、何が障害継続中で、何が復帰したのか把握しづらくなります。当時はメーラーを使った対応が主でした。そのため、障害発生メールと復帰メールを、メールのスレッド表示できるような工夫もできました。詳細はこちらの投稿をご覧ください。

ZABBIXの通知メールをスレッド化してみる | Pocketstudio.jp log3
http://pocketstudio.jp/log3/2013/06/07/zabbix-email-alerts-threadin/

・単純の数値のグラフ化 … Zabbix はアイテムを組み合わせて時系列グラフを作れます。もちろん、アイテム単体で時系列グラフを作成もできますし、これはグラフを定義する必要がありません。そのため、あとからグラフが必要になったら、その時に都度時系列グラフを生成できますし、グラフに表示する項目を組み替えるのも簡単です。

ほかにも、Zabbix は HTTP API インターフェースを持っています。これを応用すると、様々なクラウド環境、コンテナ環境への応用も容易になるかもしれません。このあたりに興味がありましたら、発表スライドの後半をご覧ください。

障害対応・運用におけるトリアージ的対応とZabbixの活用
http://www.slideshare.net/zembutsu/zabbix-conference-2015-triage-and-operations