Container insights の監視コストについて

[アーティクル]
11/11/2023

この記事では、使用法を理解するための、Container insights に関する価格のガイダンスを提供します。

1 つまたは複数のコンテナーに対して Container insights を有効にした後に、コストを測定します。
データの収集を制御してコストを削減します。

ヒント

Azure Monitor のコストを削減するための戦略については、コストの最適化と Azure Monitor に関するページを参照してください。

Azure Monitor の価格モデルは、主に、Log Analytics ワークスペースに取り込まれたデータ量 (1 日あたりギガバイト単位) に基づいています。 Log Analytics ワークスペースのコストは、収集されるデータのボリュームだけでなく、選択したプラン、およびクラスターから生成されたデータの保持期間にも依存します。

Note

コンテナーの分析情報のコストを見積もってから有効にするには、「Azure Monitor のコストを見積もる」を参照してください。

次に、Container Insights を使用して Kubernetes クラスターから収集された次の種類について説明します。このデータは、コストに影響を与え、使用状況に応じてカスタマイズできます。

Perf、Inventory、InsightsMetrics、KubeEvents は、コストの最適化設定を使用して制御できます
エージェント ConfigMap を使用してクラスター内のすべての Kubernetes 名前空間で監視されているすべてのコンテナーの stdout および stderr コンテナーのログ
クラスターで監視されているすべてのコンテナーからのコンテナー環境変数
監視を必要としないクラスターの完了した Kubernetes ジョブ/ポッド
Prometheus メトリックのアクティブなスクレイピング
kube-apiserver および kube-controller-manager マスターコンポーネントによって生成されるログデータを分析できる、Azure Kubernetes Service (AKS) クラスター内の Kubernetes メインノードログのリソースログの収集。

コスト削減のためにインジェスト制御をする

組織の異なる部署が Kubernetes インフラストラクチャと Log Analytics ワークスペースを共有しているシナリオについて考えてみましょう。各事業単位は、Kubernetes 名前空間で区切られています。 データ使用量 Runbook を使用して、各ワークスペースに取り込まれるデータ量を視覚化できます。 Runbook は、[レポート] タブから使用できます。

このブックを使用すると、ドキュメントに記載されている内容から独自のクエリライブラリを作成しなくても、データのソースを視覚化することができます。このブックでは、次のような課金対象データを表示するグラフを表示できます。

ソリューションごとの取り込まれた課金対象データの合計 (GB 単位)。
コンテナーログ (アプリケーションログ) ごとの取り込まれた課金対象のデータ。
Kubernetes 名前空間ごとの取り込まれた課金対象のコンテナーログ。
クラスター名別に分離された、取り込まれた課金対象のコンテナーログデータ。
ログソースエントリ別の、取り込まれた課金対象コンテナーログデータ。
診断メインノードログ別の、取り込まれた課金対象の診断データ

ブックの権限と権限を管理する方法の詳細については、「アクセス制御」を参照してください。

データインジェストの根本原因の特定

Container Insights データは、主にメトリックカウンター (Perf、Inventory、InsightsMetrics、カスタムメトリック) とログ (ContainerLog) で構成されます。クラスターの使用状況とサイズに基づいて、要件と監視のニーズが異なる場合があります。

[データ使用状況] ブックの [テーブル別] セクションに移動すると、Container Insights のテーブルサイズの内訳を確認できます。

データの大部分の取得元が次のいずれかのテーブルである場合:

Perf
InsightsMetrics
ContainerInventory
ContainerNodeInventory
KubeNodeInventory
KubePodInventory
KubePVInventory
KubeServices
KubeEvents

コスト最適化設定を使用したり、Prometheus メトリックアドオンに移行したりして、インジェストを調整できます

それ以外の場合、データの大部分は ContainerLog テーブルに属します。次の手順に従って、ContainerLog のコストを削減できます。

ContainerLog のコストの削減

最も多くのデータ、または必要以上のデータを生成しているソースを特定する分析を完了後、データ収集を再構成できます。 stdout、stderr、および環境変数の収集に関する詳細については、「コンテナーの Azure Monitor に対するエージェントのデータ収集を構成する」の記事を参照してください。

次の例は、コストを制御するために ConfigMap ファイルを変更して、クラスターに適用できる変更を示します。

メトリックをプルする Azure Container Insights サービスの ConfigMap ファイルで次のコードを変更して、クラスター内のすべての名前空間で stdout ログを無効にします。
```
[log_collection_settings]       
   [log_collection_settings.stdout]          
      enabled = false
```
開発名前空間からの stderr ログの収集を無効にします。たとえば dev-test です。次の ConfigMap ファイル内の次のコードを変更して、 prod や default などの他の名前空間から stderr ログを収集し続けます。

Note

kube-system ログ収集は、既定では無効になっています。既定の設定が保持されます。除外名前空間の一覧に dev-test 名前空間を追加すると、stderr ログの収集に適用されます。
```
[log_collection_settings.stderr]          
   enabled = true          
      exclude_namespaces = ["kube-system", "dev-test"]
```
ConfigMap ファイルで次のコードを変更して、クラスター全体で環境変数の収集を無効にします。この変更は、すべての Kubernetes 名前空間のすべてのコンテナーに適用されます。
```
[log_collection_settings.env_var]
    enabled = false
```
終了したジョブをクリーンアップするために、ジョブ定義 yaml にクリーンアップポリシーを指定します。クリーンアップポリシーを指定したジョブ定義の例を次に示します。詳しくは、Kubernetes ドキュメントをご覧ください。
```
apiVersion: batch/v1
kind: Job
metadata:
  name: pi-with-ttl
spec:
  ttlSecondsAfterFinished: 100
```

