verify-ssi

作成者: datadog-labs

Verify Single Step Instrumentation (SSI)がKubernetes上でエンドツーエンドで動作していることを確認します — SSIはコード変更なしでアプリケーションをAPM用に自動的に計装します。のみ…

npx skills add https://github.com/datadog-labs/agent-skills --skill verify-ssi

Verify APM SSI on Kubernetes

Before doing anything else: Fully resolve all variables in ## Context to resolve before acting. Do not begin Step 1 until every variable has a concrete value.

Triggers

Invoke this skill when the user expresses intent to:

  • Confirm SSI is working after enabling APM
  • Check whether pods are being instrumented
  • Verify the tracer is running and reporting telemetry
  • Confirm tracer config is applied correctly

Do NOT invoke this skill if:

  • SSI has not been enabled yet — run enable-ssi first
  • Pods are not being instrumented at all — use troubleshoot-ssi

Prerequisites

  • enable-ssi is complete
  • Application pods have been restarted since SSI was enabled

pup-cli: check, install, and authenticate

Claude runs

pup --version

If not found:

Claude runs

brew tap datadog-labs/pack
brew install pup

Check auth:

pup auth status --site <DD_SITE>

If not authenticated:

Claude runs

pup auth login --site <DD_SITE>

This opens a browser tab for OAuth. Complete the login there — Claude will continue once the command exits.

If valid token — proceed. ERROR: No browser available — use API key fallback: export DD_APP_KEY=<your-app-key>


Context to resolve before acting

VariableHow to resolve
CLUSTER_NAMECheck spec.global.clusterName in datadog-agent.yaml, or kubectl config current-context
ENVCheck tags.datadoghq.com/env label on the application Deployment
SERVICE_NAMECheck tags.datadoghq.com/service label on the application Deployment

Step 1: Confirm Pods are Instrumented

Claude runs

kubectl get pod -l app=<APP_LABEL> -n <APP_NAMESPACE> \
  -o jsonpath='{.items[0].spec.initContainers[*].name}'

If the output includes datadog-lib-<language>-init and datadog-init-apm-inject — SSI init containers are injected.

ERROR: Init containers missing — pod was not restarted after SSI was enabled, or namespace targeting is not matching. Restart the pod and recheck.


Step 2: Confirm the Tracer is Reporting Telemetry

Claude runs

DD_SITE=<DD_SITE> pup apm services list --env <ENV> --from 1h

If <SERVICE_NAME> appears in the services list with isTraced: true — continue to Step 3.

ERROR: Service missing — send some traffic to the app first, then retry:

Claude runs

# Port-forward and send test traffic
kubectl port-forward deployment/<DEPLOYMENT_NAME> 8099:8000 -n <APP_NAMESPACE> &
sleep 2 && for i in $(seq 1 10); do curl -s -o /dev/null http://localhost:8099/; done
sleep 30 && kill %1 2>/dev/null
DD_SITE=<DD_SITE> pup apm services list --env <ENV> --from 10m

ERROR: Still missing after traffic — check the agent's trace receiver: kubectl exec -n <AGENT_NAMESPACE> <AGENT_POD> -c agent -- agent status | grep -A 10 "Receiver (previous minute)". If receiver shows 0 traces, go to troubleshoot-ssi.


Step 3: Confirm Tracer Configuration

Only run this step if ddTraceConfigs was explicitly configured in enable-ssi (e.g. profiling, AppSec, Data Streams). If basic SSI was set up without ddTraceConfigs, skip this step — an empty response here is expected and not a failure.

Claude runs

pup apm service-library-config get \
  --service-name <SERVICE_NAME> \
  --env <ENV>

If the output shows expected environment variables matching what was configured in ddTraceConfigs — done.

If the output is empty and ddTraceConfigs was not configured — expected, not a failure.

ERROR: Config missing but ddTraceConfigs was configured — check it is present in the DatadogAgent manifest under the correct target, and that pods were restarted after the config change.


Done

Exit when ALL of the following are true:

  • Step 1: target pods have SSI init containers injected (datadog-lib-<language>-init and datadog-init-apm-inject)
  • Step 2: service appears in pup apm services list with isTraced: true
  • Step 3: tracer config matches what was set in DatadogAgent

If any check fails, go to troubleshoot-ssi.

When all steps pass, automatically proceed to onboarding-summary now — do not ask the user for permission.


Security constraints

  • Never write a raw API key into any file or chat message
  • Never run kubectl delete without user confirmation

datadog-labsのその他のスキル

dd-audit
datadog-labs
監査証跡の調査 - 誰が何を変更したか、鍵の侵害、コスト急増の根本原因、コンプライアンス証拠(SOC 2/PCI)、およびAIアクティビティの監査。
official
agent-install
datadog-labs
Datadog Operatorを使用してKubernetesにDatadog Agentをインストールします — Single Step Instrumentation (SSI)を有効にする前に必要であり、これは自動的に…
official
agent-observability-auto-experiment
datadog-labs
実在のDatadog LLM-Obsデータに対して、Claude Codeをエージェントとして、反復的なコード改善のヒルクライムをローカルで実行します。ベースライン評価を確立し、1つの…
official
agent-observability-eval-bootstrap
datadog-labs
本番トレースから評価器を初期設定する — デフォルトではオンラインLLM-judge評価器を提案し、確認後にDatadogで無効なドラフトとして作成します…
official
agent-observability-eval-pipeline
datadog-labs
計装されたml_app向けのエンドツーエンドのエージェント可観測性パイプライン — 本番トレースを分類し、障害の根本原因を特定し、評価器をブートストラップし、その後(オプションで)…
official
agent-observability-experiment-analyzer
datadog-labs
LLM実験結果を分析します。単一または比較実験、探索的またはQ&Aモードに対応します。ユーザーが「analyze experiment」「compare…」と言った場合に使用します。
official
agent-observability-replay-trace
datadog-labs
開発者が、出力が気に入らなかった特定のAgent Observability / LLM Obsトレースに対して反復作業を行いたい場合に使用します — そのトレースを再実行して…
official
agent-observability-trace-rca
datadog-labs
本番環境のLLMトレースに対する根本原因分析。LLMアプリケーションが失敗する理由を診断し、評価ジャッジの判定、ランタイムエラー、または構造的な問題から分析を開始します…
official