智能物业管理系统在写字楼中的应用，特别是智能门禁人脸识别系统和电梯控制系统，为写字楼的安全提供了高效可靠的保障。 这些系统的应用不仅使写字楼管理更加智能、便捷，也为客户提供了更好、高品质的服务体验。

首先，智能门禁人脸识别系统是写字楼物业管理系统的重要组成部分。 通过采用先进的人脸识别技术，系统可以准确、快速地识别授权人员，实现远程开门和实时监控。 与传统门禁系统相比，智能人脸识别系统更加安全可靠，避免了传统钥匙或卡丢失、被盗的风险。 同时，系统还可以记录人员的进出记录，为后期记录和审核提供数据支撑，增强安全管理的可追溯性。

其次，电梯控制系统是写字楼智能化管理的又一关键技术。 系统通过智能电梯控制器和读卡设备实现对电梯的精确控制和权限管理。 只有授权人员才能进入指定楼层，大大提高了办公楼的安全性。 此外，电梯控制系统还可以根据不同人员的权限设置电梯的出入口，有效控制人员流动楼宇自控安全系统，提高办公楼的管理效率。

智能门禁人脸识别系统和电梯控制系统的应用带来了诸多好处。 首先，对于写字楼的管理来说，由于是基于人脸特征进行识别，因此不需要额外携带门禁卡或钥匙，大大提高了便利性。 无需排队刷卡的操作，使人们的进出更加高效、快捷，为写字楼提供更高的服务质量和客户体验。

其次，智能门禁人脸识别系统和电梯控制系统有效防范非法入侵和信息泄露的风险。 由于人脸识别技术准确率高、难以伪造，系统可以快速识别授权人员，防止非授权人员进入办公楼或敏感区域。 这种基于人脸识别的安检措施，有效降低了潜在的安全风险，提高了写字楼的整体安全性。

智能门禁人脸识别系统和电梯控制系统在保证写字楼安全的同时，也为客户提供了越来越好的服务体验。 顾客无需随身携带门禁卡，只需通过人脸识别系统即可自由进出，省去了找卡、丢卡等繁琐步骤，提高了顾客的便利性和满意度。 此外，电梯控制系统的使用还可以有效减少电梯的拥堵和等待时间，使顾客的旅程更加顺畅、舒适。

一、业务背景

当今时代是一个信息爆炸的时代。 信息借助互联网趋势在全球自由流动，产生了各种平台系统和软件系统。 业务越来越多也会导致系统的复杂性。

当核心业务出现影响用户体验的问题，开发者没有及时发现，等发现问题时就为时已晚，或者当服务器的CPU不断增大，磁盘空间占用过多时已满等情况，需要运维人员及时发现并处理。 这就需要一个有效的监控系统来对其进行监控和预警。

如何对这些业务和服务器进行监控和维护，是我们开发人员和运维人员不能忽视的重要部分。 本文长度约5000字。 系统的整理一下，方便大家在选择监控技术时可以参考。

vivo服务器监控旨在为服务器应用提供系统监控、JVM监控、自定义业务指标监控等一站式数据监控，并配备实时、多维度、多渠道的报警服务，帮助用户掌握应用情况及时多方位的状态，提前及时预警和发现故障，事后提供详细数据，以便追踪定位问题，提高服务可用性。 目前，vivo服务器监控累计对接业务方已达200+。 本文介绍服务器监控。 我公司还有其他类型的优秀监控，包括普通监控、调用链监控、客户端监控。

1、监控系统基本流程

无论是开源的监控系统还是自研的监控系统，整体流程都是类似的。

1）数据收集：可以包括GC次数、线程数、老年代、新生代区域大小等JVM监控数据； 系统监控数据如磁盘使用情况、磁盘读写吞吐量、网络出口流量和入口流量、TCP连接数； 错误日志、访问日志、视频播放量、PV、UV等业务监控数据

2）数据传输：将采集到的数据以消息或HTTP协议的形式上报给监控系统。

3）数据存储：有的使用MySQL等RDBMS来存储，有的使用时序数据库来存储，还有的直接使用HBase来存储。

4）数据可视化：数据指标的图形化展示，可以是折线图、柱状图、饼图等。

5）监控报警：灵活的报警设置，支持邮件、短信、IM等多种通知渠道。

2、如何规范使用监控系统

