构建一个比较完善的监控系统

本文涉及的产品
云原生内存数据库 Tair,内存型 2GB
云数据库 Redis 版,标准版 2GB
推荐场景:
搭建游戏排行榜
简介:
在工作中或多或少接触过部分监控工具的构建,开发和完善。结合自己的一些看法,简单地谈下一个完整的监控系统所包含的组件,欢迎大家补充。

从监控的层面来看,一个比较完整的监控系统应该包含如下的层次:

1.网络层面
主要包含各个机房间网络状况,机房内机器网络状况,通过开源的工具smokeping可以做到

2.主机层面
对于网络设备来说,包括cpu,内存,端口速率,流量等

对于服务器来说,从硬件到系统层面都要进行完善的监控,底层的比如raid卡状态,磁盘容量使用状态,inode使用状况,是否只读,是否有坏道,内存使用,网卡是否百M,网卡流量等。
再上面比如负载,cpu使用,磁盘io,操作系统参数,文件描述符,网络连接数,队列,系统日志等等,现在用的比较多的工具是zabbix,nagios和cacti。

3.应用层面可用性监控
包括进程的状态,端口的状况,存活的检查等,比如监控nginx,需要监控nginx的端口状态,进程是否存活,监控dns,需要监控端口,进程,还可以监控记录是否正常解析。
这些可以简单地通过zabbix实现。

4.应用层面性能监控
在应用层仅仅做可用性的监控是不够的,还要对应用的性能做监控,这就需要用户对应用的性能影响点有深入的了解。比如监控redis,需要监控redis的cpu使用情况,cache的效率等。
监控tomcat这种jvm容器,需要监控java heap,gc,java thread等相关信息。这类监控数据也可以集成搭配zabbix里面来做

5.服务的可用性
简单地来说就是业务正不正常,这个可以在业务上线的时候统一提供一个监控url来做检测,判断url的返回码或者是内容来判断服务是否正常。提供的检测url要做一些可用性方面的简单地判
断,比如如果应用用到了redis就要去操作一下redis。这一层的监控可以通过自己开发一个小的监控程序来实现(目前我们是通过pycurl+nagios+django+bootstrap来做的)。

6.服务的qos监控
服务的可用性监控有了,服务的质量状况也需要监控。
这个又包括服务器端的和面向用户的。
1)服务器端的数据一般是通过分析访问日志来实现,比如域名的nginx的响应时间分布,平均响应时间,服务的状态(2xx,3xx,4xx,5xx占的比例),平均body size大小状况,各个pool的调用状
况,具体到省市的qos等等。
服务器端的数据也分为实时的和离线的,实时的可以借助flume+hadoop+impala或者storm的流式计算框架来实现(各个域名的nginx日志),离线的数据可以通过hadoop + hive来实现(商业 cdn qos数据)

2)面向用户的数据是通过在页面埋点来实现的,通过在页面中埋入js代码,可以在用户访问页面时,将所需要的数据通过url的形式记录在访问日志上,然后交由后端处理。


通过分析服务器端的和面向用户的qos数据相结合,可以很清楚的了解到网站的qos状况。

7.安全方面的监控
又包括主机层和服务层,比如webshell检测,主机入侵检测,后门检测,文件校验等等。

8.最后就是业务上的监控了,这个没怎么接触过,就不写了

监控的数据有了之后就是报警的问题了,这里我们倾向于:

1.通过一个中心化的事件处理平台来处理报警信息,集成cmdb的信息,把报警信息分组,定义级别并发送至相关责任人处理

2.报警邮件要包含足够多的信息,比如具体到一个域名的http code不正常,需要在报警邮件中有breakdown到http code,server,url等的相关信息,这样,报警处理人就可以快速的定位到问题。

