图片-稻子网
图片-稻子网
图片-稻子网
图片-稻子网

服务器端口监控软件-0到1000+服务器监控的搭建之路

精硕科技是中国领先的独立第三方营销大数据解决方案提供商,也是目前国内独立的第三方DMP(大数据管理平台)平台。目前已为快消品、IT、汽车等行业80%的世界百强品牌及众多国内知名品牌提供数据服务。杜蕾斯、宝洁、卡夫、雅诗兰黛、可口可乐、伊利、联合利华、麦当劳、微软、东风日产等知名品牌都在使用景硕科技的数据服务。

云智慧很荣幸邀请精硕科技运维总监顾凯先生为您带来《从几台到几千台的运维经验》精彩分享:

加入公司已经五年多,公司经历了从几十台服务器快速增长到几千台服务器的过程。目前数据量日增长超过5T,日请求数超过100亿,日计算量超过1000亿条记录。每日计算任务数超过10万,千亿条记录秒级查询,100万级QPS。

多年来,以稳定运行为前提,确保业务永不中断,带领运维团队自主研发运维系统,包括资产管理、工单管理、监控系统、域名管理、公有云管理、私有云管理等平台,分析整理运维数据,使运维工作透明化、可视化。

本次主要介绍监控系统在运维过程中从数十台服务器到数千台服务器的过渡体验。常言道,千人心中有一千个哈姆雷特,千人运维心中有一千种运维方法。没有一种方法是万能的,适用于所有场景。五年的经历大致可以分为三个阶段:

第一阶段:200台以下

第二阶段:200~1000台

第三阶段:1000+(1000多和2000多没有区别)

每个阶段的分界点不是那么精确,是一个粗略的时期,变化是一个渐进的过程。

一、 机器数小于200的阶段

这段时间的需求很简单,主要用于通知问题,快速定位和解决问题。总结起来,主要要求有三点:

1. 简单易用;

2. 稳定运行;

3. 可以报警、发邮件、发短信。

基于以上需求,可以使用比较流行的开源监控软件,Cacti, , 等。流行的开源产品文档比较多,可以快速上手,并且有很多以前的使用经验,可以避免问题很多,即使遇到问题也很容易找到解决方案。其中,邮件报警一般都支持,短信需要接入短信平台。

我们在早期选择了 Cacti。选择主要是出于个人原因。我最熟悉使用 Cacti 是因为监控开关非常方便,这几乎是愚蠢的。其实现阶段,无论是哪种监控产品,都基本可以满足需求。选择的因素取决于个人喜好。在此期间,运维同学可以偶尔任性。

二、机器数量从200到1000的阶段

在此期间,需求开始变得复杂,但主要用于通知和警报,以避免再次发生相同的问题。在此期间服务器端口监控软件,我主要做了以下工作:

图片[1]-服务器端口监控软件-0到1000+服务器监控的搭建之路-稻子网

1. 统一监控内容:统一基础监控。默认情况下,每台机器包括CPU、内存、磁盘空间等基本信息监控;

2. 覆盖监控:所有机器都纳入监控,除了基础监控,最重要的是业务监控,尽可能覆盖业务流程,通过自定义监控减少和消除重复问题,保证业务稳定运行.

3.及时通知,确保不漏报:对所有监控进行分类,根据重要程度、紧急程度等,采用邮件、微信、短信、电话等不同方式,确保每一个监控由某人处理。并且对于重要的业务,采用给你打电话的方式,不处理会一直通知你。

这期间进行了深入研究,编写了自定义脚本,增加了各种监控项,充分利用了nrpe、nsca等大部分插件和函数。

随着机器越来越多,需要监控的服务也越来越多,报警信息爆炸式增长,每天收到上千封报警邮件。有一个小插曲。我应该是第一个炸毁腾讯企业邮箱的人。不是容量爆了,而是邮件数量超过了他们数据库的最大值,导致我一周内无法收发邮件,也没办法删除。

这个阶段后期,也就是机器数接近1000台的时候,监控功能已经不能满足需求,图形功能老是捉襟见肘,于是开始思考1000台以上的情况机器。前面有两条路:

1. 根据自己的需要继续深入开发;

2. 自建监控。

这时候有的朋友会想:换个开源监控就可以解决了。使用开源软件最大的问题是你可以在这个软件中使用哪些功能。如果您没有功能,您可以自己开发或放弃使用它们。大量的报警只是改变的一个转折点。合适的开源监控产品已经不能完全满足庞大而复杂的需求。

经过长时间的慎重考虑,我决定自己搭建一个监控系统。其实也是因为之前深入了解过的整体架构和运营模式,觉得自己建一个也不是不可能。

三、机器数超过1000台的阶段

