Live Processes

Docs > インフラストラクチャー > Live Processes

Live Processes および Live Process Monitoring は Enterprise プランに含まれています。その他のプランをご利用の場合にこの機能をリクエストするには、アカウント担当者または [email protected] にご連絡ください。

はじめに

Datadog の Live Processes により、インフラストラクチャー上で実行中のプロセスをリアルタイムで可視化できます。Live Processes を使用すると、以下のことができます。

実行中のプロセスを 1 か所で表示する
ホストやコンテナのリソース消費をプロセスレベルで分類する
特定のホストや特定のゾーンで実行中のプロセスや、特定のワークロードを実行するプロセスをクエリする
システムメトリクスを使用して、実行する内部およびサードパーティソフトウェアのパフォーマンスを 2 秒の粒度でモニターする
ダッシュボードとノートブックにコンテキストを追加する

インストール

Agent 5 をご使用の場合は、この特定のインストール手順に従ってください。Agent 6 または 7 をご使用の場合は、以下の手順を参照してください。

Datadog Agent をインストールしたら、Agent のメイン構成ファイルを編集し、次のパラメーターを true に設定して、Live Processes の収集を有効にします。

process_config:
  process_collection:
    enabled: true

さらに、いくつかの構成オプションを環境変数として設定できます。

注: 環境変数として設定されたオプションは、構成ファイルで定義されている設定を上書きします。

設定が完了したら、Agent を再起動します。

Docker Agent の手順に従い、必要に応じてほかのカスタム設定に加えて、以下の属性を渡します。

-v /etc/passwd:/etc/passwd:ro
-e DD_PROCESS_CONFIG_PROCESS_COLLECTION_ENABLED=true

注:

標準インストールでコンテナ情報を収集するには、dd-agent ユーザーが docker.sock へのアクセス許可を持っている必要があります。
引き続き、Agent をコンテナとして実行してホストプロセスを収集することもできます。

次のプロセスコレクション構成で datadog-values.yaml ファイルを更新します。

datadog:
    # (...)
    processAgent:
        enabled: true
        processCollection: true

次に、Helm チャートをアップグレードします。

helm upgrade -f datadog-values.yaml <RELEASE_NAME> datadog/datadog

注: 引き続き、Agent をコンテナとして実行してホストプロセスを収集することもできます。

ご使用の datadog-agent.yaml で、features.liveProcessCollection.enabled を true に設定します。

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    credentials:
      apiKey: <DATADOG_API_KEY>

  features:
    liveProcessCollection:
      enabled: true

After making your changes, apply the new configuration by using the following command:

kubectl apply -n $DD_NAMESPACE -f datadog-agent.yaml

注: 引き続き、Agent をコンテナとして実行してホストプロセスを収集することもできます。

DaemonSet の作成に使用された datadog-agent.yaml マニフェスト内に、以下の環境変数、ボリュームマウント、およびボリュームを追加します。

 env:
    - name: DD_PROCESS_CONFIG_PROCESS_COLLECTION_ENABLED
      value: "true"
  volumeMounts:
    - name: passwd
      mountPath: /etc/passwd
      readOnly: true
  volumes:
    - hostPath:
        path: /etc/passwd
      name: passwd

詳細については、標準の DaemonSet インストールのページおよび Docker Agent の情報ページを参照してください。

注: 引き続き、Agent をコンテナとして実行してホストプロセスを収集することもできます。

Datadog で ECS Fargate プロセスを表示できます。ECS Fargate コンテナとの関係を確認するには、Datadog Agent v7.50.0 以降を使用してください。

プロセスを収集するには、Datadog Agent がタスク内でコンテナとして実行されている必要があります。

ECS Fargate でプロセスモニタリングを有効にするには、タスク定義内の Datadog Agent コンテナ定義で DD_PROCESS_AGENT_PROCESS_COLLECTION_ENABLED 環境変数を true に設定します。

たとえば、次のようにします。

{
    "taskDefinitionArn": "...",
    "containerDefinitions": [
        {
            "name": "datadog-agent",
            "image": "public.ecr.aws/datadog/agent:latest",
            ...
            "environment": [
                {
                    "name": "DD_PROCESS_AGENT_PROCESS_COLLECTION_ENABLED",
                    "value": "true"
                }
                ...
             ]
         ...
         }
    ]
  ...
}

ECS Fargate でプロセス情報の収集を開始するには、タスク定義に pidMode パラメーターを追加し、以下のように task に設定します:

"pidMode": "task"

有効化したら、Live Processes ぺージで AWS Fargate Containers ファセットを使用して ECS で実行されているプロセスをフィルタリングするか、検索クエリに fargate:ecs を入力します。

AWS ECS Fargate で Datadog Agent をインストールする方法の詳細については、ECS Fargate インテグレーションのドキュメントを参照してください。

