文档

常见故障排查流程

更新时间:
一键部署

如何排查服务注册、服务发现出现的问题?

排查步骤如下:

  1. 首先确认以下信息是否填写正确,是否是对应的 workspace 的信息:

    • InstanceId:中间件实例唯一标识。

    • AntVIP:中间件基于 AntVIP 寻址。

    • AccessKey ID:访问控制键。

    • AccessKey Secret:访问控制密钥。

  2. 如果以上信息没错,则排查服务注册、发现的链路。服务注册、发现排查的顺序是:应用 > MOSN > 注册中心。

    重要

    下述进入容器中排查的操作,都需要获取对应用户 workspace 的 kubeconfig。

    • 排查应用

      1. 在节点上输入以下命令进入应用容器:

        kubectl exec -it sofa-service-thrf4-whtpc -c <应用名称>
        故障排查1
      2. 通过以下命令查看 MOSN 的注册端口是否开启:

        curl -v http://127.0.0.1:13330
      3. 进入日志目录 /home/admin/logs

        框架、日志名称可能不同,但是日志目录都是相同的。如 Dubbo 和 Spring Cloud 的日志文件都是 spring.log。

      4. 搜索关键字 dataId 或者 EnterpriseMeshRegistry。故障排查2故障排查3

    • MOSN

      1. 进入 mosn-sidecar-container。故障排查4

      2. 找到日志:/home/admin/logs/mosn/default.log

      3. 搜索 system config init,查看用户配置的四元组信息是否正确。故障排查5

      4. 搜索 dataId 或 registry,查看服务是否成功注册。故障排查6

      5. 查看注册中心的通知接口是否打开:

        netstat -anp | grep 9600
        故障排查7

如何排查服务限流问题?

限流的配置是微服务的 DsrConsole 通过 DRM 下发到 MOSN 中的。排查步骤如下:

  1. 通过产品层查看应用的推送配置和推送记录。DRM详情

  2. 查看 DsrConsole(中间件租户)。

    进入日志目录 /home/admin/logs/ 查看是否有错误日志。

  3. 查看 MOSN:

    1. 找到日志文件 /home/admin/logs/mosn/default.log

    2. 搜索日志文件中的关键字:应用名、方法名、serviceRateLimitConfig 等,查看 value 中的内容和用户前端填写的内容是否一致。

      find *.log | grep -rn "Alipay.cloudMeshTestJavaServer:name=com.alipay.guardian.client.sofa.drm.GuardianDrm.serviceRateLimitConfig,version=3.0@DRM"
      DRM详情2

如何排查服务路由问题?

路由的配置是微服务的 DsrConsole 通过 OpenAPI 下发到 K8s 的 default namespace 中,通过 pilot ListAndWatch 对应 CR 资源的变化,通知到 MOSN。排查步骤如下:

  1. 检查 DsrConsole:

    1. 进入日志目录 /home/admin/logs/

    2. 通过关键字查询配置。

      通过 SigmaRouterRuleDispatcher 或者 dataId,查看 body 的内容和用户配置的内容是否一致。路由1

  2. 检查 Cloud Mesh OpenAPI:

    • 如果步骤 1 返回值非 200,则查看报错的具体信息,并做相应处理。如 404 cluster not find 表示查不到 K8s 的集群信息,请 提交工单

    • 如果是 token 或者 endpoint 不正确,请 提交工单

  3. 检查 K8s:

    查看 CR 的内容(CR 在用户 K8s 集群的 default namespace 下面,路由相关的 CR 是 virtualservices 和 destinationrules),判断具体的内容是否和用户填写的一致。路由2

  4. 检查 Pilot:

    1. 查看日志,检查 PILOT_SERVER_ADDRESS 指向的地址是否能到达。如不能,请 提交工单。异常日志示例如下:

      2019-10-1117:01:24,236[ERROR][normal] fail to create stream client: rpc error: code =Unavailable desc = all SubConns are inTransientFailure, latest connection error: connection error: desc ="transport: Error while dialing dial tcp xxx.xxx.xxx.xxx:xxx: i/o timeout"
    2. 查看日志,检查 Pilot 授权是否通过。如未通过,请 提交工单,检查 InstanceId、AccessKey ID、AccessKey Secret。异常日志示例如下:

      2019-10-1117:07:12,518[WARN][xds][ads client]get resp timeout: rpc error: code =Unknown desc = missing auth part of service node "xxx",retry after 1s
    3. 检查 MOSN 是否收到 XDS 内容。

      可通过 curl [podIP]:34901/api/v1/config_dump 获取。如无内容或者内容缺失,请 提交工单

  5. 检查 MOSN:

    主要检查路由的配置是否下发到服务消费者,排查步骤如下:

    1. 进入服务消费者的 MOSN 容器,通过关键字 dataId 或者 xds,查看版本号和权重是否正确。路由3

    2. 执行 find default.log | grep -rn "xds" 命令。

      示例如下:路由4

如何排查 MOSN 未注入 Sidecar 问题

排查步骤:

  1. 在控制台查看是否已创建集群,并且开启 Sidecar 注入功能。

    未开通的集群需开通 Mesh。Image 1

    说明

    Sidecar 注入配置里的 Sidecar 名称必须为 mosn,当前仅支持 mosn 这一种 Sidecar。

  2. 检查是否开启了默认模板或者注入配置规则。

    开启了默认版本示例如下:Image 2

    说明

    高亮部分为默认模板,一个 Sidecar 的一种类型(容器、虚拟机)只能开启一个默认模板。

    开启了注入配置规则示例如下:Image 3

    说明

    每开启一个注入规则,会生成一个 configMap,Sidecar 注入时会匹配规则里的条件。

    如果仅开启了注入规则,需要检查规则里的匹配条件是否和需要注入的 Pod 的内容匹配。

  3. 检查 operator 里运行指定的环境变量和 Pod里指定的 annotations 是否相符。Image 4

    检查应用 Pod 的 YAML 中是否含有 Key 为 ake.cafe.sofastack.io/mosn-inject=true 的 annotations。

    Image 5
    说明

    上图表示对应 Pod 开启了 Sidecar 功能。

  4. 查看创建 Pod 时,K8s 是否调用了 operator 的 webhook。

    1. 进入 operator 容器。

      kubectl exec -it  sidecar-operator-7564cbf97b-jbpzz  -n hxz-smmp bash

      请根据自己的实际环境修改 namespace。

    2. 循环查看 sidecar-operator.log

      tail -f /home/admin/logs/sidecar-operator.log

    3. 删除 Pod,然后重新拉起 Pod ,检查 sidecar-operator.log 是否有日志输出。

      kubectl delete pod crpc-client-5584848c67-nhzsp

      下图 operator 有日志输出,红框表示注入了 sidecar-mosn-container-template-170 模板。日志

      • 如果有日志输出,但是没有匹配到模板,检查 Sidecar operator 启动参数的 mosn-template-ns 是否和实际模板所在的 namespace 匹配,如果不匹配则修改环境变量重新启动 operator。

        下图为 Sidecar operator 启动参数的 mosn-template-ns: Image 7

        下图为实际模板所在的 namespace:默认的 namespace 为 cloudmesh;000001 租户下的 namespace 为 cloudmesh。Image 8

      • 如果没有日志输出,检查配置的 webhook 地址是否正确。

        kubectl -n hxz-smmp get cm mesh-webhooks -oyaml
        Image 9

  • 本页导读 (0)
文档反馈