常见故障排查流程-阿里云帮助中心

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

排查步骤如下：

首先确认以下信息是否填写正确，是否是对应的 workspace 的信息：
- InstanceId：中间件实例唯一标识。
- AntVIP：中间件基于 AntVIP 寻址。
- AccessKey ID：访问控制键。
- AccessKey Secret：访问控制密钥。
如果以上信息没错，则排查服务注册、发现的链路。服务注册、发现排查的顺序是：应用 > MOSN > 注册中心。
重要
下述进入容器中排查的操作，都需要获取对应用户 workspace 的 kubeconfig。
- 排查应用
  1. 在节点上输入以下命令进入应用容器：
```
kubectl exec -it sofa-service-thrf4-whtpc -c <应用名称>
```
  2. 通过以下命令查看 MOSN 的注册端口是否开启：
```
curl -v http://127.0.0.1:13330
```
  3. 进入日志目录 /home/admin/logs。
    框架、日志名称可能不同，但是日志目录都是相同的。如 Dubbo 和 Spring Cloud 的日志文件都是 spring.log。
  4. 搜索关键字 dataId 或者 EnterpriseMeshRegistry。
- MOSN：
  1. 进入 mosn-sidecar-container。
  2. 找到日志：/home/admin/logs/mosn/default.log
  3. 搜索 system config init，查看用户配置的四元组信息是否正确。
  4. 搜索 dataId 或 registry，查看服务是否成功注册。
  5. 查看注册中心的通知接口是否打开：
```
netstat -anp | grep 9600
```

如何排查服务限流问题？

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

通过产品层查看应用的推送配置和推送记录。
查看 DsrConsole（中间件租户）。
进入日志目录 /home/admin/logs/ 查看是否有错误日志。
查看 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"
```

如何排查服务路由问题？

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

检查 DsrConsole：
1. 进入日志目录 /home/admin/logs/。
2. 通过关键字查询配置。
  通过 SigmaRouterRuleDispatcher 或者 dataId，查看 body 的内容和用户配置的内容是否一致。
检查 Cloud Mesh OpenAPI：
- 如果步骤 1 返回值非 200，则查看报错的具体信息，并做相应处理。如 404 cluster not find 表示查不到 K8s 的集群信息，请提交工单。
- 如果是 token 或者 endpoint 不正确，请提交工单。
检查 K8s：
查看 CR 的内容（CR 在用户 K8s 集群的 default namespace 下面，路由相关的 CR 是 virtualservices 和 destinationrules），判断具体的内容是否和用户填写的一致。
检查 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 获取。如无内容或者内容缺失，请提交工单。
检查 MOSN：
主要检查路由的配置是否下发到服务消费者，排查步骤如下：
1. 进入服务消费者的 MOSN 容器，通过关键字 dataId 或者 xds，查看版本号和权重是否正确。
2. 执行 find default.log | grep -rn "xds" 命令。
  示例如下：

如何排查 MOSN 未注入 Sidecar 问题

排查步骤：

在控制台查看是否已创建集群，并且开启 Sidecar 注入功能。
未开通的集群需开通 Mesh。
说明
Sidecar 注入配置里的 Sidecar 名称必须为 mosn，当前仅支持 mosn 这一种 Sidecar。
检查是否开启了默认模板或者注入配置规则。
开启了默认版本示例如下：
说明
高亮部分为默认模板，一个 Sidecar 的一种类型（容器、虚拟机）只能开启一个默认模板。
开启了注入配置规则示例如下：
说明
每开启一个注入规则，会生成一个 configMap，Sidecar 注入时会匹配规则里的条件。
如果仅开启了注入规则，需要检查规则里的匹配条件是否和需要注入的 Pod 的内容匹配。
检查 operator 里运行指定的环境变量和 Pod里指定的 annotations 是否相符。
检查应用 Pod 的 YAML 中是否含有 Key 为 ake.cafe.sofastack.io/mosn-inject=true 的 annotations。
说明
上图表示对应 Pod 开启了 Sidecar 功能。
查看创建 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：
    下图为实际模板所在的 namespace：默认的 namespace 为 cloudmesh；000001 租户下的 namespace 为 cloudmesh。
  - 如果没有日志输出，检查配置的 webhook 地址是否正确。
```
kubectl -n hxz-smmp get cm mesh-webhooks -oyaml
```