监控即服务:用于微服务架构的模块化系统

in 推介 with 0 comment  访问: 131 次

除了一体化代码之外,我们的项目还有许多微服务支持。他们每个都需要被监控。由DevOps工程师监控它们几乎是不可能的。我们开发了一个监控系统,作为开发人员的服务。他们可以自己配置监控系统中的指标,使用它们,构建基于指标的仪表板,设置由阈值触发的警报。DevOps工程师唯一必须提供的是基础设施和文档。

这篇博文是我在RIT++ section的演讲稿。我们收到了有关RIT ++演示文稿版本的多个查询。如果您参加了会议或观看了视频,您几乎找不到任何新内容。否则,请欣赏此博文。我会告诉你我们是如何得出这个解决方案的,它是如何工作的,以及我们计划如何更新它。

过去:布局和计划

我们是如何到达现有的监控系统的?为了回答这个问题,我们需要回到2015年。以下是它的回顾:
15321796754206.jpg
我们有24个节点负责监控。有一大堆crons,脚本和所有类型的守护进程以某种方式监视某些内容,发送消息,执行其他功能。我们意识到,我们走的路越走越远,系统的增长就越不可持续。开发系统没有意义 - 它太麻烦了。

我们决定选择那些我们将保留和开发的监控元素,以及那些将被删除的元素。选择保留19个元素。那些仅包括Graphites,aggregators和Grafana作为仪表板。但新系统会是什么样子?喜欢这个:
15321797763821.jpg
我们有一个指标存储库 - 快速SSD磁盘和指标聚合器上的Graphites。此外,Grafana用于显示仪表板和Moira用于警报功能。我们还想开发一种寻找异常的系统。

标准:监控2.0

这就是我们2015年的计划。但我们不仅要开发基础设施和服务本身,还要开发文档。我们开发了一个企业标准,称之为Monitoring 2.0。系统要求是这样的:

我们需要UDP,因为我们有大量流量和指标生成的多个事件。如果它们都立即存储在Graphite中,则存储库将崩溃。我们还为所有指标选择了第一级前缀。
15321799061892.jpg
每个前缀都有一些属性。我们有服务器,网络,容器,资源,应用程序等的指标。有一种清晰,严格,典型的过滤方法,我们保留第一级指标并放弃其他指标。这就是我们在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的通知和电子邮件,以支持此仪表板。
15321800742904.jpg
由于我们是面向未来的业务,我们也使用该系统来监控Kubernetes。我们使用Heapster将它添加到系统中,我们在集群中安装它以收集数据并将其发送到Graphite。生成的布局如下所示:
15321801020991.jpg

监控组件

以下是我们用于执行此操作的组件的链接列表。它们都是开源的。

Graphite:

Carbon-c-relay:

Brubeck:

Collectd:

Moira:

Grafana:

Heapster:

统计

以下是我们系统的一些性能统计数据。

聚合器(brubeck)

Graphite (go-carbon)

灵活性

非常感谢我们的监控服务的灵活性。为什么它真的如此灵活?首先,它的组件是可互换的 - 组件本身及其版本。其次,它是高度可支持的。由于整个项目都是基于开源解决方案构建的,因此您可以自己编辑代码,进行更改,实现现成的无法使用的功能。我们使用相当常见的堆栈,主要是Go和Python,因此它很容易实现。

这是一个现实问题的例子。Graphite中的指标是一个文件。它有一个名字。文件名=度量标准名称。它有一条路。在Linux中,文件名限制为255个字符。这里来自数据库团队的一些人(我们的内部客户)。他们说:“我们希望监控我们的SQL查询。它们不是255个字符,而是每个8 MB。我们希望它们显示在Grafana中,查看查询的参数,甚至更好,查看查询的最高评级。如果实时显示会很棒。理想情况下,它们应该集成到警报功能中。
15321818035728.jpg
我们设置了Redis服务器,使用连接到Postgres的Collectd-plugins并从那里获取数据,将指标发送到Graphite。但我们用哈希替换度量的名称。将相同的散列作为键发送到Redis,将整个SQL查询作为值发送。剩下的唯一事情就是让Grafana连接到Redis并获取数据。我们打开Graphite API,因为它是所有监视组件和Graphite之间交互的主要接口,并输入一个名为aliasByHash()的新函数 - 从Grafana,我们得到度量的名称并在Redis查询中输入它作为关键,作为回报,我们得到了键的值,这是我们的“SQL查询”。因此,我们在Grafana中显示了一个SQL查询,理论上无法在那里显示,以及它的统计信息(调用,行,总时间, …)

结论

可用性: 我们的监控服务可从任何应用程序和任何代码全天候提供。如果您有权访问存储库,则可以将数据写入服务。语言没关系,解决方案无关紧要。您只需要知道如何打开套接字,上传指标,然后关闭套接字。

可靠性: 所有组件都具有容错功能,并且在我们的负载下运行良好。

进入门槛低: 要使用此系统,您无需了解Grafana中的编程语言和查询。您只需打开您的应用程序,设置一个套接字,将指标发送到Graphite,关闭它,打开Grafana,创建仪表板,并通过Moira通知监控您的指标。

独立: 所有这些都可以独立完成,无需DevOps工程师的参与。这是一个明显的优势,因为您可以立即开始监控您的项目,而无需向任何人寻求帮助 - 无论是入门还是进行更改。

我们在努力争取什么?

下面列出的所有内容不仅仅是抽象的想法,而是实际的目标,已经迈出了第一步。

  1. 异常探测器: 我们想要建立一个连接到Graphite存储库的服务,并通过不同的算法检查每个指标。我们有想要查看的算法,我们有数据,我们知道如何处理数据。
  2. 元数据: 我们有许多服务,它们会随着时间而变化,支持和使用它们的人也会如此。手动维护文档不是一种选择。因此,元数据现在正在构建到我们的微服务中。元数据指定开发服务的人员,支持的语言,SLA要求,通知接收者及其地址。部署服务后,将独立创建所有数据实体。因此,您有两个链接 - 一个到触发器,另一个到Grafana的仪表板。
  3. 监控一切: 我们相信每个开发人员都应该使用这个系统。在这种情况下,您始终可以了解流量的位置,发生的情况,问题和瓶颈的位置。例如,如果某些事情导致您的服务崩溃,您会发现,不是在您的客户服务代理人给您打电话时,而是从警报开始,并且能够立即打开日志并检查发生了什么。
  4. 高性能: 我们的项目不断发展,如今每分钟处理近2,000,000个指标值。一年前,这个数字是50万。与此同时,我们仍在增长,这意味着,经过一段时间,Graphite(耳语)将开始超载磁盘子系统。正如我所说,由于其组件的可互换性,监控系统非常普遍。有些人选择专门为Graphite支持和扩展他们的基础设施,但我们决定采用另一种方式 - 使用ClickHouse作为我们指标的存储库。过渡几乎完成,很快我将更详细地描述这是如何完成的 - 挑战是什么以及我们如何克服它们,迁移过程如何进行; 我将描述线束组件及其配置。

希望你喜欢读这篇文章。欢迎您提出问题,我会尽力在这里或即将发布的帖子中回答。如果有人有建立类似监控系统或在类似情况下切换到Clickhouse的经验 - 在评论中分享。

翻译原文链接:https://tech.olx.com/monitoring-as-a-service-a-modular-system-for-microservice-architecture-e53bcc144879

WeZan
Responses