容量管理系统设计方案

容量管理从本质来讲,主要需要解决的问题是系统“亚健康(有病,但还不影响生活和工作)”的情况下,我们能够及时知道,并做出对应策略,确保系统恢复到正常顺畅;本方案主要是讲的第一部分,“我们如何及时知道、并告警/预警”,不涉及到“容量处理策略”。

一.主要问题场景:

实时系统:

能提供服务,但是速度较慢;

随着业务的逐渐发展,一路上升都提供良好,但是离悬崖慢慢靠近(用一个举重运动员的话说,在压一块金牌在杠铃上,就倒了);

业务突发增长,导致短时间内,系统资源耗尽,服务质量严重下降;

离线系统:

随着业务的发展,在约定时间内逐渐无法完成任务(例如:1个小时跑一次的数据统计,随着业务增长,无法在1个小时内完成);

依据以上问题场景,数据容量系统定义以下目标,并以此目标为验收标准;

二.数据容量系统的目标:

核心目标:

容量实时监控;

容量按天日报,了解到目前系统在资源和业务方面的容量百分比,处理取于高负载的设备或者是模块;

附加目标:

成本控制,通过对低负载模块的展现,整合机器利用率,有效控制成本;

三.容量管理方案

针对实时系统,主要采用一下三种方式来达到要求:

自动化测试监控添加测速和时耗告警;(满足场景一、告警时间2分钟)

针对外网服务,自动化测试监控平台提供模拟用户角度从外网IP访问网页(目前主要是针对pay、积分、support、service四个外部网站),并且对时耗做了收集和告警;

针对后台服务,自动化测试监控平台提供模拟客户端从内网IP访问服务端,针对所有实时系统都添加了核心功能的自动化测试,并且对时耗也做了收集和告警;

针对基础资源的实时告警(满足场景三、告警时间5分钟)

针对基础资源的实时监控,主要有以下几种:

  1. 部门默认在tnm2平台上统一配置的告警策略: 单机cpu使用率:使用率大于等于95%,连续20分钟,短信告警; 单机cpu负载: 负载大于等于4,连续20分钟,短信告警; 单机应用内存使用率:使用率>85%,连续20分钟,短信告警; 单机外网流量告警: 当前流量>=200%*上周同天同点,连续出现30分钟,则短信告警 当前流量<20%*上周同天同点,连续出现30分钟,则短信告警 单机硬盘使用率: 使用率>95%,直接上报noc 使用率>90%, 预警发短信
  2. 针对OS层面,自行脚本资源配置

fd使用量:

单个进程,超过"ulimit -n"最大限定值的90%,则短信邮件告警机器负责人;

内存使用量:

单个进程,物理内存使用量超过 /bin/free | grep Mem | awk '{print $2}' 的90%,则短信邮件告警机器负责人;

swap使用量:

一台设备,若swap使用率超过1/2,则短信邮件告警机器负责人;

共享内存使用量:

一台设备,若共享内存个数使用超过/usr/bin/ipcs -m -l | grep "number of segments"最大限定的90%,则短信邮件告警机器负责人;

信号量使用量:

一台设备,若信号量使用超过/usr/bin/ipcs -s -l | grep "number of arrays"最大限定的90%,则短信邮件告警机器负责人;

消息队列使用量:

一台设备,若消息队列使用超过/usr/bin/ipcs -q -l | grep "max queues system"最大限定的90%,则短信邮件告警机器负责人;

消息队列未处理量:

一个消息队列,若未处理消息数>50个,则短信邮件告警机器负责人;

tcp连接数数(close_wait状态)

一台机器tcp连接数(close_wait状态)数量超过ulimit -n的最大限定值的60%,则短信邮件告警机器负责人;

采集容量数据,按天计算容量百分比,并预警已经取于高负载的模块和设备(满足场景二,预警时间1天)

  1. 容量采集数据以及方式: 硬件相关的基础资源:均可通过网管后台获取采样值。 关键指标:CPU使用率、CPU负载、外网入流量,外网出流量、应用内存使用率、磁盘利用率 OS相关的基础资源:设备从本机作为特性上报到公司网管,容量从网管后台取得采样值; 关键指标:FD、TCP连接数、mysql连接数 业务特性:设备从本机作为特性上报到公司网管,容量从网管后台取得采样值; 关键指标:请求量数、平均时耗、占用计算资源、失败率
  2. 计算每日负载值:
  1. 输出物:

设备负载日报(高负载管理、低负载管理)

业务模块负载日报

针对离线系统,主要采用以下方式要求:

离线任务执行时耗超过最大值,直接告警(满足场景五、告警时间2分钟;预警时间1天);

采用service收集离线任务开始时间、结束时间、执行时间标准;

采用公共工具部署在每台服务器上,各自任务自行上报开始时间点,结束时间点。

四.结束语

本方案仅仅涉及到“容量问题告警、预警”的内容,部门在这一块才刚刚起步,特别是问题出现之后的"定位、处理"还没有定论和统一解决方案,另外,容量管理系统的client端非常多,如何简单有效的管理这些client端也是个挑战。还希望大家能够有好的想法、建议,可以和hairy这边交流,让容量管理在“减少故障发生、降低故障影响”等方面发挥大作用。

相关推荐

精细化容量管理的设备成本优化之路

如何依托腾讯云完成海量数据的存储和备份

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

谢海林的专栏

1 篇文章2 人订阅

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏SDNLAB

DevOps部门正转向公有云

因获取IT基础设施来进行应用试验,DevOps 部门和IT部门的冲突正越来越大。开发者们不再等待内部IT部门为应用程序开发提供IT基础架构,而是开始通过公共云服...

3719
来自专栏SDNLAB

NFV,DevOps,云沙盒(一):机遇与挑战

当今的应用市场,电信、移动和有线电视运营商的用户需要更快速、更敏捷的现有服务,来更快的为市场带来高质量的新功能。 ? 这一切都是随着日益复杂的自动化和私有云计...

3416
来自专栏程序人生 阅读快乐

Docker进阶与实战(容器技术系列)

本书由一个真正钻研容器技术的团队写作,他们不仅仅是在使用Docker,更多的是在探索容器的未来之路,希望把“代码与产品,理论与实践”完美结合。本书内容从Dock...

721
来自专栏非著名程序员

送库了,炫酷的多重水波纹效果,你值得拥有

作者:自去年第一次发布开源库 SmartRefreshLayout 以来,深刻的感受到了开源的乐趣。 所以打算以后开发过程中把一些自己实现的实用开源库也开源出来...

632
来自专栏BestSDK

设计师必备十个“聚宝盆”,让你做梦都能笑醒

1. Designrfix 如果你是一个网页设计师, 这个blog你必须收入到书签里,Designrfix不仅每天都有最新的设计资讯和文章,还能在此发掘出新的方...

2705
来自专栏云计算

企业微服务架构转型-实施步骤

在前面的文章中已经谈到过微服务架构转型中的实施策略,今天重点谈下微服务架构转型中的实施步骤。 步骤1:4A和流程平台的下沉和能力开放 在实施微服务架构转型的时候...

2007
来自专栏CSDN技术头条

SOA架构设计经验分享—架构、职责、数据一致性

1. 背景介绍 最近一段时间都在做系统分析和设计工作,面对的业务是典型的重量级企业应用方向。突然发现很多以往觉得很简单的问题变得没有想象的那么容易,最大的问题就...

1848
来自专栏魏艾斯博客www.vpsss.net

Linode 5 美元新方案 1G 内存/1CPU/20G SSD

1133
来自专栏ytkah

公众号文章新增语音功能 让声音拉近粉丝的距离

  罗胖的公众号比较独特,每天发一条语音,吸引了一大批粉丝。也许我们没有很多题材每天一段补脑语音,但我们可以在图文消息中添加一小段语音问候,拉近和关注用户的距离...

3076
来自专栏逸鹏说道

80.8亿个微信红包技术难点在哪里?

摘要:今年除夕当日微信红包的参与人数达到4.2亿人,收发总量达80.8亿个,是羊年除夕10.1亿个的8倍。最高峰发生在00:06:09,每秒钟收发40.9万个红...

40818

扫码关注云+社区