BBX监控设计文档.docx

《BBX监控设计文档.docx》由会员分享，可在线阅读，更多相关《BBX监控设计文档.docx（7页珍藏版）》请在第一文库网上搜索。

1、BBX监控设计1 .整体设计与架构监控的架构模式1.2监控的展示方案前端框架采用VUe-Smart-Widget做一套可配置的框架，加载页面时先获取页面上已配置好的数据。展示数据的方式有两种：一种是通过直接配置AP1接口获取数据，将重新封装过的EChart或者表格直接配置到smart-widget组件中，适用于数据需要后台处理的情况。另一种是直接将grafana中配置好的监控通过iframe的方式嵌入到smart-widget组件中，适用于可以直接读数据库获取数据或者通过Prometheus监控中间件的情况。2 .监控前端详细设计2.1 可配置框架设计分为配置界面和首页。配置页面选择通过AP1

2、获取数据或者嵌入iframe两种方式，配置后将生成的相应数据存放到数据库中。首页加载时先获取其配置，生成图表。可进行拖拽，删除等操作。首页2.2 监控平台grafana相关设计2.2.1 grafana及其插件Prometheus介绍Grafana是一款用Go语言开发的开源数据可视化工具，可以做数据监控和数据统计，带有告警功能。有七大特点：可视化：快速和灵活的客户端图形具有多种选项。面板插件为许多不同的方式可视化指标和日志。报警：可视化地为最重要的指标定义警报规则。Grafana将持续评估它们，并发送通知。通知：警报更改状态时，它会发出通知。接收电子邮件通知。动态仪表盘：使用模板变量创建动态和

3、可重用的仪表板，这些模板变量作为下拉菜单出现在仪表板顶部。混合数据源：在同一个图中混合不同的数据源!可以根据每个查询指定数据源。这甚至适用于自定义数据源。注释：注释来自不同数据源图表。将鼠标悬停在事件上可以显示完整的事件元数据和标记。过滤器：过滤器允许您动态创建新的键/值过滤器，这些过滤器将自动应用于使用该数据源的所有查询。插件使用PrOmetheUS,Prometheus是一个开源监控系统，它前身是SOUndC1OUd的警告工具包。目前它是一个独立的开源项目，且不依赖与任何公司。为了强调这点和明确该项目治理结构，Prometheus在2016年继Kurberntes之后，加入了C1oudNa

4、tiveComputingFoundatiorio主要具有如下功能：F多维数据模型(时序由metric名字和k/v的1abe1s构成)。2.灵活的查询语句(PromQ1)o3.无依赖存储，支持1oca1和remote不同模型。4.采用http协议，使用pu11模式，拉取数据，简单易懂。5.监控目标，可以采用服务发现或静态配置的方式。6.支持多种统计数据模型，图形化友好。2.2.2 整体页面使用grafana的设计借鉴。din的配置方法，直接将整个监控页面引入系统中，该方式不适用于首页这种需要多方数据的场景，可以配置为中间件监控。需要修改grafana部分源码，使原有的部分功能无效。grafan

5、a精简功能，使其无法全屏以及直看其他路径的监控中间件监控2.2.3 单个组件使用grafana的设计2.3 直接使用配置grafana组件的方式。单纯获取数据库中的数据，可以通过配置数据源后写SQ1语句的方式获取到图表。调用Prometheus监控获取到的数据，需要使用PromQ1查询指标后在页面展示。2.4 调用AP1接口相关监控设计2.4.1 首页部分监控设计首页部分除去调用grafana的模块，剩余部分中图表采用echart,前端配置图表类型、AP1地址、标题、颜色等配置项，生成一个smart-widget并与其绑定后存对应数据到数据库中；表格采用e1ementUI,前端配置表头以及AP

6、1地址等配置项后生成一个smart-widget并与其绑定后存对应数据到数据库中。2.4.2 其余部分监控设计其余部分分为：业务监控，日志监控，中间件监控，监控统计等。业务监控：监控服务相关信息以及服务的调用成功失败数，调用次数；根据原型开发。日志监控：监控tomcat日志、mq日志、网关日志等；根据原型开发。中间件监控：监控消息队列以及各类消息数、消息发布者、消息连接数、节点数等；使用grafana中的页面。监控统计：监控消息格式转换以及其正确错误数等；根据原型开发。3 .监控后台详细设计3.1 一般监控一般监控指的是直接可以调用AP1接口就可以展示在前端界面的那部分监控，API接口可以由第

7、三方提供后BBX处理，也可以由第三方直接提供对应数据格式的接口供首页监控使用。3.1.1 OPS以及MQ接口处理流程大部分数据采用公共技术部的OPS采集到的数据，因此需要处理OPS中获取的数据后重新整理出BBX需要的RPC接口供前端使用，包括首页监控中的部分图表，业务监控等。大部分MQ会提供其API接口供用户获取数据，因此BBX也需要处理MQ的数据后整理出MQ监控需要的接口。OPS接口BBX次霸道最第的rpcj口3.1.23.1.3 第三方接口处理流程首页监控中会有BBX现有接口无法满足需求的情况，此时BBX可以提供需要的数据格式，第三方可以根据此数据格式写对应接口，直接将api引入首页配置中

8、使用。3.23.3 日志监控3.3.1 日志监控描述口志监控可以先于用户发现系统的故障，实时告警。对于日志的监控，一般有这么几类需求：(I)某种级别的日志(例如FATA1级别，或者ERRoR级别的日志)一旦出现，或者超过一定频率，就告警；(2)包含某些特殊含义关键字(例如OUtofMemOry,或者EXCePtion)的异常日志，一旦出现，或者超过一定频率，就告警；(3)包含某些特殊含义关键字(例如1ogin,或者C1iCk)的正常日志，一旦一定时间周期没有出现，就告警；其中，前两类需求，属于异常日志监控范畴，出现异常，实施告警。第三类需求，属于正常日志监控范畴，一定的时间没有出现“正常”，就默认异常，实施告警。3.3.2 日志监控流程设计模仿e1k的模式，由1ogStaSh分布于各个节点上搜集相关日志、数据，并经过分析、过滤后发送给远端服务器上的Easticsearch进行存储。Easticsearch将数据以分片的形式压缩存储并提供多种API供用户查询，操作。最后将监控展示在BBX中。但是1ogstash耗资源较大，运行占用CPU和内存高，另外没有消息队列缓存，存在数据丢失隐患。因此这部分还需要讨论。E1asticsearchBBX