Feb 21, 2024: Announcing Linkerd 2.15 with support for VM workloads, native sidecars, and SPIFFE! Read more »

This is not the latest version of Linkerd!
This documentation is for Linkerd 1.x, an older version with some significant differences. You may want to see the Linkerd 2.x (current) documentation instead.

Frequently asked questions

How do I pronounce “Linkerd”?


Why is it called Linkerd?

Linkerd can be thought of as a dynamic linker for microservices. In an operating system, the dynamic linker takes runtime information about the name of a library and function call to be executed, and performs whatever work is necessary to make that function invocable to an executable. Linkerd does the analogous task for microservices: it takes the name of a service and of a call to make on that service (HTTP, gRPC, etc.), and does the work required to make the call successful—including routing, load-balancing, and retrying.

How do I get to the Linkerd dashboard (or “admin”) page?

By default, the admin page can be accessed at http://localhost:9990. You can specify a different port in the admin section of the Linkerd config.

How do I get upstream service metrics?

Linkerd exposes machine-readable metrics in JSON format at http://localhost:9990/admin/metrics.json. This is configurable–see above.

Where do Linkerd logs go?

Linkerd logs to stderr. For HTTP routers, additional access logging can be configured via the httpAccessLog key in the config file.

Does Linkerd support dynamic config reloading?

No. We prefer to avoid this pattern and to offload mutable things to separate services. For example, Linkerd talks to service discovery for changes in deployed instances, and to namerd for changes in routing policy.

How does Linkerd handle service errors?

Errors generated by downstream services are passed through Linkerd unmodified.

For HTTP, errors are served with Content-type text/plain, and an explanatory error message is available in both the response body and the l5d-err header.

When the configured namers cannot resolve a service to handle the request, Linkerd responds with 400 Bad Request. This could be caused by misconfiguration of Linkerd, problems with service discovery, or by an incorrect l5d-dtab header attached to the request.

All other failures communicating with downstream services (including timeouts, inability to establish a connection, etc.) are represented as 503 Bad Gateway.

Why do I see a “No hosts available” error?

If you see a No hosts are available error message in the Linkerd logs or in a response, it means that Linkerd was unable to translate the request’s service name into a physical destination. This may be because of an incorrect dtab, an error with the service discovery lookup, or because the destination service is not running.

To debug this error, you can use the “dtab playground” in the Linkerd admin dashboard. Simply visit <linkerd host>:9990/delegator in your browser. This UI will demonstrate each step of how the request’s name is transformed by the dtab and namers.

(For more information on how Linkerd handles names, see the Routing page.)