最后附一个之前画的一个基于zabbix的一个监控的流程图:
1)用户提交监控配置和脚本至puppet server,并关联cmdb的业务和puppet的module,由puppet 实现zabbix agent的部署,更新,reload。
2)用户通过zabbix api一键式添加模板,服务器根据主机名,运行应用自动link到对应的模板,主机组等。
3)使用zabbix的server-proxy结构,zabbix agent使用passive的模式,proxy使用active的模式,由proxy负责收集数据,sync到server。
4)server的db做ms高可用,并将slave中zabbix的历史数据(history*表,trends表)通过sqoop导入hadoop集群,load至hive中归档。
5)用户可以基于hive中的历史数据做性能分析和容量规划报表。
6)zabbix server负责报警产生,并通过消息机制发送至事件处理中心,事件处理中心关联cmdb,发送至对应业务的对应负责人。

spacer.gif 174507765.png


本文转自菜菜光 51CTO博客,原文链接:http://blog.51cto.com/caiguangguang/1344826,如需转载请自行联系原作者

相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore     ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
2天前
|
Prometheus 监控 数据可视化
Grafana 插件生态系统:扩展你的监控能力
【8月更文第29天】Grafana 是一个流行的开源平台,用于创建和共享统计数据的仪表板和可视化。除了内置的支持,Grafana 还有一个强大的插件生态系统,允许用户通过安装插件来扩展其功能。本文将介绍一些 Grafana 社区提供的插件,并探讨它们如何增强仪表盘的功能性。
8 1
|
6天前
|
Prometheus 监控 Cloud Native
【揭秘可观测性】构建完美参考框架,打造系统监控的瑞士军刀!
【8月更文挑战第25天】在现代软件设计中,可观测性是确保系统稳定性和效率的关键因素。它主要由日志、指标及链路追踪(统称LMx)三大核心组件构成。本文详细介绍了构建高效可观测性框架的六个步骤:需求分析、工具选择、数据收集策略设计、实施集成、数据可视化及持续优化。并通过一个Spring Boot应用集成Prometheus和Micrometer收集指标的示例,展示了具体实践方法。合理构建可观测性框架能显著提升团队对软件系统的管理和监控能力,进而增强系统整体性能和可靠性。
22 2
|
11天前
|
存储 监控 Devops
|
15天前
|
存储 运维 监控
监控与日志管理:保障系统稳定运行与高效运维的基石
【8月更文挑战第16天】监控与日志管理是保障系统稳定运行和高效运维的基石。它们不仅能够帮助企业及时发现并解决问题,还能够为性能调优、资源优化和业务决策提供有力支持。因此,在构建系统架构时,企业应高度重视监控与日志管理的规划和实施,确保它们能够充分发挥作用,为企业的发展保驾护航。同时,随着技术的不断进步和应用场景的不断拓展,监控与日志管理也将持续演进和创新,为企业带来更多的价值和便利。
|
16天前
|
监控 Java 测试技术
分布式链路监控系统问题之Skywalking和Eagleeye在数据收集方面的问题如何解决
分布式链路监控系统问题之Skywalking和Eagleeye在数据收集方面的问题如何解决
|
16天前
|
监控 Java API
分布式链路监控系统问题之Skywalking中的witness工作的问题如何解决
分布式链路监控系统问题之Skywalking中的witness工作的问题如何解决
|
3月前
|
存储 Prometheus 运维
Prometheus监控系统中常见技术问题处理指南
本文档是Prometheus使用指南,主要针对用户在使用过程中可能遇到的技术问题提供解决方案。
100 2
|
4月前
|
XML Prometheus 运维
自动化监控有哪些开源系统
自动化监控有哪些开源系统
103 1
|
监控 Dubbo 关系型数据库
基于SkyWalking的分布式跟踪系统 - 微服务监控
基于SkyWalking的分布式跟踪系统 - 微服务监控
171 1
|
存储 监控 NoSQL
【微服务】分布式如何利用Skywalking实现链路追踪与监控?
微服务下的分布式如何实现链路追踪和监控。
926 1
【微服务】分布式如何利用Skywalking实现链路追踪与监控?
下一篇
云函数