【Rethinking IT】如何应用数据图表了解家里的 Unifi 网络状况？

admin管理员组

文章数量:1591210

1. 前言

自从之前写了《【让 IT 更简单】使用 Ubiquiti 全家桶对朋友家进行网络改造》《【Rethinking IT】如何结合 Unifi 和 MikroTik 设备打造家庭网络》两篇文章后，相信给各位正在用 Unifi 或者打算使用 Unifi 的朋友应该有所帮助。

那么，今天我就换个方向，不再讨论规划和安装 Unifi 网络设备，来研究研究如何了解家里的 Unifi 设备状况？这时候有朋友就会说，不是有 Unifi 官方的 Web 控制台，还有手机 App 嘛。没错，Unifi 在 UI 设计方面确实独树一帜，而且在其 Web 控制台和 App 中，每一个 Unifi 设备和客户端设备都有相应的 概览 页面和 洞察 页面，上面提供了 Unifi 设备和客户端设备的实时数据。但是，如果我希望研究一下某一段时间这个 Unifi 设备的历史数据，想看看这段时间该 Unifi 设备的负载情况，稳定性如何，客户端设备何时离线，是不是就无从得知了？

其实，这个需求看起来就是需要一套 监控系统 啦。那么今天，就由我来给大家 解锁 Unifi 的新玩法！

由于小弟我从未在互联网大厂 SRE 岗位工作过，只是一个小小乙方的服务器、存储设备上架搬运工，所以以下内容均为自己工作之余，在家利用 Homelab 环境瞎捣腾的，自然不是什么多高大上的东西。如果有什么写得不准确的地方，或者引用了错误的资料，还请各位大佬海涵！

2. 组件介绍

2.1. Prometheus & InfluxDB

2.1.1. 时序数据库

说 Prometheus 和 InfluxDB 之前，这里需要先提到一个概念：时序数据库 (Time Series Database，TSDB)。那么什么是时序数据库呢，此处引用 WiKi 百科的定义：

定义

A time series database is a software system that is optimized for storing and serving time series through associated pairs of time(s) and value(s). In some fields, time series may be called profiles, curves, traces or trends. Several early time series databases are associated with industrial applications which could efficiently store measured values from sensory equipment (also referred to as data historians), but now are used in support of a much wider range of applications.

什么意思呢？就是说时序数据库，它被优化成专门将一系列相关联的 “时间” 和 “数值”，进行存储和提供服务的一套软件系统。在某些领域，时间序列可能被称为剖面、曲线、轨迹或者趋势。一些早期的时间序列数据库与工业应用相关联，这些应用可以有效地存储来自传感设备的测量值，但现在用于支持更广泛的应用。

所以，时序数据其实就是随着时间不断产生的连续测量数值或者事件，时序数据库就是用来保存这些数据的手段之一。

以下引用 TDengine 官方文章中描述时序数据库的特点：

时序数据库的特点

1. 时间戳： 每个数据点都带有时间戳，这个时间戳对于数据的计算和分析十分重要。
2. 结构化： 与来自网络爬虫、微博、微信的海量数据不同，联网设备或监控系统生成的数据都是结构化的。这些数据都具有预定义的数据类型或固定长度，比如智能电表采集的电流、电压就可以用 4 字节的标准的浮点数来表示。
3. 流式： 数据源以近似恒定速率生成数据，如音频或视频流。这些数据流彼此独立。
4. 流量平稳可预测： 与电商平台或社交媒体网站的数据不同，时序数据的流量在一段时间内是稳定的，并且可以根据数据源的数量和采样周期来进行计算和预测。
5. 不变性： 时序数据一般都是 append-only，类似于日志数据，一般不容许而且也没有修改的必要。很少有场景，需要对采集的原始数据进行修改。

这么听起来，这种数据库完美契合一种系统：监控系统。

那么说到监控系统，相信不少 IT 同行可能或多或少听过 Cacti、Nagios、Zabbix 包括上面提到的 Prometheus。这其中，Cacti、Nagios、Zabbix 这 3 者，我相信曾经部署过的朋友应该都会部署 MariaDB (即 MySQL 的修改版本) 数据库。那么使用这种关系型数据库的监控系统有什么问题呢？答案是当数据量足够庞大规模的时候，这种关系型数据库就会成为整套监控系统的瓶颈之一。当然，连我都知道的事情，厂商不可能不知道，所以 Zabbix 从 4.2 版本之后开始也支持了时序数据库中的 Timscaledb。更多内容可以查阅 Zabbix 官方博客 Zabbix，时间序列数据和 TimescaleDB。

