Sharing A Powerful Tool For Application Auto Monitor

本文分享的这个应用监控小工具，本来是我在五年多以前开发实现的windows服务监控的一个windows服务。听上去比较拗口吧，是的，这个应用一开始就是个监控windows服务的windows服务。

记得当时写这个程序的直接原因就是，做数据统计结转迁移备份之类的后台定时windows任务实在太多，而且由于历史原因，服务挂掉了也没有人及时知道，最终都会造成用户投诉，但很久才反馈到开发这边，或者用户根本不投诉，而日志系统又做的不好（可以算是没有），很可能就一直不知道某些应用已经发生问题。

这个工具的缺点也很明显，我亲眼看到过某司后台强大的运维监控系统，各种详细的参数和指标，大量日志和完善的日志分析系统，可以直接定位问题至某个集群某台服务器，以及可视化数据监控平台管理后台…必须承认，这个小工具做不到某司统一监控平台系统的任何一点。

后来随着需求改变，监控的类型变多，逐渐完善，在这个过程中，也曾经考虑加入很多特殊应用的内部业务监控逻辑。但是开发组发现统一监控平台不是那么容易实现，抽象改进使监控通用必须统一应用框架，但我们那时候人手不足，只好简单粗暴实现最容易的通用逻辑，且慢慢被改造为基于http的应用的简单心跳检查，目前支持的主要应用类型有windows服务、web服务、web页面、wcf、web api等。

在某些特殊业务场景下，这个神器还能重见天日，还可以占有一席用武之地。

现在，这个应用支持两种表现形式：1、winform程序 2、windows服务

将winform改造为windows服务很简单，只要将Program类文件稍作修改：

Programusing System;
using System.ServiceProcess;
using System.Threading;
using System.Windows.Forms;

namespace ServiceMonitor
{
    using PowerServiceMonitor.Util;

    static class Program
    {
        /// <summary>
        /// 应用程序的主入口
        /// </summary>
        [STAThread]
        static void Main()
        {
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);

            MonitorConfig.InitMonitorConfig(); //初始化监控配置文件

            ////改造为winform程序
            //var isCreate = false;
            //var mutex = new Mutex(true, "powerservicemonitor", out isCreate);
            //if (isCreate == true)
            //{
            //    Application.Run(new MainForm());
            //}

            //改造为windows服务
            var ServicesToRun = new ServiceBase[]
            {
                new MonitorService()
            };
            ServiceBase.Run(ServicesToRun);
        }
    }
}

最后配合我这里介绍的动态安装windows服务或者installutil.exe，可以直接实现监控服务安装。

下面简要概括这个监控系统包括的主要功能模块。

一、应用监控管理模块

这个模块是这个应用程序的核心。

主要实现监控参数配置、监控项定义和业务逻辑实现。

最大亮点是支持动态监控项目配置。你可以通过工具界面及时调整监控项、重新定义时间间隔，同时它可以控制最大最小及隐藏，支持手动暂停和启动，还支持日志功能及时查看等。

通过这个工具，以前靠猜，面向巧合编程，经常需要码农手动一个一个排查windows日志找问题，现在直接通过工具日志就能直接定位排查线上问题了。

还有就是，这个小程序可以很简单的实现windows服务监控并尝试自动修复而减少人工干预，出现问题会根据配置发送邮件和（或）短信通知相关人员，当然，发邮件和短信的这个逻辑要依赖你自己完成，比如黑白名单功能、发送的优先级，要不要自动带上服务器IP，发送的频率控制等等。

1、监控主面板

2、监控项配置

对于监控项目和预警对象（MonitorItemInfo）的抽象非常重要，每一个监控项和提醒策略贯穿整个监控系统的始终。

MonitorItemInfousing System;

namespace PowerServiceMonitor.Model
{
    /// <summary>
    /// 待监控的项目信息
    /// </summary>
    [Serializable]
    public sealed class MonitorItemInfo
    {
        /// <summary>
        /// 应用类型
        /// </summary>
        public string AppType { get; set; }

