- 重要な情報
- はじめに
- 用語集
- ガイド
- エージェント
- インテグレーション
- OpenTelemetry
- 開発者
- API
- CoScreen
- アプリ内
- Service Management
- インフラストラクチャー
- アプリケーションパフォーマンス
- 継続的インテグレーション
- ログ管理
- セキュリティ
- UX モニタリング
- 管理
コンテナモニタリングに関するトラブルシューティング情報を提供します。
Agent のデプロイ方法には、以下の 3 つがあります。
ランタイムのコンテナとして
Amazon ECS や Amazon ECS 環境の Fargate、Amazon EKS などのクラウド環境で
これらの異なる方法には、独自のデプロイメント上の課題があります。このページは、問題を解決するための出発点として使用してください。問題が解決しない場合は、Datadog サポートに連絡してください。
Agent のリリース更新や変更の詳細については、Datadog のリリースノートを参照してください。
環境変数の挿入や DogStatsD ライブラリの構成に便利なのは、Cluster Agent に Admission Controller の機能を実装する方法です。注: Cluster Agent は、アプリケーションがデプロイされる前にデプロイされ、実行されている必要があります。
以下が正しいことを確認します。
メトリクスエンドポイントは公開され、Agent がアクセスできるようになっている。
Agent がエンドポイントにアクセスするのを妨げるようなプロキシやファイアウォールは存在しない。
Agent はオートディスカバリーを有効にしている。
ログを収集するかどうか、どのコンテナから収集するかを左右する 2 つの環境変数が存在します。
DD_LOGS_ENABLED
を true
に設定します。DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL
を true
に設定すると、すべてのコンテナからすべてのログを収集することができます。ログ (およびその他の機能) を収集対象から除外するには、コンテナのディスカバリー管理ガイドを参照してください。
Kubelet API への接続を妨げる最も一般的なエラーは、Kubelet の TLS 証明書の検証です。
TLS 検証はデフォルトで有効になっており、Agent が HTTPS 経由で Kubelet API に接続することを妨げる場合があります。専用パラメーターを使用するか、Agent マニフェストのすべてのコンテナに対して DD_KUBELET_TLS_VERIFY
変数を設定することで、TLS 検証を無効にすることができます。
TLS_VERIFY
を false
に設定します。まず、Cluster Agent がデプロイされ、ノード Agent にデータを送ることができることを確認します。
次に、Metrics Summary で外部メトリクスのスケーリングに使用したクエリを確認します。有効なクエリのみがオートスケールされます。複数のクエリがある場合、クエリのいずれかが無効であれば、すべてのクエリが無視されます。
HPA メトリクスについて、さらにサポートを求める場合は、以下を Datadog サポートに伝えてください。
describe
出力:$ kubectl describe hpa > hpa.log
describe
出力:$ kubectl describe DatadogMetric > DatadogMetric.log
ログについては、Agent のデプロイコマンドで DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL
と DD_LOGS_ENABLED
が有効になっていることを確認します。
IAM ポリシーが更新されていることを確認します。
ECS: ログを収集するコンテナにログルーターがアタッチされていることを確認します。
EKS: EKS Fargate 環境において Agent がログを収集する一般的な方法は 2 つあります。CloudWatch のログを利用したログ転送と、Kinesis Data Firehose を利用したログ転送です。Kinesis Data Firehose を使用してログを収集するには、Kinesis Data Firehose の配信ストリームを正常に実装する必要があり、いくつかのコマンドラインツールも必要です。
まず、API キーが有効であることを確認します。
次に、ノード Agent ポッドで、agent status
コマンドを実行し、結果を確認します。
kubeapi_server
、kube_controller_manager
、etcd
のメトリクスが取得できないAzure Kubernetes Service (AKS) や Google Kubernetes Engine (GKE) などのマネージドサービスでは、ユーザーは Control Plane コンポーネントにアクセスできません。そのため、これらの環境では kube_apiserver
、kube_controller_manager
、kube_scheduler
、または etcd
チェックを実行することができません。
サポートチケットを開いた後、以下のような情報を求められることがあります。
flare
コマンドを使用すると、Datadog サポートにトラブルシューティング情報を送信することができます。
ノード Agent フレア
$ kubectl exec <AGENT_POD_NAME> -it agent flare <CASE_ID>
Cluster Agent フレア
$ kubectl exec <CLUSTER_AGENT_POD_NAME> -it agent flare <CASE_ID>
これにより、ノードまたは Cluster Agent がどのようにデプロイされたか、ポッドの直近のイベントは何か、何らかの品質 (カスタムタグなど) が挿入されてホストメトリクスに適用されたかどうかについての洞察がチームに提供されます。コマンドの > <FILENAME>.yaml
セクションは、Datadog サポートにアタッチとして送ることができるファイル出力を作成します。
$ kubectl describe pod <POD_NAME> > <FILENAME>.yaml
これは、環境に Agent をデプロイするために使用されるファイルです。構成されたタグ、ログが有効になっているかどうか、特定のコンテナが無視されるように定義されているかどうかなどを Datadog に通知するものです。
ランタイム環境でデプロイする場合は、デプロイに使用したコマンドラインをサポートに送信してください。
一般的なデプロイ方法は、 Helm チャート、DaemonSet、Operator の 3 つです。
メトリクスの欠落や不正確さが発生している場合、Datadog サポートは、メトリクスのエンドポイントに到達しようとするノード Agent の cURL 出力の結果を求める場合があります。これは、Agent コンテナ内からコマンドを実行することで行われ、Agent がメトリクスにアクセスできるかどうかをサポートに知らせることができます。注: これは Fargate やマネージドサービスでは不可能です。
$ kubectl exec -it <AGENT_POD_NAME> curl -k -v ""<METRIC_ENDPOINT>""
$ docker exec -it <AGENT_CONTAINER_ID> curl -k -v "<METRIC_ENDPOINT>"
お役に立つドキュメント、リンクや記事: