私は今はオンコール業務はありませんが(顧客とのミーティングや出張により、オンコールをすることは意味をなさない)、Server Densityのモバイルアプリで(Android and iOS)アラート監視することができます。これにより、当社が使用する他の監視ツールのアプリと一緒にホーム画面上で見ることができます。
MongoDBはすべてのシャードを均等にバランスを保つようにしますが、高いロック% によるmoveChunk操作の遅れなどシステムに制約がある場合には、遅れが出てきます。そのため、定期的にクラスターが均衡を保っているか注視しておくべきです。当社では これを解決する無料のツールをリリースしました。これは、単独で、プログラムまたは Server Densityのプラグインの一部として実行することができます、
apache-topの使用はリアルタイムでのデバッグや、現在サーバー上で何が起こっているか調査するのに役立ちますが、一定期間の統計情報を収集したい場合には、あまり役立ちません。この場合に Server Density のような監視用の製品が役立ちます。当社の監視エージェントは、Apacheサーバーのステータスの出力を解析サポートして、秒ごと要望やアイドル/ビジー状態のWorkerに関する統計を提供できます。
Server Densityのようなツールを使用することにより、これを可視化でき、CPUがオーバーロードしている場合に通知を受けるように設定することができます。 – これらの指標を理解し、CPUアラートを設定するための当社のガイドブック が役立ちます。Linuxでは、すべてのCPU間でこの平均値は、平均負荷と呼ばれる別のシステム指標に抽象化されます。これは、パーセンテージではなく小数であり、例えば、CPUへのアクセスを待っているプロセス時間の長さなど、オペレーティングシステムの観点から負荷を把握することができます。平均負荷のための推奨のしきい値は、どれだけ多くCPUとコアを持っているかに依存します。 – 負荷の平均についての当社のガイドブック はさらに詳しく理解するのに役立ちます。
Apacheのリモート状態の監視
上記のすべての指標はApacheとそれが稼動するサーバの内部状態を監視しますが、ユーザーの経験を監視することも重要です。これは、外部の状態及び応答時間のツールを使用することによって達成されます。- Apacheインスタンスが世界の地域から(お客様がどこにいても)トラフィックにサービスを提供しているか、また応答時間のパフォーマンスを知りたいはずです。それにより、Apacheサーバの能力を増加させたり、また負荷分散クラスターに多くを追加することで、どの段階でより容量を追加する必要があるか知ることができます。Server Density のビルトインのウェブサイト監視.ようなサービスを利用するのが簡単です。カスタマイズされた場所から、パブリックURLと他のエンドポイントの状態を確認することができますし、パフォーマンスの低下や停電があった場合にアラートを受信できます。
今年の2月に、当社ではすべての運用マニュアルを一元化し、刷新を開始しました。私はいくつかのツールを試してみましたが、Server Density に関するあらゆる情報を保管するためにGoogle Docsを使用することにしました。すべてのインフラの管理についてはPuppetを活用しています。何がインストールされているか、設定、サーバーの管理、フェイルオーバーや配備など、ほとんどすべてのドキュメントを管理しようしていますが、他の文書のドキュメントの管理も必要です。最も重要なのはインシデント対応のガイドブックで、これはアラートが発信された際に、当社の緊急対応チームが対応処理のために確認するすべてのチェックリストです。
当社では、インフラストラクチャ全体のパフォーマンス指標のレビューを毎週行っています。これは、自動化された監視やこれらの指標の警告に置き換えるものではありません。しかしながら、時系列的にわずかな性能の低下を見つけることができ、インフラストラクチャ内の問題を調べ、性能の改善に間にあうようにコードベースをスケジュール化して、アップグレードのための準備することができます。 Server Densityを使用するので、Server Density の監視が簡単にできます。それは、通常はパフォーマンスのダッシュボードにあらかじめ設定した時間間隔でチェックするだけで、ほんの数分かかかります。