Summary

The Astra Traffic Collector (ATC) is a containerized service built on the OpenTelemetry (OTel) Collector. It receives traffic traces from sensors instrumented across your infrastructure - web servers, API gateways, service meshes, serverless functions, and mirrored network traffic - and forwards sanitized traces to Astra for API inventory building and vulnerability scanning.

Who Should Read This

DevOps engineers, platform teams, and security engineers responsible for setting up API observability, monitoring live traffic, or troubleshooting missing endpoints in Astra's API inventory.

How Traffic Collector Fits Into the Architecture

Astra's API Security Platform relies on two building blocks working together:

• Sensors : lightweight instrumentation added to your infrastructure (Nginx, Kong, Istio, Azure Functions, APIGEE, AWS API Gateway, custom applications using the OpenTelemetry SDK, or mirrored traffic via Astra Packet Processor). Each sensor is created in the Astra Dashboard under Integrations -> Traffic Connectors, producing a unique Sensor ID.

• Astra Traffic Collector (ATC) : a separate integration (with its own Collector ID, Client ID, and Client Secret) that receives OTLP traces from all your sensors, processes them, and exports them to Astra's backend.

Sensors send data to ATC; ATC sends data to Astra. Both are created independently under Traffic Connectors before you instrument anything.

Key Functions

Protocol support

ATC listens for OTLP traces over gRPC (port 4317, default) and OTLP/HTTP (port 4318, default). TLS/HTTPS can be enabled through the collector configuration, depending on your deployment requirements.

Authentication

ATC uses OAuth-based Client ID and Client Secret credentials. The collector obtains access tokens from Astra's IAM service and automatically refreshes them when required before exporting traces to Astra.

Processing pipeline

Before forwarding traces, ATC can filter (allow/deny by host or URL pattern), templatize (normalize dynamic path segments like product IDs), and redact (strip sensitive values such as credit card numbers)- all configured in config_custom.yaml.

Export

Processed traces are sent to Astra's backend, where they populate the API Inventory and drive endpoint discovery for scanning.

Storage

ATC can use the OpenTelemetry Collector's persistent file-storage extension to buffer traces if the backend is temporarily unreachable. The storage location depends on your deployment method.

Supported Sensor Types

ATC accepts traces from a variety of integrations, including:

• Web servers and reverse proxies: Nginx (including ingress-nginx in Kubernetes)

• API gateways: Kong, APIGEE, AWS API Gateway (via Astra Log Parser reading CloudWatch access logs)

• Service meshes: Istio (using EnvoyFilter and Lua-based instrumentation)

• Serverless platforms: Azure Functions (via the OpenTelemetry SDK)

• Custom applications instrumented using the OpenTelemetry SDK

• Mirrored traffic from AWS Traffic Mirroring or GCP Packet Mirroring, processed through Astra Packet Processor before reaching ATC

Available Deployment Options

ATC can be deployed as:

• Linux VM : Docker Compose with a systemd service (recommended for most self-managed deployments)

• Windows : Docker Compose deployment

• macOS : Docker Desktop using published ports (for example, 4317 and 4318)

• Kubernetes : Helm chart (traffic-collector-chart) with a custom ConfigMap for config_custom.yaml

• Cloud Marketplace image : Pre-built AWS, GCP, Azure, or DigitalOcean VM images with .env and config_custom.yaml already configured

• astra-cli : A wrapper tool that starts both ATC and a local Astra Proxy Service (MITM proxy) for temporary traffic capture from tools such as Postman, Burp Suite, Firefox, or curl

All deployment methods use the same two configuration files:

• An environment file (.env or astra.env) containing the Collector ID, Client ID, and Client Secret.

• config_custom.yaml for traffic processing rules.

Customizing Behavior

Edit config_custom.yaml to:

• Allowlist or excludelist traces by hostname or URL template

• Templatize dynamic URL segments (for example, /products/prod-12r4ty -> /products/{{product_id}})

• Redact sensitive data patterns (such as credit card numbers) from any part of the trace

After making changes, restart the Traffic Collector service to apply the updated configuration.

Examples:

• Linux: systemctl restart astra-traffic-collector

• Kubernetes: Restart the deployment or delete the pod so Kubernetes recreates it with the updated configuration.

Verifying Traces Are Flowing

Docker-based deployments (Linux, Windows, macOS)

docker logs astra-traffic-collector --since=15m

Kubernetes

kubectl logs astra-traffic-collector-0 -n astra-collector --since=15m

Look for OpenTelemetry attributes such as:

• sensor.id

• collector.id

• http.target

• http.host

• http.status_code

If these attributes are missing, the trace may not be processed correctly and the endpoint may not appear in the API Inventory.

Best Practices

• Use TLS (HTTPS) for production deployments to secure telemetry in transit.

• Keep business logic separate from telemetry instrumentation in custom applications.

• Test filtering and redaction rules in a non-production environment before forwarding traffic to Astra.

• Rotate Client Secrets periodically as part of your organization's credential management policy.

Troubleshooting

No entries in inventory or inventory is not updating

• Check that the hostname is listed under Scope URI in Target Setup or added under Extra Hosts.

• Verify that the Collector ID, Client ID, and Client Secret configured in the environment file are correct.

• Look for Unauthenticated errors in the collector logs, which typically indicate invalid or expired credentials.

Sensor cannot reach the collector

• Verify that the collector endpoint and ports (4317 for OTLP/gRPC or 4318 for OTLP/HTTP) are reachable from the sensor.

• For Istio deployments, confirm that the required ServiceEntry or networking configuration allows outbound communication to the collector endpoint.

No logs are printed

Collector logs appear only after a sensor successfully sends traces.

Verify that:

• The sensor is configured with the correct collector endpoint.

• Network connectivity to ports 4317 or 4318 is available.

• The sensor is actively generating telemetry.

Regenerating credentials

Go to Active Integrations, select the Traffic Collector instance, open the three-dot menu, and choose Regenerate Client Secret.

Update the new credentials in your .env or astra.env file and restart the Traffic Collector service. Previously issued credentials will no longer be valid after regeneration.

Need Help?

If you need assistance with configuring or troubleshooting Astra Traffic Collector, raise a support ticket directly from your Astra Dashboard. Our support team will help you verify your deployment and resolve any integration issues.