Add support information
Collect valuable information for Solo to review and troubleshoot your support request.
Environment
- Get your Gloo Gateway version.
glooctl version -o yaml
- Get the version of Kubernetes that you run in your cluster.
kubectl version -o yaml
- List the infrastructure provider that hosts your environment, such as AWS or an on-premise virtual machine (VM).
Setup
Share the installation method that you used to install Gloo Gateway, such as Helm, glooctl
, or Argo CD, and the configuration that you used during the installation.
Issue
- Provide a detailed description of the issue. Make sure to include the following information:
- If reproducable, steps to reproduce the issue
- If applicable, sample of a client request including the payload
- High-level diagram of the interactions from the perspective of the client request
- The request protocol that is handled by the application(s) in question, such as HTTP / TCP / gRPC
- If the issue is related to authentication or authorization, details of the auth configuration
- Describe the impact of the issue. For example, the issue might block an update or a demo, or cause the loss of data or an entire system.
- Export the relevant configuration files that are related to the issue.
Product-specific details
Control plane
-
Capture the output of the
glooctl check
command.
Typically, the command output indicates any errors in the control plane components or associated resources, such as in the following example.Checking Deployments... 1 Errors! Checking Pods... 2 Errors! Checking Upstreams... OK Checking UpstreamGroups... OK Checking AuthConfigs... OK Checking RateLimitConfigs... OK Checking VirtualHostOptions... OK Checking RouteOptions... OK Checking Secrets... OK Checking VirtualServices... OK Checking Gateways... OK Checking Proxies... Skipping due to an error in checking deployments Skipping due to an error in checking deployments Error: 5 errors occurred: * Deployment gloo in namespace gloo-system is not available! Message: Deployment does not have minimum availability. * Pod gloo-8ddc4ff4c-g4mnf in namespace gloo-system is not ready! Message: containers with unready status: [gloo] * Not all containers in pod gloo-8ddc4ff4c-g4mnf in namespace gloo-system are ready! Message: containers with unready status: [gloo] * proxy check was skipped due to an error in checking deployments * xds metrics check was skipped due to an error in checking deployment
-
Collect the logs for various control plane components, such as
gloo
,gloo-fed
,redis
, orobservability
by using thedebug
log level (if possible). The components vary depending on your Gloo Gateway setup and can be found in thegloo-system
namespace. At a minimum, include the logs for thegloo
pod in your support request.
To enable thedebug
log level, see Debugging control plane.
Follow the steps below to get the logs for thegloo
controller pod.- Set the log level to
debug
.kubectl port-forward deploy/gloo -n <controlplaneNamespace> 9091:9091 > /dev/null 2>&1 & PID=$! curl -X PUT -H "Content-Type: application/json" -d '{"level": "debug"}' http://localhost:9091/logging
- Capture the logs when reproducing the issue.
kubectl logs -f deploy/gloo -n <controlplaneNamespace> > gloo.log
- After you capture the logs, reset the log level to
info
.curl -X PUT -H "Content-Type: application/json" -d '{"level": "info"}' http://localhost:9091/logging kill -9 $PID
Repeat these steps for all the control plane components.
- Set the log level to
Data plane
- Capture the xDS configuration that is currently served.
glooctl proxy served-config -n <controlplaneNamespace> > served-config.yaml
- Get the configuration that is served in the
gateway-proxy
Envoy pod(s).
For more information, see Dumping Envoy configuration.kubectl port-forward deploy/gateway-proxy -n <proxyNamespace> 19000:19000 > /dev/null 2>&1 & PID=$! curl -s localhost:19000/config_dump\?include_eds > gateway-config.json kill -9 $PID
- Get the access log(s) for failed request from the
gateway-proxy
pod(s). If access logging is not enabled, refer to this guide to enable it. - If possible, collect the logs from the
gateway-proxy
Envoy pod(s) indebug
log level for the failed request.The
gateway-proxy
component comes with several loggers. Setting the log level todebug
for all loggers can get very noisy. Instead, you can change the log level for a specific logger only. For more information, see Viewing Envoy logs.-
Choose the logger that you want to get logs for. For a list of available loggers, see Viewing Envoy logs.
-
Port-forward the
gateway-proxy
pod on port 19000.kubectl -n gloo-system port-forward deploy/gateway-proxy 19000 &
-
Change the log level to
debug
for the selected logger. The following example changes the log level for thegrpc
logger.curl -X POST "127.0.0.1:19000/logging?grpc=debug"
-
Capture the logs when reproducing the issue.
kubectl logs -f deploy/gateway-proxy -n gloo-system > gateway-proxy.log
-
After you capture the logs, reset the log level to
info
.curl -X POST "127.0.0.1:19000/logging?grpc=info"
-
- Gather the stats from the proxy pod(s).
glooctl proxy stats > proxy-stats.log