容量管理系统设计方案

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

一.主要问题场景:

实时系统:

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

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

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

离线系统:

随着业务的发展,在约定时间内逐渐无法完成任务(例如: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 条评论
登录 后参与评论

相关文章

来自专栏数据的力量

【答疑解惑】做大数据过程中遇到的13个问题

1594
来自专栏QQ会员技术团队的专栏

大规模排行榜系统实践及挑战

在过去的一年中,排行榜系统从无到有,接入的业务从单一的QQ会员到企鹅电竞动漫等20几个各类业务,接入的排行榜数实现了从几个到数万的突破,单个排行榜用户数最大90...

3.6K1
来自专栏数据和云

微博MySQL优化之路 - 肖鹏

肖鹏老师对于开源数据库尤其是MySQL的研究特别深入,今天我们来一起听他分享自己对MySQL数据库的优化经验! 作者简介 ? 肖鹏 微博研发中心数据库技术负责人...

3537

云本机应用程序成熟度的模型

云本地应用程序是为了能在云基础架构上最佳地运行而构建的。云本地应用程序体系结构与为数据中心设计的传统分层应用程序非常不同。在本文中,我将讨论来自开放数据中心联盟...

2187
来自专栏IT大咖说

一线工程师宝贵经验:架构的深入思考 From FunData

内容来源:之前作者写了一篇《FunData — 电竞大数据系统架构演进》的文章,传送门:http://t.cn/RdgKWGW 觉得没有深入写出一些深层次的东西...

1033
来自专栏Java架构

千万级调用量微服务架构实践

电商是促销拉动式的场景,也是价格战驱动的场景。618和双11都是典型的促销活动。其实都是在抢用户、扩市场占有率。在这样的场景之下,对秒杀、抢购是很热衷的玩法。

1615
来自专栏木子墨的前端日常

微信分享到好友及朋友圈配置内容失效问题排查与解决方案

冷静一下,我们再来复述一下这个问题,代码线上发布后,发现微信分享的配置在部分渠道,即微信好友和朋友圈分享异常,配置的标题描述图片都没有生效,但分享到qq、QQ空...

1943
来自专栏云计算D1net

公有云提供商挑选准则

当涉及到选择一个公有云供应商时,成本常常是第一个考虑的因素。但其他的因素,例如虚拟机迁移,存储和自动扩展等,也都应该考虑在内。 在企业转移到公有云或混合云时,不...

3647
来自专栏杨建荣的学习笔记

从“悲剧”的几个运维场景谈谈运维开发的痛点

我在这个事情上栽了很多的跟头,而且会发现事情变得越来越不可控。就好比我的期望是6,达到的结果是2,反差越大,发现改进的空间很大,以至于我会陷入一个死循环,我会想...

1092
来自专栏CSDN技术头条

浅析:如何构建稳定的系统

作者:Jesper L. Andersen 原文:How to build stable systems 译者:孙薇 准备工作 第一个决策是最简单却最为重要的...

2026

扫码关注云+社区