自動インストルメンテーションの検証

このページでは、クラスタエージェントの自動インストルメンテーションを検証およびトラブルシューティングする方法について説明します。

前提条件

エージェントがコントローラにレポートしていること。「クラスターエージェントのインストールの検証」を参照してください。
クラスターエージェントをアップグレードした場合は、「クラスターエージェントのアップグレード」の手順に従い、互換性のあるイメージと YAML ファイルのセットを使用していること。

自動インストルメンテーションの検証

自動インストゥルメンテーションを適用した後、選択した名前戦略に基づいて割り当てられたアプリケーション名を使用して、アプリケーションがコントローラにレポートしていることを確認します。「クラスタエージェントを使用したアプリケーションの自動インストルメンテーション」を参照してください。
自動インストゥルメンテーションの対象となるアプリケーションポッドが再作成されたことを確認します。自動インストゥルメンテーションが適用されているため、 -w フラグを指定して kubectl get pods を使用すると、ポッドステータスの更新がリアルタイムで出力されます。正常に自動インストゥルメント化されたアプリケーションでは、アプリケーションポッドが再作成されたこと、正しい init コンテナが適用され、アプリケーションサーバエージェントがアプリケーションコンテナにコピーされたことが示されます。
```
kubectl -n <app ns> get pods -w
NAME                          READY   STATUS            RESTARTS   AGE
dotnet-app-85c7d66557-s8hzm   1/1     Running           0          3m11s
dotnet-app-6c45b6d4f-fpp75    0/1     Pending           0          0s
dotnet-app-6c45b6d4f-fpp75    0/1     Init:0/1          0          0s
dotnet-app-6c45b6d4f-fpp75    0/1     PodInitializing   0          5s
dotnet-app-6c45b6d4f-fpp75    1/1     Running           0          6s
dotnet-app-85c7d66557-s8hzm   1/1     Terminating       0          20m\
```
また、kubectl get pods -o yaml を使用して、init コンテナと init コンテナの状態が含まれるようにアプリケーションの仕様が更新されたかどうかを確認することもできます。
```
kubectl -n <app-ns> get pod <app-pod> -o yaml
...
initContainers:
- command:
- cp
- -r
- /opt/appdynamics/.
- /opt/appdynamics-java
image: docker.io/appdynamics/java-agent:latest
...
initContainerStatuses:
- containerID: docker://8bb892f322e5a043866d038631392a2272b143e54c8c431b3590312729043eb9
image: appdynamics/java-agent:20.9.0
imageID: docker-pullable://appdynamics/java-agent@sha256:077ac1c4f761914c1742f22b2f591a37a127713e3e96968e9e570747f7ba6134
...
state:
terminated:
containerID: docker://8bb892f322e5a043866d038631392a2272b143e54c8c431b3590312729043eb9
exitCode: 0
finishedAt: "2021-02-03T22:39:25Z"
reason: Completed
```
注: インストゥルメンテーションが正常に完了した場合でも、ポッドアノテーションで Node.js および .NET Core（Linux）アプリケーションの APPD_POD_INSTRUMENTATION_STATE が failed と表示されることがあります。

適用されない場合の自動インストゥルメンテーションのトラブルシューティング

アプリケーションポッドが再作成されず、init コンテナが適用されなかった場合は、クラスタエージェントで使用される名前空間とアプリケーションの一致ルールに問題がある可能性があります。

最初に、クラスタエージェントが最新の自動インストゥルメンテーション構成を使用していることを確認します。
```
kubectl -n appdynamics get cm instrumentation-config -o yaml
```
YAML 出力に最新の自動インストゥルメンテーション構成が反映されていない場合は、クラスタエージェントの YAML 設定を検証し、クラスタエージェントを適用またはアップグレードします。
Kubernetes CLI
```
kubectl apply -f cluster-agent.yaml
```
Helm チャート
```
helm upgrade -f ./ca1-values.yaml "<my-cluster-agent-helm-release>" appdynamics-charts/cluster-agent --namespace appdynamics
```

それでもポッドが再作成されない場合は、クラスターエージェントの設定で DEBUG ロギングを有効にします。

クラスタエージェント YAML

cluster-agent.yaml

apiVersion: cluster.appdynamics.com/v1alpha1
kind: Clusteragent
metadata:
name: k8s-cluster-agent
namespace: appdynamics
spec:
# content removed for brevity
logLevel: DEBUG

Helm 値 YAML

ca1-values.yaml

clusterAgent:
# content removed for brevity
logProperties:
logLevel: DEBUG

DEBUG ロギング設定を更新するには、クラスターエージェントを適用またはアップグレードします。
Kubernetes CLI
```
kubectl apply -f cluster-agent.yaml
```
Helm チャート
```
helm upgrade -f ./ca1-values.yaml "<my-cluster-agent-helm-release>" appdynamics-charts/cluster-agent --namespace appdynamics
```
クラスタエージェントのロギング設定を更新したら、ログを追跡し、クラスタエージェントがアプリケーションを検出していること、およびアプリケーションを自動インストゥルメンテーションの対象範囲内と見なしていることを示すメッセージを検索します。
```
# apply grep filter to see instrumentation related messages:
kubectl -n appdynamics logs <cluster-agent-pod> -f | grep -E 'instrumentationconfig.go|deploymenthandler.go'
```
ただし、（この例と同様に）自動インストゥルメント化するアプリケーションの出力が表示される場合には、クラスタエージェントはアプリケーションを自動インストゥルメンテーションの対象範囲内と見なしていません。
```
[DEBUG]: 2021-03-30 21:22:09 - instrumentationconfig.go:660 - No matching rule found for Deployment dotnet-app in namespace stage with labels map[appName:jah-stage framework:dotnetcore]
[DEBUG]: 2021-03-30 21:22:09 - instrumentationconfig.go:249 - Instrumentation state for Deployment dotnet-app in namespace stage with labels map[appName:jah-stage framework:dotnetcore] is false
```
自動インストゥルメンテーション構成を確認して必要な更新を決定し、変更を保存します。次に、前述のようにクラスタエージェントを削除して再作成します。たとえば、namespaceRegex を使用して instrumentationRule の名前空間設定を上書きした場合は、nsToInstrumentRegex に含まれている値を使用してください（この例では dev）。
```
apiVersion: cluster.appdynamics.com/v1alpha1
kind: Clusteragent
metadata:
name: k8s-cluster-agent
namespace: appdynamics
spec:
# content removed for brevity
nsToInstrumentRegex: stage|dev
instrumentationRules:
- namespaceRegex: dev
```

設定を更新し、クラスタエージェントが再作成されると、出力は次の例のようになります。これは、クラスタエージェントがアプリケーションを自動インストゥルメンテーションの対象範囲内として認識していることを示しています。

[DEBUG]: 2021-03-30 21:22:10 - instrumentationconfig.go:645 - rule stage matches Deployment spring-boot-multicontainer in namespace stage with labels map[appName:jah-stage acme.com/framework:java]
[DEBUG]: 2021-03-30 21:22:10 - instrumentationconfig.go:656 - Found a matching rule {stage  map[acme.com/framework:[java]]   java select .*  JAVA_TOOL_OPTIONS map[agent-mount-path:/opt/appdynamics image:docker.io/appdynamics/java-agent:21.3.0 image-pull-policy:IfNotPresent] map[bci-enabled:true port:3892] 0 0 appName  0 false []} for Deployment spring-boot-multicontainer in namespace stage with labels map[appName:jah-stage acme.com/framework:java]
[DEBUG]: 2021-03-30 21:22:10 - instrumentationconfig.go:249 - Instrumentation state for Deployment spring-boot-multicontainer in namespace stage with labels map[appName:jah-stage acme.com/framework:java] is true
[DEBUG]: 2021-03-30 21:22:10 - deploymenthandler.go:312 - Added instrument task to queue stage/spring-boot-multicontainer

