Etcd 故障排查

线上故障排查方案

⼀般包括以下⼏项，也可以将此理解为排查顺序：业务⽇志分析排查APM分析排查物理环境排查应⽤服务排查云⼚商或运营商问题排查1.1 业务⽇志分析排查这个没啥说的，看日志不会吗？ 1.2 APM分析排查APM，全称Application Performance Management,应⽤性能管理在分布式系统中，需要用到APM进行全链路分析⽬前市场上使⽤较多的链路跟踪⼯具有如下⼏个 情况，找到读写异常的进程⽹络分析使⽤dstat、vmstat等命令查看⽹络流量、TCP连接等情况，分析异常流量1.4 应⽤服务排查应⽤排查，排查应⽤本身最有可能引发的问题，针对各种场景进⾏对应分析CPU 分析使⽤jstack等命令进⾏JVM分析内存分析使⽤jmap等命令分析内存使⽤情况1.5 云⼚商或运营商问题排查排查到了这⼀步的话，只需关注云⼚商或运营商官⽅公告即可。 其中，定位排查问题时最为常⽤命令包括：jps（进程）、jmap（内存）、jstack（线程）、jinfo（参数）等。

MogDBopenGauss 故障排查思路

前提 当我们收到反馈说数据库响应慢或者压测过程中数据库有报错，第一步先收集数据库服务器资源使用情况，这一步是处理所有故障的前提。 备节点故障： 通过网络及数据库日志信息，判断节点故障原因，并尽快恢复主备节点之间的复制关系，当故障无法快速解决时，建议修改数据库参数来改变主库Xlog保留大小。

网络问题故障排查

网络问题故障排查 一、服务器网络卡慢 参考文档https://cloud.tencent.com/document/product/213/14633 1、检查本地访问域名速度 https://itango.tencent.com DNS是否生效情况 nslookup 地址 5、使用MTR分析网络延迟及丢包 https://cloud.tencent.com/document/product/213/14638 二、CDN网络访问故障 CDN网络故障原因排查https://cloud.tencent.com/document/product/228/59530 1、检查CDN是否生效以及是否需要刷新预热 https://cloud.tencent.com

故障分析 | MySQL 无监听端口故障排查

擅长数据库故障处理。对数据库技术和 python 有着浓厚的兴趣。本文来源：原创投稿*爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。 ---前言最近解决了一个比较基础的问题故障，由于排查过程挺有意思，于是就以此为素材写出了本篇文章。故障现场防火墙什么的均正常但是无法被远程访问到。简单的使用客户端登录了一下。 ERROR 2003 (HY000): Can't connect to MySQL server on '127.0.0.1' (111)根据以往经验大脑中浮现了几个常见的排查此类故障手法1.排查进程存在 mysql/data/3308/mysqld.pid --user=mysql --socket=/mysqldata/mysql/data/3308/mysqld.sock --port=33082.排查端口绑定情况 解决方案因为配置 skip-grants-tables 引起无法远程连接 mysql 服务端的故障，解决方法也是非常的简单注释重启。

故障分析 | MySQL 无监听端口故障排查

---- 前言 最近解决了一个比较基础的问题故障，由于排查过程挺有意思，于是就以此为素材写出了本篇文章。 故障现场 防火墙什么的均正常但是无法被远程访问到。简单的使用客户端登录了一下。 ERROR 2003 (HY000): Can't connect to MySQL server on '127.0.0.1' (111) 根据以往经验大脑中浮现了几个常见的排查此类故障手法 1. 排查进程存在 [root@wx ~]# ps -ef|grep [m]ysql  mysql 25973 1 1 8月30 ?  排查端口绑定情况，居然没有绑定端口 [root@wx ~]# lsof -i:3308 [root@wx ~]# ss -nltp|grep 3308 3. 本文关键字：#故障排查# ---- 文章推荐： ‍‍技术分享 | 国产麒麟 arm 上编译安装 xtrabackup8 技术分享 | MySQL 会受到“Unix千年虫“的影响吗‍ 技术分享 | MHA-MasterFailover

【故障排查】nginx504

upstream timed out (10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond) while reading response header from upstream

数据库故障排查

数据库故障排查的基本概念 数据库故障排查是指通过系统化的方法识别、分析和解决数据库运行过程中出现的问题。故障可能表现为性能下降、数据丢失、连接失败等。 常见数据库故障类型 性能问题：查询速度慢、资源占用高。 连接问题：无法连接数据库、连接超时。 数据一致性问题：数据丢失、数据损坏。 配置问题：参数设置不当、权限配置错误。 # 示例：查看MySQL慢查询日志 SHOW VARIABLES LIKE 'slow_query_log'; 性能问题的排查步骤 检查系统资源使用情况，确认是否存在资源瓶颈。 -- 示例：查看MySQL当前连接数 SHOW STATUS LIKE 'Threads_connected'; 数据一致性问题的排查步骤 检查备份和恢复策略，确保数据可恢复。 总结 数据库故障排查是一个系统化的过程，需要结合工具和方法，逐步分析和解决问题。通过掌握常见的故障类型和排查步骤，可以有效提高数据库的稳定性和性能。

linux网络故障排查

在日常使用中，经常会出现无法连通的情况，这个时候我们就需要找到问题出在哪里，这里面给各位提供一个生产环境排查网络故障的大体思路，一般情况下如果遇到网络故障，都是通过筛选的方式一点一点的确定问题所在，首先判断是本机的问题还是网络上其它设备的问题 124.65.56.141) 16.020ms Too many hops: pmtu 1000 Resume: pmtu 1000 八、硬件故障

