11

アプリケーションの状態監視システムは、あなた (開発者) や上司 (IT マネージャー) や運用 (オンコール) スタッフのために、少なくとも何をする必要がありますか?

最小要件を超えて他に何をする必要がありますか?

「インフラストラクチャ」アプリケーション (ms-exchange、apache など) を監視するだけで十分ですか? それとも、個々のユーザー アプリケーション、Web サイト、およびデータベースも監視する必要がありますか?

後者の場合、それらについて何を知る必要がありますか?

補遺: ご意見ありがとうございます。インフラストラクチャの監視ではなく、アプリケーション レベルの監視を本当に探していましたが、両方について知っておくとよいでしょう。

4

9 に答える 9

12
  • アプリケーションが実行中かどうか。
  • 異常な CPU/メモリ/ネットワーク使用量。
  • 未処理の例外を報告します。
  • さまざまなモジュールのステータス (該当する場合)。
  • 外部コンポーネント (データベース、Web サービス、ファイルサーバーなど) のステータス
  • 保留中のバックグラウンド タスクの数 (該当する場合)。
  • おそらく、アプリケーションの使用状況を追跡し、最も使用されている/使用されていない機能に関する統計をレポートすることで、最適化が最も有益な場所を知ることができます。
于 2008-09-17T02:51:12.317 に答える
2

素晴らしい質問です。

私たちは、運が悪かったので、しばらく前に私たちのニーズに合ったアプリケーションレベルの監視ソリューションを探していました。人気のある監視ソリューションは、主にインフラストラクチャを監視することを目的としており、私の意見では、ほとんどの中小企業の要件には複雑すぎます。

（主に）次の機能が必要でした：

  • アラート-インシデントについてできるだけ早く知りたかった
  • 痛みのない管理-ホステッドサービスが最適
  • 視覚化-何が起こっているのかを知り、データからある程度の知識を得るのは良いことです

適切な解決策が見つからなかったため、独自の解決策を書き始めました。最後に、AlertGridと呼ばれる稼働中のサービスで終了しました。（もちろん無料でチェックできます。）

その背後にある考え方は、カスタム監視シナリオを処理する簡単な方法を提供することです。統合APIは非常に単純です（2つの必須パラメーターを持つ1つの関数）。その瞬間、私たちと他の人はそれを次の目的で使用しています。

  • スケジュールされたタスク（cronジョブ）を監視する
  • アプリケーションロジックの実行全体を監視する
  • アプリケーションのエラーに関するアラート
  • AlertGridを使用した基本的なインフラストラクチャ監視の例にも取り組んでいます
于 2010-08-27T14:04:18.717 に答える
2

答えは「場合による」です。なぜ監視する必要があるのですか？運用スタッフの人数はどのくらいですか? 報告は必要ですか？アプリケーション環境は？アプリケーションが失敗しても誰が気にしますか? 例外が発生した場合、誰が気にしますか? 回復可能なエラーはありますか? 私は長い間、このような質問をすることができました。

于 2008-09-17T02:51:23.080 に答える
2

これは非常に自由回答の質問ですが、物理的な測定から始めます。
1. このサイトをホストしていると思われるすべてのマシンは ping 可能ですか?
2. コンテンツを提供するはずのすべてのマシンが、実際に何らかのコンテンツを提供していますか? (理想的には、これは外部ネットワークからヒットします。)
3. 各マシンで予期される各サービスが実行されていますか?
3a. それらのサービスは最近実行されましたか?
4. 各マシンにハードドライブの空き容量はありますか? (データベースを忘れないでください)
5. これらのマシンはバックアップされていますか? 前回はいつですか？

システムの物理的な監視をレイアウトしたら、システムに固有のものに対処できますか?

1. 自動化されたスクリプトはログインできますか? どのくらいかかりましたか？
2. ライブのユーザーは何人ですか? 100 万の偽アカウントが追加されたことがありますか?
...
この種の質問はより曖昧になり、非常にシステム固有のものになる可能性があります。それらは通常、物理的測定に応答するときに反応的に導出することもできます。ハード ドライブがいっぱいになりました。多くのエージェントがあまりにも多くの偽のユーザーを作成したため、Web サーバーのログがいっぱいになった可能性があります。そういうこと。

