Datadog ライブコンテナは、環境内のすべてのコンテナをリアルタイムに表示できるようにします。
htop、ctop、kubectl などの基盤ツールを手本として、ライブコンテナはユーザーのコンテナインフラストラクチャーを完全にカバーしつつ、解像度 2 秒のリソースメトリクス、ファセット検索、コンテナログストリーミングでテーブルを継続的に更新します。
ライブコンテナビューは、Docker、Kubernetes、ECS などのコンテナ技術と連動し、動的コンポーネントのタグ付けも組み込まれて、コンテナの健全性、リソース消費、ログ、デプロイなどの詳細な全体像をリアルタイムに提供します。
Datadog Agent と Cluster Agent は、ライブコンテナの Kubernetes リソースを取得するように構成できます。この機能により、特定のネームスペースまたはアベイラビリティーゾーンのポッド、デプロイメント、その他の Kubernetes の概念の状態を監視したり、デプロイメント内で失敗したポッドのリソース仕様を確認したり、ノードアクティビティを関係するログに関連付けたりすることが可能になります。
ライブコンテナの Kubernetes リソースには、以下を構成する前に Agent バージョン >= 7.21.1 および Cluster Agent バージョン >= 1.9.0 が必要です。
公式の Datadog Helm チャートを使用している場合、
datadog.orchestratorExplorer.enabled を true に設定します一部のセットアップでは、Process Agent と Cluster Agent で Kubernetes クラスター名が自動検出されません。この場合、機能は起動せず、Cluster Agent ログで以下のような警告ログが表示されます。Orchestrator explorer enabled but no cluster name set: disabling。この場合、datadog.clusterName を values.yaml でクラスター名に設定する必要があります。
Cluster Agent バージョン >= 1.9.0 は、DaemonSet を構成する前に必要となります。Cluster Agent が実行中で Agent と通信できることを確認してください。コンフィギュレーションの詳細は、Cluster Agent のセットアップドキュメントを参照してください。
以下の環境変数を使用して、Cluster Agent コンテナを設定します。
- name: DD_ORCHESTRATOR_EXPLORER_ENABLED
value: "true"
以下の RBAC アクセス許可を使用して、Cluster Agent ClusterRole を設定します。
特に apps apiGroups の場合は、ライブコンテナに
一般的な Kubernetes リソース (pods、services、nodes など) を収集する権限が必要です。
これは、Cluster Agent のセットアップ用ドキュメントに従っていれば、すでに RBAC にあります。
ない場合は、追加されていることを確認してください
（deployments、replicasets の後）。
ClusterRole:
- apiGroups: # To create the datadog-cluster-id CM
- ""
resources:
- configmaps
verbs:
- create
- get
- update
...
- apiGroups: # Required to get the kube-system namespace UID and generate a cluster ID
- ""
resources:
- namespaces
verbs:
- get
...
- apiGroups: # To collect new resource types
- "apps"
resources:
- deployments
- replicasets
# Below are in case RBAC was not setup from the above linked "Cluster Agent Setup documentation"
- pods
- nodes
- services
verbs:
- list
- get
- watch
これらのアクセス許可は、Agent DaemonSet や Cluster Agent Deployment と同じネームスペースに datadog-cluster-id ConfigMap を作成したり、デプロイや ReplicaSets を収集するために必要です。
Cluster Agent により cluster-id ConfigMap が作成されない場合、Agent ポッドは起動せず、CreateContainerConfigError ステータスに陥ります。この ConfigMap が存在しないために Agent ポッドが動かない場合は、Cluster Agent アクセス許可を更新しポッドを再起動して ConfigMap を作成すると、Agent ポッドは自動的に回復します。
Agent DaemonSet で実行される Process Agent は、有効かつ実行中（プロセス収集を実行する必要はありません）であり、かつ以下のオプションで構成されている必要があります。
- name: DD_ORCHESTRATOR_EXPLORER_ENABLED
value: "true"
- name: DD_ORCHESTRATOR_CLUSTER_ID
valueFrom:
configMapKeyRef:
name: datadog-cluster-id
key: id
一部のセットアップでは、Process Agent と Cluster Agent で Kubernetes クラスター名が自動検出されません。この場合、機能は起動せず、Cluster Agent ログで以下のような警告ログが表示されます。Orchestrator explorer enabled but no cluster name set: disabling。この場合、Cluster Agent と Process Agent の両方の env セクションに以下のオプションを追加する必要があります。
- name: DD_CLUSTER_NAME
value: "<YOUR_CLUSTER_NAME>"
コンテナは、リアルタイム収集の対象に入れたり、除外したりすることができます。
datadog.yaml に環境変数 DD_CONTAINER_EXCLUDE を渡すか、container_exclude: を追加することで、コンテナを対象から除外することができます。datadog.yaml に環境変数 DD_CONTAINER_INCLUDE を渡すか、container_include: を追加することで、コンテナを対象に入れることができます。どちらの引数も値はイメージ名になります。正規表現もサポートされています。
たとえば、名前が frontend で始まるコンテナ以外のすべての Debian イメージを除外するには、datadog.yaml ファイルに次の 2 つの構成行を追加します。
env:
- name: DD_LOGS_ENABLED
value: "true"
- name: DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL
value: "true"
volumeMounts:
- name: pointerdir
mountPath: /opt/datadog-agent/run
volumes:
- hostPath:
path: /opt/datadog-agent/run
name: pointerdir
container_exclude: ["image:debian"]
container_include: ["name:frontend.*"]
注: Agent 5 の場合は、これをメインの datadog.conf 構成ファイルに追加する代わりに、datadog.yaml ファイルを明示的に /etc/datadog-agent/ に追加してください。プロセス Agent は、ここにすべての構成オプションがあることを前提とするためです。この構成は、コンテナをリアルタイム収集から除外するだけで、オートディスカバリーからは除外しません。
コンテナページに移動します。これにより、自動的に Containers ビューが表示されます。
コンテナは、本質的に極めてカーディナリティの高いオブジェクトです。Datadog の柔軟な文字列検索は、コンテナ名、ID、またはイメージフィールドから一致する部分文字列を見つけます。
Kubernetes Resources を有効にしている場合、pod、deployment、ReplicaSet、service name などの文字列と Kubernetes ラベルは Kubernetes Resources ビューで検索可能です。
複合クエリで複数の文字列検索を組み合わせるには、以下のブール演算子を使用します。
| 演算子 | 説明 | 例 |
AND | 積: 両方の条件を含むイベントが選択されます (何も追加しなければ、AND がデフォルトで採用されます)。 | java AND elasticsearch |
OR | 和: いずれかの条件を含むイベントが選択されます。 | java OR python |
NOT / ! | 排他: 後続の条件はイベントに含まれません。単語 NOT と文字 ! のどちらを使用しても、同じ演算を行うことができます。 | java NOT elasticsearch java !elasticsearch でも同じ |
演算子をグループ化するには括弧を使用します。例: (NOT (elasticsearch OR kafka) java) OR python。
下のスクリーンショットは、あるシステムがフィルタリングによって 9 つのノードからなる 1 つの Kubernetes クラスターに絞り込まれたところを示しています。コンテナの RSS および CPU 使用率をレポートする際に、コンテナに制限がプロビジョニングされている場合は、制限との比較が示されます。ここでは、このクラスターのコンテナがオーバープロビジョニングになっていることは明らかです。制限とビンパッキングを厳しくすれば、リソースの使用率を改善できます。
コンテナ環境は動的であり、追跡が困難な場合があります。下のスクリーンショットは、kube_service と host によってピボットされたビューです。システムノイズを減らすために、kube_namespace:default に絞り込まれています。どのサービスがどこで実行されているか、キーメトリクスの飽和状態などがわかります。
ECS の ecs_task_name や ecs_task_version でピボットすると、更新時のリソース使用率の変化を把握できます。
Kubernetes リソースの場合、フィルターに使用する environment、service、または pod_phase などの Datadog タグを選択します。左側のコンテナファセットを使用して、特定の Kubernetes リソースをフィルタリングすることもできます。ポッドを Datadog タグでグループ化して、情報をすばやく見つけることができる集約ビューを取得します。
コンテナは、すべての既存のホストレベルのタグおよび個別のコンテナに関連付けられたメタデータを使用してタグ付けされます。
よく使用されるオーケストレーターとのインテグレーションを含め、すべてのコンテナは image_name でタグ付けされます。ECS と Kubernetes には、さらにいくつかのコンテナレベルのタグが提供されます。また、各コンテナには Docker、ECS、または Kubernetes のアイコンが付くため、どれがオーケストレーション中であるかが一目でわかります。
ECS コンテナは以下でタグ付けされます。
task_nametask_versionecs_clusterKubernetes コンテナは以下でタグ付けされます。
pod_namekube_pod_ipkube_servicekube_namespacekube_replica_setkube_daemon_setkube_jobkube_deploymentkube_cluster統合サービスタグ付けのコンフィギュレーションがある場合、env、service、version も自動的に取得されます。上記のタグが利用できることで、APM、ログ、メトリクス、ライブコンテナデータを結びつけることができます。
Containers ビューには、散布図および時系列ビューと、コンテナ名、ステータス、開始時刻などのフィールドでコンテナデータを整理できるテーブルが含まれています。
散布図分析を使用すると、2 つのメトリクスを比較してコンテナのパフォーマンスをより的確に把握できます。
Containers ページで散布図分析にアクセスするには、Show Summary graph ボタンをクリックし、“Scatter Plot” タブを選択します。
デフォルトでは、グラフは short_image タグキーでグループ化されます。ドットのサイズは、各グループ内のコンテナの数を表します。ドットをクリックすると、グループに参加しているすべてのコンテナとホストが表示されます。
散布図分析の上部にあるクエリを使用して、散布図分析を制御できます。
コンテナページをアクティブに使用している間、メトリクスは 2 秒の解像度で収集されます。これは、CPU などの揮発性が高いメトリクスで重要です。バックグラウンドでは、履歴を目的として、10 秒の解像度でメトリクスが収集されます。
ライブコンテナ向け Kubernetes Resources を有効にしている場合は、ページ左上の View ドロップダウンメニューで Pods、Deployments、ReplicaSets、Services ビューを切り替えます。これらの各ビューには、ステータス、名前、Kubernetes ラベルなどのフィールドでデータを整理できるデータテーブルと、ポッドと Kubernetes クラスターの全体像を示す詳細なクラスターマップが含まれています。
Kubernetes クラスターマップは、ポッドと Kubernetes クラスターの全体像を示します。カスタマイズされたグループとフィルターを使用して、すべてのリソースを 1 つの画面にまとめて表示し、ポッドの色を塗りつぶすメトリクスを選択できます。
サークルまたはグループをクリックしてクラスターマップからリソースにドリルダウンし、詳細パネルを表示します。
テーブルの行またはクラスターマップのオブジェクトをクリックすると、サイドパネルに特定のリソースに関する情報が表示されます。このパネルは、選択したコンテナまたはリソースに関する次のような情報のトラブルシューティングと検索に役立ちます。
DNS や ip_type などのタグで検索するか、このビューで Group by フィルターを使用してネットワークデータを pod_name や service などのタグでグループ化します。Kubernetes Resources ビューには、いくつかの追加のタブがあります。
このリソースの詳細なダッシュボードについては、このパネルの右上隅にある View Dashboard をクリックしてください。
docker logs -f や kubectl logs -f などのコンテナのストリーミングログを Datadog で表示します。テーブル内のコンテナをクリックして調べることができます。Logs タブをクリックすると、Live Tail からのリアルタイムデータや過去の任意の時間のインデックス化されたログが表示されます。
Live Tail を使用すると、すべてのコンテナログがストリーミングされます。ストリームを一時停止すると、高速に書き込まれているログを簡単に読むことができます。一時停止を解除すると、ストリーミングが継続されます。
簡単な文字列マッチングでストリーミングログを検索できます。Live Tail の詳細については、Live Tail のドキュメントを参照してください。
注: ストリーミングログは永続化されません。新しい検索を入力するか、ページをリフレッシュすると、ストリームはクリアされます。
対応するタイムフレームを選択することで、インデックス化して永続化するように選択したログを表示できます。インデックス化を使用すると、タグやファセットを使用してログをフィルタリングできます。たとえば、Error 状態のログを検索するには、検索ボックスに status:error と入力します。オートコンプリートによって目的のタグが見つけやすくなります。ログの重要な属性が既にタグに保存されているため、必要に応じて検索、フィルタリング、集計を行うことができます。
health 値は、コンテナの readiness プローブです。liveness プローブではありません。お役に立つドキュメント、リンクや記事:
