はじめに
本投稿はSchoo Advent Calendar 2016の25日目の投稿になります。
僕自身のエンジニアとして主戦場はここ数年はインフラ周りなので、そのあたりの投稿を何かしたいなぁ…と思い、サーバの監視や運用で利用しているツール類を今更ながら紹介してみたいと思い立ち、キーボードを叩いている次第です。
ちなみに・・・
以降で幾つかを紹介しますが、複数あるサーバで全てを使っているわけでもありませんし、紹介する以外のツールも利用しているので、そのあたりはご了承ください。
Amazon CloudWatch
通常の監視は別ツールで環境を構築している（後述のGrafanaなど）のですが、普段から注視する必要のない監視項目については、サービスをAWS上で構築していることもあってCloudWatchで監視しています。
ただし、例え普段から注視する必要のない項目であっても、監視の各項目で閾値を考えた上、閾値を超えた場合はSNSの通知を通してLambdaファンクション経由でSlackに通知がされるようにもしています。
普段見ない（あまり見る必要のない）項目での異常値が、思わぬ障害を事前に検知できることもあるからです。
（とはいえ、ほとんどCloudWatchからのAlertは飛んできませんけどね。）
- Amazon CloudWatch ( https://aws.amazon.com/jp/cloudwatch/ )
Grafana
最近はフロントエンドとして利用している人も増えたと思うのですが、監視、それもパフォーマンス監視として各種の数値情報の視覚化にて利用しています。
インフラ担当の僕は日々、必ず数回はGrafanaの画面は確認しています。
監視まわりのシステム構成は、（ちょっと簡略化していますが）以下のようになっています。
上記構成図にも出てますが、稼働監視ではSensu使っており、Sensu-Clientを各サーバにAgentとして仕込んであるので、これらのAgentから各種メトリクスをInfluxDBという時系列DBに送りつけています。
そしてGrafanaは、InfluxDBに記録された各種メトリクスを視覚化するように設定しています。
また監視サーバは、これがDownしてしまうと障害が発生しても何も気付くことができない状態に陥ってしまうので、Multi-AZで複数台でクラスタを組んであります。
ただ、、、現状の監視サーバは、インフラ関連の様々なツール類も同じサーバを利用していたり、かなり「ごった煮」状態のサーバになってしまっているので、監視の仕組みも近々Prometheusあたりのツールに移行しつつ再構築するつもりです。
（「Prometheusすばら！！」な記事もチラホラと出てきているようですし…）
- Grafana ( http://grafana.org/ )
- InfluxDB ( https://www.influxdata.com/time-series-platform/influxdb/ )
- Sensu ( https://sensuapp.org/ )
- Prometheus (https://prometheus.io/)
Monit
定番のMonitも各サーバ内での自律稼働監視を目的に、各種サーバにて利用しています。
常時稼働していないとサービスに支障をきたすデーモンの監視が主な利用方法です。（例えばNginxなど）
稼働させているデーモンのバグなどでの突然死や、それ以外にもサーバの設定状況や負荷状況によってはデーモンがOOM Killerで落とされる場合などに、何の作業もすることなくデーモンを起動し直してくれるので重宝します。
ここでデーモンプロセスの起動を扱っているみたいな書き方をすると・・・
「ってか、Upstartあるじゃん…」
みたいな声も聞こえて来そうですが・・・MonitをUpstartで立ち上げておいて、Monitはプロセスの管理と通知を担当させるというような分担にしています。
ちなみにSchooではDockerのコンテナの監視にも利用しています。
このあたり（MonitによるDockerコンテナの監視方法）、なかなかググっても出てこない気もするので、Tips的にMonitでのコンテナの監視を、Schooではどのようにしているかを書くと…
MonitのVer5.2以降（だったと思うｗ）は、プロセスの監視にpidファイル以外にもMATCHINGでプロセス名を正規表現でチェックすることができるようになっています。（See: Document）
これを利用して、例えばコンテナがstopしているときに自律的にstartしたい場合があるとすると、Monitでの監視設定を以下のように記載できます。
check process container-elasticsearch with matching "elasticsearch"
start program = "/usr/bin/docker start <container id|container name>"
stop program = "/usr/bin/docker stop <container id|container name>"
if 5 restarts within 5 cycles then timeout
Dockerの「コンテナは単一の何かしらの機能で立ち上がっていて、それが停止した場合にはコンテナの停止となる」という一般的（？）な使い方をしていれば…の場合ですが。
上記の場合は例としてelasticsearchをコンテナとして動作させているものがあったとして、それをDockerのホスト上でMonitによって監視している場合のMATCHINGを利用した最低限の設定例です。
勿論ここでも、処理が実行された場合はSlackへと通知（restartした旨の通知）がされるように設定していますが、Slack通知の仕方はググれば沢山出てくるはずなので、こちらの設定方法は割愛します。
（Slackへの通知はこちらを参考にすれば問題なく設定できるかと。）
- Monit ( https://mmonit.com/monit/ )
htop
一部のサーバでtopコマンドを置き換え利用しています。
ツリービューで親子関係表示したり、CPUやメモリリソースをテキストグラフィックで表示してくれます。
便利なツールなので一様に全サーバで入れ替えても良いかもしれませんが、そもそもtop系のコマンドは重いのでuptimeやfree、psコマンドで充分対応できるサーバには導入していません。
ごった煮で複数の機能を持っているサーバとか、稼働プロセス数が多いサーバ（Batchサーバとかは、弊社の仕組み上Forkしているプロセスも多いので、ツリービューの開閉が便利です！）とかに導入しています。
- htop ( https://hisham.hm/htop/ )
Kibana
KibanaはElastic社が提供するElasticsearchのフロントエンドGUI（可視化ツール）ですが、SchooでもフロントエンドのWebサーバのLogを色々と確認するために、td-agent+Elasticsearch+Kibana+Nginxな環境を構築して利用しています。
このKibana、つい最近に再構築してみた（ver5.0.x）のですが、UIの変わりっぷりには驚きましたｗ（随分とカラフルになってる！！）
SchooではKibanaでアクセスログをまとめて見ながら、処理に時間の掛かっているURLやエラーとなっているURLなど、その数や状況を確認することができるようにしています。
また、WebサーバのLogというRawdataを可視化することもあり、セキュリティの観点からoauth2-proxyを利用したGoogle認証を設定し、表示できるユーザも制限してあります。
（「PluginでShieldあるじゃん！」ってツッコミは、Shieldが有償なので勘弁してくださいw）
このoauth2-proxyの設定は非常に簡単で、社内向けの設定ドキュメントはあるのですが、（社内向け文書を記事化するのは一手間なのでｗ）どこかで別記事にて公開したいと思います。
- Kibana ( https://www.elastic.co/jp/products/kibana )
- oauth2-proxy ( https://github.com/bitly/oauth2_proxy )
incron
Linuxのinotifyを利用しcron起動ができるデーモンです。
Schooでは何かしらの処理やスクリプトなどを簡略化したいときに利用しています。
例えば、、、
$ touch /var/run/php-fpm/restart
のようにファイルにtouchコマンドでファイル（上記の場合は/var/run/php-fpm/restartというファイル）のタイムスタンプを更新したときの処理として、それにあわせてphp-fpmデーモンを再起動するためのコマンドを以下のように設定して実行することができます。
/var/run/php-fpm/restart IN_MODIFY,IN_NO_LOOP /sbin/service php-fpm restart
使い所としては、結果が即時で戻ってこない（数秒以上かかる）サーバ側でのコマンド発行が必要な場合や、意図的に非同期で処理をさせたいときなどにincronを利用しています。
incronは設定のみでお手軽に非同期処理として利用できるので、結構な頻度で様々に利用しています。
Chef-Solo & ansible
Chef-Soloとansible、どちらも同じ目的での利用をしているツールの紹介なのですが、両方共に使っていますｗ
使い分けですが、明確なルールが現状なく正直なところ作業者の好みで…という状態です。
（もちろん、そろそろルール作って何かしらに統一したいとも考えています…）
過去の経緯からすると、元々はChefを使っていた（僕の入社前）のですが、
「そんなに大量のサーバがある訳でもないし、Chefサーバの運用やら面倒だなぁ…」
と思い、僕が入社したあとにChefサーバを廃止してChef-Soloに変更しました。
その後、開発メンバーも増えていくなかで、ansibleを使う人も出てきて…というのが現状に至る経緯でしょうか。
ちょっとだけ運用周りでの余談ですが、他にも運用まわりではRundeckのようなGUIで一括コマンド実行できるGUIもあったりします。
このRundeckでのホスト定義は、AWSのAPIを利用してサーバリストをTagで絞り込みながら取り出し、yaml形式でホスト情報を自動生成するようにしてあったりもします。
とはいえ、インフラ担当が僕1人なので、Rundeckは僕しか使いませんけどね！ｗ
しかも数カ月に1度使うか使わないか…の頻度だし、クラスタコンソールをパッと開いてくれるスクリプトをローカルに用意すれば同じこともできるので、そのうち環境からは削除しちゃうかも・・・ｗ
- Chef ( https://www.chef.io/chef/ )
- ansible ( https://www.ansible.com/ )
- Rundeck ( http://rundeck.org/ )
まとめ
幾つかの利用しているツール類を、粒度を変えつつ紹介してみました。
監視周りではサーバで稼働してるagentのpluginはgolangで書いてあったりとか、もう少しツッコんで説明できる要素もあるんですが、そのあたりは追々（これも機会があればｗ）、また書きたいと思います。
もしかしたらAdvent Calendarの締めの記事としては、ちょっと軽めの内容かもしれません。
また、一定「読むこと」を意識していますが、校正をキッチリしている訳でもない故に読み辛いかもしれません。
更に「技術」の話ではなく、技術に絡む他の「何か」を記事にしたほうが良かったのかもしれません。
それでも使い古された本投稿のような紹介系の記事では、知らなかったものや技術を知る「切っ掛け」になれば良いとも思いますし、知っていたとしても実利用されているという「実例」として、個々の「知識」にストックされれば良いと思います。
欲を言えば、本記事にてSchooという会社やサービスを知ってもらう一つの切り口ともなれば良いとも思います。
そしてSchooを知った上で更に、今回のSchoo Advent Calendar 2016を切っ掛けに「メンバーとして一緒に！」といったような思いを持ってくれる方がいれば幸いです。