大家好,架构我是师面试样君哥 。 监控系统在科技公司非常重要,规划公司构它可以让运维人员和研发人员提前发现问题
、控架定位问题
,架构进而解决问题 。师面试样 在我们实际工作中 ,规划公司构使用的控架监控往往五花八门,比较混乱
,架构今天来聊一聊怎么规划公司的师面试样监控架构 。 监控指标采集为监控提供原始数据 ,规划公司构是控架监控系统的基础。源码库 当我们使用 Prometheus 做监控时,架构我们可以使用 Node Exporter 收集系统指标进行监控,师面试样比如内存、规划公司构CPU、磁盘
、文件描述符等信息。 数据库和中间件故障对业务影响会非常大,极端情况下可能让业务停摆 。因此必须有配套的数据库中间件监控。 对于数据库和中间件,采集数据库所在机器的系统信息如内存、CPU
、磁盘是必须的免费模板。 对于数据库,也需要采集 SQL 执行时长、数据库日志等作为监控指标 。 对于中间件,可以采集吞吐量、平均响应时长
,以及中间件自己的一些指标。比如 kafka 的 ISRShrink/ISRExpand 。 JVM 相关指标 ,比如堆内存、FULL GC 频率和时长
、线程使用情况。 业务系统的香港云服务器监控指标因为业务的复杂性
,会非常复杂和庞大
。 接口请求数量、平均响应时间、成功率。这部分指标可以使用网络抓包来获取。 业务整体运行情况 ,这部分指标有两种方式,一个是通过采集业务日志来获取,第二个业务代码主动推送执行,比如把运行情况抽象成指标保存数据库,或者通过消息队列发送给采集系统。 收集到监控指标后,要想把这些指标展示给运维人员,模板下载就需要先把指标保存下来。Prometheus 将监控数据保存在 TSDB ,一些公司选择引入外部时序数据库,比如 VictoriaMetrics 这款时序数据库就被很多公司采纳。 有些指标采集的量比较小
,也可以采用关系数据库做存储,对研发运维人员来说学习成本比较低。 小公司一般使用开源的工具就可以满足指标保存的需求
。在大公司
,业务类型广泛,指标数据量较大,需要规划指标保存方案,引入多种保存方式。亿华云 对于仅仅监控一些特定指标的情况下,只要采集到数据
,正常展示出来,就可以实现监控目标。但这只能用于较简单的监控指标,比如一个接口的请求次数 。 从宏观角度看,业务侧更关注的是总体数据
,比如昨天交易成功的业务数量,失败的建站模板业务数量。他们只会花时间看监控大盘。这个时候就需要进行一些数据加工、汇总
。 因此,指标加工也是非常重要的。这个工作也可以交给公司的大数据团队来承接 。 完成指标采集和加工后 ,怎样清晰优雅地展示给用户
,是监控设计中的一个重要环节。 知名的监控工具比如 Prometheus
、Zabbix 都有成熟的可视化界面
,可以清晰地展示给用户。但要满足更复杂
、更高要求的监控场景,这些工具很难满足需求。 这时候就需要技术团队自己开发指标可视化工具 ,这里不仅包括监控大盘 ,还包括给不同人员看的监控页面,比如给业务看的
,给运维看的,给研发看的。 有了指标采集、加工和展示,其实只完成了监控系统的准备工作 ,监控告警是我们规划监控系统的重要目标 。 监控告警的目标是让相关人员能够提前感知到问题
,及时采取措施
,防止问题扩大。 为了节省系统资源,监控告警也是需要分级别的,根据问题严重程度、业务影响范围来规划告警级别。这就要求业务系统在需求阶段就要明确业务的重要性,辅助确定监控级别
。 比如涉及金钱的交易系统
、支付系统
、账务系统,对于公司来说非常重要
,可以把他们定义成严重级别,监控到问题后
,通过短信
、OA 消息通知到值班运维人员,这样值班运维人员可以根据问题情况及时通知到相关研发人员,即使问题发生在半夜也能很快地采取措施 。 对于影响较小的业务系统、批量交易 ,可以定义成主要级别,发生问题后 ,短信或 OA 实时通知到系统负责人就可以。 对于没有业务影响的交易 ,可以定义成次要级别
,问题发生后,只需要邮件通知到开发人员,而且不用实时通知,每天集中一次或者几次就可以
。 应急方案需要提前进行设计、演练,这样可以防患于未然。假如一个严重级别的告警半夜 2 点触发了 ,研发人员睡梦中被叫醒 ,如果没有应急方案,势必会非常慌乱
。 应急方案可以根据系统的实际情况进行设计
,比如重启服务 、接口限流、熔断
、集群扩容 、故障节点摘除等。 监控系统对于科技公司来说,非常重要
。我们可以从指标采集
、指标保存、指标加工
、指标展示、监控告警 、应急方案这些方面来进行设计。希望本文对你设计监控架构有所帮助 。1.指标采集
1.1 系统指标
1.2 数据库/中间件
1.3 业务指标
2.指标保存
3.指标加工
4.指标展示
5.监控告警
6.应急方案
7.总结
