Troubleshooting the Praxis collector on Kubernetes

Use this guide when the Praxis collector running in Kubernetes is not sending data to your destinations, or has lost its connection to the Praxis backend.

Work through the steps in order. Most issues are caught in Step 1 (pod state) or Step 2 (network)—please run these before opening a support ticket, and include the results if you still need help.

Replace <namespace> with the namespace you installed the collector into.

How the collector connects

The collector makes an outbound HTTPS connection (TCP 443) from inside the cluster to the Praxis backend. It uses that connection to receive its configuration and to send your telemetry. The connection is outbound only—no inbound ports need to be opened.

If pods cannot reach the Praxis backend on TCP 443 (blocked by a NetworkPolicy, egress firewall, or missing DNS), both configuration updates and data delivery stop.

:::note Use your backend host The examples use praxis.netenrich.com. If your environment was given a different Praxis backend host during installation, substitute it wherever it appears below. :::

Step 1 — Are the collector pods healthy?

kubectl get pods -n <namespace> -l app.kubernetes.io/name=praxis-collector

Look at the STATUS column:

Status	What it usually means
Running (Ready 1/1)	Pod is up — if there's still no data, go to Step 2 (network) and Step 3 (logs).
CrashLoopBackOff / Error	The collector is failing to start — check Step 3 (logs).
Pending	Not scheduled — usually insufficient node resources or an unbound volume.
ImagePullBackOff / ErrImagePull	The node cannot pull the image — check registry access / image pull secrets.

Inspect a specific pod's recent events:

kubectl describe pod <pod-name> -n <namespace>

Step 2 — Verify network reachability from inside the cluster

Egress rules apply inside the cluster, so test from a pod—not from your laptop.

2a. Does DNS resolve, and is port 443 reachable?

Run a throwaway test pod in the same namespace:

kubectl run praxis-nettest --rm -it --restart=Never -n <namespace> \
  --image=curlimages/curl -- curl -v https://praxis.netenrich.com

Look for a completed TLS handshake and any HTTP response—that means the cluster reached the backend. Could not resolve host points to cluster DNS (CoreDNS); Connection timed out / refused points to an egress NetworkPolicy or firewall.

:::warning ping is not a reliable test ICMP is often blocked even when HTTPS is allowed, and many minimal images don't include ping. Rely on the port-443 test above, not on ping. :::

2b. If the test fails

• Check for an egress NetworkPolicy that blocks outbound 443 or DNS from the collector's pods:

  kubectl get networkpolicy -n <namespace>

• Confirm the cluster/node egress firewall (cloud security groups, NAT gateway rules) allows outbound TCP 443 to the Praxis backend host.
• If egress requires an HTTP proxy, the collector must be configured to use it, and any TLS-inspection proxy's certificate must be trusted.
• Allowlist the hostname, not a fixed IP—the IP can change.

Step 3 — Check the collector logs

In Kubernetes the collector logs to stdout, so use kubectl logs:

kubectl logs <pod-name> -n <namespace>

If a pod restarted, view the previous container's logs:

kubectl logs <pod-name> -n <namespace> --previous

Errors and warnings are logged by default, so you can read them directly.

What the messages mean

What you see	Likely cause
connection refused / connection timed out / no route to host	Egress blocked — return to Step 2
TLS handshake error / certificate signed by unknown authority	TLS-inspection proxy or untrusted certificate
Authentication/authorization errors (401 / 403)	Credential issue; the collector may need to be re-enrolled. Note and send to support
context deadline exceeded / request timeouts	Praxis backend unreachable or too slow — usually egress/network
Repeated "reconnecting" / connection-dropped messages	Unstable or filtered egress path (often a proxy closing idle connections)
no such host / DNS lookup failures	Cluster DNS (CoreDNS) — return to Step 2a

Step 4 — Restart the collector (if needed)

Roll the collector's workload to pick up a fresh start:

kubectl rollout restart deployment/<release-name>-praxis-collector-supervisor -n <namespace>

Replace <release-name> with your Helm release name. If you're unsure of the exact deployment name:

kubectl get deploy -n <namespace> -l app.kubernetes.io/name=praxis-collector

Step 5 — Common causes checklist

Confirm each of these before contacting support:

• Pods are Running / Ready, not Pending / CrashLoopBackOff / ImagePullBackOff (Step 1).
• Outbound TCP 443 to the Praxis backend works from inside the cluster (Step 2a).
• Cluster DNS resolves the Praxis backend hostname (Step 2a).
• No egress NetworkPolicy or node/cloud firewall blocks outbound 443 (Step 2b).
• No proxy or TLS-inspection appliance is silently intercepting egress.
• Nothing changed recently — a new NetworkPolicy, firewall rule, or cluster upgrade.

What to send us if you still need help

Collecting these upfront resolves tickets much faster:

1. Collector chart/image version and Kubernetes version.
2. Symptom — "no data at destination" vs. "lost connection to Praxis," and roughly when it started.
3. Step 1 result — kubectl get pods output (and kubectl describe pod for any unhealthy pod).
4. Step 2 result — output of the praxis-nettest curl pod.
5. Collector logs — kubectl logs around the failure (Step 3). Redact any secrets.
6. Network context — any egress NetworkPolicy, proxy, or firewall between the cluster and the internet, and any recent changes.