運用・監視もコード化する。開発者が監視まで考える方法論
Recruit Technologies Open Lab #3
Jul 7th, 2016
Profile
インフラを意識してコードを書くということ
最近Goで作ったもの
ニッチなツールを作るのが趣味
make2help
rake -T の Makefile版
- https://mackerel.io/
- サーバー管理・監視ツール as a Service
- 前身: はてなの社内ツール
- 管理対象のサーバーから送信するメトリクスを集計
- 監視サーバー不要で利用登録から3分でサーバー監視開始
可視化
アラート
最大1ロール2554台!
- これはちょっと格が違う例
- はてなでも最大1ロール数百台
100週連続リリース
100週連続リリース
Agenda
- 運用のコード化
- 監視とは何か
- アプリケーションエンジニアと監視
- コード化する
- 監視をコード化する
- 閾値調整をコード化する
- アラート発報とそれに付随するアクションのコード化
- 監視以外のコード化
監視に対する抵抗感
- 難しそう/よくわからない
- 謎の画面
- インフラの人が設定してくれるもの
- そもそも監視してない
モニタリングの重要性の向上
すべてのサービスで健全性と一般的な監視関連のメトリックを同じように出力することをおすすめします。(中略)
どれを選んでも、標準化するようにしてください。
- やっていくしかない(みたいなことが書いてある)
- Webサービスへの要求の向上
- リアルタイム性
- 監視からは逃げられない
監視とは継続的なテストである
by Kazuho Oku
監視とはシステムに対する高速健康診断
一般的な健康診断
- 健康診断の結果
- システム監視も同じ
- 分かる数値を追いかける/分かる数字を計測する
- ex. 体重/血圧
監視は難しくない
- 「難しくない」範囲で監視する
- 項目がたくさんあって混乱しがちなのは確か
何を監視すれば良いのかを考える
- メトリックを取得可能にする
- メトリック取得のためのインターフェースを切る
- 監視のための内部的なJSON APIを作るのが良い
- コード化する
監視のコード化
監視のコード化
- 実は監視は結構コード化されている
- 監視プラグインフォーマットはそれなりに統一されている
- 実は単なるコマンド実行
- 終了ステータスと標準出力でやりとり
- 言語はなんでもいい
- アプリケーションエンジニアはコードを書くのは得意
監視プラグインフォーマットは大きく分けて2つ
- チェック監視
- メトリック監視
- 数値データを定期的に取得するもの
- 可視化
- 閾値設定によるアラート
チェック監視
チェック監視
- OK/Warning/Critical/Unknown
- コマンド終了ステータスで状態を判定
- 0: OK
- 1: Warning
- 2: Critical
- Other: Unknown
Nagios/Sensu/Consul/Mackerelとかで使われている
メトリック監視
時系列データの
を空白区切りで出力する
% ./battery.pl
macbook.pmset.ib0 73 1467427252
Sensu/Graphite/Mackerel等で使われている
おもしろ事例
Macのバッテリーモニタリングプラグイン
pmset コマンドの実行結果をparseして整形出力してるだけ。
#!/usr/bin/env perl
use 5.014;
use warnings;
my $binfo = `pmset -g ps`; # <- ここで `pmset` コマンド実行
die "pmset failed: $!\n" if $!;
my ($battery) = $binfo =~ /\t([0-9.]+)%/ms;
die "failed retrieving current_battery: $binfo\n" unless defined $battery;
say join "\t", 'macbook.pmset.ib0', $battery, time; # <- 出力
プロダクションでの事例
自分で監視を入れて自分で問題を発見する
- アプリケーションエンジニアが自主的に監視を設定
- 社内リリース時に goroutine leakを発見
- 問題点を発見して修正
h2oに対する要望
server-status available on h2o 2.0.0 or later!
yay!
- (このエンドポイントは本来オープンにするものではありません)
- mackerel-plugin作成中(ほぼできてる)
敷居を下げる
- 監視をインフラ任せにしない
- インフラの人もアプリケーションエンジニアを巻き込めるようにする
- インフラ専任がいなくても、なんとかなるように
- 監視設定に権威を作らない
監視のコード化まとめ
- 「何を監視するか」を考えながら作れるのが理想
- 監視プラグインを書くことはそんなに難しくない
- むしろアプリケーションエンジニアが得意な領域
- インフラ任せにするのは損(お互いにとって不幸)
- 何を監視するのか考えて自分でコード化する
- 定期的に
COUNT(*) とかSQL発行してるのであればプラグインにする
- お使いの監視システムにプラグインを登録しやすくする
mkr monitors
監視設定をリポジトリ管理してCIで自動反映
アラートに対するアクション
- Slackなどのchat通知もSaaSならではで便利だが
I ♥ Webhook
- Mackerelのアラート通知はWebhookで受け取ることが可能
- Webhookには夢がある
MackerelのWebhook関連のOSS
ご活用ください！
監視だけじゃないコード化
全てのホストに監視エージェントが入っている
- 監視システムは全てのサーバー情報を知ることができる
- 実ははてなの初代Mackerelはそっちの思想の方が強い
- 最初にサーバー群をRoleで管理する仕組みを作った
- Roleに対して監視設定を行いたくなった
- 今でもアプリケーション・サーバー一覧をMackerelから取り出してdeployとかしている
- 今後はホストに紐づくメタデータを管理する機能を強化する
以上
【急募】We are Hiring
- はてなではエンジニアを募集しています
- 東京でも絶賛採用中
- もちろん京都にもおいでやす