一、综述

中间件故障，可以分为以下几个方面：

1、网络环境问题；

2、服务器资源问题（CPU、内存、磁盘）；

3、中间件运行过程中，遇到自身偶然的bug。

中间件故障，很多时候是由于 网络或者服务器资源问题 导致，所以首先要监控好网络和服务器。

中间件一般自身都没有自我监控的机制，但是都会有日志记录，可以通过 日志 和 调用方 来监控中间件是否正常。

综上分析，中间件监控，可以从以下几个方面入手：

1、通过日志监控中间件的状态。

2、通过调用方监控中间件的状态。

3、监控并记录网络和服务器状态【这是1和2的重要辅助手段】。

二、通过日志监控中间件的状态

方案一：

将中间件的日志，收集到es中。

在我们的告警平台中准实时地去查询与分析中间件日志，一旦发现异常，符合自定义规则，就触发告警。

方案二：

将中间件的日志，收集到kafka中。

在我们的告警平台中订阅消费中间件日志，根据自定义规则，实时过滤筛选，一旦发现异常，就触发告警。

三、通过调用方监控中间件的状态

在某个 真实或者测试 应用中，植入对中间件的监控，（这个应用要连续的对中间件进行正常请求），一旦调用中间件失败，就触发告警。

举个例子，如何判断kafka是正常的，只需要启动一个客户端应用，去不停地生产和消费数据，一旦发现不能生产或者消费了，就触发告警。八九不离十都能反映中间件的真实情况，哪怕是中间件僵死，或者网络断开。

关于在应用中植入对中间件的监控，具体的做法中，有一个技巧，不需要应用去改代码，只需要对客户端进行二次封装，加上监控的逻辑，如果客户端报错，就往监控中心发送告警信息。

四、监控并记录网络和服务器状态

有了前面的两种监控还不够，因为不能够确定导致中间件不可用或者故障的原因。这个时候，就要配合监控和记录网络和服务器的状态。

比如，在某个时间点，中间件故障了，查看网络波动记录，发现恰好这个时间点，网络出了问题，就知道了是因为网络导致的中间件故障。

还比如，从某个时间起，中间件不能用了，从日志也看不出来异常，这个时候如果对服务器有监控，就能及时发现是磁盘或者CPU导致的问题。

1、关于配置中心Apollo

Apollo挂掉，不会影响已拉取到配置的应用，只会造成挂掉后无法再新增和更新配置。所以说，不用考虑apollo挂掉的情况，发现apollo挂掉后，重启一下就OK。

  在UAT、预发布和生产环境运行这么久了，apollo一直都很稳定，唯一出现的问题就是 log日志量较多，预发布磁盘空间只有10G，运行一段时间后就要去清一下日志。

2、关于文件存储服务fastdfs

鉴于fastdfs还是比较稳定的，看了日志，几个月来很少出现故障，只需要实时监控日志，根据配置的策略触发告警。

另外，如果觉得还不够，可以对客户端进行二次封装，植入监控的逻辑，一旦客户端报错，就往监控中心发送告警信息。