| name | splunk-appdynamics-k8s-cluster-agent-setup |
| description | Render, validate, and gate Splunk AppDynamics Kubernetes Cluster Agent, Kubernetes auto-instrumentation, and Splunk OpenTelemetry Collector setup through the Cluster Agent, including dual-signal combined-agent plans for Java, .NET Core Linux, Node.js, Machine Agent handoff, and Splunk Observability Cloud export validation. Use when the user asks for AppDynamics Cluster Agent, Kubernetes monitoring, AppDynamics Kubernetes auto-instrumentation, Splunk OTel Collector through Cluster Agent, O11y export, or workload rollout validation. |
| compatibility | No direct Splunk Platform runtime dependency. This workflow can be used alongside Splunk Cloud Platform 10.5.2605 through its documented external APIs or handoffs. |
| metadata | {"splunk_cloud_10_5":"not-applicable","compatibility_verified":"2026-07-02"} |
Splunk AppDynamics Kubernetes Cluster Agent Setup
Kubernetes mutations require --accept-k8s-rollout. Render mode writes Helm
values, O11y collector values, secret templates, combined-agent workload
patches, and validation runbooks without touching the active cluster.
bash skills/splunk-appdynamics-k8s-cluster-agent-setup/scripts/setup.sh --render
bash skills/splunk-appdynamics-k8s-cluster-agent-setup/scripts/validate.sh
Read-only Controller API validation for Cluster Agent availability can be run
with file-backed credentials:
bash skills/splunk-appdynamics-k8s-cluster-agent-setup/scripts/poll_cluster_agent_availability.sh \
--application 'Server & Infrastructure Monitoring' \
--duration-mins 5
The probe defaults to
Application Infrastructure Performance|Root|Individual Nodes|*|Cluster Agent|Availability
so it can read every visible Cluster Agent under Server Visibility. Pass
--metric-path only when you want to pin validation to a copied full path for
one Cluster Agent.
A disabled Server Visibility health rule for Cluster Agent availability can be
rendered first, then applied after the API client has Server health-rule
permissions:
bash skills/splunk-appdynamics-k8s-cluster-agent-setup/scripts/create_cluster_agent_availability_health_rule.sh
bash skills/splunk-appdynamics-k8s-cluster-agent-setup/scripts/create_cluster_agent_availability_health_rule.sh \
--apply
Typical flow:
- Edit
template.example or pass --spec <file> with Controller, cluster,
Splunk Observability realm, token file path, and workload targets.
- Render first and review
cluster-agent-values.yaml,
splunk-otel-collector-values.yaml, dual-signal-workload-env.yaml, and
cluster-agent-rollout-plan.sh.
- Keep O11y tokens, the Controller password, and the Controller access key
file-backed. The rollout plan uses
--set-file; it does not render values.
- Execute the reviewed rollout only after explicit approval:
bash skills/splunk-appdynamics-k8s-cluster-agent-setup/scripts/setup.sh \
--apply rollout --accept-k8s-rollout --spec path/to/spec.yaml
The wrapper renders and then executes cluster-agent-rollout-plan.sh with the
mutation gate enabled. Running that rendered script directly remains dry-run by
default and requires K8S_APPLY=1 before it mutates Kubernetes.
Controller URLs default to HTTPS. Plain HTTP requires the explicit
accept_insecure_controller_http: true exception. The O11y validation API is
restricted to https://api.<realm>.signalfx.com; a reviewed proxy additionally
requires splunk_otel_collector.accept_custom_api_url: true. Live O11y
validation fails when its chmod-600 token file, Helm-release pods, readiness, or
collector log access is unavailable; it never reports a skipped probe as a pass.
