Embed Size (px)
Citation preview
モニカジ#3
はてなのNagios
株式会社はてな システムプラットホーム部id:shoichimasuhara
■ 自己紹介
● id:shoichimasuhara
● Twitter:@shoichimasuhara
● 所属:株式会社はてな システムプラットホーム部
● 経歴
● 塾● 陸自● レンサバ屋● はてなインフラ (イマココ)
■ はてなのNagios
● はてなは以前から分散Nagios監視をしています
● サーバ管理ツールにデータを蓄え、それと連携して(一部の)コンフィグを自動生成しています
■ 分散監視Nagios
監視自体は末端のNagiosが、通知やWebの表示は中央のNagiosが行う仕組みです
■ 分散監視Nagiosのメリット
● 負荷の分散
● 監視ホストと被監視ホストの距離が問題にならない● 例えばpingの速度を監視していてもリージョンをまたぐとゆらぎが出やすかったり遅すぎたり
● 距離が長くなると障害点が発見しづらい
● 単純に分散させるのに比べてデータの一元化により中央のWeb UIで確認できたりして便利
● 多すぎる監視対象● 多すぎる監視項目
● さらに分散監視
これらに対応するためサーバ管理ツールの支援を受けて設定ファイルを自動生成しています
■ サーバ管理ツール
はてなではmackerel と呼んでいる自社製のサーバ管理ツールを使っています
■ サーバ管理ツールのデータ構造
● サービス (ブックマーク、ブログなど)
● ロール (App、DBなど)
サーバ管理ツールと連携するNagiosの分散監視設定
■ 静的設定ファイルの配置● /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
■ 設定自動生成
● 設定ファイルはGit管理
● サーバ管理ツールからホスト一覧を取ってきてホスト定義ファイルを生成
● サービス定義ファイルは
/path/to/cfg/${service}/${role}.cfg
に置いてある
● hostgroup ${service}-${role} を作って対応付け
● 中央Nagios用のサービス定義は正規表現などで普通のサービス定義から自動生成
■ 問題点
● ほとんど同じ設定なのに(例えばMySQLの監視とか)新しいサービスを作るときはサービス定義ファイルを作らないといけない● 例えば blog/db.cfg と bookmark/db.cfg の内容がほぼ同じ、とか
● たまに作り忘れて監視漏れ
● もはや古い● nagios.cfg 含め設定がカオス● 設定自動生成スクリプトがカオス
新しくしよう
ということで
最近、サーバ管理ツールから作り直しました
■ サーバ管理ツール (新)
mackerel2
■ 何が変わった？
● “タグ”という概念を導入しました● blog-db も bookmark-db も mysqlというタグ をつければグルーピング出来る
● 「え、それだけ？」と思われるかもしれませんが、いままでそれがなかった
● その他いろいろ変わりましたがそれは後ほど
■ サーバ管理ツール(新)のデータ構造
● タグを含めたデータ構造を表すとこんな感じ
“タグ”を使った
サーバ管理ツールと連携するNagiosの分散監視設定
■ 静的設定ファイルの配置 (新Naios)
● /etc/nagios への symlink を張り替えることで中央/分散Nagiosを切り替え
● 設定ファイルは nagios.cfg 以外ほとんど中央Nagiosのディレクトリに入れて symlink で共通化しています
● 設定ファイル全部整えた
■ 設定自動生成(新Nagios)その1
● 設定ファイルはGit管理
● サーバ管理ツールからホスト一覧を取ってきてホスト定義ファイルを生成
● サービス定義ファイルは
/path/to/cfg/tags/${tag}.cfg
もしくは
/path/to/cfg/services/${service}/${role}/${tag}.cfg
に置いてある
■ 設定自動生成(新Nagios)その2
● ホストの対応付けは、サービス定義ファイル
…/services/${service}/${role}/${tag}.cfg
が
● ある場合は
hostgroup ${service}::${role}::${tag}
を定義して対応付け● ない場合は
hostgroup ${tag}
に参加させて対応付け
■ 設定自動生成(新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.テンプレートエンジンに食わせて生成
という形に変えました (だいぶすっきりした)
■ 結局どう変わる？● ホストを建てた時に自動的に設定が入るのは今までどおり
● 新しいサービス/ロールを追加するときも新しい設定(ポート変更とか)がない限り、サーバ管理ツールでタグをポチれば分散監視が入る
● Nagiosリポジトリの設定追加は新しいミドルウェアを追加するときぐらい
● つまりNagiosの設定変更が少なくなった
● ほとんどタグの設定のみなので重複設定がなくなり設定ファイルを大幅に削減出来た
● 監視漏れの心配が(ほぼ)なくなる
■ 課題
● Passiveチェックが中央でしか受けられない
● 中央サーバの冗長化
■ はてなNagiosのさらに詳細は
● 話が込み入って長くなるので、ご興味ある方は後ほどお声がけください
話の流れで新サーバ管理ツールの紹介ももう少し
■ サーバ管理ツール (新) (再掲)
mackerel2
■ サーバ管理ツール新旧相違点
● データ構造の整理
● Nagiosとの連携疎結合化 (API化)
● “タグ”という概念を導入した
● 分散RRDの仕組みを導入した
● Perlになった (旧システムはRailsベース)
“なぜ国内でPerlが急速に萎んだのか”
http://anond.hatelabo.jp/20130307004741
■ 分散RRDのところだけ紹介
● 万を越えるRRDファイルの更新ツライ
● いままではSSDで頑張ってきた
● awsとかどうする
● RRDも(Nagiosと同じく)分散しましょう
■ 分散RRD 大雑把な構造
①グラフ画像要求(HTTP)
② RRDストレージ検索(MySQL)
③グラフ画像要求(rrdcached)
■ 結構安直な作り
● 設置● RRDストレージと呼んでいる、クローラ同梱のRRDファイルを蓄えたホストを複数設置
● ホストとRRDストレージホストの対応をMySQLに登録しておく
● クローラは自分の担当分だけクローリング
● 閲覧● グラフの担当RRDストレージを検索● RRDストレージの rrdcached に対してgraphリクエストを投げて画像バイナリを貰う
● そのままブラウザに投げ返す
■ 問題点
● RRDストレージをまたいだグラフの描画ができない● サービスごと、リージョンごとなど分割に工夫が必要
● rrdcachedに関するノウハウが少ない
■ サーバ管理ツールの今後の希望● オープンソース化？ (新Nagiosも込で
● RRDによるいろいろな予測機能付けたいですね
わかりやすい例：ディスク溢れ予測
