上海 网站设计公司,旅游便宜网站建设,兼职网网站建设方案,西安注册公司流程一、在不同环境排查问题#xff0c;有不同的方式 1、如果是在自己的开发环境排查问题#xff0c;那你几乎可以使用任何自己熟悉的工具来排查#xff0c;甚至可以进行单步调试。只要问题能重现#xff0c;排查就不会太困难#xff0c;最多就是把程序调试到 JDK 或三方类库内…一、在不同环境排查问题有不同的方式 1、如果是在自己的开发环境排查问题那你几乎可以使用任何自己熟悉的工具来排查甚至可以进行单步调试。只要问题能重现排查就不会太困难最多就是把程序调试到 JDK 或三方类库内部进行分析。 2、如果是在测试环境排查问题相比开发环境少的是调试不过你可以使用 JDK 自带的 jvisualvm 或阿里的Arthas附加到远程的 JVM 进程排查问题。另外测试环境允许造数据、造压力模拟我们需要的场景因此遇到偶发问题时我们可以尝试去造一些场景让问题更容易出现方便测试。 3、如果是在生产环境排查问题往往比较难一方面生产环境权限管控严格一般不允许调试工具从远程附加进程另一方面生产环境出现问题要求以恢复为先难以留出充足的时间去慢慢排查问题。但因为生产环境的流量真实、访问量大、网络权限管控严格、环境复杂因此更容易出问题也是出问题最多的环境。
二、生产问题的排查很大程度依赖监控 1、对于日志主要注意两点 ① 确保错误、异常信息可以被完整地记录到文件日志中 ② 确保生产上程序的日志级别是 INFO 以上。记录日志要使用合理的日志优先级DEBUG 用于开发调试、INFO 用于重要流程信息、WARN 用于需要关注的问题、ERROR 用于阻断流程的错误。 2、对于监控在生产环境排查问题时首先就需要开发和运维团队做好充足的监控而且是多个层次的监控。 ① 主机层面对 CPU、内存、磁盘、网络等资源做监控。如果应用部署在虚拟机或 Kubernetes 集群中那么除了对物理机做基础资源监控外还要对虚拟机或 Pod 做同样的监控。监控层数取决于应用的部署方案有一层 OS 就要做一层监控。 ② 网络层面需要监控专线带宽、交换机基本情况、网络延迟。 ③ 所有的中间件和存储都要做好监控不仅仅是监控进程对 CPU、内存、磁盘 IO、网络使用的基本指标更重要的是监控组件内部的一些重要指标。比如著名的监控工具 Prometheus就提供了大量的exporter来对接各种中间件和存储系统。 ④ 应用层面需要监控 JVM 进程的类加载、内存、GC、线程等常见指标比如使用Micrometer来做应用监控此外还要确保能够收集、保存应用日志、GC 日志。 3、对于快照 应用进程在某一时刻的快照。通常情况下我们会为生产环境的 Java 应用设置 -XX:HeapDumpOnOutOfMemoryError 和 -XX:HeapDumpPath…这 2 个 JVM 参数用于在出现 OOM 时保留堆快照。
三、分析定位问题的套路 1、程序的问题来自以下三个方面 ① 程序发布后的 Bug回滚后可以立即解决。这类问题的排查可以回滚后再慢慢分析版本差异。 ② 外部因素比如主机、中间件或数据库的问题。这类问题的排查方式按照主机层面的问题、中间件或存储统称组件的问题分为两类。 主机层面的问题可以使用工具排查 CPU 相关问题可以使用 top、vmstat、pidstat、ps 等工具排查 内存相关问题可以使用 free、top、ps、vmstat、cachestat、sar 等工具排查 IO 相关问题可以使用 lsof、iostat、pidstat、sar、iotop、df、du 等工具排查 网络相关问题可以使用 ifconfig、ip、nslookup、dig、ping、tcpdump、iptables 等工具排查。 组件的问题可以从以下几个方面排查 排查组件所在主机是否有问题 排查组件进程基本情况观察各种监控指标 查看组件的日志输出特别是错误日志 进入组件控制台使用一些命令查看其运作情况。 ③ 第三因为系统资源不够造成系统假死的问题通常需要先通过重启和扩容解决问题之后再进行分析不过最好能留一个节点作为现场。系统资源不够一般体现在 CPU 使用高、内存泄漏或 OOM 的问题、IO 问题、网络相关问题这四个方面。 对于 CPU 使用高的问题如果现场还在具体的分析流程是 首先在 Linux 服务器上运行 top -Hp pid 命令来查看进程中哪个线程 CPU 使用高 然后输入大写的 P 将线程按照 CPU 使用率排序并把明显占用 CPU 的线程 ID 转换为 16 进制 最后在 jstack 命令输出的线程栈中搜索这个线程 ID定位出问题的线程当时的调用栈。 如果没有条件直接在服务器上运行 top 命令的话我们可以用采样的方式定位问题间隔固定秒数比如 10 秒运行一次 jstack 命令采样几次后对比采样得出哪些线程始终处于运行状态分析出问题的线程。 如果现场没有了我们可以通过排除法来分析。CPU 使用高一般是由下面的因素引起的 a、突发压力。这类问题我们可以通过应用之前的负载均衡的流量或日志量来确认诸如 Nginx 等反向代理都会记录 URL可以依靠代理的 Access Log 进行细化定位也可以通过监控观察 JVM 线程数的情况。压力问题导致 CPU 使用高的情况下如果程序的各资源使用没有明显不正常之后可以通过压测 Profilerjvisualvm 就有这个功能进一步定位热点方法如果资源使用不正常比如产生了几千个线程就需要考虑调参。 b、GC。这种情况我们可以通过 JVM 监控 GC 相关指标、GC Log 进行确认。如果确认是 GC 的压力那么内存使用也很可能会不正常需要按照内存问题分析流程做进一步分析。 c、程序中死循环逻辑或不正常的处理流程。这类问题我们可以结合应用日志分析。一般情况下应用执行过程中都会产生一些日志可以重点关注日志量异常部分。 对于内存泄露或 OOM 的问题最简单的分析方式就是堆转储后使用 MAT 分析。堆转储包含了堆现场全貌和线程栈信息一般观察支配树图、直方图就可以马上看到占用大量内存的对象可以快速定位到内存相关问题。 需要注意的是Java 进程对内存的使用不仅仅是堆区还包括线程使用的内存线程个数 * 每一个线程的线程栈和元数据区。每一个内存区都可能产生 OOM可以结合监控观察线程数、已加载类数量等指标分析。另外我们需要注意看一下JVM 参数的设置是否有明显不合理的地方限制了资源使用。 IO 相关的问题除非是代码问题引起的资源不释放等问题否则通常都不是由 Java 进程内部因素引发的。 网络相关的问题一般也是由外部因素引起的。对于连通性问题结合异常信息通常比较容易定位对于性能或瞬断问题可以先尝试使用 ping 等工具简单判断如果不行再使用 tcpdump 或 Wireshark 来分析
四、分析和定位问题需要注意的九个点
1、考虑“鸡”和“蛋”的问题。比如发现业务逻辑执行很慢且线程数增多的情况时我们需要考虑两种可能性 ① 程序逻辑有问题或外部依赖慢使得业务逻辑执行慢在访问量不变的情况下需要更多的线程数来应对。比如10TPS 的并发原先一次请求 1s 可以执行完成10 个线程可以支撑现在执行完成需要 10s那就需要 100 个线程。 ② 有可能是请求量增大了使得线程数增多应用本身的 CPU 资源不足再加上上下文切换问题导致处理变慢了。
2、考虑通过分类寻找规律。在定位问题没有头绪的时候我们可以尝试总结规律。 比如我们有 10 台应用服务器做负载均衡出问题时可以通过日志分析是否是均匀分布的还是问题都出现在 1 台机器。 又比如应用日志一般会记录线程名称出问题时我们可以分析日志是否集中在某一类线程上。再比如如果发现应用开启了大量 TCP 连接通过 netstat 我们可以分析出主要集中连接到哪个服务。
3、第三分析问题需要根据调用拓扑来不能想当然。 比如我们看到 Nginx 返回 502 错误一般可以认为是下游服务的问题导致网关无法完成请求转发。对于下游服务不能想当然就认为是我们的 Java 程序 比如在拓扑上可能 Nginx 代理的是 Kubernetes 的 Traefik Ingress链路是 Nginx-Traefik- 应用如果一味排查 Java 程序的健康情况那么始终不会找到根因。 又比如我们虽然使用了 Spring Cloud Feign 来进行服务调用出现连接超时也不一定就是服务端的问题有可能是客户端通过 URL 来调用服务端并不是通过 Eureka 的服务发现实现的客户端负载均衡。换句话说客户端连接的是 Nginx 代理而不是直接连接应用客户端连接服务出现的超时其实是 Nginx 代理宕机所致。
4、考虑资源限制类问题。观察各种曲线指标如果发现曲线慢慢上升然后稳定在一个水平线上那么一般就是资源达到了限制或瓶颈。 比如在观察网络带宽曲线的时候如果发现带宽上升到 120MB 左右不动了那么很可能就是打满了 1GB 的网卡或传输带宽。又比如观察到数据库活跃连接数上升到 10 个就不动了那么很可能是连接池打满了。观察监控一旦看到任何这样的曲线都要引起重视。
5、考虑资源相互影响。CPU、内存、IO 和网络这四类资源就像人的五脏六腑是相辅相成的一个资源出现了明显的瓶颈很可能会引起其他资源的连锁反应。 比如内存泄露后对象无法回收会造成大量 Full GC此时 CPU 会大量消耗在 GC 上从而引起 CPU 使用增加。又比如我们经常会把数据缓存在内存队列中进行异步 IO 处理网络或磁盘出现问题时就很可能会引起内存的暴涨。因此出问题的时候我们要考虑到这一点以避免误判。
6、排查网络问题要考虑三个方面到底是客户端问题还是服务端问题还是传输问题。 比如出现数据库访问慢的现象可能是客户端的原因连接池不够导致连接获取慢、GC 停顿、CPU 占满等也可能是传输环节的问题包括光纤、防火墙、路由表设置等问题也可能是真正的服务端问题需要逐一排查来进行区分。 服务端慢一般可以看到 MySQL 出慢日志传输慢一般可以通过 ping 来简单定位排除了这两个可能并且仅仅是部分客户端出现访问慢的情况就需要怀疑是客户端本身的问题。对于第三方系统、服务或存储访问出现慢的情况不能完全假设是服务端的问题。
7、快照类工具和趋势类工具需要结合使用。 比如jstat、top、各种监控曲线是趋势类工具可以让我们观察各个指标的变化情况定位大概的问题点而 jstack 和分析堆快照的 MAT 是快照类工具用于详细分析某一时刻应用程序某一个点的细节。 一般情况下我们会先使用趋势类工具来总结规律再使用快照类工具来分析问题。如果反过来可能就会误判因为快照类工具反映的只是一个瞬间程序的情况不能仅仅通过分析单一快照得出结论如果缺少趋势类工具的帮助那至少也要提取多个快照来对比。
8、不要轻易怀疑监控。 如果你真的怀疑是监控系统有问题可以看一下这套监控系统对于不出问题的应用显示是否正常如果正常那就应该相信监控而不是自己的经验。
9、如果因为监控缺失等原因无法定位到根因的话相同问题就有再出现的风险需要做好三项工作 ① 做好日志、监控和快照补漏工作下次遇到问题时可以定位根因 ② 针对问题的症状做好实时报警确保出现问题后可以第一时间发现 ③ 考虑做一套热备的方案出现问题后可以第一时间切换到热备系统快速解决问题同时又可以保留老系统的现场。