经过前期的思考和准备,在这个阶段,我开始开发自己的监控系统,解决痛点,完成需求。有几件事:

1.拥有当前使用的所有功能:照旧,覆盖原有功能,优化改进,替换后升级。(第一步最重要,如果之前的功能无法替代,自建之路只能到此为止。)

2. 整理告警,简化复杂度,减少重复告警:当发生轰炸告警信息时,如果不及时整理,必然会耽误真正需要处理的事情,而且对于一些原因,如线路出现问题,会反复报警,所以必须对报警信息进行处理后再下发。警告信息从之前的每天3000+下降到现在的每天不到300。

3.报警和显示分离:以前的监控系统基本具有相同的报警功能和显示功能。来自不同机房的信息也需要在中心节点进行汇总展示和告警。重要告警的处理是分秒必争,与界面显示无关,所以我在设计时将显示和告警功能分离了一次,在本地机房告警,然后集中显示.

4.分布式部署避免单点:每个机房设置一个子节点,也就是上面提到的报警节点,每个机房先设置一个中心节点报警,然后汇总并显示在中心。子节点和中心节点通过智能DNS相互备份和切换。如果中心节点宕机,DNS会自动切换到子中心节点,子节点会升级为中心节点。

图片[2]-服务器端口监控软件-0到1000+服务器监控的搭建之路-稻子网

分布式节点切换示意图

总结

自建监控系统的好处是可以充分利用数据,结合数据,分析数据,解读数据,把晦涩难懂的数据解读成人人都能看懂的数据,让产品人员、销售人员、老板都能看懂了解当前的业务状况。如何。最后给大家展示一下我们自建监控系统分析后显示的两个数据:

这张图展示了全国各省对Track系统的访问情况,不仅包括速度、访问的数据中心,还包括是否存在域名劫持等信息。当然,你自己的监控节点是无法得到这么多监控数据的。这时候就需要云智能的“监控宝”来帮忙了。我们使用监控宝在全国的200多个节点通过API返回检测数据。上传,然后整理分析,上图反馈。交换机的流量之前用的是Cacti。在有更多的开关之后,找到它是一项艰巨的任务。针对这种需求的痛点,我们的监控系统支持开关监控。除了基本的 CPU 等信息外,我们在流量上花费了一些时间。想法。

图片[3]-服务器端口监控软件-0到1000+服务器监控的搭建之路-稻子网

通过上图,可以一目了然地看到当前交换机之间的速度,流量来自哪里,有多少流量。

图片[4]-服务器端口监控软件-0到1000+服务器监控的搭建之路-稻子网

在这张图中,可以看到哪些地方的流量已经达到了警戒值,哪些交换机出现了问题,为快速定位和处理提供了极大的便利。

最后,每个公司的需求不同,每个运维面临的痛点也不同。不管有多少变化,所有的变化都是一样的。配合机器上的各种监控数据,你可以结合分析你想要的结果,在自建的路上,我们才刚刚起步,坚持!谢谢你们!

质量检查部分

问:这个底层还在吗?

A:不是,都是从零开始写的,借鉴了思路,但是收集和汇总处理的方法不一样。

问:数据库是否被监控?还是分配给专门的dba?

A:我们没有单独监控数据库,或者调用别人的监控脚本,然后获取数据。

Q:您在业务监控方面做了哪些工作?

A:我们也有一些业务监控,我发图片给你:

图片[5]-服务器端口监控软件-0到1000+服务器监控的搭建之路-稻子网

图片[6]-服务器端口监控软件-0到1000+服务器监控的搭建之路-稻子网

这是我们的业务监控。我们用文字描述所有的监控数据,让产品、业务同学和老板知道现在的情况。

Q:对于这么大量的数据采集,数据库端有什么特别的优化吗?异步处理?

答:是异步的。这个业务系统显示在大屏幕上。出现问题时,不用于研发和运维。您可以直接看到问题出在哪里,并知道该向谁询问恢复情况。.

A:好在我们在数据的集中展示和处理上遇到了一些瓶颈,我们也在不断的优化。

Q:智能DNS系统是自己开发的吗?

答:我们使用第三方智能 DNS,以及我们自己的。

问:您的数据库是 MySQL 集群吗?

A:MySQL的主从分离告警和显示还有一个原因,就是担心性能问题。显示可以延迟几秒或几分钟,但报警不能,所以报警是即时的服务器端口监控软件,不用担心监控机挂了会失明。我们目前在全国有6个节点,全部死掉的概率很小。只要一个人还活着,我们就可以报警。

问:这是以秒为单位的精确值吗?

A:二级,最慢的通知是一个电话,需要十多秒。

Q:现在只使用监控宝物吗?X光宝物在用吗?

- 答:X射线宝藏正在研究中。

问:交换机获得哪些指标?

