次の方法で共有

Azure Service Fabric での監視と診断のベスト プラクティス

  • [アーティクル]

監視と診断は、あらゆるクラウド環境でアプリケーションやサービスを開発、テスト、およびデプロイするために非常に重要です。 たとえば、アプリケーションの使われ方、Service Fabric プラットフォームによって実行されたアクション、パフォーマンス カウンターでのリソースの使用状況、クラスターの全体的な正常性を追跡できます。 この情報を使って、問題の診断と修正を行い、再発を防ぐことができます。

アプリケーションの監視

アプリケーションの監視は、アプリケーションの機能やコンポーネントがどのように使用されているかを追跡します。 アプリケーションを監視して、ユーザーに影響が及ぶ問題を把握します。 ビジネス ロジックはアプリケーションごとに固有なので、アプリケーションの監視は、アプリケーションとそのサービスを開発するユーザーに責任があります。 Azure のアプリケーション監視ツールである Application Insights を使用して、アプリケーションの監視を設定することをお勧めします。

クラスターの監視

Service Fabric の目標の 1 つは、ハードウェア障害に対する回復性をアプリケーションに持たせることです。 この目標を実現するには、プラットフォームのシステム サービスの機能を利用します。この機能は、インフラストラクチャの問題を特定し、ワークロードをクラスター内の別のノードにすばやくフェールオーバーします。 ただし、システム サービス自体に問題がある場合はどうなるでしょうか。 または、ワークロードのデプロイまたは移動でサービス配置のルールに違反したらどうなるでしょうか。 Service Fabric には、このような問題や他の問題に対応する診断機能があるため、Service Fabric プラットフォームがアプリケーション、サービス、コンテナー、およびノードとどのようにやり取りしているかについて確実に把握することができます。

Windows クラスターの場合は、診断エージェントと Azure Monitor ログを使用してクラスターの監視を設定することをお勧めします。

Linux クラスターの場合、Azure Monitor ログは Azure プラットフォームとインフラストラクチャの監視にも推奨されるツールです。 Linux プラットフォームの診断には、「Syslog 内の Service Fabric Linux クラスター イベント」で説明されているように異なる構成が必要です。

インフラストラクチャ監視

クラスター レベルのイベントを監視するには、Azure Monitor ログが推奨されます。 前のリンクで説明されているように、ワークスペースを使用して Log Analytics エージェントを構成すると、パフォーマンス メトリック (CPU 使用率など)、.NET パフォーマンス カウンター (プロセス レベルの CPU 使用率など)、Service Fabric パフォーマンス カウンター (信頼できるサービスからの例外数など)、コンテナー メトリック (CPU 使用率など) を収集できるようになります。 Azure Monitor ログで利用するには、コンテナー ログを stdout または stderr に書き込む必要があります。

ウォッチドッグ

一般的に、ウォッチドッグとは、複数のサービスにわたって正常性と負荷を監視し、エンドポイントに ping を送信し、クラスター内の予期しない正常性イベントを報告する個別のサービスを指します。 これは、1 つのサービスのパフォーマンスのみに基づくと検出されない可能性があるエラーを防ぐために役立ちます。 またウォッチドッグは、ユーザー操作を必要としない修復アクションを実行するコードをホストする場所としても適しています。たとえば、特定の時間間隔でのストレージ内のログ ファイル クリーンアップなどです。 使いやすいウォッチドッグ拡張モデルを含み、Windows と Linux の両方のクラスターで動作する、完全に実装されたオープン ソースの SF ウォッチドッグ サービスが必要な場合は、FabricObserver プロジェクトを参照してください。 FabricObserver は、実稼働可能なソフトウェアです。 テストおよび運用クラスターに FabricObserver をデプロイし、そのプラグイン モデルを使用してニーズに合わせて拡張するか、またはフォークして独自の組み込みのオブザーバーを作成することをお勧めします。 前者 (プラグイン) が推奨される方法です。

次のステップ