How to troubleshoot Open Service Mesh?
    • Dark
      Light
    • PDF

    How to troubleshoot Open Service Mesh?

    • Dark
      Light
    • PDF

    Article Summary

    #ServerlessTips - Open Service Mesh
    Author: Stephane Eyskens, Azure MVP

    There are multiple places to look at when you encounter issues with OSM. The first stop shop is the envoy container, which OSM deploys as the sidecar next to the application container. These logs are available through kubectl:

    MicrosoftTeams-image 110

    In case of issues, you’re likely going to get some cryptic envoy return codes, but you can visit this page https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage to get more info about what these return codes mean. Another stop shop is the OSM controller and, more globally, the OSM control plane. You can install OSM in a dedicated namespace or kube-system (default location with the addon). To make sure you locate the OSM control plane pods, you can issue the following get pod command:

    MicrosoftTeams-image 111

    Followed by a kubectl log on the relevant pod. You can control logging verbosity by specifying the log level in the global mesh config:

    MicrosoftTeams-image 112

    Besides logs, you can make use of the OSM CLI https://release-v1-2.docs.openservicemesh.io/docs/guides/cli/ which gives you handy commands to track down misconfigurations, especially with the osm verify command.

    MicrosoftTeams-image 491


    Was this article helpful?