最近、私は展開したDrupalサイトのいくつかでダウンタイムに直面しています。サービスやサーバー自体を再起動してダウンタイムに対処するのではなく、積極的に問題にアプローチしたいと思います。サーバー/インフラストラクチャの状態を監視するためのnagios、munin、cactiなどの監視ツールについて読んだことがありますが、実際に運用環境で試したことはありません。私はほぼ99％の時間でDrupalを扱っていますが、サーバーレベルの監視とDrupal（アプリケーションコード）レベルの監視の両方の提案を見つけたいと思います。
基本的に、サーバーの負荷が高い場合、おそらく犯人（または被害者）を指していることを通知されるので、十分な情報に基づいた決定を下すことができます。また、PHPエラー/警告が発生したときに、Drupalレベルの監視（電子メールなど）に使用されるものを知りたいです。（メールサーバー自体がダウンするとどうなりますか？）
回答:
アラートなどを使用して、同じ場所から複数のDrupalサイトを監視したい場合は、あなただけではないと言えます。以下によって満たされることにより、ビジネスのニッチになり始めています。
どちらも商用のSaaSアプローチであり、サービスを試すための無料の制限付きオプションがあります。
また、Drupalモジュールhttp://drupal.org/project/zabbixを使用したオープンソースのZabbix監視オプションもありますが、サーバーを構成して構築する必要があります。
これらすべてのオプションには、サーバーおよびdrupal固有の情報をモニターサーバーに送信するためのDrupalモジュールがあります。
どちらを使用するかに関係なく、私が絶対お勧めすることは、専任のITスタッフがいない限り、独自の監視を維持しないことです。サーバーから完全に独立したサービスに依存します。公開サーバーをダウンさせることと、監視サーバーもダウンしていることを知らないことです。ほとんどの監視サービスには、すぐにリストしたすべての要件が含まれます。
しかし、これが買い物の推奨の質問に変わる危険性があるので、リストした要件に使用するサービスはPingdomです。
これらは、Drupalに依存しないいくつかの提案です。
Drupalアプリケーション自体に関しては、Xdebug + WebgrindまたはXHProfを使用してコードのプロファイルを作成し、この質問に注目することをお勧めします。Drupalスタックパフォーマンスをベンチマークする最良の方法
小規模/中規模サイトのpingdomは便利だから好きです。顧客の観点からすると、何かが間違っているということです。ロードアベレージのようなものは、スタックの構成が大きく間違っている（そうするべきではない）か、Digg / Redditからgettingられている（この場合、とにかくできることは何もないのでなければ）何も意味しない準備済み）。
私はこの種のアラートをクールストーリー、ブロと呼んでいます。これらは、問題の状態を示すものではなく、アクションを促すことのない情報です。クールストーリーとは、アラートを受け取るべきではないものです。彼らはあなたの時間を無駄にし、あなたを妄想させます。Cool Story Broアラートは次のようなものです。
- サーバーの平均負荷は20を超えています。
- ジョブキューには、X個を超えるワークユニットが含まれています。おめでとうございます、おめでとうございます、あなたのキューはそれがすべきことを正確にしています
- 一部のメトリックは、経験的に決定された平均よりも大きくなります。私はこのようなたわごとに個人的に腹を立てます。
ブログの記事を読んでください、それは陽気です。
私が使用していますcheck_drupalを様々なDrupalのサイトを監視します。これは、drupalサイト自体のコード変更を必要としないnagiosプラグインです。唯一の要件は、サーバーにブラシが存在する必要があることです。