サーバー監視ツールを作ろう – 1日目

Pocket
LINEで送る
GREE にシェア
LinkedIn にシェア

サーバー監視スキルを持っているエンジニアは、非常に高品質なサービス運用クオリティを持っていると言ってもいいのですが、もちろんそれは、サーバー監視を知っているエンジニアと知らないエンジニアで比べれば雲泥の差という事で、その先に監視アルゴリズムにも深いクオリティが存在します。
 

難しく言うとこのブログを読んでもらえないので、監視アルゴリズムというのは、WEBサービスを運用する時に、どういう監視体制やツールを使うといいかと言うことをきちんと理解できているかどうかという事です。
 

世の中に出回っている便利なツールをたくさん駆使して使っていくのもいいかもしれませんが、ここではエンジニアブログとして、自分が使いやすい監視ツールを自ら作ってしまおうという企画を立ち上げて、今日はその第1回目です。

サーバー監視ツールに求められる事

個人的な感覚で言うと、「サーバー監視に高価なシステムは不要」という点です。
 

余っているサーバーや、予備で設置されているサーバー、スペック不足でお蔵入りしたような非力なサーバーなどを使ってそれらを監視サーバーとして使うと言う事で、エコシステムとして使えるのも、費用をかけないポイントとして重要です。
 

有償システムなどを使って便利にグラフレポートを出してもらうことに重きを置く人もいるかもしれませんが、監視ツールで最も大事なことは、「サービスが正常に動作しているかどうかをリアルタイムに判断できる」事が重要で、サーバーダウンのタイミングなどをメールで即座に教えてくれるという事が1番の仕事になります。
 

こうした、監視思考をきちんともったエンジニアがプロジェクト内にいるだけで、WEBサービス運用として、ダウンさせないシステムを構築する事が可能になるので、もしかすると、この記事に興味がある人で、自分の行なっているプロジェクトに少し不安を感じているエンジニアの方は、以前に書いた記事を参照してみてください。
 

WEBサービス運用における、監視とバックアップについての考察

簡単な構築フローと構築条件

僕の会社ですでに運用しているサービスや、WEBページなどがいくつかあり、VPSやAWSを複数台稼働しているため、それらの監視を行うことを第1目的にしています。
 

その後、新たなサービスなどを登録できるような管理画面を持ち、できれば監視計測しているログデータを分析レポートとして表示するような機能までもてれば、商用としても十分に使えるサービスになりえるとも考えています。
 

これまで手作りで、こうしたチェックバッチは作ってきた事があるんですが、その時の問題点としては、監視対象のサービスドメインが30個近くあり、監視する対象サーバー機器が150台、拠点は色々なホスティングだったり、VPSであったり、クラウドサーバーという感じで、統一性の無いという状況もあったため、できればそうした環境での網羅性も持ちたいと考えていました。
 

こうした対応環境も考慮して、「外部監視」と「内部監視」の視点でどちらでも対応でき、設置もめんどくさいインストールなどをできるだけ省いたシステムにすることを目的にしています。
 

仕様書を書いてみた

上記の条件を元に、このシステムの仕様概要を書いてみました。
 

Summery(概要)

任意のサーバーやWEBサービスの監視を行うサービス。
アカウント登録して、対象URLやIPアドレスなどで5分足監視が開始できる。
ssh(鍵)などのアクセスで、より詳細監視をすることも可能。
簡易なアクセス監視だけでも利用価値あり。
閾値を任意登録することで、メール送信のクオリティ調整

Monitoring-Specification(監視仕様)

– Ping check
– http,https access
– 表示したページに任意文字列があるかどうかのソースチェック
– sshアクセスして、dfコマンドチェック
– sshアクセスして、LAチェック
– sshアクセスして、Memoryチェック
– sshアクセスして、proc数チェック
– ssl有効期限チェック

Prequisite(必要条件)

– 外部アクセスが可能な公開サービスのみ有効
※任意のローカル環境への対応の場合は、オンプレ機器販売にて対応可能
– sshアクセスが可能なサイト(鍵が必要な場合は、管理画面で鍵アップロードすることで対応可能)

Admin-panel(管理画面)

– ユーザー登録(メールアドレス)
– 無料登録は、5サイトまで(有料は無制限)
– ヘルスチェック状態をグラフ表示
– メール送信履歴の表示
– データ保持期間は1年間
※保持期間延長の有料サービスもある。

How to respond(対応手段)

– 障害の時にどういう風に対応するかを事前セットする事ができる。
※コマンド実行して対応することも可能。
※メールで送信する事でその場でいつでも誰でも対応が可能になる。
– 運用手順などを便利に行う事が可能。

システム活用

– このシステムを複数箇所(サーバー)に設置する事で監視元を増やす事が可能になる。
他に立ち上がっている監視ポイントは、自動的に相互に監視する事が可能になる。

何故既存のソフトを使わないのか?

今回こだわりたいのは、インストールするという作業を無くしたいと考えて、外部監視だけでも成り立つ仕組みが欲しかったのと、サービス特有の情報監視を行うことを目的にしているので、既存ソフトなどでは、めんどくさいカスタマイズを行わなくてはいけなくなるのであれば、それをプラットフォーム化して自分で構築してしまおうという取り組みです。
 

あくまで、僕のブログネタとしてスタートさせるプロジェクトでもあるので、技術的なアイデアや、要望、余計なお世話コメントなどは、どんどんいただけると励みになります。

Leave a Reply

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です