プラン A は必ずしも事後対応型である必要はありませんが、これは多くのサイトが監視システムをセットアップする方法です。

于 2008-09-17T02:54:55.710 に答える
1

少なくとも、システムが正常であることを知りたいと思います。これは、システムが正常であることを定義する主観的なものです。コンピューターが稼働しているか、必要なリソースが存在するか、データがシステムを流れているか、データが適切に結果を生成しているかなどです。

私のプロジェクトでは、このほとんどを監視し、次にいくつかを監視します。それは本当に、すべてが機能していることを分析するために使用できる最高レベルに帰着します。私たちの場合、データ出力まで知る必要があります。これらのマシンが稼働していることを知る必要がある場合は、経験の浅いエンドユーザーに何が問題なのかを示す必要がありません。

データの結果を調べすぎている場合は、多くのハードワークを実行する「既成の」ツールもあります。周りを見回しているときは特にNagiosが好きでしたが、簡単に表示できる以上のものが必要だったので、独自の監視システムを作成しました。基本的に、システムの「特殊性」、メモリ/CPUスパイクなども監視します。

于 2008-09-17T02:57:08.807 に答える
1

最低限: 実行されていることを確認してください :)

ただし、他のいくつかのものは非常に便利です。たとえば、CPU 負荷、RAM 使用量、および (マルチユーザー システムでは) どのユーザーが何を実行しているかなどです。また、ネットワークにアクセスするアプリケーションについては、各アプリケーションのネットワーク接続のリスト。また、(クライアント コンピューターにアクセスできる場合) アプリの「ウィンドウ タイトル」を確認できると便利です。2 ～ 3 分ごとに変更されているかどうかを確認して保存してください。また、アプリケーションによって開かれているファイルのリストは非常に便利ですが、必須ではありません。

于 2008-09-17T02:49:52.850 に答える
1

これはかなり単純だと思います。何か問題が発生する前に十分に早く警告できるように監視してください。つまり、依存関係とアプリケーション自体を監視します。

監視しているアプリケーションの詳細を提供しない場合、詳細を提供することは非常に難しいため、原則としてそれを使用することをお勧めします.

于 2008-09-17T02:53:23.293 に答える
1

ご意見ありがとうございます。インフラストラクチャの監視ではなく、アプリケーションレベルの監視を本当に探していましたが、両方について知っておくとよいでしょう

違いは次のとおりです。

  • インフラストラクチャの監視は、サーバーに加えて、MS Exchange Server、Apache、IIS などになります。
  • アプリケーション監視は、ユーザー マシンとユーザーがジョブを実行するために使用する特定のプログラム、および/またはサーバーと、データの流れを維持するために実行するデータ移動/バックエンド アプリケーションです。

線引きが難しい場合もあります。単純化しすぎた定義は、「チームが作成した場合はアプリケーションであり、購入した場合はインフラストラクチャです」となる場合があります。

実際には両方を監視するのが最善だと思います

于 2008-11-13T05:30:14.703 に答える
1

必要なことは、アプリケーションのビジネス プロセスを分解し、主要なビジネス コンポーネントでソフトウェアにイベントを発行させることです。さらに、エンド ツー エンドの合成トランザクションを作成する必要があります (たとえば、エンド ユーザーが Web サイトをクリックするのをエミュレートします)。そのすべてのデータが監視ツールに送られます。過去に、Tivoli Monitoring の JMX アダプターに流れ込むアプリケーションの JMX を実行した後、「偽のユーザー」を実装し、結果を Tivoli Monitoring のスクリプト アダプターにパイプするスクリプトを実行しました。Tivoli Monitoring はデータを取得し、その生データからアプリケーションの正常性とパフォーマンスのグラフを作成します。

于 2010-06-17T23:17:30.820 に答える