谈谈Zabbix的容量规划

作为开源的企业级监控平台,Zabbix有着先天的优势:

1、长期由官方提供免费的技术支持服务(亦可购买收费的高级服务

2、完全开源(如有自主的技术力量,可扩展性非常强)

3、可实现全栈级监控(从底层硬件、网络、存储,到虚拟化层、操作系统、中间件,以及最上层的应用和API)

同样的,由于其是开源产品,同时Zabbix在中国的推广刚刚起步,实际部署中会遇到很多“坑”。

本文主要探讨Zabbix部署前的容量规划。


CPU

根据监控参数及选择的数据库引擎,Zabbix,特别是Zabbix数据库,可能需要大量的CPU资源,

内存和磁盘

Zabbix主要是基于Linux系统的软件,因此不需要占用过多的内存和磁盘。刚开始使用Zabbix,建议128MB物理内存和256MB可用磁盘空间。

然而, 具体需要的内存大小和磁盘空间要根据主机数量和监控参数而定。如果你计划对监控的参数进行长期保存,你应该考虑至少在数据库中预留几个GB的空间,以用来保留历史数据。 每个Zabbix的守护进程需要与数据库服务器建立多个连接。分配给连接的内存数量,取决于数据库引擎的配置。

当然,你使用的内存越多,你的数据库和Zabbix工作得越快!

数据库容量

Zabbix配置数据需要保留固定的磁盘空间,而且这个空间不会随着Zabbix系统的扩容不会增长太多。

Zabbix数据库容量主要依赖于下列这些参数,这些参数也决定了存储历史数据所需要的空间:

每秒处理值的数量(Number of processed values per second)

这个参数是指每秒种Zabbix server收到的新值数量的平均数。比如,如果我们有3000个监控项(item),监控周期是60s,经计算所得,每秒处理值的数量为3000/60 = 50.

这意味着每秒钟有50个新值写入Zabbix数据库。

历史(History)数据的回收清理设置(Housekeeper)

Zabbix会在一个固定周期内保存收到的值。正常情况下保留数周或者数月。每一个新收到的值会占用一定数量的磁盘空间以存放数据和索引。

所以,如果我们每秒钟收到50个值,且希望保留30天的历史数据,值的总数将大约在 (30*24*3600)* 50 = 129,600,000,即大约130M个值。

根据所使用的数据库引擎,以及收到值的类型【浮点(floats),整型(integers),字符串(strings),日志文件(log files)等】,单个值的磁盘使用量从40字节到数百个字节不等。一般而言,数值型(Numeric)的监控项占用大约90字节。 按之前的例子, 这意味着130M个值需要占用 130M * 90 bytes = 10.9GB 的磁盘空间。

文本(text)/日志(log)类型的监控项值的大小无法准确地预测,但你可以按每个值大约500字节来计算。

趋势(Trends)数据的回收清理设置(Housekeeper)

Zabbix为trends表中的每个监控项的值,保留一组数据:一个小时的最大值/最小值/平均值/数量。这些数据用于趋势图表和历史图表的展现。用户无法自定义这一小时的保留周期。

根据数据库的类型,Zabbix数据库需要为每组值总共占用约90字节的空间。 如果你需要保留趋势数据5年,那么3000个监控项值,每年需要 3000*24*365* 90 = 2.2GB 的空间 , 即5年需要 11GB 的空间。

事件(Events)数据的回收清理设置(Housekeeper)

每个Zabbix事件需要大约170字节的磁盘空间。很难估计Zabbix每天生成的事件数量。最糟糕的情况下,我们可能需要假设Zabbix每秒会生成一个事件。

这意味着,如果我们需要保留3年的事件,需要3*365*24*3600* 170 = 15GB的磁盘空间。

下表列出了用于计算Zabbix系统所需磁盘空间的计算公式:

范围 所需磁盘空间的计算公式 (单位:字节)

Zabbix配置文件 固定大小。一般10MB或更少。

历史(History) days*(items/refresh rate)*24*3600*bytes

items : 监控项数量

days : 保留历史数据的天数

refresh rate : 监控项平均轮询时间

bytes : 保留单个值所需要占用的字节数,依赖于数据库引擎,一般大约90字节。

趋势(Trends) days*(items/3600)*24*3600*bytes

items : 监控项数量

days : 保留趋势数据的天数

bytes : 保留单个趋势数据所需要占用的字节数,依赖于数据库引擎,一般大约90字节。

事件(Events) days*events*24*3600*bytes

events : 每秒事件数。最糟糕的情况下,每秒一(1)个事件。

days : 保留事件数据的天数

bytes : 保留单个事件所需要占用的字节数,依赖于数据库引擎,一般大约90字节。

根据现实环境中使用的MySQL后端数据库的统计,数值型(Numeric)监控项的值平均占用约90个字节,事件(Events)平均占用约170个字节。

因此,所需要的磁盘总空间按下列方法计算:

配置(Configuration) + 历史(History) + 趋势(Trends) + 事件(Events)

安装完Zabbix,磁盘空间不会立即被分配。数据库大小根据回收清理(housekeeper)设置,在某些时间点增长或停止增长。

根据上述公式,可计算出Zabbix需要使用的空间。同时,考虑到后续的扩容,建议预留至少20%的冗余量。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,723评论 6 481
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,485评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 152,998评论 0 344
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,323评论 1 279
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,355评论 5 374
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,079评论 1 285
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,389评论 3 400
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,019评论 0 259
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,519评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,971评论 2 325
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,100评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,738评论 4 324
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,293评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,289评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,517评论 1 262
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,547评论 2 354
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,834评论 2 345

推荐阅读更多精彩内容