例 1 は、ecom.* パターンに一致する名前空間の Java アプリケーションをターゲットとしています。一致する各アプリケーションは 20.20.1 Java エージェントでインストゥルメント化され、 Splunk AppDynamics コントローラの Ecommerce アプリケーションにレポートされます。デフォルトでは、階層名は Kubernetes ワークロードの名前ですが、tierName プロパティを設定することで上書きできます。

apiVersion: cluster.appdynamics.com/v1alpha1
kind: Clusteragent
metadata:
name: k8s-cluster-agent
namespace: appdynamics
spec:
appName: "<cluster-name>"
controllerUrl: "<protocol>://<appdynamics-controller-host>:8080"
account: "<account-name>"
image: "docker.io/appdynamics/cluster-agent:20.12.1"
serviceAccountName: appdynamics-cluster-agent
nsToMonitorRegex: ecom.*
#
# auto-instrumentation config
#
instrumentationMethod: Env
nsToInstrumentRegex: ecom.*
defaultAppName: Ecommerce
instrumentationRules:
- language: java
imageInfo:
image: docker.io/appdynamics/java-agent:20.20.1
agentMountPath: /opt/appdynamics

例 2 は、Java アプリケーションと Linux 上の .NET Core アプリケーションを含む名前空間をターゲットとし、次の詳細設定を組み込みます。

• Java アプリケーションと Linux 上の .NET Core アプリケーションをターゲットに、複数の instrumentationRules を使用します。
• labelMatch 戦略を使用し、ワークロード仕様 auto-instrumented-dotnet-app.yaml と auto-instrumented-java-app.yaml の framework ラベルの値に基づいてエージェントタイプと関連するエージェントイメージを決定します。
• この設定では、YAML ファイルでコントローラのアプリケーション名を割り当てるのではなく、appNameStrategy: label を使用し、ワークロード仕様のラベルに基づいてアプリケーション名を割り当てます。
• Java アプリケーションの場合は、instrumentContainer: select および containerMatchString: .*service を使用して、アプリケーション サービス コンテナのみを自動インストゥルメント化するようにクラスターエージェントに指示し、定義されている他のコンテナは無視します。

apiVersion: cluster.appdynamics.com/v1alpha1
kind: Clusteragent
metadata:
name: k8s-cluster-agent
namespace: appdynamics
spec:
appName: "<cluster-name>"
controllerUrl: "<protocol>://<appdynamics-controller-host>:8080"
account: "<account-name>"
image: "docker.io/appdynamics/cluster-agent:20.12.1"
serviceAccountName: appdynamics-cluster-agent
nsToMonitorRegex: ecom.*
#
# auto-instrumentation config
#
instrumentationMethod: Env
nsToInstrumentRegex: stage
appNameStrategy: label
instrumentationRules:
- namespaceRegex: stage
language: dotnetcore
labelMatch:
- framework: dotnetcore
appNameLabel: appName
imageInfo:
image: "docker.io/appdynamics/dotnet-core-agent:20.11.0-linux"
agentMountPath: /opt/appdynamics
- namespaceRegex: stage
language: java
labelMatch:
- framework: java
appNameLabel: appName
instrumentContainer: select
containerMatchString: .*service
imageInfo:
image: "docker.io/appdynamics/java-agent:21.3.0"
agentMountPath: /opt/appdynamics

例 3 および例 4 は、.NET および Java サービスの導入仕様を示しています。これらは、cluster-agent-auto-2.yaml の自動インストゥルメンテーション設定に基づいて appName およびフレームワークラベルを定義します。

例 3：auto-instrumented-dotnet-app.yaml

.NET

apiVersion: apps/v1
kind: Deployment
metadata:
name: dotnet-profile-service
labels:
appName: backend-services
framework: dotnetcore
spec:
containers:
- image: myrepo/profile-service:v2
name: profile-service
# ...

例 4：auto-instrumented-java-app.yaml

Java

apiVersion: apps/v1
kind: Deployment
metadata:
name: java-account-service
labels:
appName: backend-services
framework: java
spec:
containers:
- image: myrepo/account-service:v2
name: account-service
- image: myrepo/proxy-util:v1
name: proxy-util
# ...

cluster-agent-auto-2.yaml の containerMatchString の値は、account-service コンテナのみが auto-instrumented-java-app.yaml で自動インストゥルメント化されることを示しています。

追加の構成例については、 「自動インストルメンテーションの構成例」を参照してください。