はじめに

サーバは構築して終わりではなく，むしろその後，継続してサービス(たとえば，サイトなら表示できるとか)を提供することが重要です．継続してサービスを提供するには，サービス提供できていない状況(=異常)を検知する必要があります．そのため，監視をする必要があります．

しかし監視をすることには色々な点でコストがかかります．まず，監視対象とは別の監視拠点を用意しなくてはなりません．これは監視対象と監視拠点を一つにした場合，障害の内容によっては検知できないことがあるためです．また，監視拠点が落ちてしまっても監視を継続できません．そのため，通常は複数拠点による監視が必要です．また，それらの監視拠点を自前で保つ場合は監視拠点のメンテナンスコストもかかります．

そしてサークルでは(サークルでなくてもですが)予算は限られています．また，潤沢にサーバ管理に投入できる人的リソースがあるわけでもありません．また，代替りが頻繁に行われるため，あまり複雑なことをしてよくわからないけどうごいているものをふやすことも得策でもありません．そこでいかにこれらのコストを下げるかということが重要になってきます．

　監視の構成

サークルのwebサイトは商用サイトと比べクリティカルな案件ではありません．したがって，サービスのダウン検知だけを行えれば良いというのが最低条件です．また，即座にログインできるとはかぎりませんのでできるかぎりメトリクスはとっておきたいです．そこでサイト表示不可，ユーザから見て正常に動作していない状況ではアラートを出す，それ以外はメトリクスをとるのみという方針にすることにしました．

メトリクス収集にはMackerelを利用しています．これは下記の理由によるものです．弊サークルではIDCFクラウドを利用しています．そのため，MackerelのIDCFプランが無料で利用できます．通常のFreeプランとの違いはホスト数が無制限であること，グラフ表示期間が1週間であることです． Mackerelでは基本的にメトリクスのみを取るようにしています．とっているメトリクスは下記となります．また，wikiと階委員専用ページはdockerで動いています．そのため，dockerのメトリクスを取るようにしています．例外的に「ログ監視」と「ディスク残量」の監視は行っています．

外形監視にはUptimeRobotを利用しています．これはMackerelでは外形監視を無料枠ではできないためです．弊サークルのサイトは「トップページ」，「Wiki」，「会員専用ページ」の1つの静的ページおよび，2つのWebアプリケーションで構成されています． UptimeRobotではこの3つのそれぞれのトップページを文字列検知で監視しています．

議論

UptimeRobotでの外形監視は正常にサービスを提供できているかの基準で監視を行っています．そのために，特定Webアプリケーションがみれないということを防ぐため，アプリケーション単位で外形監視を作っています．単に疎通ではなく，監視文字列検知にしている理由は以下のとおりです．ひとつめはアプリケーション側の何らかの不具合により200(正常ステータス)を返しているものの必要な情報を提供できていないことを防ぐためです．アプリケーション側の不具合により，空白ページが発生してしまっても疎通確認ではこれを検知することはできません．二つ目の理由は改ざん防止です．悪意がある変更がhtmlに加えられた場合でも監視文字列未検知で検知できる可能性があります．もちろん，html全体の変化を追跡しているわけではないので，微妙な変化には耐えられませんが，通常の運用では監視文字列検知でよいと考えています．

mackerelでの監視は外形監視では検知できないがサービス影響が出る可能性があるもの，サービス影響はないものの，対応に時間が掛かる可能性があるものを監視する方針としてします．サークルのサーバではありませんが，運用している別サービスではログ監視を複数いれています．これはエラーログにエラーがでていて使えない機能がでていたものの，外形監視で検知できていなかったためです．ディスク残量はファイル削除で対応できる場合は問題がありません．しかし，ディスク増設が必要な場合は金銭的問題もありサークルでの承認を得る必要があり対応に時間がかかるため監視をしています．

サークルのサーバではあまり障害が起きていないので，同様にUptimeRobotとMackerelで監視している別サービス(shimaidon.net)でのアラートと状況について書きます．理想は障害発生時に即座にログインで対応することです．現実には仕事でしているわけではないためつねに見張ってるわけにはいきません．したがって障害時のリソースをサーバにログインしてとることができないことがあります．しかし，メトリクスをMackerelでとっているため，あとからでも当時のリソースをある程度は復元できます． 1週間分のデータでも周期的な変動でまた起きる可能性があることかどうかが推測できます．これは再発防止策を考える必要があるかの判断基準として助かっています．また，検知できなかった障害については監視項目追加，対応が不要だった項目については抑制という方針をとっています．

まとめ

UptimeRobotで外形監視を，Mackerelでメトリクスをとることで低コストで監視が行えるよという話でした．

明日は@here_1115氏です！