零代码如何打造自己的实时监控预警系统

本文涉及的产品
Elasticsearch Serverless通用抵扣包,测试体验金 200元
日志服务 SLS,月写入数据量 50GB 1个月
简介:

概要

为什么要做监控

线上发布了服务,怎么知道它一切正常,比如发布5台服务器,如何直观了解是否有请求进来,访问一切正常。
当年有一次将线上的库配置到了Beta,这么低级的错误,排错花了一个通宵,十几个人。
某个核心服务挂了,导致大量报错,如何确定到底是哪里出了问题。
SOA带来的问题,调用XX服务出问题,很慢,是否可以衡量?

由于业务系统数量大,每天都会产生大量的系统日志和业务日志,单流式业务的一台服务器产生的日志达400M 想直接查看内容打开可能几分钟,而且内容之多根本无法查看,给开发和运维带来诸多不便,现业务都是分布式的,日志也是分布在每台服务器上,所以查看日志和统计更是效率低下。实时收集分布在不同节点或机器上的日志,供离线或在线查阅及分析来提升工作效率的需求异常迫切,在此背景下,特对公司统一日志平台进行初步架构设计。

在信息化时代,日志的价值是无穷的。为了对系统进行有效的监控、维护、优化、改进,都离不开对日志的收集和分析,接下来我们来看看秉着“短平快”的互联网精神,构建的这套适合现有业务系统的统一日志平台,总体分为业务日志监控平台和软硬件服务监控平台。

业务日志平台总体设计

以上是最终的一个最终的一个架构规划,统一日志监控系统负责将所有系统日志和业务日志集中,再通过flume或logstash上传到日志中心(kafka集群),然后供Storm、Spark及其它系统实时分析处理日志,或直接将日志持久化存储到HDFS供离线数据分析处理,或写入ElasticSearch提供数据查询,或直接发起异常报警或提供指标监控查询。

根据现有业务量来看,以上架构有点“重”,可以作为以后的目标,现阶段来说可以参考以下架构:

 

      以上内容皆以配置为主,对现有业务没有影响,针对于Windows环境可以用FileBeat监控本地日志全量、增量的上传日志,对于一些稳定的日志,比如系统日志或框架日志(如HAproxy访问日志、系统异常日志等),通过rsyslog写到本地目录local0,然后logstash根据其配置,会将local0中的增量日志上传到日志中心。Java环境下可以采用log4j直接发送到Logstash。

日志处理层

可以在Logstash中对日志作简单的分类加工处理再发送出去。

我们可以将日志聚合,根据业务不同,建立不同的索引,存入ElasticSearch提供查询。 发现异常日志时,发往监控中心,向对应的业务方发起报警,发现和预发问题的实时性提高了。统计一些访问日志或调用日志等指标信息,发往监控中心来掌握相关调用趋势。调用链开始做起来了,系统性能瓶颈一目了然了。

日志存储层

ElosticSearch中按照不同业务建索引主题(数据库),业务里面再按照需求建类型(表),不需要的历史数据可按需要持久化到HDFS,以减少ES的压力。

展示层Kibana

Kibana是ELK中的组件,是一个针对Elasticsearch的开源分析及可视化平台,用来搜索、查看交互存储在Elasticsearch索引中的数据。使用Kibana,可以通过各种图表进行高级数据分析及展示。

Kibana让海量数据更容易理解。它操作简单,基于浏览器的用户界面可以快速创建仪表板(dashboard)实时显示Elasticsearch查询动态。

Kibana可以非常方便地把来自Logstash、ES-Hadoop、Beats或第三方技术的数据整合到Elasticsearch,支持的第三方技术包括Apache Flume、Fluentd等。

监控ES的整体健康状态

直接查询ES索引内容

 

简单的查询过滤日志数据窗口

 

可实时的图形统计展示

 

 

采用ElastAlert实现日志监控告警

平台缺失针对mysql连接数的告警,指定业务如流式服务数据异常,当异常触发时能够及时通过短信、邮件等方式通知相关负责人员 

如故障信息:

 

以上说的“日志”不仅限于日志信息,也可以是业务数据。

软硬件服务监控平台设计

当业务层日志发现异常时如保存数据到Mysql时经常性报连接数据库超时,只有当业务人中发现再通知我们时已经过了一段时间才发现问题,但已无法重现当时的生产环境,也就靠经验来猜原因是服务器的网络问题还是数据库的真实连接满了还是程序的写法出现问题,因此就需要监控当时生产环境的软硬件监控数据。

经过多方咨询参考各大厂的监控方案和对比在此采用Zabbix作监控。

最近各服务整体问题一览

 

针对Web服务器和API的访问性能、HAproxy、IIS、Tomcat

 

实时绘图监控服务器所有TCP端口的数量和 MySql数据库连接数、Redis性能

 

自定义聚合展示服务器各指表最近的状态,CPU、内存、流量。

 

 

显示所有服务器的一个健康状况,一目了然

 

自动注册监控新的服务器

 

报警机制,Email、微信、短信等

 

