开发者俱乐部

标题: NodeJS 服务监控报警系统的核心实现和开源共建 [打印本页]

作者: jack    时间: 2016-2-23 21:32
标题: NodeJS 服务监控报警系统的核心实现和开源共建
本帖最后由 jack 于 2016-2-23 21:33 编辑

NodeJS 服务监控报警系统的核心实现和开源共建建设服务监控系统的初衷和历程
随着基于 NodeJS 前后端分离方案的推行,前端的开发模式和角色也在发生着悄无声息的变化,而今 NodeJS 的开发俨然已经成为我们日常工作中的一部分,前端工程师与服务端、运维都有了更多的交集,但随着业务和项目的扩张,生产环境 Node 服务也在不断增多,如何对这些服务的运行状态和各项指标了如指掌是当前我们大家共同遇到的挑战。
我的初衷是建立一个专门针对 NodeJS 的服务监控平台,它能够支持服务集群的统一管理和多用户登录,旨在帮助团队的开发者、架构人员以及管理者能够直观的观察线上各个服务的实时状态,并能够帮助开发者及时发现线上服务的异常情况(比如内存泄露、服务崩溃重启、慢路由等)。
PM2 是一款非常优秀的 Node 进程管理工具,它有着丰富的特性:能够充分利用多核 CPU 且能够负载均衡、能够帮助应用在崩溃后自动重启、能够监控资源的使用情况并且支持 API 方式查看、并且有配套的 Keymetrics 可以用于服务的监控。相信不少开发者都在使用 PM2 部署自己的 NodeJS 应用,起初也曾尝试使用 Keymetrics ,但 Keymetrics 是一款商业服务且价格不菲,虽有两台服务器的免费配额但对于有着众多服务器的团队或者公司而言无异于杯水车薪,而且对于国内的大公司而言都会考虑到自身的数据敏感性不希望服务的运行状态接入到第三方平台中,当然如果你的服务器数量很少,又或者能够支付昂贵的使用费用,而且无需关心数据的安全问题依旧推荐可以使用 Keymetrics ,毕竟它是 PM2 的开发者的开发和维护,而且功能特性也很丰富。
但我遇到的场景是如何实现一套通用的监控系统,它能够独立部署而且方便进行扩展和定制化,显然在现阶段使用 Keymetrics 不是十分明智的决定,于是便想到利用 PM2 的 API 进行服务监控,但 API 的方式不利于多台机器的统一管理和聚合,而且通过 API 的方式会将服务的详细信息泄露到外网,有一定的安全隐患。之后便开始设想是否能够基于 PM2 进行一些二次开发,实现一个核心功能并具备一定定制性的系统(类似 Keymetrics ),一方面可以为整个行业的 Node 推广起到一定的积极作用,一方面能够确实帮助到我们团队的服务运维。我将这个项目命名为 PM25 ,意即基于 PM2 的基础设施多做了一点,仅此而已别无他意。
现有功能点介绍和路线图代码开源的目的、愿景
我的初衷很简单,一方面能够把自己在工作之余的贡献拿出来和行业分享,也希望绵薄之力能够对行业的 Node 推广起到一些作用,反过来也希望行业内的济济人才能够参与到它的建设中来,基于我目前的成果和代码进行更多的功能开发和细节完善,把大家对 Node 的热忱和对 PM25 的建设形成合力为行业带来一些影响或是价值,代码托管于Github,项目地址为PM25.io
开源代码的组成结构├── PM2.5-Cli// PM25 CLI├── PM2.5-Cloud// PM25 云端控制台├── PM2.5-Service// PM25 服务端代码├── PM2.5-Docs// PM25 文档└── PM2.5-Ext// PM25 扩展包
数据库组成和分表结构├── pm25                // 主库,用于监控主机的信息存储   ├── buckets         // 桶表,用于存储主机分桶信息   ├── events          // 事件表,用于存储主机的事件信息   ├── exceptions      // 错误异常表,用于存储主机的线上报错   ├── monitorings     // 监控信息表,用于存储主机的整体监控数据   ├── status          // 主表,用于存储主机的各个进程数据   └── transactions    // 网络传输表,用于存储慢路由相关信息├── pm25-session        // 会话信息库,用于存储 SSO 登录后的用户会话   └── sessions        // 会话信息主表,用于存储用户会话详情├── pm25-test           // 测试表,用于开发过程中的测试
部署拓扑图
使用截图







欢迎光临 开发者俱乐部 (http://xodn.com/) Powered by Discuz! X3.2