Debug the portal server
Debug the gloo-mesh-portal-server component that runs as an add-on to your Gloo Platform setup.
- Check that the portal server pod is running.
kubectl get pods -n gloo-mesh-addons -l app=gloo-mesh-portal-server - Check the logs of the Gloo portal server in your workload cluster. To view logs recorded since a relative duration such as 5s, 2m, or 3h, you can specify the
--since <duration>flag.kubectl logs -n gloo-mesh-addons pods/$(kubectl get pod -l app=gloo-mesh-portal-server -A -o jsonpath='{.items[0].metadata.name}')Optionally, you can format the output with
jqor save it in a local file so that you can read and analyze the output more easily.kubectl logs -n gloo-mesh-addons pods/$(kubectl get pod -l app=gloo-mesh-portal-server -A -o jsonpath='{.items[0].metadata.name}') > gloo-mesh-portal-server.json - Review the following common error messages from the portal server logs:
- Check the state of other Gloo components that the portal server uses:
- Gloo management server, particularly for translation issues
- Gloo agent
- Gloo external auth and rate limiter add-ons
- Make sure that you created all of the portal-related custom resources, and check the configuration for any errors.
kubectl get apidocs,apischemadiscoveries,ratelimitserverconfigs,RatelimitConfigs,ratelimitserversettings,ratelimitclientconfigs,ratelimitpolicies,extauthpolicies,extauthserver,routetables,portals,portalgroups,virtualgateways -A - Launch the Gloo UI and review the resources in the API and Portal tabs. Some common errors include the following:
- A route table selecting the wrong backing service for your API products.
no associated schema: This error might mean that no ApiDoc is associated with the services in the route table. Or, the route might not match a valid route per the associated OpenAPI schema in the ApiDoc.