容量管理系统设计方案

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

一.主要问题场景：

实时系统：

能提供服务，但是速度较慢；

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

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

离线系统：

随着业务的发展，在约定时间内逐渐无法完成任务（例如：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. 计算每日负载值：

[image.png]

1. 输出物：

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

业务模块负载日报

针对离线系统，主要采用以下方式要求：

离线任务执行时耗超过最大值，直接告警（满足场景五、告警时间2分钟；预警时间1天）；

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

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

四.结束语

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

相关推荐

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

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