Container Insights 監視コストの最適化

Kubernetes クラスターでは、Container Insights によって収集される大量のデータが生成されます。 このデータの取り込みと保持に対して課金されるため、コストを最適化できるように環境を構成する必要があります。 不要なデータをフィルターで除外し、データを格納する Log Analytics ワークスペースの構成を最適化することで、監視コストを大幅に削減できます。

収集したデータを分析し、収集する必要のないデータがあるかどうかを判断したら、収集したくないデータをフィルター処理するためのオプションがいくつかあります。 これには、定義済みの一連のコスト構成からの選択から、特定の抽出条件に基づいてデータをフィルター処理する各種機能の利用まで、さまざまな方法があります。 この記事では、Container Insights のデータ収集を分析および最適化する方法に関するガイダンスについて説明します。

データ インジェストを分析する

コスト削減の最適な機会を特定するには、さまざまなテーブルで収集されるデータの量を分析します。 この情報は、最も多くのデータを消費しているテーブルを特定し、コストを削減する方法に関する情報に基づいた意思決定を行うのに役立ちます。

[コンテナー分析情報の使用] Runbook を使用して、各ワークスペースで取り込まれたデータの量を視覚化できます。この Runbook は [ワークスペース] ページから利用できます。

レポートでは、テーブル、名前空間、ログ ソースなど、さまざまなカテゴリ別のデータ使用状況を確認できます。 これらの異なるビューを使用して、使用していないデータを特定し、フィルターで除外することで、コストを削減できます。

Log Analytics でクエリを開くオプションを選択すると、収集される個々のレコードの表示など、より詳細な分析を行えます。 収集されたデータの分析に使用できる追加のクエリについては、「コンテナー分析情報からのクエリ ログ」 を参照してください。

たとえば、次のスクリーンショットは、名前空間とテーブル別のデータを示す [テーブル別] に使用されるログ クエリの変更を示しています。

収集されたデータをフィルター処理する

フィルター処理できるデータを特定したら、Container Insights のさまざまな構成オプションを使用して、不要なデータをフィルターで除外します。 詳細なフィルター処理には、定義済みの構成の選択、個々のパラメーターの設定、およびカスタム ログ クエリの使用といったオプションを使用できます。

コスト プリセット

データをフィルター処理する最も簡単な方法は、Azure portal でコスト プリセットを使用することです。 各プリセットには、さまざまな操作プロファイルとコスト プロファイルに基づいて収集するさまざまなテーブル セットが含まれています。 コスト プリセットは、一般的なシナリオに基づいてデータ収集をすばやく構成できるように設計されています。

ヒント

Container Insights に Prometheus エクスペリエンスを使用するようにクラスターを構成している場合は、パフォーマンス データが Prometheus によって収集されているため、パフォーマンスの収集を無効にすることができます。

コスト プリセットの選択の詳細については、「Azure portal を使用した DCR の構成」を参照してください。

フィルター処理のオプション

適切なコスト プリセットを選択したら、次の表のさまざまな方法を使用して追加のデータをフィルター処理できます。 それぞれのオプションで、さまざまな条件に基づいてデータをフィルター処理できます。 構成が完了したら、分析とアラートに必要なデータのみが収集されているはずです。

フィルター	説明
Tables	コスト プリセット グループではなく、事前設定するテーブルを個々に選択する場合は、DCR を手動で変更します。 たとえば、ContainerLogV2 は収集するが、同じコスト プリセットに含まれる KubeEvents は収集したくない場合があります。 DCR で使用するストリームの一覧については、「DCR のストリーム値」を参照してください。また、次のガイダンスを参照してください。
コンテナー ログ	ContainerLogV2 は、クラスター内のコンテナーによって生成された stdout/stderr レコードを格納します。 DCR を使用してテーブル全体の収集を無効にすることができますが、クラスターの ConfigMap を使用して stderr ログと stdout ログの収集を個別に構成できます。 stdout と stderr の設定は個別に構成できるため、一方を有効にして、もう一方は有効にしないことができます。 コンテナー ログのフィルター処理の詳細については、「コンテナー ログのフィルター処理」を参照してください。
名前空間	Kubernetes の名前空間は、クラスター内のリソースをグループ化するために使用されます。 不要な特定の名前空間内のリソースからデータをフィルターで除外できます。 DCR を使用すると、Perf テーブルの収集を有効にしていれば、名前空間でのみパフォーマンス データをフィルター処理できます。 stdout および stderr ログ内の特定の名前空間のデータをフィルター処理するには、ConfigMap を使用します。 名前空間でログをフィルター処理する方法の詳細については「コンテナー ログのフィルター処理」、システム名前空間の詳細については「プラットフォーム ログのフィルター処理 (システム Kubernetes 名前空間)」を参照してください。
ポッドとコンテナー	注釈のフィルター処理を使用して、ポッドに付けた注釈に基づいてコンテナー ログを除外できます。 ConfigMap を使用すると、個々のポッドとコンテナーに対して stdout ログと stderr ログを収集するかどうかを指定できます。 ConfigMap の更新とポッドでの注釈の設定の詳細については、「ワークロードの注釈ベースのフィルター処理」を参照してください。

変換

取り込み時の変換を使用すると、KQL クエリを適用して、Log Analytics ワークスペースに格納する前に、Azure Monitor パイプラインのデータをフィルター処理して変換できます。 これにより、他のオプションでは設定できない抽出条件に基づいてデータをフィルター処理できます。

たとえば、ContainerLogV2 のログ レベルに基づいてコンテナー ログをフィルター処理することを選択できます。 次の図の機能を実行する変換を Container Insights DCR に追加できます。 この例では、error および critical レベルのイベントのみが収集され、その他のイベントは無視されます。

別の方法としては、重要度の低いイベントを、基本ログ用に構成された別のテーブルに保存できます。 イベントは引き続きトラブルシューティングに使用できますが、データ インジェストのコストは大幅に削減されます。

変換を使用したサンプル DCR を含む Container Insights DCR への変換の追加の詳細については、「Container Insights でのデータ変換」を参照してください。

価格レベルを構成する

Azure Monitor の基本ログを使用すると、デバッグやトラブルシューティングに使用することがあるデータの Log Analytics ワークスペースへの取り込みについて、大幅なコスト削減が可能です。 基本ログ用に構成されたテーブルは、ログ クエリのコストと引き換えに、データ インジェストの大幅なコスト削減を可能にします。つまり、必要だがアクセス頻度の低いデータに最適です。

ContainerLogV2 は、基本ログ用に構成できます。このログを使用すると、データのクエリを頻繁に実行しない場合に大幅なコスト削減を実現できます。 変換を使用すると、基本ログ用に構成された別のテーブルに送信するデータを指定できます。 この方法の例については、「Container Insights でのデータ変換」を参照してください。

次のステップ

Container Insights で収集されたデータから最近の使用パターンに基づいてどのようなコストが発生する可能性があるかを理解するには、「Log Analytics ワークスペースでの使用量の分析」に関する記事を参照してください。