其它特性

可监控Linux、Windows、打印机、文件系统、网卡设备、 SNMP OID、数据库等平台服务状态。

允许灵活地自定义问题阀值, Zabbix 中称为触发器(trigger), 存储在后端数据库中。

高级告警配置,可以自定义告警升级(escalation)、接收者及告警方式。

数据存储在数据库中  历史数据可配置 内置数据清理机制。

web 前端采用 php 访问无障碍。
Zabbix API 提供程序级别的访问接口,第三方程序可以很快接入。

灵活的权限系统。

结合以上业务和软硬件上的日志方便开发和运维实时查找问题提高解决问题的效率,而且前期均可只通过配置0代码就可实现监控和报表展示。

扩展性

可用Spark对数据实时分析,智能拦截异常数据和直接发送异常警报。

在Zabbix上结合自己的业务需求二次开发应用系统层面上的预警监控系统。

以后可加入Kafka将日志集中,至于为什么选用kafka集群来构建日志中心,理由主要如下:

1、分布式架构,可支持水平扩展。

2、高吞吐量,在普通的服务器上每秒钟也能处理几十万条消息(远高于我们的峰值1.5万条/秒)。

3、消息持久化,按topic分区存储,支持可重复消费。

4、可根据broker配置定期删除过期数据。

本文转自欢醉博客园博客,原文链接http://www.cnblogs.com/zhangs1986/p/7466992.html如需转载请自行联系原作者


欢醉

相关实践学习
以电商场景为例搭建AI语义搜索应用
本实验旨在通过阿里云Elasticsearch结合阿里云搜索开发工作台AI模型服务,构建一个高效、精准的语义搜索系统,模拟电商场景,深入理解AI搜索技术原理并掌握其实现过程。
ElasticSearch 最新快速入门教程
本课程由千锋教育提供。全文搜索的需求非常大。而开源的解决办法Elasricsearch(Elastic)就是一个非常好的工具。目前是全文搜索引擎的首选。本系列教程由浅入深讲解了在CentOS7系统下如何搭建ElasticSearch,如何使用Kibana实现各种方式的搜索并详细分析了搜索的原理,最后讲解了在Java应用中如何集成ElasticSearch并实现搜索。  
相关文章
|
11月前
|
存储 SQL 算法
跑批为什么这么难
业务系统产生的明细数据需经加工处理以支持企业经营,此过程称作“跑批”,常在夜间进行以免影响生产系统。跑批任务涉及大量数据及复杂计算,导致耗时较长。开源计算引擎SPL可直接基于文件系统计算,提供更优算法与存储机制,显著提升跑批效率。例如,L银行贷款协议跑批任务从2小时缩短至10分钟,性能提高12倍;P保险公司车险业务的历史保单关联任务从近2小时缩短至17分钟,速度提升近7倍;T银行贷款跑批任务提速204倍。
|
小程序 JavaScript 开发者
uniapp小程序订单页面UI
uniapp小程序订单页面UI
714 0
|
12月前
|
前端开发 JavaScript 中间件
七、Flask蓝图使用之七
七、Flask蓝图使用之七
262 0
|
前端开发 API Docker
web前端开发项目走proxy代理后端接口,构建发布到生产等环境后,如何修改api接口
web前端开发项目走proxy代理后端接口,构建发布到生产等环境后,如何修改api接口
210 0
|
XML 数据格式 SoC
深入理解AMBA总线(十)AHB Bus Matrix以及AHB的局限性
深入理解AMBA总线(十)AHB Bus Matrix以及AHB的局限性
1256 0
|
Linux 网络安全
suse 12 升级 OpenSSH-7.2p2 到 OpenSSH-8.4p1
suse 12 升级 OpenSSH-7.2p2 到 OpenSSH-8.4p1
407 0
|
JSON jenkins 测试技术
Python接口自动化测试框架(工具篇)-- 接口测试工具HTTPRUNNER
本文介绍了Python接口自动化测试框架HTTPRunner,包括其安装、使用方法,并通过实际操作演示了如何利用HTTPRunner进行接口测试,同时还探讨了HTTPRunner作为接口自动化测试解决方案的可能性和实用性。
322 0
|
Ubuntu Linux iOS开发
|
SQL 存储 Java
SQL游标的应用场景及使用方法
SQL游标的应用场景及使用方法
|
搜索推荐 测试技术 流计算
承上启下:基于全域漏斗分析的主搜深度统一粗排
文章首先介绍了淘宝搜索的多阶段检索系统,包括召回、粗排和精排阶段。粗排模型的目标是优化商品的排序,以提高在召回集合中选择优质商品的能力。文章提到,粗排模型与精排模型的目标有所不同,粗排更注重腰部商品的排序,而精排更注重头部商品的排序。 此外,文章还探讨了模型的损失函数形式,发现原始的softmax损失函数在处理多正样本时存在问题,提出了改进的损失函数,使得模型在粗排阶段的表现更佳。最后,作者们总结了优化工作的进展,以及优化样本对齐,以实现更好的整体效果。