至于 Prometheus (普罗米修斯：你没听错，就是跟异形前传同名的那个普罗米修斯) 就是一款本身就是基于时序数据库打造的监控系统。在我对 Unifi 设备和 Proxmox VE 虚拟化做监控方案之前，我其实是不知道 InfluxDB 的。因为平时工作接触较多都是 VMware vSphere，而在这种商业软件的加持下，VMware 天然有自己一套完美的监控运维平台，也就是 vRealize Operations，现在改名叫 Aria Operations。所以，我在研究 Proxmox VE 监控的时候发现，数据中心 > 指标服务器 页面下就支持 Graphite 和 InfluxDB。而这俩，也都是时序数据库。

所以我就搜索了一下时序数据库发展历程，可以看到我上述提到的 Graphite、InfluxDB、Prometheus、TimeScale 都先后应运而生。

并且我还搜索了一下相关排名，DB-Engines 网站上关于时序数据库的受欢迎程度排名中，InfluxDB 目前依然是遥遥领先。那就更让我觉得我可能是需要稍微了解了解这个 InfluxDB 了。

2.1.2. Prometheus

Prometheus 受启发于 Google 的 Brogmon 监控系统 (相似的 Kubernetes 是从 Google 的 Brog 系统演变而来)，从2012年开始由前 Google 工程师在 Soundcloud 以开源软件的形式进行研发的系统监控和告警工具包，并且于 2015 年早期对外发布早期版本。自此以后，许多公司和组织都采用了 Prometheus 作为监控告警工具。Prometheus 的主要特性有：

• 一个多维数据模型，包含由 metric 和 key/value 标识的时间序列数据
• PromQL 是一种灵活的查询语言
• 不依赖分布式存储，单个服务器节点是自治的
• 基于 HTTP 协议通过 Pull 形式进行收集时间序列数据
• Push 形式的时间序列数据是通过一个中间网关来支持的
• Targets 可以通过服务发现或静态配置发现的
• 多种模式的图形和仪表盘支持

Prometheus 生态系统由多个组件组成，其中许多是可选的：

• Prometheus Server：Prometheus 主服务器，用于抓取和存储时间序列数据。
• Client Libraries：用于检测应用程序代码的库，主要用于客户端。
• Push Gateway：支持短期生命周期的作业。
• Exporter：为 HAProxy、StatsD、Graphite 等服务提供数据。
• Alert Manager：一个告警处理工具。
• 各种支持工具。

2.1.3. InfluxDB

InfluxDB 是一套由 InfluxData 公司开发的时序数据库，它具备以下特性：

• 基于 Go 语言开发，只需要二进制文件即可运行
• 针对时序数据进行快速写入
• 简单高效的 HTTP API
• 类似 SQL 的查询语法
• 能够实时查询，数据在写入时被索引后就能够被立即查出
• 支持对 Tag 建索引，实现快速有效的查询
• 数据保留策略 (Retention policies) 能够有效地使旧数据自动失效

InfluxDB 本身只是一套数据库，那么监控数据如何写入呢？Prometheus 会拉取各种 Exporter 暴露出来的 metrics 数据，而 InfluxData 公司则开发了一套整体的 TICK 堆栈 (类似 ELK：3 个字母分别代表 Elasticsearch、Kibana、Logstash)。其中：

• Telegraf：一个插件驱动的服务器代理，用于收集和报告指标。Telegraf 插件直接从其运行的系统获取各种指标，从第三方 API 中提取指标，甚至通过 StatsD 和 Kafka 消费者服务监听指标。
• Chronograf：是堆栈的管理用户界面和可视化引擎，它可以轻松设置和维护基础结构的监视和警报。
• Kapacitor：是一个数据处理引擎，它可以处理来自 InfluxDB 的流数据和批处理数据。
  

2.2. Grafana

本文标签： 图表家里状况数据网络