监控中心方案设计

场景1：公司内部的机器有数万台，需要对每台机器的运行情况进行监控告警，包括系统监控、JVM监控及JDBC监控等，要求尽可能让应用无感知，且易升级维护。
部署方案
启动： StartAgent作为系统基础环境，机器分配之后就启动。应用启动之后与StartAgent建立连接传输JVM、JDBC等监控信息，StartAgent本身采集系统监控信息，然后将所有的监控汇总传送到监控中心。
升级：如果是Docker部署，直接在镜像中升级版本即可；若是非Docker部署，直接在线升级（下载新版本，原先进程kill掉，启动新进程）；

场景2：前置机部署在CP的服务器，需要对每台机器的运行情况进行监控告警，包括系统监控、JVM监控及JDBC监控等，要求尽可能跨平台、不依赖外部环境，且易升级维护。

跨平台： JVM本身就是跨平台的，利用自带的JMX协议即可实现；系统监控的跨平台是困难的，基本思路是前置机只封装一些常见操作系统的监控，特殊系统的监控可以在前置机启动时向监控中心发出脚本热升级请求，监控中心下发监控脚本实现。
升级：当前前置机的部署都是非Docker环境，直接在线升级（下载新版本，原先进程kill掉，启动新进程）即可；

监控项

JDBC监控（客户端角度）

　　说明：数据库监控的难点在于数据库类型的多样性，如分布式数据库、关系型数据库等，因此想要屏蔽数据库的差异，实现统一监控是不可能的。以下方案适用于遵循JDBC规范的数据库。
　　分析：应用的部署架构如下图所示，可用于数据库监控的有“ORM层”和“数据源层”，但是ORM层无法监控数据库连接，且对应用侵入比较大。数据源层常用有DBCP、C3P0及Druid，最佳选择必然是Druid。不仅仅是因为性能（Druid针对Oracle和MySql做了特别优化，比如Oracle的PS Cache内存占用优化，MySql的ping检测优化），还有就是：1. Druid支持所有JDBC兼容的数据库，包括Oracle、MySql、Derby、Postgresql、SQL Server、H2等等；2. 强大的监控功能，通过Druid提供的监控功能，可以清楚知道连接池和SQL的工作情况，而且方便扩展。
　　　　　　　　　　　　　　　
　　结论： 应用的数据源使用Druid，监控客户端启动时开启Druid的监控开关，并将JdbcStatManagerMBean注册到MXBeanServer，所有的监控信息从其属性值获取即可，如下图所示：

JVM监控

　　JVM是跨平台的，对于JVM的监控和管理，JDK提供了JMX框架（java.lang.management包），并且将常用的监控信息已经封装成各种MBean（ManagementFactory获取），支持应用程序通过本地或者远程调用的方式获得监控数据。
　　基本思路：监控客户端启动时将各种MBean注册到MXBeanServer,然后通过RMI或者自定义协议方式与MXBeanServer进行交互，获取各种监控数据。

系统监控

　　分析：系统监控的难点在于操作系统的差异性，不同的操作系统具有自己的监控项和监控命令。好在就是绝大部分的应用都是部署在主流操作系统上（类Unix、Windows等），非主流的操作系统占了极少的比例。
　　基本思路：监控客户端封装通用代码，能够适用于绝大部分的主流操作系统即可。对于个性化的监控指令由监控中心控制，客户端在启动时对操作系统的环境进行判断，如果客户端已有的监控脚本无法满足需求，则向服务发出“脚本热升级”的请求，然后服务端下发监控指令，客户端对脚本热升级即可。这样做的好处是客户端永远是通用的，服务端具有控制权，可以灵活配置各种监控指令。