1.
モニカジ#3

2.
はてなのNagios
株式会社はてな システムプラットホーム部
id:shoichimasuhara

3.
■ 自己紹介
● id:shoichimasuhara
● Twitter:@shoichimasuhara
● 所属:株式会社はてな システムプラットホーム部
● 経歴
● 塾
● 陸自
● レンサバ屋
● はてなインフラ (イマココ)

4.
■ はてなのNagios
● はてなは以前から分散Nagios監視をしています
● サーバ管理ツールにデータを蓄え、それと連携
して(一部の)コンフィグを自動生成しています

5.
■ 分散監視Nagios
監視自体は末端のNagiosが、
通知やWebの表示は
中央のNagiosが行う仕組みです

6.
■ 分散監視Nagiosのメリット
● 負荷の分散
● 監視ホストと被監視ホストの距離が問題になら
ない
● 例えばpingの速度を監視していてもリージョンをま
たぐとゆらぎが出やすかったり遅すぎたり
● 距離が長くなると障害点が発見しづらい
● 単純に分散させるのに比べてデータの一元化に
より中央のWeb UIで確認できたりして便利

7.
● 多すぎる監視対象
● 多すぎる監視項目
● さらに分散監視
これらに対応するため
サーバ管理ツールの支援を受けて
設定ファイルを自動生成しています

8.
■ サーバ管理ツール
はてなでは
mackerel と呼んでいる
自社製のサーバ管理ツール
を使っています

9.
■ サーバ管理ツールのデータ構造
● サービス (ブックマーク、ブログなど)
● ロール (App、DBなど)

10.
サーバ管理ツールと連携する
Nagiosの分散監視設定

11.
■ 静的設定ファイルの配置
● /etc/nagios への symlink を張り替えることで中央/分散
Nagiosを切り替え
● 設定ファイルは nagios.cfg 以外ほとんど中央Nagiosのディレ
クトリに入れて symlink で共通化しています
/etc/nagios -> /path/to/nagios-conf/etc/central #中央Nagios
/etc/nagios -> /path/to/nagios-conf/etc/distributed #分散Nagios
/path/to/nagios-conf
├── bin
├── etc
│ ├── central
│ │ ├── nagios.cfg
│ │ ├── objects
│ │ │ ├── commands.cfg
│ │ │ ├── contactgroups.cfg
│ │ │ ├── contacts.cfg
│ │ │ ├── services.cfg
│ │ │ ├── templates.cfg
│ │ │ └── timeperiods.cfg
│ │ └── resource.cfg
│ ├── distributed
│ │ ├── nagios.cfg
│ │ ├── objects
│ │ │ ├── commands.cfg -> ../../central/objects/commands.cfg
│ │ │ ├── services.cfg -> ../../central/objects/services.cfg
│ │ │ ├── templates.cfg -> ../../central/objects/templates.cfg
│ │ │ └── timeperiods.cfg -> ../../central/objects/timeperiods.cfg
│ │ └── resource.cfg -> ../central/resource.cfg

12.
■ 設定自動生成
● 設定ファイルはGit管理
● サーバ管理ツールからホスト一覧を取ってきてホスト
定義ファイルを生成
● サービス定義ファイルは
/path/to/cfg/${service}/${role}.cfg
に置いてある
● hostgroup ${service}-${role} を作って対応付け
● 中央Nagios用のサービス定義は正規表現などで普通の
サービス定義から自動生成

13.
■ 問題点
● ほとんど同じ設定なのに(例えばMySQLの監視とか)新
しいサービスを作るときはサービス定義ファイ
ルを作らないといけない
● 例えば blog/db.cfg と bookmark/db.cfg の内容が
ほぼ同じ、とか
● たまに作り忘れて監視漏れ
● もはや古い
● nagios.cfg 含め設定がカオス
● 設定自動生成スクリプトがカオス

14.
新しくしよう

15.
ということで

16.
最近、サーバ管理ツールから作り直しました

17.
■ サーバ管理ツール (新)
mackerel2

18.
■ 何が変わった？
● “タグ”という概念を導入しました
● blog-db も bookmark-db も mysqlというタグ をつ
ければグルーピング出来る
● 「え、それだけ？」と思われるかもしれませんが、
いままでそれがなかった
● その他いろいろ変わりましたがそれは後ほど

