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