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

概要

为何要作监控

线上发布了服务，怎么知道它一切正常，好比发布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.5万条/秒)。

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

四、可根据broker配置按期删除过时数据。