19.
■ サーバ管理ツール(新)のデータ構造
● タグを含めたデータ構造を表すとこんな感じ

20.
“タグ”を使った
サーバ管理ツールと連携する
Nagiosの分散監視設定

21.
■ 静的設定ファイルの配置 (新Naios)
● /etc/nagios への symlink を張り替えること
で中央/分散Nagiosを切り替え
● 設定ファイルは nagios.cfg 以外ほとんど中央
Nagiosのディレクトリに入れて symlink で共
通化しています
● 設定ファイル全部整えた

22.
■ 設定自動生成(新Nagios)その1
● 設定ファイルはGit管理
● サーバ管理ツールからホスト一覧を取ってきてホスト定義
ファイルを生成
● サービス定義ファイルは
/path/to/cfg/tags/${tag}.cfg
もしくは
/path/to/cfg/services/${service}/${role}/${tag}.cfg
に置いてある

23.
■ 設定自動生成(新Nagios)その2
● ホストの対応付けは、サービス定義ファイル
…/services/${service}/${role}/${tag}.cfg
が
● ある場合は
hostgroup ${service}::${role}::${tag}
を定義して対応付け
● ない場合は
hostgroup ${tag}
に参加させて対応付け

24.
■ 設定自動生成(新Nagios)その3
● もう正規表現で頑張らない
● 中央Nagiosサービス定義作成は通常のNagiosの設定を
1.Nagios::Object::Config でパース
2.以下のパラメタを強制的に設定
• active_check_enabled = 0
• check_command = 'check_dummy!2...
• check_freshness = 1
• freshness_threshold ||= 10800
3.テンプレートエンジンに食わせて生成
という形に変えました (だいぶすっきりした)

25.
■ 結局どう変わる？
● ホストを建てた時に自動的に設定が入るのは今までどおり
● 新しいサービス/ロールを追加するときも新しい設定(ポート変更
とか)がない限り、サーバ管理ツールでタグをポチれば分散監視
が入る
● Nagiosリポジトリの設定追加は新しいミドルウェアを追加すると
きぐらい
● つまりNagiosの設定変更が少なくなった
● ほとんどタグの設定のみなので重複設定がなくなり設定ファイル
を大幅に削減出来た
● 監視漏れの心配が(ほぼ)なくなる

26.
■ 課題
● Passiveチェックが中央でしか受けられない
● 中央サーバの冗長化

27.
■ はてなNagiosのさらに詳細は
● 話が込み入って長くなるので、ご興味ある方は
後ほどお声がけください

28.
話の流れで
新サーバ管理ツール
の紹介ももう少し

29.
■ サーバ管理ツール (新) (再掲)
mackerel2

30.
■ サーバ管理ツール新旧相違点
● データ構造の整理
● Nagiosとの連携疎結合化 (API化)
● “タグ”という概念を導入した
● 分散RRDの仕組みを導入した
● Perlになった (旧システムはRailsベース)
“なぜ国内でPerlが急速に萎んだのか”
http://anond.hatelabo.jp/20130307004741

31.
■ 分散RRDのところだけ紹介
● 万を越えるRRDファイルの更新ツライ
● いままではSSDで頑張ってきた
● awsとかどうする
● RRDも(Nagiosと同じく)分散しましょう

32.
■ 分散RRD 大雑把な構造
② RRDストレージ検索(MySQL)
①グラフ画像要求(HTTP)
③グラフ画像要求(rrdcached)

33.
■ 結構安直な作り
● 設置
● RRDストレージと呼んでいる、クローラ同梱のRRD
ファイルを蓄えたホストを複数設置
● ホストとRRDストレージホストの対応をMySQLに登録
しておく
● クローラは自分の担当分だけクローリング
● 閲覧
● グラフの担当RRDストレージを検索
● RRDストレージの rrdcached に対してgraphリクエ
ストを投げて画像バイナリを貰う
● そのままブラウザに投げ返す

34.
■ 問題点
● RRDストレージをまたいだグラフの描画がで
きない
● サービスごと、リージョンごとなど分割に工夫
が必要
● rrdcachedに関するノウハウが少ない

35.
■ サーバ管理ツールの今後の希望
● オープンソース化？ (新Nagiosも込で
● RRDによるいろいろな予測機能付けたいですね
わかりやすい例：ディスク溢れ予測