业务层面的监控与故障发现分析及解决思路！

　　或许站在业务的角度来说，很多业务都是等到用户找客服反应的时候才发现有故障，那么当出现这个情况的时候或许已经使业务出现故障影响了很多客户。如果说问题到了这个地步，我相信各位运维在处理起来也会很仓促，导致压力巨大。

　　那么我认为作为运维工程师要做的应该是比用户早的发现故障，或者说是还没有出现故障，只是到达了一个风险点的时候就做到提前处理故障。所以故障的提前发现以及处理是非常有必要的，那么在环境中对于故障的发现这个操作最重要的方式就是监控了。

 　　大部分的故障原因其实就是性能达到了无法处理的程度。只要关注各类服务的性能指标变化，就可以提前发现故障的趋势。那么我将我在上家公司做的zabbix监控项做一个总结。或许可以做到提前发现故障的操作！

　　　　1.业务的页面完整性，如果说用户访问业务是出现大量的404状态码，那么在这个时候是否是自身的页面丢失呢？所以可以设定业务日志404状态码的数值来做到监控业务的页面完整，这个值具体要看业务的体量。（我当初设定的值为100）。

　　　　2.PHP业务的状态信息：监控PHP-FPM的状态（status）页面，查看当前正在处理的请求等。记录到监控系统，设定好阈值（根据服务器是性能），镜像告警。

　　　　3.吞吐量：通过访问日志可以得到RPM,对突发请求量提前接入观察。

　　　　4.进程存活和端口：监控进程是否存活，如监控php的端口是否存活！

　　　　5.tcp的SYN_RCVD状态：这个根据需求来定，一般监控这个值的原因是体现发现dos攻击，即使做到防火墙拦截。关于用SYN_RCVD状态监控dos攻击的说明可以看这篇文章：

https://www.cnblogs.com/lgdyes/articles/17525650.html

　　　　6.MySQL的监控：因为某些业务的性能比较以来后端数据库的性能（如php），所以后端也要加强监控，当然mysql可监控的项目是非常多的，如写入数量，读取数量等，具体更具自身业务的平均pv或者并发与dba做沟通后监控。可用show status命令查看mysql的一些可监控项。

　　　　7.要求合适的报警机制：根据你所制定的阈值，通过比较可靠的渠道推送给运维部门，如钉钉，邮箱等。

　　那么上方的这些内容一般是我在公司上线业务时就会做好的一些监控项，但是肯定是包括但不限于的关系了，那么具体的监控项要更具公司自身业务的情况来做，并不是所有的业务都需要这样去设置，很简单的例子，如果你的业务时tomcat业务呢，你还需要监控上方php的状态信息嘛?所以说，监控项的设定要具体到自己对业务的了解，以及对各类linux组件的性能了解。

  此文章只是对于业务层面的一些监控，当然正常的监控也应该监控到一些硬件的性能如：系统进程消耗CPU的时间百分比，CPU处于空闲状态的百分比等。