最新のインフラストラクチャは、オンプレミスデータセンターの従来のフルスタックシステムから、それらのフルスタックシステムを構成するために使用されていたより小さな階層化されたサービスに進化し、サポートインフラストラクチャの管理を抽象化できるようになりました。 これがクラウドコンピューティングの根底にある現象です。
クラウドは、メンテナンスの負担のないインフラストラクチャと、サーバーの構築と構成に必要な時間のないスケーラビリティを約束します。 管理の負担がクラウドプロバイダーに移されているため、このような約束が存在します。 この責任の移転により、可視性が制限され、監視がより困難になります。
ホワイトボックスとブラックボックスの監視
伝統的に、モニタリングは次のように分類されます 白い箱 or ブラックボックス モニタリング。 ホワイトボックス監視は、システムタイプ（ハードウェア、オペレーティングシステム、実行中のアプリケーション）に基づく監視メトリックで構成されます。 一方、ブラックボックスの監視には、システムに依存しないメトリックの監視が含まれます。
システム固有の情報が常に利用できるとは限らないため、クラウドサービスではホワイトボックスの監視が常に可能であるとは限りません。 たとえば、us-east-2でEC1インスタンスをサポートするクラウドプロバイダーが管理するシステムの詳細を知ることはできません。 ただし、監視対象のデータは通常、サービスの状態を包括的に把握するのに十分なほど具体的ではないため、ブラックボックスの監視だけでは必ずしも十分ではありません。 たとえば、ロードバランサーがC名に応答していないことを知っているだけでは、問題を特定するのに十分ではありません。 その後、バックエンドエラーや異常なホストが存在するかどうかがわかった場合は、問題がDNS構成にあるのか、バックエンドWebサーバーの可用性にあるのかを特定できます。
クラウドサービスは、ブラックボックスシステムとホワイトボックスシステムの両方の組み合わせと見なすことができるため、完全な可視性には次の両方が必要です。
ホワイトボックスコンポーネントの監視を詳しく見てみましょう。 クラウドで実行されているアプリケーションとサービスのパフォーマンスは、エンドユーザーにとってパフォーマンスの低いアプリケーションを避けようとしている可能性があるため、通常、理解して監視することが最も重要です。 これはリソースパフォーマンスの監視であり、通常、メトリックが関連するリソースに固有であるホワイトボックス監視アプローチで実現されます。 通常、クラウドプロバイダーは、ある程度のリソースパフォーマンスデータ（CloudWatch、Azure Monitorなど）を公開しますが、アプリケーション固有のメトリックが追加で収集される場合もあります。 通常、より多くのあなた パフォーマンス監視 はシステムタイプに合わせて調整されているため、より具体的なアラートとパフォーマンスの問題が発生し、パフォーマンスの問題の根底にすばやく到達できるようになります。
ブラックボックスコンポーネントの監視を詳しく見てみましょう。 クラウドに裏打ちされたアプリケーションとサービスの可用性は、クラウドプロバイダーが維持するインフラストラクチャの可用性に依存します。 修正できる可能性が高いものではありませんが、クラウドプロバイダーのパフォーマンスは、エンドユーザーに表示されるアプリケーションの可用性とパフォーマンスに影響を与える可能性があります。 可用性は、サービス制限やスケジュールされたイベントなどによっても影響を受ける可能性があります。 特定のシステムの詳細を知らなくても可用性をテストしているため、これは主にブラックボックスの監視と見なすことができます。 クラウドプロバイダーがクラウドサービスをどのようにサポートしているかについての即時の洞察は提供されていないため、そのシステムの詳細に基づいたテストにアクセスすることはできません。 ただし、たとえばAPI呼び出しへの応答を確認することで、システムの全体的なアップ/ダウンの可用性をテストできます。
ほとんどの場合、別の監視対象コンポーネントがあります。それは請求です。 クラウドの支出を監視することは、クラウドステッカーの衝撃を回避するための鍵となる可能性があります。 パフォーマンスに最も関係があるわけではありませんが、財務部門にクラウド支出の内訳を探している人がいる可能性があります。 次に、リザーブドインスタンスのオファー、それらのオファーをどの程度活用しているか、投資収益率を決定するために必要なその他すべての指標を追跡します。 これはおそらくブラックボックスよりもホワイトボックスの監視ですが、完全ではありません。 クラウドプロバイダーのAPIを介してパフォーマンスデータを取得できるツールは、クラウドプロバイダーによって公開された請求データを提供できる必要があります。
ここで、 LogicMonitor、クラウドで実行されているいくつかのアプリケーションを備えたハイブリッドインフラストラクチャがあります。 クラウドプロバイダーから報告された基本的なパフォーマンスメトリクスだけでなく、今後のEC2スケジュールメンテナンスイベントについて通知を受け、サービス制限にどれだけ近づいたかを確認し、リザーブドインスタンスオファーがいつ設定されたかを追跡する必要があることがわかりました。期限が切れる。 構築しました LMクラウド 上記で特定されたXNUMXつの主要コンポーネントであるリソースパフォーマンス、クラウドプロバイダーの可用性、ROIに焦点を当てた監視戦略により、クラウド、マルチクラウド、およびハイブリッド環境に対する包括的な可視性を提供します。 AWSとAzureをサポートして最初にリリースされましたが、監視対象の各コンポーネントについて具体的に調べている内容の内訳は次のとおりです。
1.リソースのパフォーマンス — LogicMonitorは、ほとんどの場合CloudWatchとAzure Monitorを介してデータを収集し（EC2インスタンスとVMの基本的なコンピューティングメトリックなど）、場合によってはサービス固有のAPIを介して追加のデータを収集します（実行中のタスク数を取得するECSAPIやAzureResource Health API VMステータス情報を取得します）。 LogicMonitor Collectorをさらに活用して、Apache、Tomcat、Zookeeper、Kafkaなどの従来のアプリケーションのOSレベルのメトリックとパフォーマンスデータを取得できます。このようなデータ収集に使用できる1000以上のテンプレートのライブラリがあります。ボックス。 イベントデータは、LogicMonitorのLambdaブループリントまたはAzure関数を介してパフォーマンスデータグラフにオーバーレイでき、クラウド環境で発生するイベントと監視しているパフォーマンスデータの間の相関を有効にします。 これらの要素が一緒になって、完全なリソースパフォーマンスを提供します クラウドサービスの監視.
2.クラウドプロバイダーの可用性 — LogicMonitorは、AWSとAzureによって報告された可用性の問題についてアラートを出します。さらに、LogicMonitor Collectorを利用して、クラウドプロバイダーのSDKを介して基本的なサービスの可用性を確認できます。 この可用性情報は、監視対象のリソースパフォーマンスデータと一緒に表示できるため、問題がいつ発生しているのかがわかります。
あなたの側の構成の問題から、そしてそれがあなたのクラウドプロバイダーの問題であるときから。 また、サービス制限の使用率と今後予定されているイベントを監視し、組み込みのアラートしきい値により、問題に注意が必要なときに事前に通知を受け取ることができます。
3.ROI — LogicMonitorは、サービス、地域、運用、アカウント、およびタグごとにクラウドの支出を監視します（タグが定義されていることを前提としています）。 リザーブドインスタンスオファーも自動検出および監視されます。 LogicMonitorの強力なダッシュボードおよびレポート機能を使用すると、このデータをスライスして、必要に応じてさいの目に切ることができます。 すぐに使用できるダッシュボードをカスタマイズし、電子メールによる定期的な配信をスケジュールすることで、内部の利害関係者を巻き込むことができます。
上記のXNUMXつのコンポーネントの監視には、クラウドサービスの完全な可視性を実現するためのホワイトボックスとブラックボックスの両方の監視アプローチが含まれます。
