Skip to main content
protocols.pageprotocols.page
4317

Port 4317 – OpenTelemetry (OTLP gRPC)

TCP

Port 4317 is the OpenTelemetry Protocol (OTLP) gRPC port. Applications instrumented with OpenTelemetry export traces, metrics, and logs to an OTel Collector on port 4317 (gRPC) or port 4318 (HTTP). OTLP is the standard telemetry data format for the OpenTelemetry ecosystem, supported by Jaeger, Tempo, Prometheus, and most observability vendors.

Port Number

4317

Protocol

TCP

Service

OpenTelemetry Protocol gRPC

Range

IANA Registered (1024–49151)

Description

OTLP gRPC on port 4317 is the primary export target for OpenTelemetry SDKs. The OTel Collector receives telemetry on 4317, processes it (batching, filtering, enrichment), and exports to backends like Jaeger (traces), Prometheus (metrics), and Loki (logs). Port 4318 is the OTLP HTTP endpoint. The Collector should be deployed as a sidecar or DaemonSet in Kubernetes.

Security risks

  • 1No authentication by default – OTel Collector's OTLP receiver accepts data from any source without verifying identity, enabling telemetry injection (fake spans/metrics)
  • 2Telemetry data injection: attacker sends crafted traces that trigger false alerts, mask real incidents by flooding with noise, or inject misleading latency data
  • 3Resource exhaustion: unbounded ingestion on 4317 without rate limiting allows an attacker to overwhelm the Collector, dropping legitimate telemetry during an incident
  • 4Sensitive data in telemetry: spans often carry db.statement (SQL queries), http.url (with tokens), messaging.payload, and custom attributes containing PII or secrets
  • 5Exfiltration via Collector: if an attacker compromises the Collector config, they can add an exporter that sends all telemetry to an external endpoint

Firewall guidance

Allow inbound 4317 only from application pods/instances that send telemetry. In Kubernetes, deploy the Collector as a DaemonSet (localhost only) or use NetworkPolicy to restrict access to application namespaces. Enable mTLS on the OTLP receiver for cross-network collection. Never expose 4317 to the internet.

Diagnosis commands

Check if OTLP gRPC receiver is responding (shows registered services)

shell
grpcurl -plaintext localhost:4317 list

Test OTLP HTTP endpoint (4318) reachability

shell
curl -v http://localhost:4318/v1/traces -d '{}'

OTel Collector's own metrics – count of received spans

shell
curl -s http://localhost:8888/metrics | grep otelcol_receiver_accepted_spans

Collector health check extension (must be enabled in config)

shell
curl -s http://localhost:13133/ | jq .

Usage examples

Port 4317 – OpenTelemetry (OTLP gRPC)
shell
OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317
docker run -p 4317:4317 otel/opentelemetry-collector

Common services on this port

OpenTelemetry CollectorGrafana AlloyJaeger CollectorSignoz OTel CollectorDatadog Agent (OTLP)

Related ports

4318

OTLP HTTP (OpenTelemetry alternate)

16686

Jaeger UI (trace visualization)

9090

Prometheus (metrics backend)

14250

Jaeger Collector gRPC (legacy)

55679

OTel Collector zpages (debug)

History

OpenTelemetry was formed in 2019 by merging OpenTracing and OpenCensus (both CNCF projects). OTLP (OpenTelemetry Protocol) was designed as a unified wire format for traces, metrics, and logs. Port 4317 was registered with IANA for OTLP gRPC in 2021. The OTel Collector (Golang) acts as a vendor-neutral pipeline agent. OpenTelemetry reached stable status for traces (2022), metrics (2023), and logs (2024).

FAQ

When should I use 4317 (gRPC) vs 4318 (HTTP)?

Use 4317 (gRPC) for production workloads: it supports streaming, bidirectional communication, efficient binary encoding (protobuf), and connection multiplexing. Use 4318 (HTTP/protobuf or HTTP/JSON) when gRPC is blocked (browser apps, environments with HTTP-only proxies) or for debugging (JSON payload is human-readable). Performance difference is minimal for most workloads.

How do I add authentication to the OTel Collector?

In collector config: receivers.otlp.protocols.grpc.tls (server cert + CA for mTLS), or use the bearertokenauth extension with a shared token. For Kubernetes: deploy with service mesh (Istio) for automatic mTLS, or use the k8s RBAC authenticator extension. The headers_setter processor can inject auth for exporters. Production: always use mTLS between SDKs and Collector.