除了一体化代码之外，我们的项目还有许多微服务支持。他们每个都需要被监控。由DevOps工程师监控它们几乎是不可能的。我们开发了一个监控系统，作为开发人员的服务。他们可以自己配置监控系统中的指标，使用它们，构建基于指标的仪表板，设置由阈值触发的警报。DevOps工程师唯一必须提供的是基础设施和文档。
这篇博文是我在RIT++ section的演讲稿。我们收到了有关RIT ++演示文稿版本的多个查询。如果您参加了会议或观看了视频，您几乎找不到任何新内容。否则，请欣赏此博文。我会告诉你我们是如何得出这个解决方案的，它是如何工作的，以及我们计划如何更新它。
过去：布局和计划
我们是如何到达现有的监控系统的？为了回答这个问题，我们需要回到2015年。以下是它的回顾：
我们有24个节点负责监控。有一大堆crons，脚本和所有类型的守护进程以某种方式监视某些内容，发送消息，执行其他功能。我们意识到，我们走的路越走越远，系统的增长就越不可持续。开发系统没有意义 - 它太麻烦了。
我们决定选择那些我们将保留和开发的监控元素，以及那些将被删除的元素。选择保留19个元素。那些仅包括Graphites，aggregators和Grafana作为仪表板。但新系统会是什么样子？喜欢这个：
我们有一个指标存储库 - 快速SSD磁盘和指标聚合器上的Graphites。此外，Grafana用于显示仪表板和Moira用于警报功能。我们还想开发一种寻找异常的系统。
标准：监控2.0
这就是我们2015年的计划。但我们不仅要开发基础设施和服务本身，还要开发文档。我们开发了一个企业标准，称之为Monitoring 2.0。系统要求是这样的：
- 全天候可用性，
- 指标存储间隔= 10秒，
- 指标和仪表板的结构化存储，
- SLA> 99.99％，
- 通过UDP收集事件指标!
我们需要UDP，因为我们有大量流量和指标生成的多个事件。如果它们都立即存储在Graphite中，则存储库将崩溃。我们还为所有指标选择了第一级前缀。
每个前缀都有一些属性。我们有服务器，网络，容器，资源，应用程序等的指标。有一种清晰，严格，典型的过滤方法，我们保留第一级指标并放弃其他指标。这就是我们在2015年看到这个系统的方式。今天它看起来像什么？
今天：监控组件之间的互动
首先，我们监控应用程序 - 我们的PHP代码，应用程序和微服务 - 简而言之，我们的开发人员编码的所有内容。所有应用程序都通过UDP将指标发送到Brubeck聚合器（statsd，用C重写）。它被证明是合成测试中最快的。Brubecks通过TCP将聚合的指标发送到Graphite。
它有一种特殊的指标 - 计时器。它们非常方便。例如，对于服务的每个用户连接，您都会将响应时间度量标准发送给Brubeck。即使有一百万个响应，聚合器也只生成10个指标。您有访问者数量，最大，最小和平均响应时间，中值和4百分位数。然后数据被传输到Graphite，我们看到它全部存在。
我们还汇总了硬件和软件指标，系统指标以及我们的传统监控系统Munin（我们使用它直到2015年）。我们使用C守护进程CollectD收集所有这些内容（它嵌入了一整套插件，可以查询安装它的主机系统的任何资源，并且您只需要在配置中指定数据应该写入）并发送石墨的数据。它还支持python插件和shell脚本，因此您可以开发自定义解决方案：CollectD将从本地或远程主机收集数据（让我们假设有一个Curl）并将其发送到Graphite。
然后，所有收集的指标将被发送到Carbon-c-relay。它是Graphite的Carbon Relay解决方案，在C中进行了修改。它是一个路由器，它收集我们从聚合器发送的所有指标并将它们路由到节点。路由时，它会检查指标的有效性。首先，它们必须与上面显示的前缀布局匹配，其次，它们必须对Graphite有效。否则，它们会被丢弃。
然后，Carbon-c-relay将指标发送到Graphite集群。作为主要度量标准库，我们使用Go中修改的Carbon-cache。由于其多线程功能，Go-carbon比Carbon-cache强大得多。它接收数据并使用whisper包（标准包，用python编写）将其写入磁盘。要从我们的存储库中读取数据，我们使用Graphite API。它比标准的Graphite WEB快得多。接下来的数据会发生什么？
数据被发送到Grafana。作为主要数据源，我们使用Graphite集群，我们将Grafana作为Web界面，用于显示指标和构建仪表板。对于他们的每项服务，开发人员都会构建自己的仪表板。然后，他们绘制图表，显示从他们的应用程 除了Grafana，我们还有SLAM。这是一个python守护程序，用于根据Graphite的数据计算SLA。正如我所说，我们有几十个微服务，每个微服务都有其特定的要求。使用SLAM，我们检查文档，将其与Graphite的数据进行比较，并评估我们服务的可用性级别是否符合规范。
警报是下一步。它使用强大的系统 - Moira构建。它是自主的，因为它在引擎盖下有自己的石墨。它由SKB Kontur团队开发，用Python和Go编写，是100％开源的。Moira接收进入Graphites的相同流。如果由于某种原因，存储库已关闭，则警报功能仍将起作用。
我们在Kubernetes中部署了Moira，作为主数据库，它使用了一组Redis服务器。因此，我们有一个容错系统。它将度量流与触发器列表进行比较：如果没有提及，则会丢弃度量标准。因此它能够每分钟处理数十亿字节的指标。
我们还添加了一个公司LDAP，借助该公司LDAP，公司系统的任何用户都可以为现有（或新）触发器设置通知。由于Moira包含Graphite，它支持其所有功能。所以，首先你选择一条线并将其复制到Grafana中。检查数据在图表中的显示方式。然后将同一行复制到Moira。设置限制，现在您有一个提醒。要做到这一切，你不需要任何特殊技能。Moira可以通过短信，电子邮件，Jira，Slack等发送警报。它还支持自定义脚本的执行。当它被触发并订阅自定义脚本或二进制文件时，它会启动二进制文件并将JSON发送到二进制文件的stdin。你的程序必须解析它。这取决于您如何处理JSON。将其发送到Telegram，在Jira中打开任务，或者做任何你想做的事。
对于警报功能，我们还使用我们的专有解决方案 - Imagotag。我们根据我们的需求调整了通常用于商店中电子价格标签的面板。我们用它来显示Moira触发器。它表明了他们的状态和时间。我们的一些开发人员已取消订阅Slack的通知和电子邮件，以支持此仪表板。
由于我们是面向未来的业务，我们也使用该系统来监控Kubernetes。我们使用Heapster将它添加到系统中，我们在集群中安装它以收集数据并将其发送到Graphite。生成的布局如下所示：
监控组件
以下是我们用于执行此操作的组件的链接列表。它们都是开源的。
Graphite:
- go-carbon：github.com/lomik/go-carbon
- whisper: github.com/graphite-project/whisper
- graphite-api: github.com/brutasse/graphite-api
Carbon-c-relay:
Brubeck:
Collectd:
Moira:
Grafana:
Heapster:
统计
以下是我们系统的一些性能统计数据。
聚合器(brubeck)
- 指标数量： ~ 300000/sec
- 将指标发送到Graphite的时间间隔：30秒
- 服务器资源使用率：~6％ CPU（这里我们指的是功能齐全的服务器）; ~ 1Gb RAM; ~ 3Mbps LAN
Graphite (go-carbon)
- 指标数量: ~ 1600000/min
- 指标刷新间隔: 30sec
- 指标存储模式: 30秒35天，5分钟90天，10分钟365天（了解服务如何在较长时间内执行）
- 服务器资源使用率：~ 10％ CPU; ~ 20Gb RAM; ~ 30Mbps LAN
灵活性
非常感谢我们的监控服务的灵活性。为什么它真的如此灵活？首先，它的组件是可互换的 - 组件本身及其版本。其次，它是高度可支持的。由于整个项目都是基于开源解决方案构建的，因此您可以自己编辑代码，进行更改，实现现成的无法使用的功能。我们使用相当常见的堆栈，主要是Go和Python，因此它很容易实现。
这是一个现实问题的例子。Graphite中的指标是一个文件。它有一个名字。文件名=度量标准名称。它有一条路。在Linux中，文件名限制为255个字符。这里来自数据库团队的一些人（我们的内部客户）。他们说：“我们希望监控我们的SQL查询。它们不是255个字符，而是每个8 MB。我们希望它们显示在Grafana中，查看查询的参数，甚至更好，查看查询的最高评级。如果实时显示会很棒。理想情况下，它们应该集成到警报功能中。
我们设置了Redis服务器，使用连接到Postgres的Collectd-plugins并从那里获取数据，将指标发送到Graphite。但我们用哈希替换度量的名称。将相同的散列作为键发送到Redis，将整个SQL查询作为值发送。剩下的唯一事情就是让Grafana连接到Redis并获取数据。我们打开Graphite API，因为它是所有监视组件和Graphite之间交互的主要接口，并输入一个名为aliasByHash（）的新函数 - 从Grafana，我们得到度量的名称并在Redis查询中输入它作为关键，作为回报，我们得到了键的值，这是我们的“SQL查询”。因此，我们在Grafana中显示了一个SQL查询，理论上无法在那里显示，以及它的统计信息（调用，行，总时间， …）
结论
可用性: 我们的监控服务可从任何应用程序和任何代码全天候提供。如果您有权访问存储库，则可以将数据写入服务。语言没关系，解决方案无关紧要。您只需要知道如何打开套接字，上传指标，然后关闭套接字。
可靠性: 所有组件都具有容错功能，并且在我们的负载下运行良好。
进入门槛低: 要使用此系统，您无需了解Grafana中的编程语言和查询。您只需打开您的应用程序，设置一个套接字，将指标发送到Graphite，关闭它，打开Grafana，创建仪表板，并通过Moira通知监控您的指标。
独立: 所有这些都可以独立完成，无需DevOps工程师的参与。这是一个明显的优势，因为您可以立即开始监控您的项目，而无需向任何人寻求帮助 - 无论是入门还是进行更改。
我们在努力争取什么？
下面列出的所有内容不仅仅是抽象的想法，而是实际的目标，已经迈出了第一步。
- 异常探测器: 我们想要建立一个连接到Graphite存储库的服务，并通过不同的算法检查每个指标。我们有想要查看的算法，我们有数据，我们知道如何处理数据。
- 元数据: 我们有许多服务，它们会随着时间而变化，支持和使用它们的人也会如此。手动维护文档不是一种选择。因此，元数据现在正在构建到我们的微服务中。元数据指定开发服务的人员，支持的语言，SLA要求，通知接收者及其地址。部署服务后，将独立创建所有数据实体。因此，您有两个链接 - 一个到触发器，另一个到Grafana的仪表板。
- 监控一切: 我们相信每个开发人员都应该使用这个系统。在这种情况下，您始终可以了解流量的位置，发生的情况，问题和瓶颈的位置。例如，如果某些事情导致您的服务崩溃，您会发现，不是在您的客户服务代理人给您打电话时，而是从警报开始，并且能够立即打开日志并检查发生了什么。
- 高性能: 我们的项目不断发展，如今每分钟处理近2,000,000个指标值。一年前，这个数字是50万。与此同时，我们仍在增长，这意味着，经过一段时间，Graphite（耳语）将开始超载磁盘子系统。正如我所说，由于其组件的可互换性，监控系统非常普遍。有些人选择专门为Graphite支持和扩展他们的基础设施，但我们决定采用另一种方式 - 使用ClickHouse作为我们指标的存储库。过渡几乎完成，很快我将更详细地描述这是如何完成的 - 挑战是什么以及我们如何克服它们，迁移过程如何进行; 我将描述线束组件及其配置。
希望你喜欢读这篇文章。欢迎您提出问题，我会尽力在这里或即将发布的帖子中回答。如果有人有建立类似监控系统或在类似情况下切换到Clickhouse的经验 - 在评论中分享。
本文由 空心菜 创作，采用 知识共享署名4.0 国际许可协议进行许可
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名
最后编辑时间为: Jul 21, 2018 at 02:19 pm