次の方法で共有

クラスターの監視

クラスター レベルで監視して、ハードウェアとクラスターが期待どおりに動作しているかどうかを判断することが重要です。 Service Fabric はハードウェア障害時にアプリケーションの実行を維持できますが、アプリケーションまたは基になるインフラストラクチャでエラーが発生しているかどうかを診断する必要があります。 また、クラスターを監視して容量をより適切に計画し、ハードウェアの追加または削除に関する決定に役立てる必要があります。

Service Fabric は、EventStore とさまざまなログ チャネルを使用して、 Service Fabric イベントとして、いくつかの構造化プラットフォーム イベントをすぐに公開します。

Windows では、Service Fabric イベントは単一の ETW プロバイダーから利用でき、オペレーショナルチャネルとデータ & メッセージングチャネルの間で選択するために使用される関連する があります。これにより、必要に応じてフィルター処理される送信Service Fabricイベントを分離することができます。

  • オペレーショナル Service Fabric とクラスターによって実行される高レベルの操作 。これには、ノードが起動するイベント、デプロイされる新しいアプリケーション、アップグレードのロールバックなどが含まれます。イベントの完全な一覧 については、こちらをご覧ください。

  • 運用 - 詳細
    健康レポートと負荷分散の決定。

操作チャネルには、ETW/Windows イベント ログ、 EventStore (Windows クラスターのバージョン 6.2 以降で Windows で利用可能) など、さまざまな方法でアクセスできます。 EventStore を使用すると、エンティティごとにクラスターのイベント (クラスター、ノード、アプリケーション、サービス、パーティション、レプリカ、コンテナーを含むエンティティ) にアクセスでき、REST API と Service Fabric クライアント ライブラリを介して公開されます。 EventStore を使用して開発/テスト クラスターを監視し、運用クラスターの状態をポイントインタイムで把握します。

  • データとメッセージング
    メッセージング (現在は ReverseProxy のみ) とデータ パス (Reliable Services モデル) で生成された重要なログとイベント。

  • データとメッセージング - 詳細
    クラスター内のデータとメッセージングからのすべての非クリティカルなログを含む冗長チャネル (このチャネルではイベント数が多いです)。

これらに加えて、2 つの構造化された EventSource チャネルと、サポート目的で収集されるログがあります。

  • Reliable Services イベント
    プログラミング モデル固有のイベント。

  • Reliable Actors イベント
    プログラミング モデル固有のイベントとパフォーマンス カウンター。

  • サポート ログ
    Service Fabric によって生成されたシステム ログは、サポートを提供する際にのみ使用されます。

これらのさまざまなチャネルは、推奨されるプラットフォーム レベルのログ記録の大部分をカバーします。 プラットフォーム レベルのログ記録を向上させるには、正常性モデルの理解を深め、カスタム正常性レポートを追加し、カスタム パフォーマンス カウンター を追加して、サービスとアプリケーションがクラスターに与える影響をリアルタイムで把握することを検討してください。

これらのログを利用するには、Azure portal でのクラスターの作成時に "診断" を有効のままにすることを強くお勧めします。 診断を有効にすると、クラスターがデプロイされると、Azure Diagnostics は運用、Reliable Services、Reliable Actors のチャネルを確認し、「 Azure Diagnostics を使用したイベントの集計」で詳しく説明されているようにデータを格納できます。

Azure Service Fabric の正常性と負荷レポート

Service Fabric には独自の正常性モデルがあり、これらの記事で詳しく説明されています。

正常性の監視は、特にアプリケーションのアップグレード中に、サービスを運用する複数の側面にとって重要です。 サービスの各アップグレード ドメインがアップグレードされた後、アップグレード ドメインは、デプロイが次のアップグレード ドメインに移動する前に正常性チェックに合格する必要があります。 OK 正常性状態を達成できない場合、展開はロールバックされ、アプリケーションは既知の OK 状態のままです。 一部のお客様は、サービスがロールバックされる前に影響を受ける可能性がありますが、ほとんどのお客様には問題は発生しません。 また、人間のオペレーターからのアクションを待つ必要なく、比較的迅速に解決が行われます。 コードに組み込まれている正常性チェックが多いほど、デプロイの問題に対するサービスの回復力が高くなります。

サービス正常性のもう 1 つの側面は、サービスからのメトリックのレポートです。 メトリックはリソース使用量のバランスを取るために使用されるため、Service Fabric では重要です。 メトリックは、システムの正常性のインジケーターにもなることができます。 たとえば、多数のサービスを持つアプリケーションがあり、各インスタンスが 1 秒あたりの要求 (RPS) メトリックを報告する場合があります。 あるサービスが別のサービスよりも多くのリソースを使用している場合、Service Fabric はサービス インスタンスをクラスターの周りに移動して、リソース使用率を維持しようとします。 リソース使用率のしくみの詳細については、「メトリックを使用して Service Fabric のリソース使用量と負荷を管理する」を参照してください。

