Download PDF
Download page クラスタエージェントのトラブルシューティング.
クラスタエージェントのトラブルシューティング
このページでは、クラスタエージェントのインストールのトラブルシューティング手順について説明します。「クラスタエージェントのインストール」および「クラスタエージェントのインストールの検証」を参照してください。
クラスタエージェントがコントローラに表示されない問題のトラブルシューティング
クラスタエージェントのインストール後に、クラスタダッシュボードがコントローラに表示されない場合は、コントローラとの接続に問題があると考えられます。
サーバの可視性ライセンスが使用可能であることを確認します。クラスタエージェントを正常に登録するには、使用可能なサーバの可視性ライセンスが必要です。詳細については、クラスタエージェントの要件およびサポート対象環境を参照してください。コントローラ UI から、[Administration/License/Account Usage] でライセンスが使用できることを確認します。
クラスタ エージェント イベントを確認します。クラスタエージェントまたはクラスタ エージェント オペレータの起動に失敗した場合は、
appdynamics
名前空間のイベントを確認します。kubectl -n appdynamics get events # to sort by most recent events: kubectl -n appdynamics get events --sort-by='.lastTimestamp'
BASHその他のイベントについては、クラスタエージェントポッドの仕様で確認できます。
kubectl -n appdynamics get pod <cluster-agent-pod> -o yaml
BASHコントローラの通信に関するエラーについて、クラスタエージェントのログを確認します。コマンドラインプロンプトを開き、次のように入力します。
kubectl -n appdynamics logs <cluster-agent-pod-name>
BASHクラスタエージェント設定を確認します。クラスタエージェントは、1 分に 1 回設定の変更を確認します。設定が適用され、クラスタエージェントが新しい値を使用していることを確認するには、コマンドラインプロンプトを開き、次のように入力します。
kubectl -n appdynamics describe cm cluster-agent-mon cluster-agent-log cluster-agent-config
CODE最新のクラスタエージェントがインストールされていることを確認します。クラスタエージェントを以前のバージョンからアップグレードする場合、以前のオペレータ YAML またはイメージに互換性がない場合があります。「クラスタエージェントのアップグレード」で説明されている手順を使用して、クラスタ エージェント オペレータとクラスタエージェントを再インストールする必要があります。
メトリックを報告しないクラスタエージェントのトラブルシューティング
クラスタエージェントが特定のコンテナ、ポッド、またはノードのメトリックを報告しない場合は、Kubernetes メトリックサーバの問題が原因であると考えられます。メトリックがメトリックサーバによって報告されない場合、クラスタエージェントはメトリックを報告できません。
メトリックサーバがメトリックを送信していることを確認するには、クラスタのプライマリノードから次のコマンドを入力します。
$ kubectl get --raw /apis/metrics.k8s.io/v1beta1/pods
コマンドの出力にコンテナのメトリックが表示されない場合は、メトリックサーバに問題がある可能性があります。次に、メトリックサーバからの出力例を示します。
{
"kind":"PodMetricsList",
"apiVersion":"metrics.k8s.io/v1beta1",
"metadata":{
"selfLink":"/apis/metrics.k8s.io/v1beta1/pods"
},
"items":[
{
"metadata":{
"name":"replicaset-test-cjnsc",
"namespace":"test-qe",
"selfLink":"/apis/metrics.k8s.io/v1beta1/namespaces/test-qe/pods/replicaset-test-cjnsc",
"creationTimestamp":"2019-09-23T10:24:46Z"
},
"timestamp":"2019-09-23T10:23:38Z",
"window":"30s",
"containers":[
{
"name":"appagent",
"usage":{
"cpu":"1667384n",
"memory":"258672Ki"
}
}
]
}
]
}
メトリックサーバは、ノード、ポッド、コンテナからメトリックを収集するため、すべての問題をログに記録します。メトリックサーバのログを取得して表示するには、次を入力します。
$ kubectl logs <metric-server pod name> -n <namespace for metric-server(default value is: "kube-system")> --tail <number of required lines of logs>
次に例を示します。
$ kubectl logs metrics-server-6764b987d-mtn7g -n kube-system --tail 20
メトリックサーバログでは、メトリックを収集できなかった理由が明らかになることがあります。次に例を示します。
E0920 11:44:54.204075 1 reststorage.go:147] unable to fetch pod metrics for pod test-qe/replicaset-test-9k7rl: no metrics known for pod
E0920 11:44:54.204080 1 reststorage.go:147] unable to fetch pod metrics for pod test/replicaset1-458-g9n2d: no metrics known for pod
E0920 11:44:54.204089 1 reststorage.go:147] unable to fetch pod metrics for pod kube-system/kube-proxy-t54rc: no metrics known for pod
E0920 11:45:19.188033 1 manager.go:111] unable to fully collect metrics: unable to fully scrape metrics from source kubelet_summary:ip-111.111.111.111: unable to fetch metrics from Kubelet ip-111.111.111.111 (111.111.111.111): Get https://111.111.111.111:2222/stats/summary/: dial tcp 111.111.111.111:2222: i/o timeout
クラスタエージェントの再起動
クラスタエージェントが再起動した場合は、ポッドの詳細から再起動が発生したことを確認できます。ポッドの詳細を取得するには、次を入力します。
kubectl get pods -n appdynamics
サンプル出力:
NAME READY STATUS RESTARTS AGE
appdynamics-operator-6fff76b466-qtx57 1/1 Running 0 4h18m
k8s-cluster-agent-perf-jg-6fc498d557-q7zst 1/1 Running 1 83m
クラスタエージェントが予期せず再起動した場合、RESTARTS
カウント値は 0 より大きくなります。名前空間とログの両方を明示的にリセットする必要があります。
cluster-agent.yaml
ファイルのデフォルトの stdoutLogging: true
プロパティを上書きしないことを推奨します。このプロパティを false
に設定すると、kubectl logs
コマンドはログを返しません。
クラスタエージェントのログは、クラスタエージェントが Kubernetes によって再起動された場合でも保持されます。(再起動した)クラスタエージェントポッドのクラスタエージェントログを表示するには、次を入力します。
kubectl -n appdynamics logs --previous ${CLUSTER_AGENT_POD_NAME}
クラスタエージェントポッドが再起動した場合、(UI で設定した)モニタ対象の名前空間は保持されません。UI を使用して名前空間を設定した場合は、nsToMonitorRegex
下の cluster-agent.yaml
ファイルに同じ名前空間を追加して、その設定を適用する必要があります。その結果、クラスタエージェントポッドでは、再起動時にモニタ対象の名前空間が保持されます。
cluster-agent.yaml
ファイルに名前空間を追加しなかった場合は、モニター対象の名前空間を再設定できます。
- Cisco AppDynamics Agents > Cluster Agents > {CLUSTER_AGENT} > Configure に移動します。
- モニタする名前空間を追加します。
「名前空間の追加または削除」を参照してください。
OpenShift 4.x での APM 相関
OCI(Open Container Initiative)互換ランタイム(CRI-O)を使用するコンテナ ランタイム インターフェイスは、Red Hat Openshift 4.x のデフォルト コンテナ ランタイムです。OpenShift 4.x で APM エージェントを使用する場合は、CRI-O コンテナに必要なシンタックスをサポートするように UNIQUE_HOST_ID
を更新する必要があります。この設定は、新規アプリケーションコンテナと既存のアプリケーションコンテナの両方に適用されます。アプリケーション エージェントを実行している場合は、アプリケーション エージェントの YAML
ファイルを変更する必要があります。
Openshift 4.x で APM 相関を使用してアプリケーション エージェントを実行するには、次の手順に従います。
アプリケーション エージェントの
YAML
ファイルを開きます。ファイル内の
spec: > args:
セクションを見つけます。この例を参考にして、
containers spec
のUNIQUE_
HOST_ID
引数を更新します。spec: containers: - name: client-api command: ["/bin/sh"] args: ["-c", "UNIQUE_HOST_ID=$(sed -rn '1s#.*/##; 1s/(.{12}).*/\\1/p' /proc/self/cgroup) && java -Dappdynamics.agent.uniqueHostId=$UNIQUE_HOST_ID $JAVA_OPTS -jar /java-services.jar"] envFrom: - configMapRef: name: agent-config
CODEAPM 相関が正しく機能している場合、[Pod Details] リンクをクリックすると、リンクによってそのノードの APM ノードダッシュボードが開きます。
クラスタエージェントまたはポッドがコントローラに表示されない
エージェントまたはポッドがコントローラに表示されない場合、またはエージェントまたはポッドが登録およびレポートされていない場合は、「クラスタエージェントのコントローラ設定」の sim.cluster.agent.limit
と sim.cluster.pod.limit
の説明を確認してください。
セキュリティポリシーが有効な場合にクラスタエージェントポッドが作成されない
ポッドセキュリティポリシーがクラスタに適用されている場合は、cluster-agent-operator.yaml
ファイルに次を追加します。
securityContext:
runAsUser: 1000
次の YAML ファイルの例は、セキュリティコンテキストを示しています。
apiVersion: apps/v1
kind: Deployment
metadata:
name: appdynamics-operator
namespace: appdynamics
.
.
spec:
.
.
.
template:
.
.
securityContext:
runAsUser: 1000