EDAS 基础排查

EDAS

先说下 EDAS 包含什么，
所有的应用管控和集群管理，限流降级，扩容所容，基础监控，服务监控。
除此之外的 ARMS ，CSB ，DTS（scheduler X） 都不是 EDAS 范围内，只是放了一个入口在 EDAS，出现问题一定先分清楚是 EDAS 管控问题还是自己的应用代码问题，还是其他产品的组件文件，便于定位。

案例：

应用发布失败 jvm crash

排查：

• 1） 先看下发布失败应用对应的变更记录发现发布应用失败是因为卡在了健康检查失败。健康检查的 URL 必须是返回 200 的才可以，通过报错可以知道后端的 tomcat 返回了 502。
• 2） 登陆健康检查失败的 ECS 节点 ps -ef | grep tomcat 看下进程是否还在，如果进程不在了肯定检查不通过
• 3） 查看 tomcat 的 Catalina 日志发现 jvm 有 crash 信息 hsf_error 存在 /home/admin/hsf_err_pidxxxx ，看下日志中的报错。

报错分析：

Stack: [0x00002b4bb1a14000,0x00002b4bb1b15000],  sp=0x00002b4bb1b11610,  free space=1013k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x2e233c]  Annotations::make_java_array(Array<unsigned char>*, Thread*)+0x7c
V  [libjvm.so+0x995047]  Reflection::new_method(methodHandle, bool, bool, Thread*)+0x5f7
V  [libjvm.so+0x723ff9]  get_class_declared_methods_helper(JNIEnv_*, _jclass*, unsigned char, bool, Klass*, Thread*)+0x479
V  [libjvm.so+0x72448b]  JVM_GetClassDeclaredMethods+0xcb
J 2209  java.lang.Class.getDeclaredMethods0(Z)[Ljava/lang/reflect/Method; (0 bytes) @ 0x00002b4b1c7fdc68 [0x00002b4b1c7fdbc0+0xa8]
J 5630 C2 java.lang.Class.privateGetDeclaredMethods(Z)[Ljava/lang/reflect/Method; (67 bytes) @ 0x00002b4b1c148f14 [0x00002b4b1c148e20+0xf4]
J 6310 C1 org.springframework.util.ReflectionUtils.getDeclaredMethods(Ljava/lang/Class;)[Ljava/lang/reflect/Method; (134 bytes) @ 0x00002b4b1d1ce8b4 [0x00002b4b1d1ce000+0x8b4]
J 6787 C1 org.springframework.util.ReflectionUtils.doWithMethods(Ljava/lang/Class;Lorg/springframework/util/ReflectionUtils$MethodCallback;Lorg/springframework/util/ReflectionUtils$MethodFilter;)V (176 bytes) @ 0x00002b4b1d33cbf4 [0x00002b4b1d33cb80+0x74]
J 6817 C1 org.springframework.util.ReflectionUtils.doWithMethods(Ljava/lang/Class;Lorg/springframework/util/ReflectionUtils$MethodCallback;)V (7 bytes) @ 0x00002b4b1d3602e4 [0x00002b4b1d360280+0x64]
j

jvm 线程的 stack trace 报错，看下是否开启的 ARMS 的监控，尝试关闭掉后再开启，然后再控制台上重置应用。

案例：

The proxy server received an invalid response from an upstream server. Sorry for the inconvenience.Please report this message and include the following information to us.Thank you very much!

排查：

一般是后端应用服务器影响超时或无影响导致的，原因有挺多种，直接原因就是slb健康检查、tengine（客户ECS主机）上设置的连接检查超时了。
根本原因挺多的，tomcat影响慢（例如：客户ECS主机CPU资源紧张，业务压力大的时候，进程短暂挂起等）、长时间的Full GC（单指超过SLB健康检查的时间的）、其他原因。

临时解决办法：

• 1、调整健康检查url的页面大小（尽量用默认的_ehc.html或特别小的页面）
• 2、稍微加大slb健康检查超时时间 3、根据ECS主机上 tengine日志、应用日志、应用监控优化相关配置参数和应用

案例：

触发 OOM 报警

• 一般是 swarm 集群，应用内存设置太小导致，跳到内存即可。

案例：

调整 tomcat 参数配置

• 所有 tomcat 的更改都要通过控制台上进行修改，如果手动修改 tomcat 的 server.xml 配置文件可能导致文件损坏。

案例：应用停止

描述：

全部EDAS 普通应用（非 docker） 出现 显示运行状态为 停止，但实际是在运行中，可以显示运行中的服务列表。
对应用进行重置操作，重置后，运行状态仍为停止。 进行启动操作，报错。
同时对应用进行新版本应用部署，部署后新版本不生效。运行效果的仍是旧版本应用

排查：

缩小一下应用使用的 -Xmx 值 或者 扩大一下 ECS 主机的内存，还可以加 swap，这些搞好以后，重置一下应用即可。

案例：

ARMS 监控缺少 SQL 数据
背景：
ARMS 监控是集成了 tlog 和 eagleEye 一体的对外共提供服务的产品，和 EDAS 是完全独立的两个产品，EDAS 只是作为入口访问，二者的监控数据也不是同一个数据源。

排查：

• 检查是否安装了 edas agent：

  • 通过 EDAS 控制台一键开通，免手动安装 agent。
  • 通过 ARMS 的手动安装脚本暗转，参考
• 看下 pom.xml 文件中依赖的数据库驱动和版本是否在下列表中

组件  JDK 1.7  JDK 1.8
Dubbo  2.5.X+  2.5.X+
Google HTTP Client  1.10.X+  1.10.X+
HttpClient 3  3.X+  3.X+
HttpClient 4  4.X+  4.X+
JDK HTTP  1.7.X+  1.7.X+
Jetty  8.X+  8.X+
MyBatis  3.X+  3.X+
MySQL JDBC  5.0.X+  5.0.X+
Oracle JDBC  10.2.X+  10.2.X+
OkHttp  2.X+  2.X+
Redis  2.X+  2.X+
Spring Boot  1.3.X+  1.3.X+
Spring  4.X+  4.X+
Tomcat  7.X+  7.X+
Undertow  1.3X+  1.3X+
WebLogic  12.X+  12.X+
MemCached  2.8+  2.8+

案例：

No mapping found for HTTP request with URI [/testali/_ehc.html] in DispatcherServlet with name 'spring-mvc'

排查：

这是一个开源的 spring 报错，web.xml 中的映射没找到所以报错，可以直接 Google 一些开源的处理经验，这种问题并不是 EDAS 的问题，属于自己的程序问题。

案例：

用户应用发布，卡在应用端口检查失败上，tenginx 端口启动失败

排查：

出现这种问题，先看下不是的应用是否关闭了流量管理的功能，tenginx 在 EDAS 中主要负责流量转发的功能，如果关闭了流量管理，会导致 tengnix 安装启动失败。

发现类似问题，先把主机上的应用 kill 掉，然后打开流量管理功能，重启 staragent ，再开始部署应用。

案例：

排查：

遇到这种问题，需要开通容器服务，链接如下：

https://www.aliyun.com/product/containerservice

如果没有开通这个服务不建议点开这个标签，后期会优化这个交互的提示。

案例：

应用发布单报错启动失败，错误信息如下：

[agent] 2018-11-27 21:21:24 CST [22734] - [taskId: 90cd0437-9842-4fae-b39a-fdc2e387e383] - 39 - Unzip war failed with error: sh: /opt/taobao/install/ajdk-8.2.4_fp1-b8/bin/jar: No such file or directory 」

排查：

• 客户端在应用上部署 war 包时需要使用 jar 命令做解压，edas 是通过在 ecu 机器上的一个脚本 /home/admin/edas/script/common/normalAgentUtil.py 去解压 war 包的，这个脚本中会去读取 /opt/taobao/install/ajdk-8.2.4_fp1-b8/bin/jar 这个绝对路径的 jar ，如果用户端有人在机器上改过这个命令的路径可能导致解压时找不到 jar 命令。
• echo $JAVA_HOME 看下用户自己机器的 java 环境目录在哪里，如果不一致的，可以改下脚本，将 normalAgentUtil.py 读取 jar 目录的方式改为 $JAVA_HOME 即可。

案例：

低版本 EDAS container 问题导致 HSF 序列化报错

HSF serialization request failed on client side. Make sure the Biz DO is serializable and its corresponding dependency is latest.

排查：

将 EDAS 容器的版本升级到 3.5.1 即可解决。

案例：

EDAS 应用绑定 SLB 报错

排查：

• 1）出现问题后先看下应用发布单的变更记录卡在了哪一步，一般绑定 SLB 报错，可以看下是否卡在了健康检查那一步，如是，可以看下是端口启动失败还是 URL检查失败。
  

• 2）绑定SLB 是和后端 tomcat 关联，如果绑定失败也要看下 tomcat 对应的 catalina.out 的日志中是否有报错，本案例中是用户的 tomcat 应用出现 oom 导致 tomcat 启动失败，所以 SLB 绑定时检查端口失败。
  

总结一下这个问题，需要我们利用好发布单的 “变更记录” 功能，同时要结合 tomcat 的完整日志 Catalina.log 去分析。