合成モニタリングのベストプラクティス

合成モニタリングは、今日のSaaSおよびWebアプリケーションとネットワークのパフォーマンスを確認するための最新の方法です。スクリプトを使用して、エンドユーザーがアプリケーションを体験するときにたどるパスをエミュレートします。

合成のベストプラクティスが必要な理由

合成モニタリングは、ITスタッフにビジネスクリティカルなSaaSおよびWebアプリのパフォーマンスコンテキストを提供します。全社的な展開を除いて、ITスタッフは、問題が発生するまでSaaSアプリを操作することはめったにありません。総合的な監視は、IT部門が時間の経過に伴うベースラインのパフォーマンスを理解し、その期待値をユーザーから聞いた問題と一致させるのに役立ちます。

多くの合成プロバイダーは、これらのアプリのアラートの最初の行として基本的な可用性チェックを提供していますが、現代の世界では、アプリがダウンすることはめったにありません。むしろ、ローカルネットワーク、ワイドエリアネットワーク、混雑などの無数の要因により、アプリのパフォーマンスが低下することがよくあります。一部のSaaSプロバイダーはアプリをアンダープロビジョニングしますが、これはAWS、Azure、GoogleCloudの自動スケーリングの世界ではますます頻繁に発生しません。 ITチームはアプリのログインページではなく会社のホームページをターゲットにしているため、可用性チェックも失敗します。さらに、ログインページは、監視対象のアプリに実際にログインし、実際のユーザーと同じようにデータを読み込むスクリプトの代わりにはなりません。

合成モニタリングを機能させるためのベストプラクティス

ビジネスに適した合成セットアップを見つける方法はいくつかあります。 ITチームは、合成モニタリングソリューションを構成する際に、これらの詳細を考慮する必要があります。

チケット分析を行う

チケットの過去1か月または四半期を見て、どのアプリが最も厄介だったかを分析します。アプリに再現性のない問題、一般的なパフォーマンスの問題、注目度の高い問題があるかどうかにかかわらず、総合的な監視用にリストを用意しておく必要があります。

高価なアプリを探す

アプリに最高額を支払っている場合、ユーザーエクスペリエンスが悪いと、アプリの生産性や信頼性が損なわれる可能性があります。これらのアプリを事前に特定し、積極的に監視することで、これらの問題を軽減できます。

アプリのフットプリントを検討する

GSuiteやOffice365などのアプリのパフォーマンスの問題は、従業員ベース全体に影響を与える可能性があります。それらを適切に監視する必要があります。 Office 365のログイン画面での可用性チェックでは、それが削減されることはありません。これらの大規模なアプリはそれぞれ、実際には独立して動作するアプリのエコシステムであり、ほとんどの場合、同じ場所にあるマシンのさまざまなクラスターでホストされています。

追跡可能な目標を設定する

総合的な監視ソリューションを設定することは、設定して忘れる努力のように思えるかもしれません。それはほとんど真実ですが、総合的な監視から何が必要かを判断するために、事前にいくつかの準備作業を行う必要があります。多くの場合、合成スクリプトは、時間の経過に伴うアプリの通常のパフォーマンスを示すために使用されます。これにより、ITチームは、ユーザーの苦情を待つ代わりに、逸脱について警告し、アクションを実行できます。ただし、行動を起こすには、より多くの情報が必要です。ネットワークコンテキストは、SaaSおよびWebアプリを監視するために非常に重要です。これは、アプリがソースとユーザーの間を移動するときに、動的に変化するルーティングでLANとWANを移動するためです。問題の根本原因を理解するには、インシデント発生時のルート、アプリ、エンドユーザーを関連付けることが重要です。

総合的な監視の目標は、ユーザーの操作を厳密にシミュレートして、ユーザーが影響を受ける可能性があるときにアラートのしきい値がトリガーされるようにすることです。これは、アプリケーションのマーケティングで生成されたホームページとゲートウェイのログイン画面を無視することを意味します。より複雑なスクリプトを作成することは、合成モニタリングから正確で有用な結果を得る秘訣です。最終的には、問題をより迅速に解決するIT運用チームの能力が得られるはずです。一般的な苦情のチケット解決時間を追跡することは、総合的な監視の成功を評価するための優れた方法です。