ConfigMaps にこれらの変更を 1 つまたは複数適用したら、コマンド kubectl apply -f <config3. map_yaml_file.yaml> でクラスターにそれを適用します。たとえば、コマンド kubectl apply -f container-azm-ms-agentconfig.yaml を実行して既定のエディターでファイルを開き、変更して保存します。

基本ログの構成

Log Analytics ワークスペースにおいて、主にデバッグ、トラブルシューティング、監査のために基本ログとして使用する ContainerLog で、データインジェストコストを節約することができます。基本ログの制限事項を含む詳細については、Azure Monitor での基本ログの構成に関するページを参照してください。 ContainerLogV2 は、コンテナー分析情報で使用される基本ログの構成済みのバージョンです。 ContainerLogV2 には、詳細なテキストベースのログレコードが含まれます。

基本ログを構成するには、ContainerLogV2 スキーマで行う必要があります。詳細については、「ContainerLogV2 スキーマ (プレビュー) を有効にする」を参照してください。

Prometheus メトリックのスクレ―ピング

Note

このセクションでは、Log Analytics ワークスペースの Prometheus メトリックの収集について説明します。この情報は、Managed Prometheus を使って Prometheus メトリックをスクレイピングしている場合は適用されません。

Log Analytics ワークスペースで Prometheus メトリックを収集する場合は、クラスターから収集するメトリック数を制限してください。

スクレイピングの頻度が最適に設定されていることを確認します。既定値は 60 秒です。頻度は 15 秒に上げることができますが、スクレイピングしているメトリックがその頻度で公開されていることを確認する必要があります。そうしない場合、多くの重複したメトリックがスクレイピングされ、その間隔で Log Analytics ワークスペースに送信されますが、データインジェストとリテンションのコストが加算される半面、その価値は下がります。
Container insights では、メトリック名ごとの除外リストとインクルージョンリストがサポートされています。たとえば、クラスター内の kubedns メトリックをスクレイピングする場合、既定で何百ものメトリックがスクレイピングされる可能性があります。しかし、ほとんどの場合、メトリックのサブセットにのみ関心を持たれます。スクレイピングするメトリックの一覧を指定したことを確認するか、データの取り込み量を節約するために、少数を除いて除外することもできます。スクレイピングを有効にし、Log Analytics の請求額の負担になるだけの、これらの多くのメトリックを使用しないようにすることは簡単です。
ポッドの注釈を使用してスクラップするときは、使用しない名前空間からポッドメトリックのスクレイピングを除外するように、名前空間でフィルター処理する必要があります。たとえば、dev-test 名前空間です。

Kubernetes クラスターから収集されるデータ

メトリックデータ

Container insights には、Log Analytics ワークスペースにログデータとして書き込まれる、一連の収集された定義済みのメトリックとインベントリ項目が含まれます。次の表のすべてのメトリックは、1 分ごとに収集されます。

Type メトリック

ノードメトリック cpuUsageNanoCores
cpuCapacityNanoCores
cpuAllocatableNanoCores
memoryRssBytes
memoryWorkingSetBytes
memoryCapacityBytes
memoryAllocatableBytes
restartTimeEpoch
used (disk)
free (disk)
used_percent (disk)
io_time (diskio)
writes (diskio)
reads (diskio)
write_bytes (diskio)
write_time (diskio)
iops_in_progress (diskio)
read_bytes (diskio)
read_time (diskio)
err_in (net)
err_out (net)
bytes_recv (net)
bytes_sent (net)
Kubelet_docker_operations (kubelet)

コンテナーメトリック cpuUsageNanoCores
cpuRequestNanoCores
cpuLimitNanoCores
memoryRssBytes
memoryWorkingSetBytes
memoryRequestBytes
memoryLimitBytes
restartTimeEpoch

Type	メトリック
ノードメトリック	`cpuUsageNanoCores` `cpuCapacityNanoCores` `cpuAllocatableNanoCores` `memoryRssBytes` `memoryWorkingSetBytes` `memoryCapacityBytes` `memoryAllocatableBytes` `restartTimeEpoch` `used` (disk) `free` (disk) `used_percent` (disk) `io_time` (diskio) `writes` (diskio) `reads` (diskio) `write_bytes` (diskio) `write_time` (diskio) `iops_in_progress` (diskio) `read_bytes` (diskio) `read_time` (diskio) `err_in` (net) `err_out` (net) `bytes_recv` (net) `bytes_sent` (net) `Kubelet_docker_operations` (kubelet)
コンテナーメトリック	`cpuUsageNanoCores` `cpuRequestNanoCores` `cpuLimitNanoCores` `memoryRssBytes` `memoryWorkingSetBytes` `memoryRequestBytes` `memoryLimitBytes` `restartTimeEpoch`

クラスターインベントリ

次に、既定で収集されるクラスターインベントリデータの一覧を示します。

KubePodInventory – 1 分ごとにポッドあたり 1
KubeNodeInventory – 1 分ごとにノードあたり 1
KubeServices – 1 分ごとにサービスあたり 1
ContainerInventory – 1 分ごとにコンテナーあたり 1

次のステップ

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