完了できなかった場合の自動インストゥルメンテーションのトラブルシューティング

アプリケーションポッドが再作成されたものの、インストゥルメント化されたアプリケーションがコントローラにレポートしていない場合、自動インストゥルメンテーションが正常に完了しなかったか、アプリケーションサーバーエージェントがコントローラに登録できていません。

アプリケーションポッドが再起動されており、init コンテナが正常に完了していない場合は、[Cluster Agent Events] ダッシュボードまたは kubectl get events を使用してアプリケーション名前空間のイベントを確認します。init コンテナの実行を妨げる可能性のある一般的な問題としては、イメージプルまたはリソースクォータの問題があります。
```
kubectl -n <app ns> get events
```
アプリケーションの導入仕様が init コンテナで更新されたこと、およびステータス情報にエラーが含まれているかどうかを確認します。
```
kubectl -n <app-ns> get pod <app-pod> -o yaml
```

アプリケーションコンテナ内でシェルを起動して、自動インストゥルメンテーションの結果を確認します。アプリケーションサーバーエージェントの環境変数が正しく設定されているかどうか、およびログにエラーがないかどうかを確認します。

kubectl -n <app-ns> exec -it <app-pod> /bin/sh
# Issue these commands in the container
env | grep APPD
# For Java app
env | grep JAVA_TOOL_OPTIONS # or value of defaultEnv
ls /opt/appdynamics-java
cat /opt/appdynamics-java/ver<version>/logs/<node-name>/agent.<date>.log
# For .NET Core app
ls /opt/appdynamics-dotnetcore
cat /tmp/appd/dotnet/1_agent_0.log
# For Node.js app
ls /opt/appdynamics-nodejs
cat /tmp/appd/<id>/appd_node_agent_<date>.log

Node.js または .NET Core アプリケーションをインストゥルメント化しているときに、自動インストゥルメンテーションファイルがアプリケーションコンテナにコピーされており、アプリケーションサーバーエージェントのログが存在しない場合、またはバイナリの非互換性に関するエラーが表示される場合は、アプリケーションイメージと（自動インストゥルメンテーション設定のイメージプロパティで参照される）アプリケーションサーバーエージェントイメージが一致していない可能性があります。.NET Core の場合、イメージ OS のバージョンが一致している必要があります（Linux など）。Node.js の場合、イメージ OS のバージョンと Node.js のバージョンが一致している必要があります。確認するには、イメージタグ、Dockerfile、またはアプリケーションコンテナに対する exec の実行をチェックします。
```
$ kubectl -n <app-ns> exec -it <app-pod> /bin/sh
cat /etc/os-release   # (or /etc/issue)
NAME="Alpine Linux"...
# for Node.js app
node -v
```

アップグレードされた展開の再インストルメンテーションの問題のトラブルシューティング

Helm アップグレードを使用して展開仕様を編集する場合、クラスタエージェントはアップグレードされた展開を再インストゥルメントしません。クラスタエージェントが適用した仕様への変更がインストルメンテーションプロパティに干渉する場合、インストルメンテーションは機能しなくなります。この問題は主に、Java インストルメンテーションで、Java アプリケーションが JAVA_TOOL_OPTIONS を使用しており、helm アップグレードによって展開仕様の JAVA_TOOL_OPTIONS 環境変数がオーバーライドされる可能性がある場合に発生します。Java エージェントがこの環境変数を使用してシステムプロパティを消費するため、オーバーライドが発生し、インストルメンテーションが失敗します。
クラスタエージェントは、アノテーションを使用して、展開のインストルメンテーションの状態を確認します。展開ツールまたはスクリプトが編集またはパッチ Kubernetes API を使用して展開仕様を編集する場合、展開のアノテーションは更新されません。したがって、インストルメンテーションの状態に変更がない場合、再インストルメンテーションは発生しません。
展開仕様のアノテーション APPD_DEPLOYMENT_INSTRUMENTATION_STATE を削除すると、この問題を回避できます。