?作者简介：大家好，我是蓝胖子? ☁️博客首页：CSDN主页蓝胖子的编程梦 ?每日一句：人生的烦恼，多在于明白的太多，而做的太少 大家好，我是蓝胖子，随着微服务的流行，服务的可观测性概念被越来越多人提及到，究竟什么是可观测性？我们应该如何构建服务的可观测性？我将会在这篇文章中逐步提及到，并对和可观测性相关的工具 Opentelemetry做一个大致的介绍。 ?可观测性指的是什么 首先，我们来
大家好,我是蓝胖子，关于性能分析的视频和文章我也大大小小出了有一二十篇了，算是已经有了一个系列，之前的代码已经上传到 github.com/HobbyBear/performance-analyze ，接下来这段时间我将在之前内容的基础上，结合自己在公司生产上构建监控系统的经验，详细的展示如何对线上服务进行监控，内容涉及到的指标设计，软件配置，监控方案等等你都可以拿来直接复刻到你的项目里，这是一
大家好，我是蓝胖子，在golang中可以使用go pprof的工具对golang程序进行性能分析，其中通过go trace 命令生成的trace view视图对于我们分析系统延迟十分有帮助，鉴于当前对trace view视图的介绍还是很少，在粗略的看过trace统计原理后，我将对这部分做比较详细的介绍。 trace view 视图简介 在go代码里，我们可以通过trace.Start和trac
大家好,我是蓝胖子，关于性能分析的视频和文章我也大大小小出了有一二十篇了，算是已经有了一个系列，之前的代码已经上传到github.com/HobbyBear/performance-analyze, 接下来这段时间我将在之前内容的基础上，结合自己在公司生产上构建监控系统的经验，详细的展示如何对线上服务进行监控，内容涉及到的指标设计，软件配置，监控方案等等你都可以拿来直接复刻到你的项目里，这是一套非
大家好，我是蓝胖子，今天我们来分析下网络连接中经常出现的RST信号，连接中出现RST信号意味着这条链接将会断开，来看下什么时候会触发RST信号，这在分析连接断开的原因时十分有帮助。 在开始分析触发RST的场景之前，我们先来准备下需要的客户端和服务端代码，以方便我们进行测试。 服务端代码目前先是在8080端口监听，然后将接收到的消息打印出来。 func main() { listen, e
请求慢的原因很多，当出现前端反应接口慢时，而通过后端日志查看请求处理时间并不慢时，往往会手足无措，当面对网络问题出现手足无措时，这就是在提醒你该抓包分析了，那么一般如何根据抓包文件去分析慢请求呢，今天我们就来看看。 抓包文件分析 准备用我在测试环境抓到的包去进行分析，首先执行抓包命令。 sudo tcpdump -i lo port 6310 -w http.pcap -w 命令能让我在
??性能优化，服务监控方面的知识往往涉及量广且比较零散，希望将这部分知识整理成册，愿以后性能排查不再抓瞎。
我又和redis超时杠上了 服务监控系列文章 服务监控系列视频 背景 经过上次redis超时排查，并联系云服务商解决之后，redis超时的现象好了一阵子，但是最近又有超时现象报出，但与上次不同的是，这次超时的现象发生在业务高峰期，在简单看过服务器的各项指标以后，发现只有cpu的使用率在高峰期略高，我们是8核cpu，高峰期能达到90%的使用率，其余指标都相对正常。 但究竟是不是cpu占比高的问题导致
一次排查某某云上的redis读超时经历 问题背景 最近一两天线上老是偶现的redis读超时报警，并且是业务低峰期间，甚是不解，于是开始着手排查。 以下是我的排查思路。 排查思路 查阅 redis 慢查询日志 既然是redis超时，首先想到的还是 对于redis的操作命令存在慢查询导致的。 redis的慢查询阈值是10ms,唯一的慢查询是备份时的bgrewriteaof语句，并不是业务命令，既然从
一次系统延迟性优化案例问题背景线上隔三差五晚上10点左右总会有sql报警出现，且是同样的sql，我们的sql报警是在应用程序内部通过对sql操作增加钩子函数，对sql前后执行的位置记录下时间戳，然后sql执行完毕后，对时间戳进行相减得到sql执行时长，大于1s则报警。晚上10点正好是我们的业务高峰。部分接口也会在此期间出现超过2s的响应。探索过程排查sql慢查询由于是执行sql的地方出现报警，所以
mysql invalid conn排查问题背景我们的服务端程序是使用golang进行开发 ，mysql的客户端库是go-mysql-driver ,系统测试环境频繁总时不时报出invalid conn 错误，但实际拿sql执行时却是正常执行。排查思路原因分析客户端使用了无效连接由于报错信息是invalid conn 连接无效的提示，首先考虑了客户端使用了过期连接。mysql服务器端和客户端都能配
一次goroutine 泄漏排查案例背景这是一个比较经典的golang协程泄漏案例。背景是这样，今天看到监控大盘数据发现协程的数量监控很奇怪。呈现上升趋势，然后骤降。虽然对协程数量做了报警机制，但是协程数量还是没有达到报警阈值，所以没有报警产生。不过有经验的开发应该应该能一眼看出，这个肯定是协程泄漏了，因为协程数量一直在上涨，没有下降趋势，，中间下降的曲线其实是服务器重启造成的。pprof分析为了
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