Linux 网络延迟故障排查

在 Linux 服务器中，可以通过内核调优、DPDK 以及 XDP 等多种方式提高服务器的抗攻击能力，降低 DDoS 对正常服务的影响。在应用程序中，可以使用各级缓存、WAF、CDN 等来缓解 DDoS 对应用程序的影响。

TCP 常见故障排查

发生错包的原因有很多，但是一般都是由于网线或者网卡等硬件故障造成。如果你的服务器在换了机房或者网络发生了变更之后，延迟明显增加。这个时候你就要怀疑是不是网卡丢包或者是错包引起的了。

Linux网络延迟故障排查

原文:https://blog.devgenius.io/linux-troubleshoot-network-latency-a6da740f5cb8

面试-线上故障如何排查

面试经常会被问到java应用出现了问题,如何排查,主要使用下面几个命令基本都能解决 执行top命令，查看所有进程占用cpu的排序 执行top -Hp pid,查看java进程下的所有线程占用cpu的情况

【图解】Kubernetes Deployment 故障排查指南

如果你不知道从何下手，那么在 Kubernetes 中排查故障可能会是一项艰难的任务。文本以超详细的图解说明了如何对 Kubernetes Deployment 进行故障排查，相信会对你有启发。 K8sMeetup 3个步骤排查 kubernetes Deployment 故障 在深入探究有故障的 Deploymen 时，必须明确 Kubernetes 是如何工作的。 应该从最底层开始为 Deployment 做故障排查。首先，检查 Pod 是否已就绪并在运行中 ? 如果 Pod 已就绪，应该检查 Service 是否能将流量路由到 Pod ? 排查 Ingress 故障 如果已经到了这个阶段，那么意味着： Pod 在运行中且是就绪状态； Service 可以分发流量分配到 Pod。 但是你仍然看不到应用程序的响应。 K8sMeetup 总结 如果你不知从何下手，那么在 Kubernetes 中进行故障排查可能会是一项艰巨的任务。

网络故障基本排查步骤

网络故障基本排查步骤：

Kubernetes 故障排查工具- Robusta 解析

Hello folks，我是 Luga，今天我们来分享一款用于 Kubernetes Cluster 故障排查的开源工具 - Robusta （罗布斯塔）。 作为一个用于多集群 Kubernetes 监控、故障排除和自动化的开源平台，就像 Docker 用于部署应用程序的基础设施即代码一样，Robusta 用于维护 Kubernetes Cluster 应用程序和处理其警报的基础设施即代码 — 01 — Robusta 概述 作为一款用于 Kubernetes Cluster 故障排查的开源平台，其本质是为了弄清楚我们当前所构建的 Kubernetes Cluster 的健康状况，并针对所出现的告警行为进行合理解释以及给予我们相关修复建议 Cli 通常具备两个主要用途，具体如下所示： （1）基于自动生成的 Helm 值使的 Robusta 安装变得更容易，便捷，有利于维护，节省资源成本； （2）可以手动触发 Robusta 故障排除工作流程

Bluestore下的SSD故障排查

线上发现L版本一个OSD down，不确定是否磁盘故障，之前的filestore排查起来比较熟，换成Bluestore以后，有些细节上的操作不一样，因为用到的是SSD，所以有了这篇排查文档。 排查过程 定位故障节点 [root@demo-host ceph]# ceph osd tree|grep down 20 1.00000 osd.20 9cb7-5263-bec0-3fa34dc0373f ceph-dfe4f8f2-880f-414d-af58-5b3c77ed2628 -wi-ao---- <5.46t 最后保守起见还是手工点亮故障灯

JVM 线上故障排查基本操作

今天的文章，就如我们的题目一样，讲的是基本操作，也就是一些排查线上问题的基本方法。为什么这么说呢？ 还有，本文的排查环境是 Linux。 CPU 飚高 线上 CPU 飚高问题大家应该都遇到过，那么如何定位问题呢？ 最后对代码进行排查。 如何操作呢？ 通过 top 命令找到 CPU 消耗最高的进程，并记住进程 ID。 内存问题排查 说完了 CPU 的问题排查，再说说内存的排查，通常，内存的问题就是 GC 的问题，因为 Java 的内存由 GC 管理。 总结 基于文章的标题，我们这个是基本操作，故障排查是说不完的话题，每个故障涉及的知识也都很多，因此，我们在学习了基本的排查之后，还需要学习更多事故排查技术，比如排查 IO，网络，TCP 连接等等。

网站无法访问故障排查

场景4:网站业务问题，导致网站无法访问原因：网站本身业务问题，服务没起来，服务器有问题，导致网站无法访问排障方法：直接通过IP进行访问，若无法访问，仔细排查网站的业务是否有问题解决方案：业务问题各种各样

JAVA 应用线上故障排查手册

线上故障主要会包括 CPU、磁盘、内存（含JVM）以及网络问题，而大多数故障可能会包含不止一个层面的问题，所以进行排查时候尽量四个方面依次排查一遍。 CPU 首先会排查 CPU 方面的问题。CPU 异常往往还是比较好定位的。原因包括业务逻辑问题(死循环)、频繁 gc 以及上下文切换过多。 4）gc 问题和线程 gc 问题除了影响 CPU 也会影响内存，排查思路也是一致的。 如果参数正常，但是 young gc 频率还是太高，就需要使用 Jmap 和 MAT 对 dump 文件进行进一步排查了。 3）触发 fullGC G1 中更多的还是 mixedGC，但 mixedGC 可以和 youngGC 思路一样去排查。