Ports & exposure
How you reach Orbtrace on Kubernetes and how to change any port — the app on 8080, your Collector's OTLP ports, and the Doris/Postgres/Valkey ports.
Every address you actually expose is yours to choose — none of the default port numbers are hard-wired into how you reach the system:
| Port | Belongs to | How to change it |
|---|---|---|
| 8080 | Orbtrace app + UI | On Kubernetes you don't publish 8080 directly — you reach Orbtrace through the Ingress / Route on your own hostname (443). If you expose a Service instead, its port is orbtrace.service.port. (On Docker Compose, remap the host port, e.g. 9000:8080.) |
| 4317 / 4318 | Your Collector (OTLP gRPC / HTTP) | Not Orbtrace's ports — Orbtrace never ingests OTLP. You choose them in your Collector's receiver config. |
| 9030 / 8030 | Doris FE (MySQL query / HTTP) | Point at whatever your Doris uses: doris.queryPort and doris.httpPort. |
| 5432 / 6379 | Postgres / Valkey (or Redis) | When external, postgres.port / valkey.port. Bundled, they're reachable only inside the cluster and are never published. |
The one fixed value is the app's internal container port (8080) — it sits behind the Service and Ingress and never needs to be reached directly, so there's no reason to change it. Everything a user or an app connects to (your hostname, your Collector's OTLP ports, your Doris/Postgres/Valkey ports) is fully under your control.
Health probes (readiness / liveness)
The chart wires Kubernetes probes against the app's actuator endpoints — useful to know both for tuning and for your own external monitoring:
| Endpoint | Used by | Contains | Access |
|---|---|---|---|
/actuator/health/readiness | startup + readiness probes | readinessState + the Doris/Postgres connection — an unreachable datastore flips the pod NotReady (traffic stops routing to it) | anonymous, status only |
/actuator/health/liveness | liveness probe | livenessState only — deliberately excludes the datastores, so a Doris outage never restart-loops the app | anonymous, status only |
/actuator/health | your monitoring / curl checks | the composite | anonymous callers get {"status":"UP"} only; the per-component breakdown needs an authenticated call (show-details: when-authorized) |
Probe endpoints are anonymous by design — the kubelet can't carry a token, and locking them down would leave the pod permanently unready. They never leak internals: hostnames, versions, and component details stay behind authentication. Because the Route/Ingress is a catch-all, they're also reachable from outside; the payload is status-only so this is low-risk, but if your policy requires it, block /actuator/* at your edge (Ingress path rules, a Route path, or your WAF) — the kubelet probes in-cluster and is unaffected.
Tuning. The knob you're most likely to need is the first-boot budget: the app applies the full Doris schema before binding the web port, so the startup probe must wait for it. orbtrace.startupProbe.failureThreshold (default 60, ×10s = 10 minutes) is the wait — raise it for a slow or very large Doris. Every other cadence is tunable the same way (chart ≥ 2.0.7): orbtrace.readinessProbe.* and orbtrace.livenessProbe.* each take initialDelaySeconds / periodSeconds / failureThreshold / timeoutSeconds — e.g. raise timeoutSeconds on IOPS-starved nodes, or readinessProbe.failureThreshold if brief Doris blips shouldn't pull the pod out of rotation. The probe paths are fixed app endpoints. The SMTP and Quartz health indicators are deliberately excluded from the composite so a mail-server hiccup can't take the pod down.