- 重要な情報
- はじめに
- 用語集
- ガイド
- エージェント
- インテグレーション
- OpenTelemetry
- 開発者
- API
- CoScreen
- アプリ内
- Service Management
- インフラストラクチャー
- アプリケーションパフォーマンス
- 継続的インテグレーション
- ログ管理
- セキュリティ
- UX モニタリング
- 管理
Supported OS
このチェックでは、開始に使用されるランタイムにかかわらず、実行中のコンテナに関するメトリクスが報告されます。
注: container
チェックは containerd
チェックとは異なります。container
チェックでは、コンテナのランタイムにかかわらず、システムにあるすべてのコンテナの標準メトリクスが報告されます。
containerd
は、containerd
ランタイムについて実行され、containerd.*
ネームスペースでメトリクスを公開します。
コンテナは、Datadog Agent チェックの核であり、対応するコンテナランタイムが検出されると自動的にアクティベートされます。 ご使用の環境により、対応するコンテナランタイム (Docker、containerd) へのアクセスの構成が必要になる場合があります。
container
チェックには、自動アクティベーションのためフォルダーのマウントが必要です。これは公式 Helm Chart および Datadog Operator により管理され、セットアップは Kubernetes、Docker、ECS、ECS Fargate 用に文書化されています。
container
チェックにより公開されるコンフィギュレーション設定はありません。共通フィールドをカスタマイズまたは container
チェックのアクティベーションを強制するには、以下の手順に従います。
Agent のコンフィギュレーションディレクトリのルートにある conf.d/
フォルダーに container.d/conf.yaml
ファイルを作成します。
container
チェックで CPU、メモリ、ネットワーク、ディスク IO に関するメトリクスを収集できます。
ご使用の環境によって、一部のメトリクスは使用できない場合があります (Linux / Windows など)。
Agent の status
サブコマンドを実行し、Checks セクションで container
を探します。
このインテグレーションによって提供されるメトリクスのリストについては、[metadata.csv][12] を参照してください。
ご不明な点は、Datadog のサポートチームまでお問合せください。