IT運用チームがパフォーマンスの問題をトラブルシューティングするときにアラート通知に大きく依存するのは当然です。 非常に一般的であるため、最新のものを捧げました 上級ユーザーのWebキャスト トピックに。 Webキャストからの重要なポイントは、LogicMonitorダッシュボードを適切に調整されたアラート通知と組み合わせて使用すると、解決時間を大幅に改善できることでした。 新しい光沢のあるダッシュボードNOCウィジェットの使用方法に関するいくつかのベストプラクティスを学ぶために読んでください。
トラブルシューティングは、LogicMonitorからアラート通知を受信した瞬間から始まります。 アラートの調査方法はケースごとに異なることを認識していますが、LogicMonitorダッシュボードが設定されている場合 戦略的 問題の問題をより迅速に特定するのに役立ちます。
各アプリケーションを反映するようにダッシュボードを設定することをお勧めします。 これは、アプリケーションのさまざまなコンポーネントすべてのデータとステータスを明確に示すことを意味します。 たとえば、次のダッシュボードは新しいNOCウィジェットを使用して、左側にバックエンドWebサーバーのステータス、中央にロードバランサーのステータス、右側にフロントエンド外部サービスチェックのステータスを表示します。側：
この配置は、アプリケーションのコンポーネントがどのように実行されているか、およびさまざまなコンポーネントが互いにどのように関連しているかを簡単に視覚化できるため、価値があります。 トラブルシューティングの際、アプリケーションを反映するダッシュボードをLogicMonitorから受信するアラートと組み合わせて使用すると、アプリケーションのコンテキストでアラートについて考えるのに役立ちます。 このようなダッシュボードがないと、顧客がアラート通知を受信すると、アプリケーションの状態やアラートに焦点を当てて見落としている可能性があるものについて考えるのではなく、アラートの対象に焦点を合わせる傾向があることがわかりました。
例として、Webサイトが外部のSiteMonitorチェックからダウンしていることを示すアラートを受信し、ロードバランサーが複数のバックエンドサーバーのダウンを報告する場合を考えてみます。 この状況での一般的な反応は、問題がWebサーバーにあると想定することです。ロードバランサーがバックエンドのダウンを報告したため、これは不合理ではないため、調査はWebサーバーのログの確認、Apacheの再起動などから開始できます。この状況のダッシュボードを見ると、Webサーバー自体に問題がないことがすぐにわかります。
アラートをコンテキストで確認すると、問題はWebサーバー自体にあるのではなく、ロードバランサーとWebサーバー間の通信にあることが明らかです。 これにより、ファイアウォールがパスをブロックしている問題や、ヘルスチェックが利用できないためにロードバランサーによって使用されているコンテンツなどの問題に調査がすばやく絞り込まれます。 （理想的には、監視は同じヘルスチェックの内容もチェックするので、これが問題である場合は、監視から明確に明らかになるはずです。）
ほとんどの問題の解決は簡単です–本当の問題がどこにあるかがわかれば。 適切に計画されたダッシュボードは、その問題がどこにあるかを特定するのに役立ちます。
要約すると、次のそれぞれを実行するようにしてください 次の運用上の問題：
- アプリケーションの各コンポーネントの監視を包括的に設定します。
- アプリケーションの論理構造を反映するダッシュボードを設定します。 アプリケーションの各コンポーネントのステータスを表示して、問題が発生したときに機能しているコンポーネントと機能していないコンポーネントをすばやく特定できるようにします。 ダッシュボードに主要業績評価指標をグラフ形式で含めます。これは、上位10のグラフを使用して、多くの情報を効果的に表示するのに最適な場所です（HTTP要求による上位10のWebサーバー、CPUなど）。
- アプリケーションのコンテキストでアラートについて考えてください。 アラートを受け取ったら、ダッシュボードを確認して、アプリケーションのどのコンポーネントが問題を引き起こしているのかを特定します。
ウェブキャストの録画をご覧になりたいですか？ こちらをクリックしてください.
今後の高度なウェビナートピックに関するアイデアやリクエストがある場合は、メールでお問い合わせください。 [メール保護].
Sarah Terryは、LogicMonitorの製品管理チームに所属しています。