curl localhost:8001
. This is the admin interface of every sidecar. To see a list of all available resources, run curl localhost:8001/help
.curl localhost:8001/config_dump
from within the sidecar. This is the full configuration of the sidecar, which can be used for comparison with the mesh configuration you expect to have been applied.502
or a 503
error, it's likely an issue with JWT filter configuration or with SPIRE.502
or 503
error in a web browser, the problem is likely with either ingress to the edge service, or a failure in the filter chain, such as the JWT filter./services/fibonacci
). With this error, it is likely you won't see this request at all. If this is the case, then check for logs indicating a filter chain failure, this would appear as something like:no healthy upstream
error, check the edge logs and grep for your path (e.g. /services/fibonacci
). You may see a log that looks like this:"-"
, which means it is not known. If this is the case, you can follow more specific steps to verify discovery and ultimately go back through the deploy a service guide and make sure to create all of the necessary mesh objects from steps 2 and 3.upstream connect error
error, check the edge logs and grep for your path - (e.g. /services/fibonacci
). You may see a log that looks like this:10.42.1.8:10808
, we can see that this is not a discovery issue from edge to sidecar. To rule out discovery as the problem, next check the service's sidecar logs.503
log that looks like the following:{UPSTREAM-HOST}
value. If the value is "-"
, there is a discovery issue from sidecar to service. You will likely need to hard code the address for this in the local cluster. If the value is something like [::1]:9080
, the instance that you configured in this step of deploying a service (the local cluster) could be wrong, or the service may have other security requirements that don't allow the sidecar to make requests to it as configured.curl localhost:8001/clusters
./services/fibonacci
and you see the following in the edge logs:503
, but you don't see any indication of this request in the sidecar's logs, this is likely an mTLS problem.curl localhost:8001/stats | grep ssl
. You will see something like the following:curl localhost:8001/logging?level=debug -XPOST
. Then, make the failing request again. Because of the high volume of logs, it may be best to run curl localhost:8001/logging?level=info -XPOST
immediately afterwards to turn off debug logging while you inspect the output.TLS error
or OPENSSL
. The errors that come up here may also indicate more specifically what the problem is./logging
/logging?level=<log-level>
level
.error
, warn
, info
, debug
.