故障类型 ---- 线上的jvm故障基本可以分为两大类: CPU____占用过高。 内存问题,通常可以理解为gc的问题,因为java的内存用gc进行管理。 故障排查兵器谱 ---- 命令行工具 jps等工具都是对tools.jar类的包装,使用起来方便简单.在下边的故障排查中会用到我们这里提到的工具,大家平时应该熟记于心. top: top命令用于实时显示 -v pid #输出虚拟机进程启动时JVM参数 jstat: JVM Statistics Monitoring Tool，用于收集HotSpot虚拟机各方面的运行数据 #我想监控gc，每250ms查询一次 visualVM CPU问题 ---- CPU负载比较高的时候，我们需要先找到那个java进程，然后根据(进程ID)找到的那个”问题线程”，根据线程的堆栈信息找到代码,最后进行代码排查。 内存问题的排查思路和cpu类似,在进行cpu分析的时候也顺带说了下内存: 通过top命令定位内存消耗最高的进程,并记住进程pid jmap -histo:live pid查看当前进程创建的活跃对象的数目和占用内存的大小
1 ping命令简介 Ping命令主要用于检查网络连接及主机是否可达。 -t：持续地ping直到人为中断，Ctrl+Break暂时中止ping命令并查看当前的统计结果，而Ctr+C则中断命令的执行。 4 ping故障现象以及原因总结 A、故障现象：全部可达，但时间较长 可能原因： 中间网络状况不佳。 网关设备做了QoS，限制了转发速度。 B、故障现象：全部不可达 可能原因： 网络中断（含设备与线缆）。 中间经过的防火墙设备不允许进行ping探测，丢弃了ICMP报文。 网络产生环路，TTL减到1后被丢弃。 网络拥塞导致报文响应慢。 C、故障现象：部分可达 可能原因： 网络状况不佳，部分报文被丢弃。 中间网络配置有负载分担，且其中部分分担网络故障。 遭到“泛洪”攻击。
Vite学习指南，基于腾讯云Webify部署项目。
1 tracert命令简介 Ping可以告诉用户目标是否可达，而Tracert命令用于测试数据包从发送主机到目的地所经过的设备，它主要检查网络连接是否可达，以及分析网络什么地方发生了故障。 Tracert的执行过程如下： 首先发送一个TTL为1的UDP报文。 到达第一跳时TTL超时，第一跳设备发回一个ICMP错误消息，指明此数据包不能被发送。 发送主机将TTL加1，重新发送此数据包。 以上步骤循环进行，直到到达目的地。这样，发送主机就能够记录每一个ICMP TTL超时消息的源地址，得到IP数据包到达目的地所经历的路径。 host：可以是IP地址或域名，如果是域名会首先进行DNS解析，并显示解析后的IP地址。 当网络上出现路由环路时，使用ping命令只能知道接收端出现超时错误，而tracert命令能够很容易发现路由环路等潜在问题。在tracert某地址时，多次出现相同的地址，即可认为出现了路由环路。
在讲解事件、故障处理思路前，先讲一个故障场景（以呼叫中心系统作为一例子）： 业务人员反映呼叫中心系统运行缓慢，部份电话在自助语言环节系统处理超时，话务转人工座席，人工座席出现爆线情况。 但，如果故障是偶发性的，是有极小概率出现的，则比较难排查，这依赖于系统是否有足够的故障期间的现场信息来决定是否可以定位到总是原因。 在排查故障原因时应该避免全面性的排查，建议先把问题范围缩小到一定程序后再开始协调关联团队排查。 排查进展，展示信息 领导决策 2、完善监控 1）从监控可视化上完善 完善的监控策略需要有统一的可视化操作界面，在制定完善的监控策略后，故障处理人员需要能够快速的看到相应的运行数据，比如：能够看到一段时间的趋势 全面性的应用监控可以让故障提前预警，并保存了影响应用运行环境的数据，以缩短故障处理时间。
整理自官方开发文档 目录 概述 配置 Test runner 具有所需一切的 Dev server 使用 PyCharm 进行调试 Web server 独立守护进程 提示和故障排除 概述 如果您使用 run 命令，例如： run cron run worker -c 1 提示和故障排除 如果您想调试它，相同的一组修改将适用于 getentry 项目的运行配置。 如果您希望 Sentry 在调试环境中的行为不同于常规运行中的行为，您可以添加任意环境变量，然后在您的 .sentry/sentry.conf.py 文件中检查它们。 如果您单独运行的守护进程不工作，您可以通过调试 devserver --debug-server 并在 src/sentry/runner/commands/devserver.py 上插入断点来进行故障排除 Relay PII 和数据清理 Sentry 开源版与商业 SaaS 版的区别 Sentry 企业级数据安全解决方案 - Relay 入门 Sentry 监控 - 私有 Docker Compose 部署与故障排除详解
web端实现同样的基础组件和API，webpack打包js文件时做好组件映射，这样同一套业务代码可以运行在三端。 支持后端渲染直出提升首屏渲染可见时间，常规的静态页面渲染要经过js下载、执行，react组件渲染、数据加载、组件更新等耗时时间较长，如下图所示，在无缓存+wifi+笔记本i5+8g环境下，js大小为100kb ，js下载+执行耗时300+ms 由于flex兼容判断是依赖浏览器环境，后端渲染需要去掉这些依赖补全全部的兼容样式，服务端渲染首屏主要耗时在后端渲染耗时较短200ms内基本可以返回html内容。 "a" /* default */], { className: "_41z5ub", style: styles.iconRight }) ) 优化前后对比 环境为桌面 页面js加载和执行耗时如下 优化前 script加载和执行耗时168ms 优化后 script加载和执行耗时125ms 主要缩减react+reactweb组件大小, 大小从251kb缩减到117kb
LNMP 架构应用程序 日志排错 介绍下开发语言和服务器环境，PHP7.2+Linux CentOs LNMP 指 Linux+Nginx+Mysql+PHP 程序部署后，出现如下图示 ? 应用程序运行中，对于运行缓慢 CPU 占比高等情况，都可以采用重启 Web 容器服务解决，比如 Tomcat PHP-FPM 服务。 ❝正常情况下，重启服务可以让线上服务正常恢复运行。 ❞ ❝风险是往往会毁坏现场，有可能使事故异常无据可查。 这种情况可以以下两个角度排查 1 代码一致性 2 服务器环境权限 对于非编译型语言开发的应用，如 PHP 程序，本地服务是完整的代码，所以程序能够正常运行。 每次事故和故障的复盘，究其原因都会发现难逃以下几点 开发原则执行不彻底 开发流程执行不到位 参与方沟通不到位，没有达成一致 以上几个问题 可以从程序设计原则，流程标准化，代码审查和沟通体制等多个方面精进优化
设备统计 通过 Hightopo 地下综合管廊智慧管理 Web平台，工作人员轻点鼠标，就可以清楚看到各个舱内的运维、保养、故障维修等情况统计数据。 7 天内管线破损、人员异常、环境异常、设备异常的告警数据采用环形图展示，让管理者清楚告警的构成情况。告警列表动态显示警报级别和故障地址，便于统计事故易发地。 工单的收集利于问题的统计，后续可排查出事故频繁发生的地点和时间，提前采取预防措施，避免类似问题的发生。 管廊内部系统 无论承载的管线出现故障，还是自身附属设备出现故障，都可能造成部分功能的瘫痪，因此建设综合管廊时需要设置各类现场传感器用于监测和控制管廊内部设施运行情况。 综合管廊各舱智能监测系统，具备对各舱本体、运行环境等进行智能检测。采用环形图动态显示各舱室能耗占比，比对分析巡检数据，可及时发现设备和运行环境中存在的高耗能情况，及时进行调整。
设备统计 通过 Hightopo 地下综合管廊智慧管理 Web平台，工作人员轻点鼠标，就可以清楚看到各个舱内的运维、保养、故障维修等情况统计数据。 7 天内管线破损、人员异常、环境异常、设备异常的告警数据采用环形图展示，让管理者清楚告警的构成情况。告警列表动态显示警报级别和故障地址，便于统计事故易发地。 管廊内部系统 无论承载的管线出现故障，还是自身附属设备出现故障，都可能造成部分功能的瘫痪，因此建设综合管廊时需要设置各类现场传感器用于监测和控制管廊内部设施运行情况。 综合管廊各舱智能监测系统，具备对各舱本体、运行环境等进行智能检测。采用环形图动态显示各舱室能耗占比，比对分析巡检数据，可及时发现设备和运行环境中存在的高耗能情况，及时进行调整。 能耗历史的统计方便管理者对系统事件和报警进行历史追溯，查询统计、事故分析。
设备统计 通过 Hightopo 地下综合管廊智慧管理 Web平台，工作人员轻点鼠标，就可以清楚看到各个舱内的运维、保养、故障维修等情况统计数据。 7 天内管线破损、人员异常、环境异常、设备异常的告警数据采用环形图展示，让管理者清楚告警的构成情况。告警列表动态显示警报级别和故障地址，便于统计事故易发地。 管廊内部系统 无论承载的管线出现故障，还是自身附属设备出现故障，都可能造成部分功能的瘫痪，因此建设综合管廊时需要设置各类现场传感器用于监测和控制管廊内部设施运行情况。 综合管廊各舱智能监测系统，具备对各舱本体、运行环境等进行智能检测。采用环形图动态显示各舱室能耗占比，比对分析巡检数据，可及时发现设备和运行环境中存在的高耗能情况，及时进行调整。 能耗历史的统计方便管理者对系统事件和报警进行历史追溯，查询统计、事故分析。 节能减排考核 建立科学、完整、统一的节能减排统计、监测和考核体系，按规定做好各项能源和污染物指标统计、监测，按时报送数据。
本文会对虚拟化技术与 Docker 容器技术做一个对比，然后引出一些 Docker 的名词术语，比如：容器、镜像等，随后将使用 Docker 搭建一个 Java Web 运行环境，最后将对本文做一个总结 不管是虚拟机还是 Docker 容器，它们都是为了隔离应用程序的运行环境，节省我们的硬件资源，为我们开发人员提供福利。 安装相关软件 为了搭建 Java Web 运行环境，我们需要安装 JDK 与 Tomcat，下面的过程均在容器内部进行。 /bin/bash source ~/.bashrc sh /opt/tomcat/bin/catalina.sh run 注意：这里必须先加载环境变量，然后使用 Tomcat 的运行脚本来启动 Tomcat 最后是“初始命令”，它是上面编写的运行脚本，里面封装了加载环境变量并启动 Tomcat 服务的命令。
本文会对虚拟化技术与 Docker 容器技术做一个对比，然后引出一些 Docker 的名词术语，比如：容器、镜像等，随后将使用 Docker 搭建一个 Java Web 运行环境，最后将对本文做一个总结 不管是虚拟机还是 Docker 容器，它们都是为了隔离应用程序的运行环境，节省我们的硬件资源，为我们开发人员提供福利。 我们再来看看 Docker 的 Logo 吧： ? 安装相关软件 为了搭建 Java Web 运行环境，我们需要安装 JDK 与 Tomcat，下面的过程均在容器内部进行。 /bin/bashsource ~/.bashrcsh /opt/tomcat/bin/catalina.sh run 注意：这里必须先加载环境变量，然后使用 Tomcat 的运行脚本来启动 Tomcat 最后是“初始命令”，它是上面编写的运行脚本，里面封装了加载环境变量并启动 Tomcat 服务的命令。
背景 监控是提高故障处理能力和保障服务质量必需的一环，它需要负责的内容包括：及时上报错误、收集有效信息、提供故障排查依据。 假如监控系统里记录了设备信息、错误发生时的场景信息和用户的操作流程，我们就可以直接根据这些信息进行问题定位，在最短时间内完成故障修复，减小问题的影响面。 提供故障排查依据：监控前端SDK所上报的错误信息和其它的记录信息，其最终目的都是作为我们排查故障的依据，为我们保障服务提供坚实的依靠。 监控分类 综上所述，我们的监控平台强调实时性和全面性。 监控前端SDK：收集用户端错误和相关信息，并进行上报 监控Web层支撑系统：处理上报的监控信息 监控面板：提供实时查看上报信息的面板，方便监控数据的便捷使用 前端SDK运行在前端页面中，收集监控数据上报到支撑系统里 环境模块 环境模块收集以下环境信息：项目配置信息、Web环境数据、JsBridge环境数据。 其它的一些诸如UA、ISP等Web层可以获取的信息由Web层获取。
本文试图厘清在这样的网络环境下怎样解决运维的难题。 ❆ 那些熟悉的“车祸现场” 让我们先看几个运维人员特别熟悉的“车祸现场”吧。 第一个比较常见的问题是没有收到报警但是用户报障。 运维人员经常要和开发团队去讨论到底是网络的问题还是应用的问题，往往耗费很大精力比如用数据证明交换机上没有 error、能否看到 TCP 会话、甚至借助 Web 统计工具的结果来区分故障边界。 ? 通过控制器 Web 页面，我们可以对服务器（比如 KVM 宿主机）上的虚拟交换机执行自动化网络诊断，例如最基本的虚拟端口 VLAN 配置正确性检查等；对于虚拟机之间的东西向流量，我们可以在宿主机上插入 在本文所述的部署场景中，当用户报障的时候我们可以通过一下简单的四步操作，快速定位问题。 ? 1、首先控制器 Web 页面上可以触发对 OvS 的自动化网络检查，把排障范围进一步缩小。 4、最后当我们排除了 Overlay 网络层面的问题后，可以通过关联 Underlay 网络路径进一步对物理网络进行检查。 通过以上四步检测，多数情况下故障都能被排查到。
故障排除从来都不是一项有趣的任务，尤其是像这种MySQL因为内存不足而崩溃的故障。Peter Zaitsev在2012年写了一篇博客文章：用许多有用的技巧解决MySQL内存使用问题。 有了新版本的MySQL(5.7+)和performance_schema，一切都不同了，我们可以更轻松地对MySQL内存分配进行故障排除。 在本文中，我将向您展示如何使用它。 这是最坏的情况，我们才需要进行故障排除。 从哪里开始对MySQL内存泄漏进行故障排除 下面是我们可以从下面步骤开始（(假设它是一个Linux服务器)）： 第1部分:Linux操作系统和配置检查 1. 每当MySQL进程被OOM“dmesg”杀死时，日志中也会显示相关的周围环境细节信息。 2. 对于非生产环境，我们可以使用其他工具(如Valgrind、gdb等)来检查MySQL的使用情况 第2部分:检查MySQL内部 现在，我们可以检查MySQL内部的内容，以查找潜在的MySQL内存泄漏。
一、故障现象 某天，开发在生产环境照常通过配置中心修改了应用配置后，发现应用开始大量报错。 查看日志，发现原来是redis无法获取到连接了，所以导致接口大量报错。 情急之下，只能把所有机器上的Tomcat都重启了一遍，故障恢复。 二、初步分析 由于故障发生的时间和配置中心修改配置十分吻合，所以后来立马联系我们来一起帮忙排查问题（配置中心是我们维护的）。 虽然后来运维帮忙统一修复了这个设置问题，但是需要重启才会生效。所以目前生产环境还有相当一部分机器的Max Open Files是4096。 应用对外的服务由于无法连接Redis，导致请求超时，客户端请求堆积，陷入恶性循环 6.2 后续优化措施 通过这次问题排查，我们不仅对Too many open files这一问题有了更深的认识，对平时不太关心的 4、遇到故障，不要慌张，保留现场 生产环境遇到故障，不要慌张，如果一时无法解决问题的话，可以通过重启解决。不过应该至少保留一台有问题的机器，从而为后面排查问题提供有利线索。
运用 Hightopo 自主研发的前端可视化引擎 HT for Web 实现可交互式的 Web 风力发电数字孪生三维场景。 利用图扑软件的可视化场景将智能设备的实时运行参数接入两侧的 2D 面板，将项目概况、实时指标、机组状态、环境参数、发电统计、节能减排等复杂、抽象的数据以丰富的图表、图形和设计元素展现，实现集中管控。 点击升压站三维模型可跳转至升压站视角，展示站内主要观测数据，如环境信息、负荷统计、风功率预测、消防检查信息、巡检车信息等。 环境信息 图扑软件数字孪生三维可视化系统中的升压站环境信息监测主要整合了整个风电基地的天气、平均温度、主要风向、平均风速数据，方便实施把控风场大环境信息。 故障列表 巡检车辆在检测到设备故障时，将信息上报登记至后台，将主要故障信息展示于图扑软件监管平台的前端故障列表中，并按照故障时间置顶排序，方便维修人员及时查看与处理。
持续集成可以解决什么问题： 能验证代码是否可以正常编译 验证组建或模块是否能够集成 验证自动化测试用例是否正常运行 测试环境的部署 持续集成不能解决什么问题： 生产环境的发布 部署失败后回撤 不能构建环境 导致构建排队，阻塞，同时 pipeline 可能会争夺资源（多个进程读写同一个文件），产生冲突，轻则稍等片刻，重则测试环境崩溃。 以上的特性，你敢在生产环境上使用吗？一旦发布失败，或者需要回撤，持续集成并没有很好的解决方案。 我认为，持续集成尚不完善，测试环境玩玩可以，生产环境还是不要了。 问题收集 产品线都多少条？ 被动监控，故障发生运维人员永远不是第一个发现故障的人 监控IP地址与TCP端口，很多时候HTTP 80端口正常接受请求，但WEB服务器不能正常工作。 将所有业务逻辑都逐一模拟一次，任何一个环节出现问题，立即发出警告。 模拟人工 这里主要监控服务是否可用，可以检查软件的工作情况，涉及测试环节。
扫码关注云+社区
领取腾讯云代金券
云服务器
测试服务 WeTest
云数据库 PostgreSQL
文件存储
SSL 证书