- 重要な情報
- はじめに
- 用語集
- エージェント
- インテグレーション
- OpenTelemetry
- 開発者
- API
- CoScreen
- アプリ内
- インフラストラクチャー
- アプリケーションパフォーマンス
- 継続的インテグレーション
- ログ管理
- セキュリティ
- UX モニタリング
- 管理
Datadog のライブプロセスにより、インフラストラクチャー上で実行中のプロセスをリアルタイムで可視化できます。ライブプロセスを使用すると、以下のことができます。
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_AGENT_ENABLED=true
注:
dd-agent
ユーザーが docker.sock
へのアクセス許可を持つ必要があります。Daemonset の作成に使用された dd-agent.yaml マニフェスト内に、以下の環境変数、ボリュームマウント、およびボリュームを追加します。
env:
- name: DD_PROCESS_AGENT_ENABLED
value: "true"
volumeMounts:
- name: passwd
mountPath: /etc/passwd
readOnly: true
volumes:
- hostPath:
path: /etc/passwd
name: passwd
詳細については、標準の Daemonset インストールのページおよび Docker Agent の情報ページを参照してください。
注: 引き続き、Agent をコンテナとして実行してホストプロセスを収集することもできます。
次のプロセス収集コンフィギュレーションで datadog-values.yaml ファイルを更新してから、Datadog Helm チャートをアップグレードします。
datadog:
# (...)
processAgent:
enabled: true
processCollection: true
I/O とオープンファイルの統計情報は、昇格した権限で実行される Datadog system-probe によって収集することができます。system-probe の process モジュールを有効にするには、次の構成を使用します。
下記のシステムプローブのコンフィギュレーションの例をコピーします。
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
を編集し、process モジュールを有効にします。
system_probe_config:
process_config:
enabled: true
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_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
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
タグ付けはナビゲーションを強化します。すべての既存のホストレベルのタグに加えて、プロセスは 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
統合サービスタグ付けのコンフィギュレーションがある場合、env
、service
、version
も自動的に取得されます。
上記のタグが利用できることで、APM、ログ、メトリクス、プロセスデータを結びつけることができます。
注: このセットアップはコンテナ化環境にのみ適用されます。
散布図分析を使用すると、2 つのメトリクスを比較してコンテナのパフォーマンスをより的確に把握できます。
Processes ページで散布図分析にアクセスするには、Show Summary graph ボタンをクリックし、“Scatter Plot” タブを選択します。
デフォルトでは、グラフは command
タグキーでグループ化されます。ドットのサイズは、各グループ内のプロセスの数を表します。ドットをクリックすると、グループに参加しているすべてのポッドとコンテナが表示されます。
散布図分析の上部にあるクエリを使用して、散布図分析を制御できます。
複数のホストまたはタグにまたがるプロセスグループのカウントに基づいてアラートを生成するには、ライブプロセスモニターを使用します。プロセスアラートは、モニターページで構成できます。詳細は、ライブプロセスモニターのドキュメントを参照してください。
ダッシュボードやノートブックでプロセスメトリクスをグラフ化するには、時系列ウィジェットを使用します。構成するには、
From
フィールドのタグを使用してフィルタリングDatadog ではプロセス収集を使用して、ホストで実行されているテクノロジーを自動検出します。これにより、こうしたテクノロジーの監視に役立つ Datadog インテグレーションが識別されます。この自動検出されたインテグレーションは、インテグレーション検索に表示されます。
各インテグレーションには、次の 2 つのステータスタイプのいずれかがあります。
インテグレーションを実行しているが、インテグレーションが有効になっていないホストは、インテグレーションタイルの Hosts タブにあります。
サードパーティ製ソフトウェアが検出された後、ライブプロセスはそのソフトウェアのパフォーマンスを分析するのに役立ちます。
インテグレーションビュー(ホストごとに Nginx 処理のクエリを集約する場合)や他のカスタムクエリをカスタマイズするには、ページ上部の +Save ボタンをクリックします。この操作により、クエリ、テーブルの列の選択、可視化設定が保存されます。保存ビューを作成し、追加のコンフィギュレーション無しに必要な処理へ迅速にアクセスへしたり、チームメイトとプロセスデータを共有したりできます。
ライブプロセスは、それぞれのコンテナで実行中のプロセスを監視することで、コンテナデプロイの可視化をさらに強化しています。ライブコンテナページでコンテナをクリックすると、実行中のコマンドやリソース消費量を含むプロセスツリーが表示されます。コンテナメトリクスと共にこのデータを使用し、コンテナやデプロイの不具合の根本的な原因を探ります。
APM トレースでサービスのスパンをクリックすると、基礎インフラストラクチャーで実行中のプロセスを確認できます。サービスのスパンプロセスは、リクエスト時にサービスが実行されているホストまたはポッドと相関関係にあります。CPU および RSS メモリなどのプロセスメトリクスをコードレベルのエラーとともに分析することで、アプリケーション特有の問題かインフラストラクチャーの問題かを見分けることができます。プロセスをクリックすると、ライブプロセス ページが開きます。関連するプロセスはサーバーレスおよびブラウザのトレースでサポートされていません。
ネットワークの概要で依存関係を調べる際、相互に通信するエンドポイント(サービスなど)の基底のインフラストラクチャーで実行される処理を確認できます。プロセスメタデータを使用して、ネットワークの接続の悪さ(TCP の再送信数が多いことから)やネットワークの呼び出し遅延の高さ(TCP ラウンドトリップタイムが長いことから)の原因が、エンドポイントのリソースを消費する重いワークロードであり、結果、通信の健全性や効率性に影響を与えているかを判断できます。
ライブプロセスをアクティブに使用している間、メトリクスは 2 秒の解像度で収集されます。これは、CPU などの揮発性のメトリクスでは重要です。バックグラウンドでは、履歴を目的として 10 秒の解像度でメトリクスが収集されます。
docker-dd-agent
にマウントされた /etc/passwd
ファイルが必要です。これは公開ファイルですが、プロセス Agent はユーザー名以外のフィールドを使用しません。user
メタデータフィールド以外のすべての機能は、このファイルにアクセスせずに機能します。注: ライブプロセスは、ホストの passwd
ファイルのみを使用し、コンテナ内に作成されたユーザーのユーザー名解決は実行しません。