メトリックは、サービスのパフォーマンスに関する分析情報を提供するのにも役立ちます。 時間の経過と同時に、メトリックを使用して、サービスが予想されるパラメーター内で動作していることを確認できます。 たとえば、月曜日の朝の午前 9 時に平均 RPS が 1,000 であることが傾向に示されている場合は、RPS が 500 を下回っているか 1,500 を超える場合にアラートを生成する正常性レポートを設定できます。 すべてが完全に問題ありませんが、顧客が優れたエクスペリエンスを持っていることを確認する価値があるかもしれません。 サービスでは、正常性チェックのために報告できる一連のメトリックを定義できますが、クラスターのリソース分散には影響しません。 これを行うには、メトリックの重みを 0 に設定します。 メトリックの重みがクラスターのリソース分散に与える影響を確実に理解するまでは、重みを 0 に設定してすべてのメトリックを開始し、重みを増やさないことをお勧めします。

ヒント

重み付けメトリックを使用しすぎないでください。 分散のためにサービス インスタンスが移動されている理由を理解するのは困難な場合があります。 いくつかのメトリックは、長い道のりを行くことができます!

アプリケーションの正常性とパフォーマンスを示すことができる情報は、メトリックと正常性レポートの候補です。 CPU パフォーマンス カウンターは、ノードの使用方法を示すことができますが、1 つのノードで複数のサービスが実行されている可能性があるため、特定のサービスが正常かどうかは示されません。 ただし、RPS、処理された項目、要求待ち時間などのメトリックはすべて、特定のサービスの正常性を示すことができます。

Service Fabric サポート ログ

Azure Service Fabric クラスターについて Microsoft サポートに問い合わせる必要がある場合は、ほとんどの場合、サポート ログが必要です。 クラスターが Azure でホストされている場合、サポート ログはクラスターの作成の一環として自動的に構成および収集されます。 ログは、クラスターのリソース グループ内の専用ストレージ アカウントに格納されます。 ストレージ アカウントには固定名はありませんが、アカウントには、 ファブリックで始まる名前の BLOB コンテナーとテーブルが表示されます。 スタンドアロン クラスターのログ コレクションの設定については、「 スタンドアロンの Azure Service Fabric クラスターの作成と管理」および「スタンドアロンWindows クラスターの構成設定」を参照してください。 スタンドアロンの Service Fabric インスタンスの場合は、ログをローカル ファイル共有に送信する必要があります。 これらのログはサポートのために 必要 ですが、Microsoft カスタマー サポート チーム以外のユーザーが使用できるようには意図されていません。

パフォーマンスの測定

クラスターのパフォーマンスを測定して、クラスターのスケーリングに関する負荷を処理し、決定を推進する方法を理解するのに役立ちます (Azure またはオンプレミスでのクラスターのスケーリングの詳細を参照してください)。 パフォーマンス データは、ユーザーまたはアプリケーションやサービスが実行した可能性のあるアクションと比較して、将来ログを分析する場合にも役立ちます。

Service Fabric の使用時に収集するパフォーマンス カウンターの一覧については、「パフォーマンス メトリック」を参照してください。

クラスターのパフォーマンス データの収集を設定する一般的な 2 つの方法を次に示します。

  • エージェントの使用
    通常、エージェントには収集可能なパフォーマンス メトリックの一覧があり、収集または変更するメトリックを選択する比較的簡単なプロセスであるため、これはマシンからパフォーマンスを収集する方法として推奨されます。 Service Fabric の Azure Monitor ログ統合で Azure Monitor ログを提供する Azure Monitor と Log Analytics エージェントの設定 に関する記事では、Log Analytics エージェントの詳細について説明します。これは、クラスター VM とデプロイされたコンテナーのパフォーマンス データを取得できる監視エージェントの 1 つです。

  • Azure Table Storage のパフォーマンス カウンター
    イベントと同じテーブル ストレージにパフォーマンス メトリックを送信することもできます。 これには、クラスター内の VM から適切なパフォーマンス カウンターを取得するように Azure Diagnostics 構成を変更し、コンテナーをデプロイする場合に Docker 統計を取得できるようにする必要があります。 Service Fabric の WAD でパフォーマンス カウンターを構成してパフォーマンス カウンターコレクションを設定する方法について説明します。

次のステップ