A:CPU、内存、警告信息、流量、端口。

Q:阿里云服务器的性能是不是比自己的托管服务器差很多?

图片[7]-服务器端口监控软件-0到1000+服务器监控的搭建之路-稻子网

A:目前公司使用的阿里云自建数据库存在严重的性能问题。云服务的IO普遍存在问题,阿里巴巴最为严重。

问:业务监控如何工作?

A:业务监控其实和 类似,但是没有那么细粒度。

问:

答:如果不在程序中埋点,是通过监控数据来实现的,所以只能做到现象级,不能做到代码级。

Q:有监控日志吗?还是CPU?

答:不再是 CPU。对于程序是否正常运行的一些综合判断,业务监控中看到的一项可能对应十几个监控,还有一些逻辑判断,主要是把人工分析模式改成自动的。这与公司的业务有关。有的是API,有的是程序,不同的业务不同,响应速度也不同。

问:

A:算上我,一共有8个人。这张图片是我们开发的平台。

图片[8]-服务器端口监控软件-0到1000+服务器监控的搭建之路-稻子网

Q:运维的日常工作是如何划分产品的?

A:前期,第二阶段自动化完成后,基本是可选的,通过工单系统完成。常规工单审批完成后自动上线,无需运维参与。

A:早期用的是基于kvm的开发,后来发现太重了。对私有云的简单理解就是 kvm 自动化。

Q:你们的物理机配置是怎样的?

A:最低配置也是双6核,64G。

A:运维可视化的另一个原因是别人不了解运维或者运维在做什么,经常被误解为安装系统和执行脚本。可视化就是展示大家关注的东西,用运维数据教育大家。工单是所有运维操作的起点,也是避免来回走动的工具。工单系统其实是我最用心设计的系统。订单流程,尤其是审批。遇到滥用工单会让你发疯。

图片[9]-服务器端口监控软件-0到1000+服务器监控的搭建之路-稻子网

问:

答:你可能需要X光宝。

Q: 可以监控网络出口带宽的拥塞情况吗?

A:X光宝主要用于应用性能监测。X射线宝就像应用系统的CT扫描仪,可以采集用户在移动终端和浏览器上的实际体验性能数据、服务器上运行的应用环境、数据库访问、应用代码,然后利用大数据技术进行快速诊断和分析收集到的数据,找出影响应用性能的“病变”,给出诊断建议。网络链路的监控由监控宝完成。实现从客户端到服务端的全链路服务监控和问题诊断。

Q:突然失败是什么意思,前端代理报错了吗?需要时下车?

答:比如某个功能正常工作,但是突然点击没有任何反应,代码没有报错,过一段时间又恢复了,日志正常,但是没有什么原因,但是CPU和内存正常,没有网络流量。波动较大,连接数也在正常范围内。

Q:您有没有遇到过因内网问题导致的业务失败?

A:X光宝应该可以帮到你,X光宝很详细。透视宝可以解决内部问题,监控宝可以解决外部问题,结合起来就ok了。可以检查交换机是否有SFP网络振荡。我遇到过这种情况。

问:什么是 sfp 网络抖动?如果有网络问题,那么其他一切都应该受到影响,对吧?

A:网络震荡是指交换机重新学习mac地址,导致短时间内网络故障。

A:专业的解释是由于报文变化或者定时器超时,反复触发重新计算,根桥选择、端口角色切换、端口状态转换三个过程会继续进行。常见的原因有:

链路故障:网络上某个端口的链路属性,如端口状态、速度、双工模式等不断变化;

节点故障:单台交换机CPU高,无法在固定间隔内发送或处理STP报文;

网络故障:网络拥塞,导致根端口方向的STP报文在转发过程中被丢弃;L2PT透传其他网络的STP报文,导致本端STP收敛不正确;网络组播抑制功能配置错误,偶尔会丢弃STP报文。针对不同的故障原因,需要修改配置或优化网络设计来解决震荡问题。

简单来说就是如果某个模块或者网线出现问题,导致频繁上下线,就会出现网络震荡。

Q:遇到这种问题会不会报警?特点是网络短时间不可用?顾总花了多长时间才发现?

A:如果单独看开关,会被认为是误报。结合业务发现,事实并非如此。我们大数据集群在成长过程中遇到的问题,就看你怎么设置阈值了,套路是不会报的。我对此做了专门的监控,但是找不到端口,交换机的常规日志中也没有。有一条特殊的日志记录,但是记不住了(可以加一下吗?)

问:端口双工和速率变化如何?切换日志还没收集?

© 版权声明
THE END
喜欢就支持一下吧
点赞0 分享
评论 抢沙发
头像
欢迎您留下宝贵的见解!
提交
头像

昵称

取消
昵称表情代码图片