I/O 統計

I/O とオープンファイルの統計情報は、昇格した権限で実行される Datadog システムプローブによって収集することができます。これらの統計情報を収集するには、システムプローブのプロセスモジュールを有効にします。

下記のシステムプローブの構成の例をコピーします。

sudo -u dd-agent install -m 0640 /etc/datadog-agent/system-probe.yaml.example /etc/datadog-agent/system-probe.yaml

/etc/datadog-agent/system-probe.yaml を編集してプロセスモジュールを有効にします。
```
system_probe_config:
  process_config:
    enabled: true
```
Agent を再起動します:
```
sudo systemctl restart datadog-agent
```
注: システムで systemctl コマンドを利用できない場合は、代わりに次のコマンドを実行します。sudo service datadog-agent restart

プロセス収集のフットプリント最適化

Linux では、(個別のプロセスエージェントではなく) コア Datadog Agent でコンテナおよびプロセス収集を実行することで、Datadog Agent の全体的なフットプリントを削減します。Datadog Agent v7.65.0 以降では、これがデフォルトで有効になっています。注: プロセスエージェントは、Cloud Network Monitoring では引き続き必要です。

この機能の Agent ステータスは、Process Component セクションに記載されています。たとえば、次のようになります。

=================
Process Component
=================


  Enabled Checks: [process rtprocess]
  System Probe Process Module Status: Not running
  Process Language Detection Enabled: False

  =================
  Process Endpoints
  =================
    https://process.datadoghq.com. - API Key ending with:
        - *****

  =========
  Collector
  =========
    Last collection time: 2026-01-14 10:04:49
    Docker socket: /var/run/docker.sock
    Number of processes: 48
    Number of containers: 0
    Process Queue length: 0
    RTProcess Queue length: 0
    Connections Queue length: 0
    Event Queue length: 0
    Pod Queue length: 0
    Process Bytes enqueued: 0
    RTProcess Bytes enqueued: 0
    Connections Bytes enqueued: 0
    Event Bytes enqueued: 0
    Pod Bytes enqueued: 0
    Drop Check Payloads: []
    Number of submission errors: 0

プロセス引数のスクラビング

Live Processes ページで機密データを非表示にするために、Agent はプロセスコマンドラインから機密性の高い引数をスクラビングします。この機能はデフォルトで有効になっており、以下のいずれかの単語に一致するプロセス引数では値が非表示になります。

"password", "passwd", "mysql_pwd", "access_token", "auth_token", "api_key", "apikey", "secret", "credentials", "stripetoken"

注: この一致では、大文字と小文字は区別されません。

custom_sensitive_words ファイルの process_config セクションにある datadog.yaml フィールドを使用して、独自のリストを定義して、デフォルトのリストと統合します。ワイルドカード (*) を使用して、一致のスコープを独自に定義できます。ただし、ワイルドカード ('*') 単独の使用は、機密語としてサポートされていません。

process_config:
    scrub_args: true
    custom_sensitive_words: ['personal_key', '*token', 'sql*', '*pass*d*']

注: custom_sensitive_words 内の単語には、英数字、アンダースコア、ワイルドカード ('*') のみを使用できます。ワイルドカードのみの機密語はサポートされていません。

次の図に、Live Processes ページに表示されたプロセスの一例を示します。上の構成を使用して、プロセス引数が非表示にされています。

scrub_args を false に設定すると、プロセス引数のスクラビングを完全に無効化できます。

datadog.yaml 構成ファイルで strip_proc_arguments フラグを有効にすることで、プロセスのすべての引数をスクラビングすることもできます。

process_config:
    strip_proc_arguments: true

Helm チャートを使用して、デフォルトのリストにマージされる独自のリストを定義できます。環境変数 DD_SCRUB_ARGS と DD_CUSTOM_SENSITIVE_WORDS を datadog-values.yaml ファイルに追加し、Datadog Helm チャートをアップグレードします。

datadog:
    # (...)
    processAgent:
        enabled: true
        processCollection: true
    agents:
        containers:
            processAgent:
                env:
                - name: DD_SCRUB_ARGS
                  value: "true"
                - name: DD_CUSTOM_SENSITIVE_WORDS
                  value: "personal_key,*token,*token,sql*,*pass*d*"

ワイルドカード (*) を使用して、一致のスコープを独自に定義できます。ただし、ワイルドカード ('*') 単独の使用は、機密語としてサポートされていません。

DD_SCRUB_ARGS を false に設定すると、プロセス引数のスクラビングを完全に無効化できます。

また、datadog-values.yaml ファイルで DD_STRIP_PROCESS_ARGS 変数を有効にすることで、プロセスのすべての引数をスクラビングすることもできます。

datadog:
    # (...)
    processAgent:
        enabled: true
        processCollection: true
