Networking and ports

Telegraf Controller serves different kinds of traffic on different ports. When you run Telegraf Controller, identify the ports and listeners it uses, determine which clients need access to each one, and expose them safely with Transport Layer Security (TLS), firewalls, and reverse proxies.

Ports and listeners

Telegraf Controller starts up to three HTTP listeners. Each listens on all network interfaces, so use your firewall to control which networks can reach each port.

ListenerDefault portConfigure withUsed by
Web interface and API8888portBrowsers, API clients, and agents fetching configurations
Web interface (optional)Not setui-portBrowsers, when the web interface is served on its own port
Agent heartbeat service8000heartbeat-portTelegraf agents sending heartbeats

The agent heartbeat service is a separate HTTP server embedded in the same Telegraf Controller process. Requests to it require an API token. Both the API listener and the heartbeat listener also expose unauthenticated health endpoints designed for load balancers and monitoring. See Health endpoints.

Expose the right ports

  • Browsers need the web interface and API port. If you serve the web interface on a separate port with ui-port, browsers load the interface from that port and call the API directly, so they need both ports.
  • Telegraf agents need the web interface and API port to fetch configurations and the heartbeat port to send heartbeats.
  • Load balancers and monitoring systems need whichever ports they probe for health.

No other inbound access is required. Where possible, keep all ports off the public internet and restrict them to the networks that need them.

If you turn off authentication for endpoint groups with disable-auth-endpoints, anyone with network access to those endpoints can use them without an API token. Before turning off authentication for the heartbeat or agents groups, make sure your firewall restricts those ports to networks you trust.

TLS

One certificate and key pair (ssl-cert-path and ssl-key-path) enables HTTPS on all listeners: the web interface and API, the separate web interface port if configured, and the agent heartbeat service. For setup, certificate options, and configuring agents to trust the certificate, see Secure with TLS.

Reverse proxies and public URLs

When Telegraf Controller runs behind a reverse proxy, or port remapping changes the addresses clients use, adjust the URLs Telegraf Controller presents:

  • Public endpoints: set the User Interface URL, API URL, and Heartbeat URL in settings so that invite links, agent commands, and generated heartbeat configuration use the external addresses. See Public endpoints.
  • Split web interface mode: when ui-port is set and a proxy changes the URL or port browsers use, configure the API URL the web interface calls and the origins the API accepts. See Public URLs and CORS.

High availability

In a high-availability cluster, the load balancer routes web interface and API traffic to each node’s API port and agent heartbeat traffic to each node’s heartbeat port, using the unauthenticated health endpoints as probes. See Configure a load balancer.

Outbound connections

Telegraf Controller also opens outbound connections that restricted networks may need to allow:

  • Database: your PostgreSQL server, if you use PostgreSQL instead of SQLite.
  • Authentication providers: your LDAP or OIDC provider, when configured.
  • Audit log forwarding: your syslog or webhook destinations, when audit log forwarding is configured.

Was this page helpful?

Thank you for your feedback!