在使用监控系统之前，我们需要了解监控对象的基本工作原理，比如JVM监控，我们需要清楚JVM的内存结构以及常见的垃圾回收机制； 其次，我们需要确定如何描述和定义监控对象的状态，比如监控某个业务功能的接口性能，可以监控接口的请求量、耗时情况、错误量等； 确定如何监控对象的状态后，需要定义合理的报警阈值和报警类型。 当收到报警提醒时，帮助开发者及时发现故障； 最后，建立完善的故障处理体系，接到报警后快速响应，及时处理线上故障。

2.vivo服务器

监控系统架构及演进之路

在介绍vivo服务器端监控系统架构之前，我们先带大家了解一下时序数据库。 在理解之前，先解释一下我们为什么选择它。 原因如下：

1）监测数据采集指标在某一时间点具有唯一值，没有复杂的结构和关系。

2）监测数据指标具有随时间变化的特点。

3）基于HBase分布式可扩展的时序数据库，存储层不需要太多的精力，并且具有HBase吞吐量高、扩展性好的特点。

4）开源，用Java实现，并提供基于HTTP的应用程序编程接口，可以轻松修改以进行故障排除。

1 简介

1）基于HBase的分布式可扩展时序数据库主要用作监控系统。 例如，采集大规模集群（包括网络设备、操作系统、应用程序）的监控数据并存储和查询，支持秒级数据采集，支持永久存储，可进行容量规划，轻松接入现有In监控系统，系统架构图如下：

（来自官方文档）

存储结构单元是Data Point，即某个时间点的值。 数据点包括以下几个部分：

核心存储两个表：tsdb 和 tsdb-uid。 表tsdb用于存储监控数据，如下图：

（图片来源：）

Row Key为+hour hour++，取对应的字节映射并组合； 列族t为小时小时剩余秒数，对应值为Value。

表tsdb-uid用于存储刚才提到的字节映射，如下图所示：

（图片来源：）

图中“001”表示tagk=hots或tagv=，提供正向和负向查询。

2）使用策略说明：

2. 实践中应注意的事项

1）精度问题

String value = "0.51";
float f = Float.parseFloat(value);
int raw = Float.floatToRawIntBits(f);
byte[] float_bytes = Bytes.fromInt(raw);
int raw_back = Bytes.getInt(float_bytes, 0);
double decode = Float.intBitsToFloat(raw_back);
/**
 * 打印结果：
 * Parsed Float: 0.51
 * Encode Raw: 1057132380
 * Encode Bytes: 3F028F5C
 * Decode Raw: 1057132380
 * Decoded Float: 0.5099999904632568
 */
System.out.println("Parsed Float: " + f);
System.out.println("Encode Raw: " + raw);
System.out.println("Encode Bytes: " + UniqueId.uidToString(float_bytes));
System.out.println("Decode Raw: " + raw_back);
System.out.println("Decoded Float: " + decode);

如上面代码，在存储浮点数据时，无法获知存储意图，转换时会存在精度问题，即存储“0.51”，取出来为“0.52568”。

2）聚合函数问题

大多数聚合函数，包括sum、avg、max、min都是LERP()插值方法，即对得到的值进行填充，对于空值需求的使用并不友好。 有关详细信息，请参阅相关文档。

目前服务端监控使用的是我们修改后的源码，并且增加了新的函数来满足内置函数插入空值的需求。

三、vivo服务器监控采集器原理

1）定时器

包含3种收集器：OS收集器、JVM收集器和业务指标收集器，其中OS和JVM每分钟进行收集和聚合，业务指标收集器会实时收集并在时间点1完成聚合和重置分钟。 3个采集器的数据打包上报，上报动作异步超时。

2）业务指标采集器

业务指标采集有两种方式：日志输出过滤和工具代码上报（侵入式）。 日志输出过滤是通过继承log4j来获取指标配置中指定的输出，并根据指标中配置的关键字和聚合方式等信息进行同步监控和采集； 代码上报是根据代码中指定的指标代码上报信息，是一种侵入式收集方式，通过调用监控提供的Util来实现。 业务指标配置将每 5 分钟从 CDN 刷新一次。 内置多种聚合器用于聚合，包括count计数、sum求和、平均值、max最大值和min最小值统计。

4、老版本vivo服务器监控架构设计

1) 数据收集和报告

