本文再写一篇和具体业务逻辑几乎无关的公共服务应用监控平台。PowerDotNet自研的应用监控平台系统，是服务治理的重要拼图，和服务治理平台配合使用效果更好。
监控开源产品非常丰富，站在巨人的肩膀上，PowerDotNet自研的监控平台，除了基本的监控功能，还可以通过加一层代理，将应用接入开源监控软件，降低应用和监控软件的耦合。
在介绍系统和应用的时候，我们说过应用的一种分法是可以分为带界面的和不带界面的，服务或者非服务等等等等，拆分方法不同，关注的应用形态也就不同。
带界面的应用比较容易肉眼看到问题和异常状况，虽然最终原因可能绝大多数都是服务端接口问题而不是带界面应用自身的问题，这一点估计绝大多数客户端、前端、移动端等终端开发者会表示赞同。
而不带界面的应用服务，尤其是微服务集群，由于多样的外部依赖和版本、错综复杂的业务逻辑甚至短暂高并发的冲击，很容易产生莫名其妙的“隐藏”问题，最终导致被延迟发现甚至直接忽略的业务异状。
定位线上应用服务问题的方法，一种是通过强大的日志平台系统，这基本上是各种公司技术人员解决问题的直接方案，可是日志系统应对的绝大多数问题都是在问题发生后了，相对而言比较被动。
另一种相对主动的解决方案，是通过灵活且相对实时的监控和预警，即应用监控平台系统，可以在问题发生前就能迅速发现并定位预警，甚至可通过技术手段如守护进程自动修复异状。
本文介绍的PowerDotNet的监控平台系统，主要是针对基于服务平台治理的后端应用的业务逻辑型监控，也就是直接针对应用的监控，但不包括应用的外部依赖如数据库、缓存等的监控。
对于其他非应用服务的软件产品监控，比如关系型数据库、缓存、消息队列以及ElasticSearch、ETCD、HBase等NewSQL产品，单独开发监控程序成本较高，建议直接使用或二次开发开源的监控产品。
当年在某司我看到过一个应有尽有的大型监控系统，几年前我自己也因为业务需要尝试着写过点监控业务（猛击这里），虽然写的不够深入和全面，部署也不太容易，却也解决了燃眉之急。
在实现PowerDotNet监控系统之前，先后参考调研了nagios、zabbix、opserver、open-falcon、ARMS、uptime-kuma、hertzbeat、prometheus和grafana等主流开源监控产品，也借鉴了某司的监控平台系统。
对比这些监控软件，尤其prometheus和grafana，作为后起之秀确实全面强大灵活，所以在前面介绍基础设施公共服务的时候我就感觉没必要单独再造轮子，但已写好的又不忍丢弃，咩哈哈。
按照时间、服务器、系统、应用和具体API服务或页面进行精准监控和分析是PowerDotNet的刚需，所以PowerDotNet的监控平台系统开发出来也不是完全没有用武之地，仅针对应用监控还是拿得出手的。
PowerDotNet的监控平台系统Power.XMonitor主要包括如下四部分：
1、XMonitor.Client 监控客户端接入SDK，支持Thrift和Http协议
2、XMonitor.Gateway 监控网关，客户端推送至网关，网关将监控数据推送至服务端
3、XMonitor.Server 监控服务端，主要包括监控数据消息队列生产者XMonitor.Producer、消费者XMonitor.Consumer和监控预警服务XMonitor.ForewarnAlert
4、XMonitor.AdminUI 监控管理后台，主要用于预警配置，查看监控数据和日志，以及监控仪表盘等。
Power.XMonitor最粗监控粒度是时间范围，最细监控粒度则精确到某个具体API服务，可按需监控某段时间范围内、某台服务器，某个系统，某个应用，某个服务的监控数据，支持灵活的监控预警指标和规则配置，支持邮件、钉钉、短信、微信等通知通道。
和Power.XLogger日志接入代理类似，应用监控接入代理业务逻辑和资源使用当然是越少越好，对于业务系统接入几乎完全无感，最终做到简单易用灵活可插拔，这也是我们开发Agent应遵守的准则之一。
下面详细讲讲PowerDotNet内置的应用监控平台系统Power.XMonitor。
环境准备
1、（必须）.Net Framework4.5+
2、（必须）MySQL或SqlServer或PostgreSQL或MariaDB或MongoDB或InfluxDB或ElasticSearch
3、（必须）PowerDotNet数据库管理平台，主要使用DBKey功能
4、（必须）PowerDotNet配置中心Power.ConfigCenter
5、（必须）PowerDotNet注册中心Power.RegistryCenter
6、（必须）PowerDotNet缓存平台Power.Cache
7、（必须）PowerDotNet消息平台Power.Message
8、（可选）PowerDotNet数据同步平台Power.DataX
一、数据采集
Power.XMonitor的数据采集主要分为系统环境和业务逻辑指标参数两部分。
系统环境指标部分主要包括CLR的线程数、打开的句柄数、CPU、内存、磁盘、实时Socket连接数等。
业务逻辑指标部分主要包括服务器IP和端口、被调用服务数、服务被调用总次数、服务调用异常总数、服务请求总流量、服务应答总流量、服务调用总耗时、服务调用最大耗时等。
对于一般业务系统而言，上面的监控数据采集基本能满足常规需求，尤其是微服务API关注的常见业务参数都设计在里面，对直接分析和排查问题很有帮助。
二、数据传输
Power.XMonitor支持将采集的数据以Thrift或者HTTP协议上报给监控平台系统，上报服务默认以消息队列（也可配置为直接写库）的形式异步高速处理，防止上报成为业务系统性能瓶颈。
上报协议支持在配置中心动态配置，默认为最为通用的HTTP协议，如果业务系统追求更高性能，可以配置为Thrift协议。
Power.XMonitor主要配置参数包括：
接入应用只需在应用启动时写如下一行代码，即可无其他侵入代码实现监控功能。
//启动监控 XMonitor.StartCollector();
对于使用PowerDotNet服务治理平台提供的服务治理客户端的服务，则无需写任何代码，因为客户端程序自动集成了XMonitor，应用只需在配置中心配置App.UseXMonitor、App.MonitorRate、App.MonitorProtocal和App.MonitorCenterUrl，一个PowerDotNet服务治理下的服务即可拥有XMonitor的监控功能。
对于非API服务的应用，比如Asp.Net MVC、WebForms等应用，也可以通过XMonitor.Client和ActionFilterAttribute配合自动产生监控数据，XMonitor.Client同时还提供了推送监控数据接口，业务系统完全可以按需埋点监控。
三、数据存储
Power.XMonitor监控数据量主要由监控频率、应用和服务器多少来决定。
根据经验，实际产生的监控数据量虽然远远不如日志系统，但相对数量还是不小的，查询和统计也有不少的工作量。
Power.XMonitor默认监控频率是30秒，存储的数据支持按分钟、小时和天分组统计存储。没有设计按秒存储，一是因为考虑到数据量较大，二是基于实际情况，监控也没有必要必须精确到秒。
目前监控数据存储支持MySQL、SqlServer、PostgreSQL和MariaDB四种关系型数据库，也支持MongoDB和ElasticSearch存储，还可以使用时序数据库InfluxDB存储。
有了数据库管理平台的DBKey功能，监控数据库可按需选择切换，非常轻松即可实现一键切换，XMonitor推荐使用MongoDB或ElasticSearch或MySQL。
考虑到中大型应用的监控数据量通常都比较庞大，所以我们设计监控系统的时候都需要考虑分片处理。
DBKey配置监控数据库这种方式天然就适合数据分片存储，在监控数据发展到一定数据量级以后，不需要运维和DBA介入，直接换个DBKey或者通过DataX数据同步平台修改DBKey连接串就可以切换新的监控存储介质，历史监控数据如果需要，可以重新部署一份监控可视化站点专门查询历史监控数据。
对于监控基础数据如预警规则、预警指标、告警配置等，可以直接通过数据同步平台同步数据，做到分片切换用户完全无感知。
四、数据可视化
1、监控面板
Power.XMonitor开发了几个常用的业务监控仪表盘，支持将常见监控指标通过柱状图、饼图和折线图进行友好展示，可在页面灵活配置刷新时间自动刷新获取数据。
（1）、时间角度看API调用次数
如果监控时间范围在同一天内，按照小时进行拆分汇总聚合显示
如果时间查询范围不在同一天，则按天聚合显示
（2）、从服务器角度看API调用次数
（3）、流量监控
（4）、API最大耗时
这个最大耗时对于性能问题排查非常有用，当然完全可以通过日志系统进行定位，不过监控系统查询更加直接。
（5）、服务器指标监控
还可以支持磁盘监控，磁盘统计数据已有，只是没在界面上展示出来。
2、每天监控数据
以天为单位进行汇总统计，监控数据在XMonitor.Consumer消费时在内存中运算而来。
3、每小时监控数据
和每天监控数据产生类似，以小时为单位进行汇总统计，监控数据在XMonitor.Consumer消费时在内存中运算而来。
4、每分钟监控数据
和每小时监控数据产生类似，以分钟为单位进行汇总统计，监控数据在XMonitor.Consumer消费时在内存中运算而来。
相对而言，每分钟产生的监控数据就比较大了，一般来说，监控到小时和天就基本够用了，如果你的应用不需要详细监控到分钟，完全可以不写入这个数据。
5、服务消费者监控统计
监控面板基于服务生产者的监控统计非常常见，其实Power.XMonitor也支持基于服务消费者的监控统计，比如我们经常会统计哪些（接口消费者）应用调用了什么（服务生产者）接口，消费者调用失败的接口次数、消费者调用的最耗时接口等等。
五、监控告警
对于监控系统而言，及时准确多样的预警提醒也非常重要，尤其是对于核心业务系统而言，尽早发现问题可以减少甚至避免不必要的损失。
监控告警模块设计出了预警指标、告警配置和预警规则三个子模块，灵活设置适配常见的预警功能。
1、预警指标
预警指标包括系统环境指标和业务逻辑指标，阈值类型支持百分比和数值，支持自定义阈值触发表达式，可适配绝大多数情况下的监控业务场景。
2、告警配置
告警配置支持告警时间段设置，默认0至23小时，也就是全天都支持告警消息支持。
告警周期的意思是，针对某个监控项的监控，重复发送消息的间隔时间不能小于告警周期，这样可以防止重复发送大量告警消息。
告警配置有紧急、严重和警告三种告警级别，通常都可以配置为警告级别，非核心应用也可以按需配置为紧急或严重级别。
3、预警规则
一个预警规则，可以绑定一个或多个预警指标；一个预警规则，可以绑定一个或多个告警配置。
预警指标和告警配置相互独立，没有直接关系，这样设计的好处是最大程度复用预警指标和告警配置。
预警规则配置可以精确到某台服务器，或者某个系统，或者某个应用，甚至直接精准到某个服务接口或者具体页面，按需配置，支持监控的最大灵活性。
4、告警消息
Power.XMonitor默认通过消息平台Power.Message进行消息提醒，支持邮件、钉钉、短信和微信的消息提醒，当然也预留接口可以按需使用其他自定义消息平台进行提醒。
以触发钉钉警告信息为例，用户接受到简易直接的监控告警提醒信息如下：
如何进行合理设置告警频率并减少误报也非常考验监控告警模块的设计。
监控告警设置的告警周期通常设置为2分钟（120秒），核心业务可以调整小一些，这样就可以减少大量重复不必要的告警消息。
Power.XMonitor的监控告警可根据服务器、系统、应用和API服务动态设置告警频率，默认设置为，相同服务器、系统、应用和API服务，最低1分钟内不重复告警，降低发送消息的频率，减少无效误报可能。
默认最低1分钟告警间隔，和监控频率有关，Power.XMonitor的默认监控频率是30秒，建议将间隔设置为两个或四个频率周期，这样几乎不会丢失异状，又不过分增加服务器压力，这也是实践得出的结论。
5、告警反馈
Power.XMonitor理论上对所有的告警信息都需要有告警反馈处理，否则告警信息一直红色提示为“未处理”。
标记为已处理的告警信息，建议进行故障分类管理，这样非常有利于开发和运维人员快速定位并解决问题。
六、监控黑白名单
根据实际经验，因为业务应用开发水平的差异，对于应用接入方，我们要做到监控可按需启停处理，否则某些“劣质”、“腐败”、多变的应用会有意或无意的拖累甚至搞垮监控平台，影响更多的系统和应用正常监控。
Power.XMonitor支持黑白名单功能，只要应用接入方认为自己的应用或服务完全稳定可靠无需监控，加入白名单的通通放行，不做监控处理，加入黑名单的则给出告警提醒，定时放弃监控。
1、应用黑白名单
某些稳定的字典型应用，稳定运行后除非硬件挂掉或断电，否则几乎不会再修改发布或扩容，比如PowerDotNet的DBKey服务，可以将整个应用加入监控白名单。
2、接口黑白名单
API应用中某些接口稳定运行，或者非核心业务功能的接口，访问量极少的接口或过时的接口，不监控也不影响应用运行，可以把这部分接口加入白名单，减少资源开销。
3、页面黑白名单
页面应用中某些页面，如静态页、访问极少、逻辑简单几乎不会出错的页面，可以加入白名单。
七、监控高可用
监控接口完全异步化处理，客户端推送超时时间设置要短一些，默认超时时间为2秒，可通过配置中心动态调整，也支持动态监控开关，这样做的目的是哪怕监控服务挂了也不影响业务主流程。
监控服务应该尽可能减少外部依赖，就算有依赖也要保证依赖的组件和服务高可用，否则监控服务及其依赖就需要监控服务监控，自己监控自己容易进入死循环，所以应该将依赖的服务绕开监控。
Power.XMonitor目前仅依赖获取DBKey信息和发送消息两个接口，当监控服务开始工作时会自动绕开监控这两个基础服务，当然这两个接口的调用频率并不高，且业务逻辑较为简单，经实践验证非常可靠。
参考：
https://github.com/opserver/Opserver