        /// <summary>
        /// 监控的项目名称
        /// </summary>
        public string SvcName { get; set; }

        /// <summary>
        /// 监控的项目对应值 例如：windows服务对应进程名称 web服务则对应一个url
        /// </summary>
        public string SvcValue { get; set; }

        /// <summary>
        /// 是否启用
        /// </summary>
        public bool IsEnabled { get; set; }

        /// <summary>
        /// 是否发送邮件提醒
        /// </summary>
        public bool IsSendEmail { get; set; }

        /// <summary>
        /// 是否发送短信提醒
        /// </summary>
        public bool IsSendSMS { get; set; }

    }
}

如果你曾有过每天都有多个新应用同时上线的工作经历，你一定知道这些抽象多么重要。

实际上，如果应用较少，应用类型很单一，我们完全可以定义一套通用的监控策略，而不用每个应用都有一个配置。

但是，变化是永恒的主题，不同子系统的不同应用肯定会有不同的监控业务逻辑，这里千万不要认为是过度设计，我反而认为至少少了两个抽象，定时时间策略和回调通知报警接口。

监控的应用类型也可以动态扩展，小程序中已经定义了监控接口IServiceMonitor，按照自己的业务要求实现逻辑，然后加上配置即可。

IServiceMonitorusing System.Collections.Generic;

namespace PowerServiceMonitor.Contract
{
    using PowerServiceMonitor.Model;

    /// <summary>
    /// 服务监控接口
    /// </summary>
    public interface IServiceMonitor
    {
        /// <summary>
        /// 开始监控处理
        /// </summary>
        /// <param name="monitorConfigPath">待监控项配置文件地址</param>
        /// <returns></returns>
        IList<MonitorResultInfo> Start(string monitorConfigPath);
    }
}

其实，目前为止，这个工具的最大的两个不足是：

（1）、监控调度周期不灵活

目前每个监控项的时间间隔定义是一致的，实际上，监控项的定时策略完全可以改造成类似quartz（cron表达式）那样的定时任务调度，每个监控项都有自己的独特的时间策略。

真正做到某一类型应用或者某一个应用单独设置时间间隔进行监控才是接近最佳的。

（2）、不支持热插拔

虽然这个工具已经支持监控项及定时调度配置实时改动，但是不支持监控项动态插件式的监控模式。

理想的情况是，有新的监控项目，直接开发搞出一个新的dll至某文件夹，当然有可能还要加上一段配置文件，然后监控不重启即可动态监控。

虽然我之前搞过一个插件式文件处理系统，但是考虑到监控程序应该易用简单不出问题，还是放弃了插件式设计思路。

二、管理员模块

定义了一个简易管理员功能模块，实现了登陆和改密需求，示例代码为了演示需要，被我改变了原来的基于角色的权限控制（RBAC）服务（AdminUserService）。

      

当然，这个模块你可以根据监控需要进行扩展。

对了，这个小程序启动时需要输入用户名和密码，您可以根据如下用户名和密码进行登陆：

用户名：admin

密码：123456

三、日志管理模块

如你所知，监控系统越高级，监控参数越详细，依赖的日志也越多。

这个工具定义了统一日志接口ILog，示例中模拟支持文本、数据库和NoSQL类型的日志。

但是远远不够，实际监控平台还需要分享大量web请求响应日志、OS日志等。

日志模块可通过配置的方式进行动态管理。

如果你需要开发可视化的管理后台，建议使用RDBMS如MySQL或者MongoDB等NoSQL记录日志，当然你完全可以开发其他类型的日志提供程序与之适配。

最后再重复一次，这个小程序启动时需要输入用户名和密码，您可以根据如下初始用户名和密码进行登陆：

用户名：admin

密码：123456

demo地址：PowerServiceMonitor