与需求侧应用连接的监控采集器-代理根据监控指标配置采集相应数据，每分钟上报一次数据。 采用的指标配置每5分钟从CDN下载并更新一次，CDN的内容由监控后台上传。

2）计算与存储

监控后台接收到的数据被拆解并存储在数据库中，可供可视化图表调用。 监控项、应用、指标、报警的配置存储在MySQL中； 分布式任务分发模块采用Redis实现，实现多个监控服务的协同运行。 用于分布式计算。

3）报警检测

获取监控指标数据，根据报警配置检测异常，并通过第三方自研的消息、短信发送异常情况，报警检测通过分布式任务分发模块完成分布式计算。

5、vivo服务器监控旧版本部署架构

1）自建机房A

部署架构以国内为例。 监控项目部署在自建机房A，监控本地机房的新闻。 依赖的Redis、MySQL等都在同一个机房​​。 需要上传的监控指标配置由文件服务上传到CDN进行监控，需要应用设备调用。

2）云机房

云机房的监控需求要求应用设备将监控数据上报到本地云机房，云机房通过路由将指定队列转发到自建机房A，并进行监控配置云机房是通过CDN拉取的。

6、新版vivo服务器监控架构设计

1）收购（接入方）

业务方接入-并在相应环境的监控后台配置相关监控项，完成接入。 - 会定期拉取监控项的配置，每分钟收集服务数据并报告。

2）数据聚合

老版本支持将采集到的数据路由到监控机房（同一机房不会出现此行为），由监控后台服务消耗； CDN负责承载各个应用的配置，供应用定期拉取。 新版本-作为监控数据网关，使用http上报监控数据和拉取指标配置，放弃了之前使用的上报和CDN同步配置方式，避免两者失效时对监控上报的影响。

3）可视化并支持报警和配置（监控后台）

负责前台数据的多元化展示（包括业务指标数据、分机汇总数据、单服务器数据、业务指标复合计算呈现）、数据汇总、报警（目前包括短信和自研消息） ）， ETC。

4）数据存储

存储采用HBASE集群和开源作为聚合中介。 原始数据上报后，持久化到HBase集群。 Redis作为分布式数据存储，用于调度任务分配、报警状态等信息。 后台涉及的指标和报警配置均存储在MySQL中。

3. 监测、收集、报告和存储监测数据的策略

为了降低监控访问成本，避免上报失败和CDN同步配置失败对监控系统的影响，采集层会通过HTTP直接上报给代理层，采集层和数据代理层的队列将用于在灾难期间最大限度地利用数据。 救援。

详细流程描述如下：

1）收集器（-）根据监控配置每分钟收集并压缩数据，存储到本地队列中（最大长度为100，即最大存储时间为100分钟的数据），并通知可以通过HTTP上报方式将数据上报给网关。

2）网关（-）收到上报数据后进行认证，如果发现非法则丢弃； 同时判断下层是否异常熔断，如果发生则通知采集层重置数据返回队列。

3）网关验证上报时带入的监控配置的版本号。 如果过期，返回结果时会返回最新的监控配置，需要采集层更新配置。

4）网关将上报的数据存储到应用对应的Redis队列中（单个应用缓存队列key最大长度为1w）； 存储队列完成后，立即返回HTTP报告，表明网关已收到数据，采集层即可取出条目数据。

5）网关对Redis队列数据进行解压、聚合； 如果熔断异常，之前的行为将暂停； 完成后，将存储在HTTP中； 如果大量存储行为异常，就会触发熔断。

4、核心指标

1、系统监控报警和业务监控报警

采集到的数据存储到HBase后，通过分布式任务分发模块完成分布式计算。 如果满足业务方配置的报警规则，就会触发相应的报警楼宇自控信息采集器原理，报警信息将被分组并路由到正确的通知方。 可通过自行开发的短信发送报警，并可通过姓名、工号、拼音查询并输入需要接收报警的人员。 当收到大量重复报警时，可以消除重复的报警信息，并且可以通过MySQL表记录所有报警信息，方便后续查询和统计，报警的目的不仅仅是帮助开发者及时发现故障建立故障应急机制的同时，还要将监控项目和报警排序服务与业务特点相结合，借鉴行业最佳监控实践。 报警流程图如下：

2. 支持的报警类型及计算公式

1）最大值：当指定字段超过该值时，触发报警（报警阈值单位： ）。

