Deployment index: every mode in telemetry-shippers

Quick reference for which deployment strategy applies to which infrastructure. The other rule files in this skill cover the six primary modes in depth; everything else is indexed here with a one-paragraph callout.

Contents

• Master deployment table
• Secondary deployment callouts
• Deprecated Kubernetes charts
• Fleet Management-related paths
• macOS standalone
• Choosing the right mode
• Key facts

Master table

Callouts — secondary deployments

Short one-paragraph entries for the modes not covered in a dedicated rule file. Enough to route a user to the right directory and flag the unique gotcha; read the source README for the full recipe.

otel-ecs-ec2-windows

Windows Server 2022 ECS on EC2 with OTel deployed as a Daemon service. Network mode is awsvpc, not host — unlike Linux ECS EC2. No filelog receiver (Windows containers don't expose log files on the host the same way), and Docker is unavailable for container introspection. Current CDOT builds (v0.5.11+, coralogix/coralogix-otel-collector#176) fall back to ECS task metadata when Docker is missing on Windows, so host-related resource attributes can still populate for Infra Explorer. opamp extension depends on the pinned image version — the Windows CloudFormation template historically ships an older Windows collector image (coralogixrepo/coralogix-otel-collector:<version>-windowsserver-2022) that predates OpAMP on Windows; for Fleet Management there, use the -Supervisor wrapper or bump to a collector build ≥ v0.130. (The otel-windows-standalone chart on a modern build DOES render extensions: [opamp] by default.) Minimum instance type t3.xlarge because of Windows memory footprint; infrastructure uses a NAT Gateway in a private subnet. resourcedetection.detectors uses [env] only — the system detector fails on Windows. See telemetry-shippers/otel-ecs-ec2-windows/ for the values.yaml.

otel-batch-ecs-ec2

AWS Batch job definitions with a sidecar OTel container. Batch jobs are one-shot: start → run → exit. Config is pulled from SSM Parameter Store (otel_config_parameter_store_cfn.yaml creates the parameter + execution role), loaded via --config env:OTEL_CONFIG. The app container must dependsOn: [{containerName: otel-collector, condition: START}] — same anti-race pattern as ECS Fargate but scoped to one-shot jobs. FireLens routes logs through the sidecar. Image: coralogixrepo/coralogix-otel-collector:<version>. Troubleshooting: "job stuck in RUNNABLE" is usually compute-environment vCPU limits, not an OTel problem; "permission denied" is the Batch execution role missing ssm:GetParameter on the config parameter.

otel-eks-fargate

EKS Fargate uses a statefulset for the primary collector (Fargate doesn't support daemonsets because there's no shared host) and a secondary deployment that acts as a self-monitoring pod (Fargate workloads can't reach the host kubelet). Two manifests: cx-eks-fargate-otel.yaml (primary) and cx-eks-fargate-otel-self-monitoring.yaml (secondary). Requires IRSA (IAM roles for service accounts) with CloudWatchAgentServerPolicy:

eksctl utils associate-iam-oidc-provider --cluster=NAME --approve
eksctl create iamserviceaccount --cluster=NAME --region=REGION \
  --name=cx-otel-collector --namespace=cx-eks-fargate-otel \
  --role-name=EKS-Fargate-cx-OTEL-ServiceAccount-Role \
  --attach-policy-arn=arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy --approve
kubectl apply -f cx-eks-fargate-otel.yaml

Current cx-eks-fargate-otel.yaml includes k8sattributes in the traces and metrics/otlp pipelines (verified against the telemetry-shippers HEAD manifest). A historical version was missing it — users on an older copy of the manifest who report empty pod metrics / related-data visualizations should re-pull the manifest rather than hand-patching. The metrics/kubeletstats and metrics/self pipelines intentionally do not run k8sattributes; users needing pod-level enrichment on those pipelines still need to add it. Each Fargate pod has a unique IP (contrary to an earlier misconception that Fargate pods shared IPs), so pod_association: [{sources: [{from: resource_attribute, name: k8s.pod.ip}]}] works correctly. Alternative for users wanting cluster-wide tail sampling: the otel-integration chart with values-eks-fargate.yaml deploying into the same cluster. See telemetry-shippers/otel-eks-fargate/.

otel-agent/k8s-helm and otel-agent/k8s-helm-windows (deprecated)

The old agent-only chart (coralogix/opentelemetry-coralogix). Deprecated in favor of otel-integration which bundles agent + cluster-collector + optional gateway in one chart. Users still on this chart see missing features (no Infra Explorer entity events, missing span metrics defaults, no Fleet Management support). Migration:

helm uninstall otel-coralogix-agent -n coralogix
helm upgrade --install otel-coralogix-integration coralogix/otel-integration -n coralogix -f values.yaml

Similarly, otel-agent/k8s-helm-windows is deprecated — use otel-integration with opentelemetry-agent-windows.enabled: true.

otel-infrastructure-collector (deprecated)

Single-replica cluster-level collector. Superseded by the opentelemetry-cluster-collector subchart of otel-integration. No new deployments — migrate users to the current chart.

Fleet Management–related paths

otel-ecs-supervisor, otel-supervised-collector, otel-supervised-cdot, otel-supervised-ebpf-profiler — all use the OpAMP supervisor pattern for remote config management. See preset-fleet-management.md for the surface area that intersects with this skill. Deep OpAMP protocol / supervisor-binary / remote-config-precedence coverage is out of scope here.

macOS standalone

otel-macos-standalone uses launchd (com.coralogix.otelcol plist label, /opt/otelcol install prefix). Same env conventions as Linux standalone (CORALOGIX_PRIVATE_KEY, CORALOGIX_DOMAIN). Logs via filelog against /var/log/system.log (no journald on macOS). See the macOS note at the end of setup-linux-standalone.md.

Choosing the right mode

Key Facts

• otel-integration is the primary Kubernetes deployment. otel-agent/k8s-helm and otel-infrastructure-collector are deprecated.
• ECS EC2 Windows uses awsvpc + no filelog. Linux ECS EC2 uses host network + filelog. Don't reuse Linux patterns on Windows.
• EKS Fargate uses a statefulset and needs a separate self-monitoring pod. Current manifest HAS k8sattributes in traces and metrics/otlp (earlier versions did not — users on old copies should re-pull).
• AWS Batch sidecars load config from SSM and need the dependsOn START anti-race pattern.
• macOS = launchd, Linux = systemd, Windows = Service. Otherwise the same env/config contract.
• Fleet Management / OpAMP-supervisor paths (otel-ecs-supervisor etc.) are out of scope beyond the minimum overlap — see preset-fleet-management.md for that overlap (endpoint shape, values-vs-UI precedence). Deep OpAMP internals are not covered here.