eviry tech & service blog

「株式会社エビリー」の社員ブログです。弊社では、クラウド型動画配信サービス「millvi」、ソーシャル動画データ及び分析サービス「kamui tracker」、YouTube総合メディア「かむなび」を開発・提供しています。https://eviry.com/

(初級編)サーバーの外部監視と内部監視について

はじめに

プロダクト開発本部 ゼネラルマネージャーの⇧boraです。
開発本部では、クラウド型動画配信サービスの「millvi」とソーシャル動画データ及び分析サービスの「kamui tracker」の開発・保守を担当しています。
嬉しい事に、弊社では毎年新卒が入社しており、また中途入社の方も増え、若い方が増えて来ています。

今回は一般的な話になりますが、サーバーの監視について、私の見解も含めて記載します。
今は立場上、直接の対応を行なっていないので、これまで在籍していた会社での経験を思い出しながら記載します。
既にやっている方には目新しい内容はないと思いますが、ご了承ください。

監視

監視は、外部監視と内部監視を分けるのが一般的です。

外部監視

外部監視は、ユーザー体験を監視するもので、インターネット越しに監視したいので、サービスをやっているデータセンターやクラウド以外の所にサーバーやインスタンスを用意して、そこから監視します。
ツールは有名どころでは、NagiosやZabbix、Cactiなどがあます。個人的にはNagiosを好んで使っていました。理由は軽量で手軽だから。外部監視としては、これで十分だった。

監視内容は、外から出来るもの全般で、

  • サービスのURL(LB経由)にアクセスして、特定の文字が含まれるか?
  • 上記が閾値(3秒等)以内で、レスポンスが返って来ているか?
  • TCP80や443ポートが空いているか?
  • サービスのドメインでDNSに問い合わせをして、想定された設定値が返ってくるか?

など

外部監視のアラートは、ユーザー体験が損なわれている状態なので、クリティカルな状態の場合が多いです。
まれに外部監視の環境が原因でアラートが上がる場合もあります。(社内のサーバールームに設置していて、社内ネットワークの影響を受けた等)

内部監視

内部監視は、個々のサーバーの状態を監視するもので、インターネットと関係なく監視したいので、サービスをやっているデータセンターやクラウド内にサーバーやインスタンスを用意して、そこから監視します。
ツールは外部監視と同様のモノも使えますし、クラウドならAWSのCloudWatchやGCPのStackdriver Monitoring等も使えます。

監視内容は、リソースやサービスの稼働状況などで、

  • CPU(Load Average)、ディスクの空き容量等のリソースが閾値以下か?
  • ApacheやNginx、Postfix等のプロセスが起動しているか?
  • DBのレプリケーションをしていたら、レプリされているか?
  • NAS等をマウントしていたら、マウントされているか?
  • ログ(Syslog等)に、特定の文字列が出力されたか?

など

内部監視は閾値により、予兆なのか、もうすぐヤバそうなのか、既にやばいのかを分けて設定しないと、クリティカルかどうかを判断するのが難しくなります。

アラートの分類

分類されていない状態でアラートが飛んでくると判断する手間が増えるし、沢山飛んでくると感覚が麻痺して、危機感が持てなくなってしまいます。
引き継ぎ案件では、麻痺状態になっていた事が多かったですが、後からではほぼ何も出来ず。顧客の理解も得られず。
何事も後からやるのは大変なので、その時にやる事が大切ですね。

弊社はプロダクト開発をしているので、最大化したい価値は単発のスピードではなく、将来も含めたスピードや運用の手間の削減。
更に、ちょっとした拘りによる使い易さから、他社では真似できない価値まで強化して行きたいと考えています。

話がそれてしまいましたが、私のベストプラクティスはMLを下記の基準で分けるです。
過去に在籍した2社で導入しており、運用も回っていました。
最近では、弊社でも導入しているSlackに送るのも有効です。

  • critical -> 即対応必要。監視会社にも送って、電話でエスカレーションして貰うのがベスト(受託なら顧客との契約で決める)
  • warnning -> 営業日に対応すれば良い
  • notice -> 情報なので見なくても良いが、たまには見て欲しい。Logwatch等のroot宛のメールを転送

最後に

次回も初級編として、サーバー障害対応の観点と方法について、ケース毎に何回かに分けて書きたいと思います。
とは言え、今のメインはチームや組織作りで、最近やっとプロダクト開発において、価値を最大化するにはどうすれば良いかが見え始めて来たので、そちらもいずれ書きたいと思っています。