agents:
    containers:
        processAgent:
            env:
            - name: DD_STRIP_PROCESS_ARGS
              value: "true"

クエリ

プロセスのスコーピング

プロセスは、本質的に極めてカーディナリティの高いオブジェクトです。関連するプロセスを表示するようにスコープを絞り込むには、テキストフィルターやタグフィルターを使用します。

テキストフィルター

検索バーにテキスト文字列を入力すると、コマンドラインやパスにそのテキスト文字列を含むプロセスをクエリする際に、曖昧文字列検索が使用されます。2 文字以上の文字列を入力すると結果が表示されます。以下の例では、Datadog のデモ環境を文字列 postgres /9. でフィルタリングしています。

注: /9. はコマンドパスの一部と一致し、postgres はコマンド自体と一致しています。

複合クエリで複数の文字列検索を組み合わせるには、以下のブール演算子を使用します。

AND: 積: 両方の条件を含むイベントが選択されます (何も追加しなければ、AND がデフォルトで使用されます)。
例: java AND elasticsearch
OR: 和: いずれかの条件を含むイベントが選択されます。
例: java OR python
NOT / !: 排他: 後続の条件がイベントに含まれません。単語 NOT または文字 ! のどちらを使用しても、同じ演算を行うことができます。
例: java NOT elasticsearch または java !elasticsearch

演算子をグループ化するには括弧を使用します。たとえば、(NOT (elasticsearch OR kafka) java) OR python です。

タグフィルター

プロセスのフィルタリングには、host、pod、user、service などの Datadog タグを使用することもできます。検索バーに直接タグフィルターを入力するか、ページ左側のファセットパネルで選択します。

Datadog は自動的に command タグを生成するので、以下をフィルタリングできます。

サードパーティソフトウェア、例: command:mongod、command:nginx
コンテナ管理ソフトウェア、例: command:docker、command:kubelet
一般的なワークロード、例: command:ssh、command:CRON

コンテナ化環境タグ

さらに、ECS コンテナ内のプロセスは、以下でもタグ付けされます。

task_name
task_version
ecs_cluster

Kubernetes コンテナ内のプロセスは、以下でタグ付けされます。

pod_name
kube_service
kube_namespace
kube_replica_set
kube_daemon_set
kube_job
kube_deployment
kube_cluster_name

Unified Service Tagging の構成がある場合、env、service、version は自動的に取得されます。これらのタグが利用できるようになると、APM、ログ、メトリクス、プロセスデータを結びつけられるようになります。注: この設定はコンテナ化環境にのみ適用されます。

カスタムタグの作成ルール

ここでは、 Process Tags Read および Process Tag Write Datadog ロールのアクセス許可が必要です。

コマンドラインに基づいてプロセスに手動でタグを追加するためのルール定義を作成できます。

[Manage Process Tags] (プロセスタグの管理) タブで、[New Process Tag Rule] (新規プロセスタグルール) ボタンを選択します。
参照用のプロセスを選択します。
タグのパースおよび一致基準を定義します。
検証に合格したら、新しいルールを作成します。

ルールが作成されると、ルール基準に一致するすべてのプロセスコマンドライン値でタグが利用可能になります。これらのタグは検索で利用可能で、ライブプロセスモニターや Custom Metrics の定義で使用できます。

散布図

散布図分析を使用すると、2 つのメトリクスを比較してコンテナのパフォーマンスをより的確に把握できます。

Processes ページで散布図分析にアクセスするには、[Show Summary graph] (サマリーグラフを表示) ボタンをクリックし、[Scatter Plot] (散布図) タブを選択します。

デフォルトでは、グラフは command タグキーでグループ化されます。各ドットのサイズは、そのグループ内のプロセスの数を表します。ドットをクリックすると、グループに参加している個別のプロセスとポッドとコンテナが表示されます。

グラフの上部にあるオプションを使用して、散布図分析を制御できます。

表示するメトリクスの選択。
2 つのメトリクスの集計方法の選択。
X 軸と Y 軸の目盛の選択 (線形/対数)。

プロセスモニター

複数のホストまたはタグにまたがるプロセスグループの数に基づいてアラートを生成するには、ライブプロセスモニターを使用します。プロセスアラートは、モニターページで構成できます。詳細は、ライブプロセスモニターのドキュメントを参照してください。

ダッシュボードとノートブックでのプロセス

ダッシュボードやノートブックでプロセスメトリクスをグラフ化するには、時系列ウィジェットを使用します。構成するには、次のようにします。

プロセスをデータソースとして選択します。
検索バーのテキスト文字列を使用してフィルタリングします。
グラフ化するプロセスメトリクスを選択します。
From フィールドのタグを使用してフィルタリングします。

サードパーティソフトウェアのモニタリング

自動検出インテグレーション

