平台缺失针对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配置定期删除过期数据。