为数据下采样设计物联网网关设备

导航至

物联网数据部署的架构方式有很多种,适合一家企业的方案不一定适合另一家。根据您物联网项目的规模和复杂性,可能会有很多组件。其中一种更为通用的架构是将传感器枢纽或物联网网关设备部署来收集多个传感器节点上的数据,然后将其转发到企业的上游数据收集系统。这些网关或枢纽设备通常允许ZWave设备连接到互联网进行数据上传,或者将蓝牙设备与WiFi或其他网络连接桥接。

此外,大多数这些网关或枢纽设备通常都是“哑”网关。它们除了将数据转发到上游收集器外,不做任何事情。但如果物联网网关可以是一个智能设备呢?如果可以在将数据转发之前在网关设备上进行本地分析和数据处理呢?这难道不是很有用吗!

构建网关

今天早上,我决定构建(另一个)物联网智能网关设备。我以前(某种程度)构建过一个基于运行InfluxDB的ARTIK-520。但ARTIK-520并不便宜,而当您构建物联网设备时,有时候更便宜是更好的选择。并不总是这样,但当您构建大量网关时,您可能不希望在这方面花费太多。我翻出了几年前买的Pine-64盒子,开始工作。为什么选择Pine-64而不是树莓派?因为Pine-64大约是树莓派的一半价格。是的,一半的价格。它是15美元而不是35美元,所以这是一个原因。它拥有相同的ARM A53四核1.2 GHz处理器——我的有2GB的内存,而树莓派只有1GB——如果对GPU有兴趣的话,它还有更强大的GPU。它还内置了WiFi,因此无需外接,我还配备了可选的ZWave板,以便我可以与亚GHz物联网设备通信。

运行这类设备作为物联网网关的其中一个优点是,您的存储限制仅由所使用的microSD卡的容量决定。我只使用了16GB的卡,但Pine-64可以支持高达256GB的卡。

要在Pine-64上启动和运行TICK Stack需要什么?不出所料,实现的时间非常短!一旦你的Pine-64设备启动运行——我建议使用Xenial镜像,因为它是最官方的Pine-64镜像,而且是Ubuntu,所以用InfluxDB进行操作非常简单。别忘了运行

apt-get upgrade

一旦它启动运行,确保一切更新到最新。

接下来,将Influx仓库添加到apt-get

curl -sL https://repos.influxdata.com/influxdb.key | apt-key add -
source /etc/lsb-release
echo "deb https://repos.influxdata.com/${DISTRIB_ID,,} ${DISTRIB_CODENAME} stable" | tee -a /etc/apt/sources.list

你可能需要用sudo运行这些命令,但我为了方便起见,先运行‘sudo bash’,然后一切就绪。

接下来,你需要添加一个包,这个包是必需的,以便访问InfluxData仓库

apt-get install apt-transport-https

然后,你就可以开始了!

apt-get install influxdb chronograf telegraf kapacitor

现在你就可以使用了!

 对设备进行负载测试

我决定对这个小巧的设备进行负载测试,看看它能处理什么,所以我从GitHub下载了‘influx-stress’并运行了对这个设备的测试。

Using batch size of 10000 line(s)
Spreading writes across 100000 series
Throttling output to ~200000 points/sec
Using 20 concurrent writer(s)
Running until ~18446744073709551615 points sent or until ~2562047h47m16.854775807s has elapsed

哇……每秒200,000个点!这应该会对我的小Pine-64造成很大的压力!结果证明它确实是这样

SafariScreenSnapz005

正如你所见,它很快就用完了2GB的内存,CPU也被占满到了100%。但在实际生活中,作为网关设备,它不太可能遇到这样的负载。我认为,如果只是从几十到可能一百多个传感器收集数据,作为网关的实际使用,我会很好地控制在我的范围内。

本地分析

正如你从上面的仪表板中可以看到,我可以在Pine-64上轻松进行一些本地分析。它有一个内置的HDMI接口和完整的GPU,所以允许本地访问仪表板进行监控非常简单。但正如我之前所说,如果设备能做的不仅仅是这些,那就更有用了。在现实世界中,你不太可能在一个网关设备上收集所有数据并做所有的分析等。这不是网关/集线器的作用。一些本地分析、警报等是好的——在可能的情况下,将一些处理推向边缘——但你仍然想将数据传输到上游。

对物联网数据进行降采样

使用网关设备简单地转发所有数据到上游是非常容易的,但如果你正在处理网络连接问题,或者你正在尝试节省金钱或带宽,或者两者都需要,你将在转发数据之前想要进行一些数据降采样。幸运的是,这也非常容易做!一个可以进行本地分析、处理一些本地警报,并在将数据向上游转发之前进行降采样的网关设备在物联网中非常有用。这也相当简单!

首先,让我们设置我们的网关设备,使其能够将数据向上游转发到InfluxDB的另一个实例。有几种方法可以做到这一点,但因为我们将通过Kapacitor进行一些数据降采样,所以我们将通过kapacitor.conf文件来做到这一点。kapacitor.conf文件已经有一个包含[[influxdb]]条目的节,为‘localhost’,所以我们只需要为上游实例添加一个新的[[influxdb]]节

[[influxdb]]
 enabled = true
 name = "mycluster"
 default = false
 urls = ["http://192.168.1.121:8086"]
 username = ""
 password = ""
 ssl-ca = ""
 ssl-cert = ""
 ssl-key = ""
 insecure-skip-verify = false
 timeout = "0s"
 disable-subscriptions = false
 subscription-protocol = "http"
 subscription-mode = "cluster"
 kapacitor-hostname = ""
 http-port = 0
 udp-bind = ""
 udp-buffer = 1000
 udp-read-buffer = 0
 startup-timeout = "5m0s"
 subscriptions-sync-interval = "1m0s"
 [influxdb.excluded-subscriptions]
 _kapacitor = ["autogen"]

这解决了部分问题。现在我们需要实际降采样数据并转发。由于我使用的是Chronograf v1.3.10,所以我有一个内置的TICKscript编辑器,所以我将转到Chronograf的“警报”选项卡,创建一个新的TICK脚本,并选择telegraf.autoget数据库作为我的数据源

 

create

我实际上还没有在这台设备上收集传感器数据,所以我将使用CPU使用率作为我的数据,并在TICKScript中进行降采样。我已经编写了一个非常基础的TICKScript来降采样我的CPU数据并将其转发到上游

stream
 |from()
 .database('telegraf')
 .measurement('cpu')
 .groupBy(*)
 |where(lambda: isPresent("usage_system"))
 |window()
 .period(1m)
 .every(1m)
 .align()
 |mean('usage_system')
 .as('mean_usage_system')
 |influxDBOut()
 .cluster('mycluster')
 .create()
 .database('downsample')
 .retentionPolicy('autogen')
 .measurement('mean_cpu_idle')
 .precision('s')

该脚本只是每分钟取CPU测量的‘usage_system’字段,计算平均值,然后将该值写入上游的InfluxDB实例。在网关设备上,CPU数据如下

Raw

我在上游实例上的降采样数据如下

Downsample

这是相同的数据,但粒度更小。最后,我将设置网关设备上的数据保留策略为仅1天,这样就不会填满设备,但我仍然可以保留一些本地历史记录

 

现在,我有一个可以收集本地传感器数据、向本地用户提供一些分析、进行一些本地警报(一旦我设置了一些Kapacitor警报)的物联网网关设备,然后将本地数据降采样并发送到我的企业InfluxDB实例以进行进一步分析和处理。我可以在网关设备上提供高度粒度的毫秒级数据,在上游设备上提供较低粒度的1分钟数据,这样我仍然可以洞察本地传感器,而无需支付发送所有数据的带宽费用。

我还可以使用这种方法通过在区域InfluxDB实例上存储1分钟数据,并将进一步降采样的数据转发到可以聚合我整个企业传感器数据的InfluxDB实例来进一步链式存储数据。

可以将所有数据发送到最终的企业数据聚合器,但如果我要聚合成千上万的传感器及其数据,存储和带宽成本可能会开始超过数据高度粒度的有用性。

结论

我经常重复这一点,可能不得不把它纹在我的额头,但我会再说一遍:物联网数据只有在及时、准确、可操作的情况下才有用。数据越旧,其可操作性就越低。其可操作性越低,所需细节就越少。降采样您的数据,并在前进的过程中设置越来越长的数据保留策略,可以确保您的高度即时数据具有高度的特定性和准确性,同时保留数据中的长期趋势,以进行长期趋势分析。