u011236069的博客

摘要问题发生在周末，正在家休息突然接收到告警信息提示linux内存使用率超过90%，刚接收到信息以为是程序发生了内存泄漏。登录Linux通过top命令发现系统占用内存正常。各进程内存使用率都很低使用命令：free -h 查看内存使用情况命令：free -h下图为已经清理后的可以看到used使用了1.8GB，当时告警used为6.3GB而且还在持续增长中使用：通过释放 文件缓存,手动释放缓存的方法命令：echo 3> /proc/sys/vm/drop_cache...

简介 今天刚上班就被拉到紧急处理群被告知Apache Log4j2 存在安全隐患需要升级相关依赖版本起因： 2021年11月24日，阿里云安全团队向Apache官方报告了Apache Log4j2远程代码执行漏洞。2021年12月10日，阿里云安全团队发现 Apache Log4j 2.15.0-rc1 版本存在漏洞绕过，请及时更新至 Apache Log4j 2.15.0-rc2 版本。漏洞描述Apache Log4j2是一款优秀的Java日志框架。202...

Arthas是Alibaba开源的Java诊断工具，深受开发者喜爱。在线排查问题，无需重启；动态跟踪Java代码；实时监控JVM状态。Arthas支持JDK 6+，支持Linux/Mac/Windows，采用命令行交互模式，同时提供丰富的Tab自动补全功能，进一步方便进行问题的定位和诊断。快速入门1. 启动math-game curl -O https://arthas.aliyun.com/math-game.jar java ...

简介 众所周知，我们的程序运行产生很多的数据：log，业务数据，行为轨迹等，但是每种数据如何存储，存储周期有多久合适

简介 一般来说每家互联网公司大都会有测试环境（包括日常），预发环境，生产环境。三个环境相互隔离。开发完成一个功能会部署到测试环境，供测试人员测试和其他业务线测试使用。测试没问题，提交上线申请，通过则在部署到预发环境再次测试验收没问题，才能正式上线。 因为功能扩展，本次在测试环境更改了表结构以及对象类型，导致后续状态修改失败，因为很少对记录表做更改，也就忽略问题的追踪。突然一个其他业务现的小伙伴回复他们执行结果没有？然后跟踪发现确实没有。这个影响就比较重大了，回想一下组内小...

简介 随着业务的扩展，用户的增长，稳定性和可用性要求也越来越严格。从主备切换，一主多从，读写分离，哨兵模式等，我们经历很多应用部署层面和应用架构层面的灾备，在业务代码层面其实我们很多业务也做很多稳定性和可用性的工作。 因为我们基础服务将要迎来很多业务方的接入，对我们稳定性和可用性也提出更多的要求。现在我们就来看看我们在业务代码层面灾备思路1: 存储方面 众所周知不论是什么样的业务最终都是要将数据落到数据库中，基础服务同样。为了能够保证我们的服务稳...

简介 我们使用的是ECS部署的应用，因为是云产品，可以配置很多的告警指标，其中有一个关键指标就是磁盘使用率，对成熟的公司来说日志数据和业务数据同等重要‼️，甚至可能会更重要一些。log数据能够帮助我们定位问题和做一些修复性的工作。 问题：ECS磁盘告警 我们ECS采用的是ssd云盘，大小为40G，正常来说系统+应用相关文件磁盘使用不会超过50%，因为我们日志会根据日期和文件大小进行分割，有效期7天（非核心业务逻辑，保存有效期可以降低）。因为一次优化日志导致l...

简介 我们有一个基础服务，这个基础服务平时外部调用量并不是很大，我们有一个小集群（三台4d8g规格的ECS）。运行平稳，后面因为业务方需求我们我们做了一个功能扩展，因为业务方将基础服务当作MQ使用，因此访问量突然增大，平时我们tps：2-10个，这个新的功能支持后tps：200以上，高峰时期业务方评估在tps：2500-2800。这个完全超出了我们当时开发时的数据预估。因此联系测试组对基础服务处理能力进行了压测，果然我们是有瓶颈性问题的，最终的瓶颈点相信很多小伙伴已经猜...

简介 在应用日常管理中，我们常常需要登录linux通过命令查看应用运行的相关情况。后续会慢慢增加使用到命令批量清理进程脚本： 场景：某些脚本被连续执行多次产生的进程，可以使用此命令批量处理for i in `ps aux|grep '进程名称'|grep -v grep|awk '{print $2}'`;do kill -9 $i;done注意：此处kill 方式采用的是kill -9 如果是应用业务相关的进程请使用kill -15 来进行清理...

概述： 由于我们基础组件承载的业务后续会有大数据量进来，其中一张核心的数据表占据80-95%读写操作，经过压测发现当2500tps时就会造成数据库cpu使用100%，导致基础组件出现不稳定，大量服务报错。因此需要对基础组件进行优化。优化阶段一：MQ引入和数据库升级 step1:引入MQ异步化，通过谷歌限流控制消费频率（被限流的数据重新丢回队列） 原因：考虑到我们当时对外提供的服务属于异步服务（可以使用MQ或redis等作存储然后异步处理消费即可），因...

概述： 由于我们负责的基础组件（xxl-job）经常需要做一些定制化的改造因此会经常的重启测试环境（devops -> git pull 指定分支 -〉打包部署）考虑到7*24小时保证服务的可用，我们使用Linux 定时任务crontab 做了一个每分钟探活重启脚本，为了方便扩容这个脚本也上传到项目的git中，git 中的探活脚本指定的是生产环境（使用生产环境的Apollo配置）。因为发现接到用户反馈测试环境不可用了，因此登录ECS使用命令进行了重启，与用户沟通后确认可以。然后开始看...