2) 最小值：当指定字段低于该值时，触发报警（报警阈值单位： ）。

3）波动量：取当前时间到前15分钟的最大值或最小值以及15分钟内的平均值，进行浮动百分比报警。 波动量需要配置波动基线，只有当标记超过基线值“报警阈值”时才进行判断，低于基线值则不会触发报警（报警阈值单位：）。

计算公式：

4）日日比：取当前时间与昨天同一时刻的值作为浮动百分比报警（报警阈值单位： ）。

计算公式：浮动利率=（本期值-上期值）/上期值

5）周周比：取当前时间与上周同一天同一时间的值作为浮动百分比报警（报警阈值单位：）。

计算公式：浮动利率=（本期值-上期值）/上期值

6）小时日比：取当前时间到前一小时的数据值之和与昨天同一时间前一小时的数据值之和作为浮动百分比报警（报警阈值单位：）。

计算公式：浮动率=(浮动)(-)/(浮动)。

五、示范效果

1、业务指标数据查询

1）在查询条件栏“指标”中，可以选择指定指标。

2）双击图表上的指标名称可显示大图，下方为指标字段按开始时间的合计值。

3) 滚轮可以缩放图表。

2.系统监控&JVM监控指标数据查询

1）页面每分钟自动刷新一次。

2）如果某条线，即某台机器整条线显示为红色，则说明该机器超过半小时没有上报数据。 如果机器异常离线，必须仔细检查。

3) 点击详情按钮，可详细查询系统及JVM监控数据。

3、业务指标配置

单个监控指标（通用）可以采集单个指定日志文件的数据。

6、主流监控对比

1、

诞生于1998年，核心组件采用C语言开发，Web端采用PHP开发。 它是老式监控系统的优秀代表，可以监控网络参数、服务器健康状况和软件完整性，应用广泛。

使用MySQL进行数据存储不支持Tag特性，无法进行多维度的聚合统计和报警配置，使用不灵活。 没有相应的SDK，应用层监控支持有限，也没有我们自研监控提供的侵入式跟踪采集功能。

整体成熟度较高，集成度高导致灵活性差。 监控复杂度增加后，定制难度就会增加，而使用的MySQL关系数据库对于大规模监控数据插入和查询来说是个问题。

2. 打开-

它是一个企业级、高可用、可扩展的开源监控解决方案，提供实时报警、数据监控等功能。 它是用Go和语言开发的，由小米开源。 非常容易监控整个服务器的状态，比如磁盘空间、端口存活情况、网络流量等等。 基于Proxy-，通过自埋点很容易实现应用层的监控（如监控接口的访问量、耗时）等个性化监控需求，且集成方便。

官方架构图如下：

3.

它是一个采用Go语言开发的开源监控报警系统和时序数据库（TSDB），是监控系统的开源版本。

像小米的Open-，借鉴了，在数据模型中引入了Tag，可以支持多维度聚合统计和报警规则设置，大大提高了使用效率。 监测数据直接存储在本地时间序列数据库中。 单个实例可以处理数百万数据。 架构简单，不依赖外部存储。 单个服务器节点可以直接工作。

官方架构图如下：

4.vivo服务器监控

作为监控后台管理系统，可以进行可视化查看、报警配置、业务指标配置等，具有JVM监控、系统监控和业务监控等功能。 通过采集层（-）和数据代理层（-）的队列，实现灾难时数据的最大限度抢救。

提供SDK是为了方便业务方集成，支持日志输出过滤、入侵代码上报数据等应用层监控和统计。 基于时间序列开源数据库，修改了源码，增加了新的函数，满足内置函数的空值插入。 具有强大的数据聚合能力，可以提供实时、多维度、多渠道的报警服务。

七、总结

本文主要介绍vivo服务器监控架构的设计和演进。 是一个基于java技术栈的实时监控系统。 同时，还简单列出了业界主流的几类监控系统。 希望能够帮助大家了解监控系统，在技术选型上做出更合适的选择。

监控系统涉及面广，是一个庞大而复杂的系统。 本文仅介绍服务器端监控中的JVM监控、系统监控和业务监控（包括日志监控和工具代码的入侵报告）。 不涉及客户端监控、全链路监控等，想要理解透彻，必须理论联系实际，才能深入。

作者丨vivo互联网服务器团队-邓海波