Datadog ではプロセス収集を使用して、ホストで実行されているテクノロジーを自動検出します。これにより、こうしたテクノロジーのモニターに役立つ Datadog インテグレーションが識別されます。この自動検出されたインテグレーションは、インテグレーションの検索に表示されます。

各インテグレーションには、次の 2 つのステータスタイプのいずれかがあります。

+ Detected (+ 検出済み): このインテグレーションは、それを実行しているホストでは有効になっていません。
✓ Partial Visibility (✓ 部分的な可視性): このインテグレーションは、一部で有効になっていますが、すべての関連ホストで実行されているわけではありません。

インテグレーションを実行しているが、インテグレーションが有効になっていないホストは、インテグレーションタイルの [Hosts] (ホスト) タブにあります。

インテグレーションビュー

サードパーティソフトウェアが検出されると、Live Processes はそのソフトウェアのパフォーマンスを分析するのに役立ちます。

まず、ページ右上の Views (ビュー) をクリックし、Nginx、Redis、Kafka などの、あらかじめ設定されたオプションの一覧を開きます。
そのソフトウェアを実行中の処理のみにページを限定するビューを選択します。
重いプロセスを調べる場合は、[Integration Metrics] (インテグレーションメトリクス) タブに切り替え、基盤となるホストにあるソフトウェアの健全性を分析します。関連する Datadog インテグレーションを有効にしてある場合は、インテグレーションから収集されたすべてのパフォーマンスメトリクスを表示できるため、問題がホストレベルなのかソフトウェアレベルなのかを判断できます。たとえば、プロセス CPU と MySQL クエリのレイテンシーが相関して急上昇する場合、全表スキャンなどの集中的な操作が、同じ基盤となるリソースに依存する別の MySQL クエリの実行を遅らせていることが考えられます。

インテグレーションビュー (ホストごとに Nginx 処理のクエリを集約する場合) やほかのカスタムクエリをカスタマイズするには、ページ上部の [+Save] (+保存) ボタンをクリックします。この操作により、クエリ、テーブルの列の選択、可視化設定が保存されます。保存ビューを作成して、追加の構成なしに必要なプロセスに迅速にアクセスしたり、チームメイトとプロセスデータを共有したりできます。

プラットフォームにおけるプロセス

ライブコンテナ

Live Processes では、それぞれのコンテナで実行中のプロセスをモニターすることで、コンテナデプロイの可視化をさらに強化しています。ライブコンテナページでコンテナをクリックすると、実行中のコマンドやリソース消費量を含むプロセスツリーが表示されます。ほかのコンテナメトリクスと共にこのデータを使用し、コンテナやデプロイの不具合の根本原因を判別します。

APM

APM トレースでサービスのスパンをクリックすると、基盤となるインフラストラクチャーで実行中のプロセスを確認できます。サービスのスパンプロセスは、リクエスト時にサービスが実行されているホストまたはポッドと相関関係にあります。CPU および RSS メモリなどのプロセスメトリクスをコードレベルのエラーと共に分析することで、アプリケーション固有の問題なのか、インフラストラクチャーの問題なのかを切り分けることができます。プロセスをクリックすると、Live Processes ページが開きます。関連するプロセスは、サーバーレスおよびブラウザのトレースでサポートされていません。

Cloud Network Monitoring

Network Analytics ページで依存関係を調べる際、相互に通信するエンドポイント (サービスなど) の基盤となるインフラストラクチャーで実行されるプロセスを確認できます。プロセスメタデータを使用して、ネットワーク接続の不具合 (TCP の再送信数が多いことを示唆) やネットワーク呼び出しレイテンシーの高さ (TCP ラウンドトリップタイムが長いことを示唆) の原因が、エンドポイントのリソースを消費する重いワークロードであり、その結果、通信の健全性や効率性に影響を与えているかを判断できます。

リアルタイムのモニター

通常、プロセスは 10 秒間隔で収集されます。Live Processes ページでアクティブに作業している間は、メトリクスが 2 秒間隔で収集され、リアルタイムで表示されます。これは、CPU などの変動が大きいメトリクスで重要です。ただし、履歴として収集する場合は、デフォルトの 10 秒間隔でメトリクスが取り込まれます。

追加情報

リアルタイム (2 秒) のデータ収集は 30 分後にオフになります。リアルタイム収集を再開するには、ページをリフレッシュします。
コンテナのデプロイで、各プロセスのユーザー名を収集するには、docker-dd-agent にマウントされた /etc/passwd ファイルが必要です。これは公開ファイルですが、プロセスエージェントはユーザー名以外のフィールドを使用しません。Agent が特権なしで実行されている場合は、マウントは行われません。/etc/passwd ファイルへのアクセス権がない場合でも、user メタデータフィールド以外のすべての機能は動作します。注: Live Processes は、ホストの passwd ファイルのみを使用し、コンテナ内で作成されたユーザーのユーザー名解決は実行しません。