您的位置:首页 > 运维架构

如何打造前所未有的服务器端监控体验?

2015-09-21 10:29 465 查看
对于开发人员来说,其应用性能是需要特别关注的。在用户体验至上的大环境要求下,性能优化是十分必要的。无意中在知乎看到的这个问题,发现了成都华天创腾一位开发人员的回答分析了阿里云监控功能及 OneAPM 服务器端监控的使用对比,那么就来看下他的故事吧!以下是未经修改的原文:

太久没有写博客了,只是一味的吸收网上的攻略,感觉有点对不起这个行业。做了太多的拿来主义,从来没有几个原创给行业带来一点点的贡献!好吧装 B 装完了。说正事。

话说工欲善其事必先利其器,这里最近发现一个造神器的公司,OneAPM - 端到端的应用性能管理软件云解决方案。

先介绍下我的服务器,作为创业公司没有那么多 ¥ 去买实体服务器,托管,运维,安全防护都是一个大问题。所有当时还好有点经验,理智的给老板介绍了购买阿里云服务器。一下就搞定了这些所有的烦恼(当时是这么认为的),并且阿里云提供了服务器状态监控,服务监控。但是这些仍然只是满足了日常监控和运维的需求。一旦遇到详细点的性能监控的需求就嗝屁了。

本来是在找服务器运行状态监控软件的时候,无意在网上发现了 OneAPM,注册了一个账号后后来没有怎么使用,他们当时还没有推出我需求的服务器监控的软件,后来他们出了新版本后积极联系我,本以为他们和阿里云的东西差不多,后来在他们客服妹妹的悉心调教(我真没有吃过她豆腐)下装了一个试了试,不用不知道一用吓一跳,这个东西比阿里云的监控的详细多了。

上图有图才有真相

阿里云的监控



OneAPM 的监控



优势一下就出来了有木有,阿里云的监控只提供了总体的一个数据监控,而 OneAPM 提供了非常详细的占用信息。虽然 Linux 下也可以用命令看,但是我是比较懒的人(尼玛事情多的爆啊,能用一分钟解决的问题绝不想花两分钟)

话说他给我解决了什么问题吧,由于最近业务量暴涨,突然多了非常多的写库操作。导致数据库服务器的 CPU 暴涨一直都是 100%,尼玛这东西当时导致监控的服务器和服务各种报警,直接吓尿了,到阿里云监控上只看到了 CPU 占用了百分之但是那个程序占用的尼玛完全木有任何信息啊全靠自己去慢慢琢磨,老板的要求是服务器报警不能超过 30 分钟必须解决时间紧迫。当时登陆了 OneAPM 后台看采集回来的数据,清清楚楚的看到是 MySQL 数据库。几乎吞噬了所有数据库服务器的 CPU 这样下去不导致数据库服务器宕机才怪。

接下来 用OneAPM 的应用监控,查看服务对数据库的读写操作按次数进行排序,基本上是9:1的读写比例。



还好哥当时留了一手有先见之明,在另外的服务器上准备了一个从备份库,并且配置
**oeba
的读写分离,因为 PHP 接口用 amoeba 会报错,所以都是直连的主库。但是分析了最近的写库业务都是来源于 Java 服务,赶紧把 Java 的服务都切到
**oeba
服务的数据库中间件上,做了读写分离后 CPU 分分钟降到了 50% 的正常水平,从早上 8 点报警到中午十二点,基本解决了由大量数据写入数据库导致的 CPU 暴涨引起的一次性能问题。神器在手天下我有!!

其实我就是做了一次打酱油的其他的都给工具做了!!

------以上是分享的全部内容------
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: