一年前，我们推出了一个促销项目的试点版本 .
最初，该项目被称为Road-To-Barcelona，后来变成了Road-To-Berlin（因此截图中的R2B），最后被称为xRide。
该项目的主要想法是：我们不想提供集中式汽车或踏板车租赁服务（我们谈论的是踏板车，又名电动摩托车，而不是踢踏板车/踏板车），我们想要建立一个去中心化租赁平台。 关于我们遇到的困难 .
最初，该项目专注于汽车，但由于截止日期、与制造商的沟通时间极长以及大量的安全限制，最终选择了电动滑板车作为试点。
用户在手机上安装iOS或Android应用程序，接近自己喜欢的滑板车，之后手机和滑板车建立点对点连接，交换ETH，用户可以通过打开滑板车开始骑行电话。 旅行结束时，还可以使用用户手机钱包中的以太坊支付旅行费用。
除了踏板车之外，用户还在应用程序中看到了“智能充电器”，通过访问该充电器，用户可以在当前电池电量低时自行更换。
这就是我们去年 XNUMX 月在两个德国城市波恩和柏林推出的试点项目的大致情况。
然后，有一天，在波恩，一大早，我们的支持团队（在现场维护滑板车的工作状态）接到警报：其中一辆滑板车消失得无影无踪。
如何找到并归还？
在本文中，我将讨论这一点，但首先是讨论我们如何构建自己的物联网平台以及如何监控它。
监控什么以及为何监控：踏板车、基础设施、充电站？
那么，我们想要在项目中监控什么？
首先，这些是滑板车本身 - 电动滑板车本身相当昂贵，在没有充分准备的情况下无法启动这样的项目；如果可能，您希望收集尽可能多的有关滑板车的信息：关于它们的位置、充电水平， ETC。
此外，我还想监控我们自己的 IT 基础设施的状态 - 数据库、服务以及它们工作所需的一切。 还需要监控“智能充电器”的状态，以防它们发生故障或电池电量耗尽。
滑板车
我们的滑板车是什么？我们想了解它们什么？
第一件也是最重要的事情是 GPS 坐标，因为有了它们，我们可以了解它们在哪里以及它们在哪里移动。
接下来是电池充电，通过它我们可以确定滑板车的充电即将结束并发送榨汁机或至少警告用户。
当然，还需要检查我们的硬件组件发生了什么情况：
- 蓝牙有用吗？
- GPS模块本身可以工作吗？
- 我们还遇到一个问题，即 GPS 可能会发送错误的坐标并卡住，这只能通过对踏板车进行额外检查来确定，
并尽快通知支持人员解决问题
- 我们还遇到一个问题，即 GPS 可能会发送错误的坐标并卡住，这只能通过对踏板车进行额外检查来确定，
最后：检查软件，从操作系统和处理器、网络和磁盘负载开始，最后检查我们自己的更具体的模块（, ).
硬件
我们的“铁”部分是什么？
考虑到最短的时间框架和快速原型设计的需要，我们选择了最简单的实施和组件选择选项 - Raspberry Pi。
除了 Rpi 本身之外，我们还有一块定制板（我们自己开发并从中国订购，以加快最终解决方案的组装过程）和一组组件 - 继电器（用于打开/关闭滑板车），电池充电读取器、调制解调器、天线。 所有这些都紧凑地包装在一个特殊的“xRide 盒子”中。
还应该指出的是，整个盒子由一个额外的移动电源供电，而该移动电源又由踏板车的主电池供电。
这使得即使在行程结束后也可以使用监控并打开踏板车，因为主电池在将点火钥匙转到“关闭”位置后立即关闭。
码头工人？ 普通Linux？ 和部署
让我们回到监控，那么 Raspberry - 我们有什么？
我们首先想要使用 Docker 来加速向物理设备部署、更新和交付组件的过程。
不幸的是，人们很快就发现，RPi 上的 Docker 虽然可以工作，但会产生大量开销，特别是在能源消耗方面。
使用“本机”操作系统的差异虽然不是那么大，但仍然足以让我们警惕过快失去电量的可能性。
第二个原因是我们在 Node.js 上的合作伙伴库之一（原文如此！）——系统中唯一不是用 Go/C/C++ 编写的组件。
该库的作者没有时间提供任何“本地”语言的工作版本。
不仅节点本身不是低性能设备的最优雅的解决方案，而且库本身非常消耗资源。
我们意识到，即使我们愿意，使用 Docker 对我们来说也会产生太大的开销。 我们做出了有利于本机操作系统并直接在其下工作的选择。
OS
因此，我们再次选择了最简单的选项作为操作系统并使用 Raspbian（适用于 Pi 的 Debian 版本）。
我们所有的软件都是用Go编写的，所以我们系统中的主要硬件代理模块也是用Go编写的。
他负责使用 GPS、蓝牙、读取电量、打开滑板车等。
部署
立即出现的问题是需要实现一种向设备提供更新 (OTA) 的机制 - 既更新我们的代理/应用程序本身，又更新操作系统/固件本身（因为新版本的代理可能需要更新内核）或系统组件、库等）。
经过长时间的市场分析，发现有很多为设备提供更新的解决方案。
从相对简单、主要面向更新/双启动的实用程序（如 swupd/SWUpdate/OSTree）到成熟的平台（如 Mender 和 Balena）。
首先，我们认为我们对端到端解决方案感兴趣，所以选择立即落在了平台上。
本身 被排除是因为它实际上在其 balenaEngine 中使用了相同的 Docker。
但我注意到，尽管如此，我们最终还是不断使用他们的产品 用于 SD 卡上的闪存固件 - 一个简单且极其方便的实用程序。
所以，最终的选择落在了 。 Mender 是一个用于组装、交付和安装固件的完整平台。
总体而言，该平台看起来很棒，但我们花了大约一周半的时间才使用修复构建器构建了固件的正确版本。
我们越是沉浸在其复杂的使用过程中，就越清楚地意识到，要完全部署它，我们需要比我们更多的时间。
唉，紧迫的期限意味着我们被迫放弃使用 Mender 并选择一个更简单的。
Ansible
在我们的情况下，最简单的解决方案是使用 Ansible。 几本剧本就足以开始。
它们的本质是我们只需通过 ssh 从主机（CI 服务器）连接到我们的 rasberry 并向它们分发更新。
一开始，一切都很简单 - 你必须与设备位于同一网络上，倾倒是通过 Wi-Fi 完成的。
在办公室里，只有十几个测试树莓派连接到同一网络，每个设备都有一个静态 IP 地址，也在 Ansible Inventory 中指定。
Ansible 将我们的监控代理交付给终端设备
3G / LTE
不幸的是，在我们拥有实际的滑板车之前，Ansible 的这个用例只能在开发模式下工作。
因为正如您所知，滑板车不会连接到一个 Wi-Fi 路由器，不断等待网络上的更新。
事实上，除了移动 3G/LTE 之外，踏板车根本无法进行任何连接（即使如此，也并非始终如此）。
这立即带来了许多问题和限制，例如连接速度低和通信不稳定。
但最重要的是，在 3G/LTE 网络中，我们不能简单地依赖分配给网络的静态 IP。
一些 SIM 卡提供商部分解决了这个问题；甚至有专门为具有静态 IP 地址的 IoT 设备设计的特殊 SIM 卡。 但我们无法使用此类 SIM 卡，也无法使用 IP 地址。
当然，有一些想法可以在像 Consul 这样的地方进行某种 IP 地址注册，即服务发现，但我们不得不放弃这种想法，因为在我们的测试中，IP 地址可能会经常更改，从而导致极大的不稳定。
因此，传递指标最方便的用法不是使用拉模型（我们将向设备获取必要的指标），而是使用推送模型，将指标从设备直接传递到服务器
VPN
作为这个问题的解决方案，我们选择了 VPN - 特别是 .
系统启动时的客户端（踏板车）连接到 VPN 服务器并且能够连接到它们。 该隧道用于传送更新。
理论上，同一个隧道可以用于监控，但这样的连接比简单的推送更复杂，可靠性也更低。
云资源
最后，有必要监控我们的云服务和数据库，因为我们使用 Kubernetes 来监控它们，理想情况下，以便在集群中部署监控尽可能简单。 理想情况下，使用 ，因为对于部署，我们在大多数情况下都会使用它。 当然，要监控云，您需要使用与踏板车本身相同的解决方案。
给定
呼，我们好像已经把描述整理好了，让我们把最后需要的东西列出来：
- 快速解决方案，因为在开发过程中就需要进行监控
- 数量/数量——需要许多指标
- 需要收集日志
- 可靠性 - 数据对于发射成功至关重要
- 你不能使用拉模型 - 你需要推
- 我们不仅需要硬件的统一监控，还需要云的统一监控
最终图像看起来像这样
堆栈选择
因此，我们面临着选择监控堆栈的问题。
首先，我们正在寻找最完整的一体化解决方案，既能同时满足我们的所有要求，又能足够灵活，能够根据我们的需求定制其使用。 尽管如此，我们仍然受到硬件、架构和截止日期的许多限制。
有各种各样的监控解决方案，从成熟的系统开始，例如 , или 最后提供现成的车队管理解决方案。
最初，后者对我们来说似乎是一个理想的解决方案，但有些没有完全监控，有些免费版本的功能受到严重限制，有些根本无法满足我们的“需求”，或者不够灵活，无法适应我们的场景。 有些已经过时了。
在分析了许多类似的解决方案后，我们很快得出结论：我们自己组装一个类似的堆栈会更容易、更快捷。 是的，这比部署完全现成的车队管理平台要复杂一些，但我们不必做出妥协。
几乎可以肯定的是，在所有大量的解决方案中，已经有一个现成的解决方案完全适合我们，但就我们而言，自行组装某个堆栈并“为我们自己”定制它要快得多，而不是更快。测试现成的产品。
有了这一切，我们并没有努力自己组装整个监控平台，而是寻找功能最强大的“现成”堆栈，只需能够灵活配置它们。
(B)埃尔克？
第一个真正考虑的解决方案是著名的 ELK 堆栈。
其实它应该叫BELK，因为这一切都始于Beats -
当然，ELK是监控领域最著名、最强大的解决方案之一，在日志收集和处理方面更是如此。
我们打算使用 ELK 来收集日志并长期存储从 Prometheus 获得的指标。
对于可视化，您可以使用 Grafan。
事实上，新的 ELK 堆栈可以独立收集指标（metricbeat），Kibana 也可以显示它们。
但是，ELK 最初是从日志中发展而来的，到目前为止，指标的功能存在许多严重的缺陷：
- 比 Prometheus 慢很多
- 集成的地方比 Prometheus 少得多
- 为他们设置警报很困难
- 指标占用大量空间
- 在 Kiban 中设置带有指标的仪表板比在 Grafan 中复杂得多
总的来说，ELK 中的指标比较重，而且还没有其他解决方案那么方便，其中现在不仅仅是 Prometheus：TSDB、Victoria Metrics、Cortex 等。 当然，我真的很想立即拥有一个成熟的一体化解决方案，但对于 metricbeat 来说，有太多的妥协。
而 ELK 堆栈本身也有很多困难时刻：
- 它很重，如果您收集相当大量的数据，有时甚至会非常重
- 你需要“知道如何烹饪”它——你需要扩展它，但这并不是一件容易的事
- 精简免费版本 - 免费版本没有正常警报，并且在选择时没有身份验证
我必须说，最近最后一点已经变得更好了，另外 （包括认证）定价模式本身开始发生变化。
但当我们准备部署这个解决方案时，根本没有任何警报。
也许我们可以尝试使用 ElastAlert 或其他社区解决方案来构建一些东西，但我们仍然决定考虑其他替代方案。
洛基 - 格拉法纳 - 普罗米修斯
目前，一个好的解决方案可能是构建一个纯粹基于 Prometheus 作为指标提供者的监控堆栈，Loki 用于日志，而对于可视化，您可以使用相同的 Grafana。
不幸的是，在项目销售试点开始时（19 年 0.3 月至 0.4 月），Loki 仍处于 beta 版本 XNUMX-XNUMX，并且在开发开始时不能将其视为生产解决方案根本不。
我还没有在严肃的项目中实际使用 Loki 的经验，但我可以说 Promtail（收集日志的代理）对于 kubernetes 中的裸机和 pod 都非常有效。
蜱
也许 ELK 堆栈最有价值（唯一？）的全功能替代品现在只能称为 TICK 堆栈 - Telegraf、InfluxDB、Chronograf、Kapacitor。
我将更详细地描述下面的所有组件，但总体思路是这样的：
- Telegraf - 收集指标的代理
- InfluxDB - 指标数据库
- Kapacitor - 用于警报的实时指标处理器
- Chronograf - 用于可视化的网络面板
对于 InfluxDB、Kapacitor 和 Chronograf，我们使用官方 helm 图表来部署它们。
需要注意的是，在最新版本的 Influx 2.0（beta）中，Kapacitor 和 Chronograf 成为了 InfluxDB 的一部分，不再单独存在
电报
是一个非常轻量级的代理，用于收集状态机上的指标。
他可以监控大量的一切，从 对
伺服器 .
它有许多很酷的优点：
- 快速且轻量级（用 Go 编写）
- 消耗最少的资源
- 默认推送指标
- 收集所有必要的指标
- 无需任何设置的系统指标
- 硬件指标，例如来自传感器的信息
- 添加您自己的指标非常容易
- 许多开箱即用的插件
- 收集日志
由于推送指标对我们来说是必要的，所以所有其他优势都不仅仅是令人愉快的补充。
代理本身收集日志也非常方便，因为不需要连接额外的实用程序来记录日志。
如果您使用，Influx 将为您提供最便捷的日志处理体验 .
Telegraf 通常是收集指标的绝佳代理，即使您不使用 ICK 堆栈的其余部分也是如此。
为了方便起见，许多人将它与 ELK 和其他各种时间序列数据库交叉使用，因为它几乎可以在任何地方编写指标。
数据库
InfluxDB是TICK堆栈的主要核心，即指标的时间序列数据库。
除了指标之外，Influx 还可以存储日志，尽管从本质上来说，它的日志只是同样的指标，只是代替了通常的数字指标，主要功能是通过一行日志文本来完成的。
InfluxDB 也是用 Go 编写的，在我们（不是最强大的）集群上，与 ELK 相比，它的运行速度似乎要快得多。
Influx 的一大优势还包括非常方便且丰富的数据查询 API，我们非常积极地使用它。
缺点 - $$$ 还是缩放？
我们发现 TICK 堆栈只有一个缺点 - 它 亲爱。 更。
付费版本有哪些免费版本没有的功能？
据我们所知，TICK 堆栈的付费版本和免费版本之间的唯一区别是扩展能力。
也就是说，您只能在以下情况下建立具有高可用性的集群： .
如果你想要完整的HA，你要么需要付费，要么使用一些拐杖。 有一些社区解决方案 - 例如 看起来像是一个有效的解决方案，但据报道它不适合生产，以及
- 一个简单的解决方案，通过 NATS 进行数据泵送（它还必须进行扩展，但这可以解决）。
很遗憾，但它们似乎都被放弃了 - 没有新的提交，我认为问题是即将发布的新版本 Influx 2.0，其中很多事情都会有所不同（没有关于尚未缩放）。
官方有免费版本 - 事实上，这是一个原始的HA，但只是通过平衡，
因为所有数据都将写入负载均衡器后面的所有 InfluxDB 实例。
他有一些 例如覆盖点的潜在问题以及提前创建指标基础的需要
（这在 InfluxDB 正常工作期间自动发生）。
除了 ，这意味着您可能不需要的重复指标（处理和存储）的额外开销，但无法将它们分开。
维多利亚指标？
因此，尽管事实上我们对 TICK 堆栈除了付费扩展之外的所有方面都完全满意，但我们决定看看是否有任何免费解决方案可以替代 InfluxDB 数据库，同时保留剩余的 T_CK 组件。
时序数据库有很多，但最有前途的是Victoria Metrics，它有很多优点：
- 快速而简单，至少从结果来看是这样
- 有一个集群版本，现在甚至有很好的评论
- 她可以分片
- 支持InfluxDB协议
我们并不打算基于 Victoria 构建一个完全自定义的堆栈，主要希望是我们可以使用它作为 InfluxDB 的直接替代品。
不幸的是，这是不可能的，尽管事实上支持 InfluxDB 协议，但它仅适用于记录指标 - 只有 Prometheus API 在“外部”可用，这意味着无法在其上设置 Chronograf。
此外，指标仅支持数字值（我们对自定义指标使用字符串值 - 更多内容请参见参考资料部分） ).
显然，出于同样的原因，VM无法像Influx那样存储日志。
另外，需要注意的是，在寻找最优解时，Victoria Metrics 还没有那么流行，文档小得多，功能也较弱
（我不记得集群版本和分片的详细描述）。
基地选择
因此，我们决定在试点中仍然将自己限制在单个 InfluxDB 节点。
做出这样的选择有几个主要原因：
- 我们真的很喜欢 TICK 堆栈的全部功能
- 我们已经成功部署它并且效果很好
- 最后期限已经过去，没有太多时间来测试其他选项。
- 我们没想到负载这么重
我们在第一阶段的试点中没有太多滑板车，开发过程中的测试也没有发现任何性能问题。
因此，我们决定对于这个项目来说，一个 Influx 节点就足够了，不需要扩展（见最后的结论）。
我们已经决定了堆栈和基础 - 现在关于 TICK 堆栈的其余组件。
电容器
Kapacitor 是 TICK 堆栈的一部分，该服务可以实时监控进入数据库的指标并根据规则执行各种操作。
总的来说，它被定位为潜在异常跟踪和机器学习的工具（我不确定这些功能是否有需求），但它最流行的使用场景更为常见——警报。
这就是我们将其用于通知的方式。 当特定踏板车离线时，我们设置了 Slack 警报，智能充电器和重要基础设施组件也做了同样的事情。
这使得快速响应问题以及接收一切恢复正常的通知成为可能。
一个简单的例子：为我们的“盒子”供电的额外电池已损坏或由于某种原因耗尽了电量；只需安装新电池，一段时间后我们应该会收到一条通知，告知滑板车的功能已恢复。
在 Influx 2.0 中 Kapacitor 成为 DB 的一部分
计时表
我见过许多不同的监控 UI 解决方案，但我可以说，就功能和用户体验而言，没有什么能与 Chronograf 相比。
奇怪的是，我们开始使用 TICK 堆栈，并使用 Grafan 作为 Web 界面。
我不会描述它的功能；每个人都知道它设置任何东西的广泛可能性。
然而，Grafana 仍然是一款完全通用的仪器，而 Chronograf 主要是为与 Influx 配合使用而设计的。
当然，正因为如此，Chronograf 可以提供更聪明或更方便的功能。
也许使用 Chronograf 的主要便利在于您可以通过 Explore 查看 InfluxDB 的内部。
看起来 Grafana 具有几乎相同的功能，但实际上，只需点击几下鼠标即可在 Chronograf 中设置仪表板（同时查看那里的可视化效果），而在 Grafana 中您迟早还是会拥有编辑 JSON 配置（当然，Chronograf 允许上传您手动配置的 dashas 并在必要时将它们编辑为 JSON - 但在 UI 上创建它们后我从来不需要碰它们）。
Kibana 具有更丰富的功能来创建仪表板和控件，但此类操作的用户体验非常复杂。
创建方便的仪表板需要一些良好的理解。 尽管 Chronograf 仪表板的功能较少，但制作和定制它们却要简单得多。
仪表板本身除了令人愉悦的视觉风格之外，实际上与 Grafana 或 Kibana 中的仪表板没有什么不同：
查询窗口如下所示：
值得注意的是，除其他外，了解 InfluxDB 数据库中的字段类型，计时器本身有时可以自动帮助您编写查询或选择正确的聚合函数（例如平均值）。
当然，Chronograf 可以尽可能方便地查看日志。 它看起来像这样：
默认情况下，Influx 日志被定制为使用 syslog，因此它们有一个重要的参数 - 严重性。
顶部的图表特别有用；在上面您可以看到发生的错误，并且颜色会立即清楚地显示严重性是否较高。
有几次我们通过这种方式发现了重要的错误，查看上周的日志并看到红色尖峰。
当然，理想情况下应该为此类错误设置警报，因为我们已经拥有了这方面的一切。
我们甚至将其打开了一段时间，但在准备试点的过程中，我们发现出现了很多错误（包括 LTE 网络不可用等系统错误），这也给 Slack 通道带来了“垃圾邮件”多了，却没有带来太大的好处。
正确的解决方案是处理大多数此类错误，调整其严重性，然后才启用警报。
这样，只有新的或重要的错误才会发布到 Slack。 由于期限紧迫，根本没有足够的时间进行这样的设置。
认证
还值得一提的是，Chronograf 支持 OAuth 和 OIDC 作为身份验证。
这非常方便，因为它允许您轻松地将其连接到服务器并创建成熟的 SSO。
在我们的例子中，服务器是 — 它用于连接到监控，但同一台服务器也用于验证滑板车和向后端发出的请求。
“行政”
我要描述的最后一个组件是我们在 Vue 中自己编写的“管理面板”。
基本上，它只是一个独立的服务，可以同时显示来自我们自己的数据库、微服务的滑板车信息以及来自 InfluxDB 的指标数据。
此外，许多管理功能也移至此处，例如紧急重启或为支持团队远程开锁。
还有地图。 我已经提到过，我们从 Grafana 而不是 Chronograf 开始 - 因为 Grafana 地图以插件的形式提供，我们可以在其中查看滑板车的坐标。 不幸的是，Grafana 的地图小部件的功能非常有限，因此，在几天内用地图编写自己的 Web 应用程序要容易得多，以便不仅可以看到当前的坐标，还可以显示滑板车所走的路线，能够过滤地图上的数据等（所有这些功能我们无法在简单的仪表板中配置）。
Influx 已经提到的优点之一是能够轻松创建自己的指标。
这使得它可以用于各种各样的场景。
我们试图在那里记录所有有用的信息：电池电量、锁定状态、传感器性能、蓝牙、GPS 和许多其他健康检查。
我们在管理面板上显示了所有这些。
当然，对我们来说最重要的标准是滑板车的运行状况 - 事实上，Influx 会自行检查这一点，并在节点部分用“绿灯”显示它。
这是通过函数完成的 — 我们用它来了解盒子的性能并向 Slack 发送相同的警报。
顺便说一下，我们以《辛普森一家》中角色的名字来命名滑板车 - 这样很方便区分它们
总的来说，这种方式更有趣。 经常听到诸如“伙计们，史密瑟斯死了！”之类的话。
字符串指标
重要的是，InfluxDB 不仅允许您存储数值，就像 Victoria Metrics 的情况一样。
看起来这并不是那么重要——毕竟，除了日志之外，任何指标都可以以数字的形式存储（只需添加已知状态的映射——一种枚举）？
在我们的案例中，至少在一种情况下字符串指标非常有用。
恰好我们的“智能充电器”的供应商是第三方，我们无法控制开发过程以及这些充电器可以提供的信息。
结果，收费 API 远非理想，但主要问题是我们无法始终了解它们的状态。
这就是 Influx 来拯救的地方。 我们只是将收到的字符串状态写入 InfluxDB 数据库字段中，无需进行任何更改。
有一段时间，只有“在线”和“离线”等值出现，根据这些信息显示在我们的管理面板中，并将通知发送到 Slack。 然而，在某些时候，像“断开连接”这样的价值观也开始出现在那里。
后来发现，如果充电器在一定次数的尝试后仍无法与服务器建立连接，则在连接丢失后会发送一次此状态。
因此，如果我们只使用一组固定的值，我们可能无法在正确的时间看到固件中的这些变化。
一般来说，字符串指标提供了更多的使用可能性；您几乎可以在其中记录任何信息。 当然，您也需要小心使用这个工具。
除了通常的指标之外，我们还在 InfluxDB 中记录了 GPS 位置信息。 这对于在我们的管理面板中监控滑板车的位置非常有用。
事实上，我们总是知道我们需要的时候在哪里以及哪辆踏板车。
当我们寻找踏板车时，这对我们非常有用（见最后的结论）。
基础设施监控
除了滑板车本身之外，我们还需要监控整个（相当广泛的）基础设施。
一个非常通用的架构看起来像这样：
如果我们突出显示一个纯粹的监控堆栈，它看起来像这样：
我们想要在云中检查的是：
- 数据库
- 钥匙斗篷
- 微服务
由于我们所有的云服务都位于 Kubernetes 中，因此收集有关其状态的信息会很好。
幸运的是，Telegraf 开箱即用，可以收集大量有关 Kubernetes 集群状态的指标，而 Chronograf 立即为此提供了漂亮的仪表板。
我们主要监控 Pod 的性能和内存消耗。 如果发生跌倒，Slack 会发出警报。
Kubernetes 中有两种跟踪 Pod 的方法：DaemonSet 和 Sidecar。
两种方法都有详细描述 .
我们使用 Telegraf Sidecar，除了指标之外，还收集了 Pod 日志。
在我们的例子中，我们必须修改日志。 尽管 Telegraf 可以从 Docker API 中提取日志，但我们希望通过终端设备收集统一的日志，并为此为容器配置 syslog。 也许这个解决方案并不美观，但对其工作没有任何抱怨，并且日志在 Chronograf 中显示得很好。
监控监控？？？
最终，监控系统的老问题出现了，但幸运的是，或者不幸的是，我们根本没有足够的时间来解决这个问题。
尽管 Telegraf 可以轻松发送自己的指标或从 InfluxDB 数据库收集指标，以便发送到同一个 Influx 或其他地方。
发现
我们从试点结果中得出了什么结论？
怎样才能进行监控呢？
首先，TICK堆栈完全满足了我们的期望，并给了我们比我们最初预期更多的机会。
我们需要的所有功能都已具备。 我们用它做的一切都没有问题。
Производительность
免费版本中 TICK 堆栈的主要问题是缺乏扩展功能。 这对我们来说不是问题。
我们没有收集准确的负载数据/数字，但我们一次收集了大约 30 辆踏板车的数据。
他们每个人都收集了三打以上的指标。 同时，收集设备的日志。 数据收集和发送每 10 秒发生一次。
需要注意的是，经过一周半的试点，当大部分“童年问题”得到纠正并且最重要的问题已经解决时，我们不得不减少向服务器发送数据的频率30秒。 这是必要的，因为我们的 LTE SIM 卡上的流量开始迅速消失。
大部分流量被日志消耗；指标本身，即使间隔 10 秒，实际上也不会浪费流量。
结果，一段时间后，我们完全禁用了设备上的日志收集，因为即使没有持续收集，具体问题也已经很明显了。
在某些情况下，如果仍然需要查看日志，我们只需通过 VPN 通过 WireGuard 进行连接即可。
我还要补充一点，每个单独的环境都是相互分离的，并且上述负载仅与生产环境相关。
在开发环境中，我们提出了一个单独的 InfluxDB 实例，该实例继续每 10 秒收集一次数据，并且没有遇到任何性能问题。
TICK - 中小型项目的理想选择
根据这些信息，我得出的结论是，TICK 堆栈非常适合相对较小的项目或绝对不期望任何 HighLoad 的项目。
如果您没有数千个 pod 或数百台机器，即使一个 InfluxDB 实例也能很好地处理负载。
在某些情况下，您可能对 Influx Relay 作为原始高可用性解决方案感到满意。
当然，没有人会阻止您设置“垂直”扩展并简单地为不同类型的指标分配不同的服务器。
如果您不确定监控服务的预期负载，或者您保证拥有/将拥有一个非常“重”的架构，我不建议使用免费版本的 TICK 堆栈。
当然，一个简单的解决方案是购买 - 但在这里我无法发表评论，因为我自己并不熟悉其中的微妙之处。 除此之外，它非常昂贵，绝对不适合小公司。
在这种情况下，今天我建议通过 Victoria Metrics 收集指标并使用 Loki 收集日志。
确实，我会再次预约，Loki/Grafana 比现成的 TICK 方便得多（因为它们具有更大的多功能性），但它们是免费的。
这一点很重要：这里描述的所有信息都与 Influx 1.8 版本相关，目前 Influx 2.0 即将发布。
虽然我还没有机会在战斗条件下尝试它，并且很难得出关于改进的结论，但界面肯定变得更好，架构已经简化（没有 kapacitor 和 chronograf），
模板出现（“杀手级功能”- ）。 但不幸的是，目前，版本 2 没有我们选择第一个版本的关键点 - 没有日志收集。
该功能也将出现在 Influx 2.0 中，但我们找不到任何截止日期，甚至是大概的截止日期。
如何不打造物联网平台（现在）
最后，在启动试点后，在没有适合我们标准的替代方案的情况下，我们自己组装了自己成熟的物联网堆栈。
不过，最近它推出了 Beta 版本 - 遗憾的是，当我们开始制作这个项目时，她不在场。
我们对最终结果以及我们自己组装的基于 Ansible + TICK + WireGuard 的平台非常满意。 但今天，我建议您在尝试自己构建自己的物联网平台之前仔细研究一下 Balena。
因为最终它可以完成我们所做的大部分事情，而且 OpenBalena 是免费且开源的。
它不仅知道如何发送更新，而且还内置了 VPN 并为在物联网环境中使用而量身定制。
就在最近，他们甚至发布了他们的 ，可以轻松连接到他们的生态系统。
嘿，失踪的踏板车怎么办？
于是，“拉尔夫”摩托车就消失得无影无踪。
我们立即跑去查看“管理面板”中的地图，其中包含来自 InfluxDB 的 GPS 指标数据。
通过监控数据，我们轻松确定该车于前一天21:00左右离开停车场，行驶了约半小时到达某区域，并在某德国房屋旁停至凌晨5点。
凌晨 5 点之后，没有收到任何监控数据——这意味着要么额外的电池完全耗尽，要么攻击者终于找到了如何从滑板车上移除智能硬件的方法。
尽管如此，警方仍然被传唤到滑板车所在的地址。 滑板车不在那里。
不过，屋主也对此感到惊讶，因为他昨晚竟然骑着这辆踏板车从办公室回家。
事实证明，一名支持员工一早就到达并拿起了踏板车，发现其额外的电池已完全耗尽，并将其（步行）带到了停车场。 并且附加电池因受潮而失效。
我们偷了自己的踏板车。 顺便说一句，我不知道后来如何以及由谁解决了警察案件的问题，但监控效果很好......
来源： habr.com