Live Processes is included in the Enterprise plan. For all other plans, contact your account representative or success@datadoghq.com to request this feature.

はじめに

Datadog’s Live Processes gives you real-time visibility into the processes running on your infrastructure. Use Live Processes to:

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

インストール

Agent 5 の場合は、こちらのバージョン固有のインストール手順に従ってください。Agent 6 または 7 をご利用の場合は、以下の手順を参照してください

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

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 をコンテナとして実行してホストプロセスを収集することもできます。

Update your datadog-values.yaml file with the following process collection configuration:

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

Then, upgrade your Helm chart:

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

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

In your datadog-agent.yaml, set features.liveProcessCollection.enabled to 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 をコンテナとして実行してホストプロセスを収集することもできます。

In the datadog-agent.yaml manifest used to create the DaemonSet, add the following environmental variables, volume mount, and volume:

 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

See the standard DaemonSet installation and the Docker Agent information pages for further documentation.

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

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

In order to collect processes, the Datadog Agent must be running as a container within the task.

To enable process monitoring in ECS Fargate, set the DD_PROCESS_AGENT_PROCESS_COLLECTION_ENABLED environment variable to true in the Datadog Agent container definition within the task definition.

例:

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

To start collecting process information in ECS Fargate, add the PidMode parameter to the Task Definition and set it to task as follows:

"pidMode": "task"

Once enabled, use the AWS Fargate Containers facet on the Live Processes page to filter processes by ECS, or enter fargate:ecs in the search query.

Processes in AWS Fargate

For more information about installing the Datadog Agent with AWS ECS Fargate, see the ECS Fargate integration documentation.

I/O 統計

I/O とオープンファイルの統計情報は、昇格した権限で実行される Datadog system-probe によって収集することができます。system-probe の process モジュールを有効にするには、次の構成を使用します。

  1. 下記のシステムプローブのコンフィギュレーションの例をコピーします。

    sudo -u dd-agent install -m 0640 /etc/datadog-agent/system-probe.yaml.example /etc/datadog-agent/system-probe.yaml
    
  2. /etc/datadog-agent/system-probe.yaml を編集し、process モジュールを有効にします。

    system_probe_config:
      process_config:
        enabled: true
    
  3. Agent を再起動します

    sudo systemctl restart datadog-agent
    

    : システムで systemctl コマンドを利用できない場合は、代わりに次のコマンドを実行します: sudo service datadog-agent restart

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

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

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

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

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

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

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

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

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

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

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

process_config:
    strip_proc_arguments: true

Helm チャートを使い、デフォルトのリストにマージされる独自のリストを定義できます。環境変数 DD_SCRUB_ARGSDD_CUSTOM_SENSITIVE_WORDSdatadog-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_ARGSfalse に設定すると、プロセス引数のスクラビングを完全に無効化できます。

また、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 はコマンド自体と一致しています。

Postgres

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

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

演算子をグループ化するには括弧を使用します。例: (NOT (elasticsearch OR kafka) java) OR python

タグフィルター

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

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

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

プロセスの集約

タグ付けはナビゲーションを強化します。すべての既存のホストレベルのタグに加えて、プロセスは user でもタグ付けされます。

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

  • task_name
  • task_version
  • ecs_cluster

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

  • pod_name
  • kube_pod_ip
  • kube_service
  • kube_namespace
  • kube_replica_set
  • kube_daemon_set
  • kube_job
  • kube_deployment
  • Kube_cluster

統合サービスタグ付けのコンフィギュレーションがある場合、envserviceversion も自動的に取得されます。 上記のタグが利用できることで、APM、ログ、メトリクス、プロセスデータを結びつけることができます。 : このセットアップはコンテナ化環境にのみ適用されます。

散布図

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

Processes ページで散布図分析にアクセスするには、Show Summary graph ボタンをクリックし、“Scatter Plot” タブを選択します。

Scatter plot 選択

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

散布図分析の上部にあるクエリを使用して、散布図分析を制御できます。

  • 表示するメトリクスの選択。
  • 2 つのメトリクスの集計方法の選択。
  • X 軸と Y 軸の目盛の選択 (Linear/Log)。
コンテナ検査

プロセスモニター

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

プロセスモニター

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

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

  1. プロセスをデータソースとして選択
  2. 検索バーのテキスト文字列を使用してフィルタリング
  3. グラフ化するプロセスメトリクスを選択
  4. From フィールドのタグを使用してフィルタリング
プロセスウィジェット

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

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

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

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

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

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

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

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

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

サードパーティ製ソフトウェアが検出された後、ライブプロセスはそのソフトウェアのパフォーマンスを分析するのに役立ちます。

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

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

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

ライブコンテナ

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

APM

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

ネットワークパフォーマンス監視

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

リアルタイムの監視

Processes are normally collected at 10s resolution. While actively working with the Live Processes page, metrics are collected at 2s resolution and displayed in real time, which is important for volatile metrics such as CPU. However, for historical context, metrics are ingested at the default 10s resolution.

追加情報

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

その他の参考資料

PREVIEWING: may/unit-testing