把一切监控起来（转载）

  监控的重要性对于网站的运行来说至关重要，这点无需赘述，但是如何做，方法各异，这里分享下Kelude在监控方面的做法。

一、监控分类     

      首先要说明的是，我们以下讨论的都是系统运行过程中的监控。并不涉及开发过程。我们对系统运行过程中监控的对象做了以下分类：

• 用户行为：包括用户访问的URL，用户来源，用户在一个页面上点击的位置，使用的浏览器等等
• 应用错误、心跳、性能：应用是否存活、应用是否产生了500错误或者说是能捕获到的异常、页面响应时间是否在指定的范围内
• 机器硬件指标：包括CPU、Load、Mem，Disk
• 基础软件：主要检测提供服务的基础软件(mysql/nginx/tomcat等)是否正常运行
• 业务软件：这些软件都是为业务需要而开发的，比如Kelude中的调度系统。
• 数据库：测试通过某个账号是否能正常连接到数据库
• 业务事件：这些事件通常是和重要业务相关的，如果检测到哪个业务事件在指定时间没发生，我们便发出报警信息。

二、用户行为     

     针对用户行为，我们是通过日志分析和页面点击埋点进行的收集。awstats可以很方便地统计出nginx日志的信息，从这里便可以获取到用户的来源，页面ref，浏览器，访问的URL等信息。由于我们的域名都统一在了一个域名下，约定了所有的请求都走url，所以nginx的日志统计可以很精准地反应系统pv/uv甚至单个应用的指标数据。

     用户的实时点击数据，我们也进行了监控。有别于url分析，有些元素点击是不会触发url请求的，这些点击对我们来说，也是有意义的，比如分析什么按钮被点击最多，界面布局是否合理等。该方案采用Node.js方案，js前端收集用户鼠标click位置绝对坐标，发送到服务端，服务端将数据推送到监控页面端，由监控页面实时地显示用户在某个页面上的点击位置。

三、应用错误

应用的错误分为2类，程序上的500错误和能捕获到的异常。对于500错误，在Rails中采用了exception_notification_rails3 gem包来实现错误的监控。我们在基础的错误信息基础上增加了用户的联系方式、系统当前环境信息。这样，用户一旦不幸遇到我们的一个 Exception，相关开发人员会立即收到一封错误邮件。类似地，在Java应用中，也会对异常的http请求码进行处理，通过webx框架中的pipleline机制，添加一个Valve进行异常的检测和处理。即使这是为我们自己的失误亡羊补牢，但是却还是带来比较好的用户体验。用户经常很感叹：你怎么这么快知道我进行了xx操作出错了呢？

在应用中，被捕获的异常如果需要发送给开发，我们是通过旺旺实时弹窗来实现的。当捕获到异常时，直接调用旺旺消息，提示重要的信息。

四、应用性能

在Rails3框架中，提供了ActiveSupport::Notifications这个强大的事件通知和订阅机制。通过订阅"process_action.action_controller"即可拿到每次请求的开始时间，结束时间以及应用每一层（MVC）所消耗的时间。得到这些时间后，性能监控就变得简单了，计算下响应时间和每一层的告警时间，然后将异常的记录到DB，而且，在记录到DB时，我们增加了回调机制，记录严重性能问题的实时提醒。这样，如果开发的代码不合格或者遇到DB等问题，性能监控会立即报警。只要有不达性能指标的请求发生，提醒就会一直发生，直到你去修复它为止。在Java应用中，我们使用了集团Dragoon平台。该平台的应用性能监控只是其功能的一个子集，能够实现对Java应用的JDBC、URI的请求时间的监控。通过平台直接可以直观看到当前的应用性能情况，也是很方便的。

五、Kelude的监控平台

      以上二、三、四提及的监控点，我们没有用统一到一个平台化的里面，而除了这些监控之外，我们其他的监控都统一到了一个监控体系里面。这些监控项目都有一个共通点：需要轮洵地检查。调研了业界的系统后，我们决定用Nagios+Centreon+Cacti的解决方案。Nagios负责底层检测，Centreon负责可视化配置Nagios，Cacti负责展示机器实时信息。我们在Nagios上配置了旺旺通知脚本、手机通知脚本后，错误和警告就可以实时地被开发接收到了。最后，我们自己将Nagios的监控脚本进行了扩展，将所有的监控数据实时收集起来，汇总到一个页面，通过这个界面，我们可以直观了解到当前Kelude系统的整体运行情况，如下图：

当一个监控项添加进来时，我们会自动地按监控类别进行分类，这个是通过添加监控时，指定的一个identifier来区分的。然后一个监控通过Centreon添加到Nagios后，会在check时将检查的结果和日志推送到Kelude监控平台。这样我们就得到一个监控项的实时展现信息，如下图：

当被监控的项目异常（非告警）时，系统会自动开始一次故障记录，表明当前系统出现了问题，当接下来某次Check正常时，此次故障记录完成。汇总成如下信息：

这样，无需人工干预，被监控对象的故障、稳定性就自动有了。我们看下每个对象的稳定性，就可以给对应的负责人打KPI了，呵呵。

      接下来是每一项的具体实施：

• 应用心跳：我们要求每个应用都提供一个preload页面，用于检测自身的逻辑、数据等是否OK。以此来判断该应用是否OK。Nagios对应的脚本为check_kelude_http_responde.pl。检查响应体。
• 机器硬件指标：对应的Nagios脚本为check_kelude_performance.pl。 CPU、Load、Mem，Disk任何一项达到临界值时，就会产生旺旺+手机信息。
• 基础软件+业务软件：用了同一个检测脚本实现：check_kelude_process.pl。检测指定的进程名称/机器端口/进程数量。
• 数据库：通过check_kelude_mysql.pl来实现。
• 业务事件：业务事件的检测稍有特殊，因为逻辑由业务方控制，我们的做法就是让业务方提供http接口，在接口中检查自身的业务逻辑，和preload类似。对应的监控脚本也是：check_kelude_http_responde.pl

      我们Kelude的监控到此就结束了。可能有同学要说了，还有网络环境、前端错误、安全攻击啥的，怎么不监控了，不是说把一切都监控起来么。诚然，要做到一个全面的监控，确实应该继续考虑这些，但是由于我们是内部系统，网络环境我们并不关心，比如网速过慢啦，DNS不通啦等等，而前端错误，从几年的开发总结下来，其错误不会导致太多的Block。往往可能是一个js错误或者css问题，所以我们也默认忽略，由全面的WEB UI测试和用户反馈来保证。安全攻击也不在我们考虑范围内，这些就交给安全团队的人去做吧。