在本文中,我们将介绍 Coroot,这是一个使用 eBPF 技术构建的开源工具,旨在用于 Kubernetes 或基于 Docker/containerd 的环境,甚至是非容器化应用程序。Coroot 收集和分析遥测数据(指标、日志、跟踪和配置文件),将其转换为可用信息,使您能够快速识别和修复应用程序问题。我们将介绍如何为 Kubernetes 安装和配置 Coroot,以及它的作用,以及它的优缺点。
Coroot 是一个相当新的工具,第一次提交到 GitHub 可以追溯到 2022 年 8 月 22 日。这个项目背后的团队以前在实现另一个可观察性解决方案方面有丰富的经验(它是一个用于基础设施监控的专有系统)。现在,他们将 Coroot 定位为一个全面的遥测收集和故障监测系统。让我们试一试吧!
安装 Coroot
Coroot 有三个版本:免费(开源)、云(按节点定价)和企业(可以是云或本地安装)。Cloud 和 Enterprise 都包含作者的支持;后者还拥有附加功能,例如 RBAC(基于角色的访问控制)、SSO(单点登录)、审核日志等。
我们将在 Kubernetes 1.23 集群中安装和评估 Coroot 的开源版本。
安装方法 #1
为此,我们从官方存储库中的 Kubernetes 清单开始。清单创建了 Namespace、PersistentVolumeClaim、Deployment 和 Service。
但是,我们想看看该服务是如何从外部工作的,没有 PortForward 或其他技巧。因此,我们添加了一个 Ingress 资源。在 NGINX 中,使用可用于进入应用程序的外部 DNS 地址创建了一个配置文件。由于 Coroot 没有授权,我们通过 GitLab 使用 Dex 授权来保护资源。
在容错配置中运行 Coroot:该服务有一个名为 PG_CONNECTION_STRING 的变量。设置它会导致服务将其配置保存在 PostgreSQL 中。在这种情况下,可以在容错配置中运行它(但本主题超出了本文的范围)。
安装方法 #2
您可以使用原始的 Helm 图表安装 Coroot。
该图表安装了所有必要的导出器以及 Coroot、Pyroscope 代码分析系统和 ClickHouse 来存储其数据。
配置 Coroot
安装后,我们可以转到该工具的 Web 界面,并通过指定其名称、Prometheus 地址和凭据来创建一个新项目。
在 Coroot 中创建新项目, Prometheus 集成设置
注意:由于我们的集群由 Deckhouse 管理,因此与 Prometheus 的通信是在 RBAC 授权下进行的,这增加了集群的安全性。因此,我们不得不以 NGINX 代理容器的形式实现一个小 hack,该容器通过 RBAC 获取访问 Prometheus 的令牌。Coroot 无法通过 RBAC 向 Prometheus 进行开箱即用的身份验证,因为它仅提供基本授权。
如果使用常规 YAML 清单安装了 Coroot,则可能需要安装 coroot-node-agent。为了让 Coroot 工作并在从每个节点收集指标时为您提供可观测性见解,此代理是必不可少的。
下一步是将 node-agent DeamonSet 添加到部署中,从 Pod 配置指标收集,并将它们提供给 Prometheus。一旦我们的 Kubernetes 设置完成,许多令人兴奋的功能就会出现在 Coroot 界面中。
Coroot 功能
Pod 信息
让我们首先查看一下 Pod 之间的网络:
注意:虽然我们不得不模糊名称以避免泄露基础设施细节,但如果需要,可以在 Coroot 网站上找到一个很好的视觉演示。
开发和运营团队可能会发现此功能相当方便。即使没有参与该项目的人也可以通过查看此图轻松了解所有服务的交互方式。以红色突出显示的应用程序是 Coroot 认为行为异常的应用程序(例如,响应时间过长)。这个简洁功能的缺点是,您无法移动块以使布局更具可读性。
下一步是什么?您可以选择一个容器以更详细地查看有关它的信息:
它具有 CPU 使用率指标:
...以及内存使用指标:
...和磁盘使用情况指标:
Coroot 可以解析日志并根据模式发现类似的消息:
Pod 过滤
默认仪表板显示来自所有命名空间的 Pod。这不是最方便的事情,所以让我们来看看如何过滤掉它们。
您可以在项目设置中通过选择应用程序类别来执行此操作。应用程序可以按命名空间或类型进行分组。还有一些正则表达式可以用来制作命名空间模式——例如,你可以把它设置为 review
或 test
。
在上面的示例中,筛选是按命名空间完成的。这是一个相当方便的 Coroot 功能。通过应用这种筛选,您可以更准确地了解应用程序在命名空间中相互链接的位置。如果应用程序使用来自另一个命名空间(如 DBMS)的资源,则也应将其添加到类别中。
此功能的不足之处在于,当您导航到另一个部分时,所选类别会重置。
节点状态监控和告警
Coroot 提供了一些很酷的监控和通知功能:
- 您可以将其与依赖于 Slack、PagerDuty 和 Microsoft Teams 的 SRE 流程集成(遗憾的是目前不是最重要的),它将在其中发送有关部署过程的告警。
- 您还可以配置 SLO 违规、CPU 利用率、Redis 不可用等告警。
对于每个 Kubernetes 资源(Deployment 或 StatefulSet),您可以指定一个指标来计算 SLO 和目标值。
我们使用 Slack 来了解 Coroot 中的警报工作原理。为此,我们将 Coroot 应用程序添加到 Slack 工作区,并指定了用于发送警报的 Oauth 令牌/通道(请参阅下面的 Coroot 界面)。
事实证明,告警被及时发送到 Slack,对于值班的 SRE 工程师来说似乎非常有用:
现在我们来看一下节点监控。“节点”选项卡显示运行代理的节点的状态,您可以轻松发现未充分利用或过度利用的节点,从而帮助您进行适当的资源管理:
单击节点名称将打开一个小仪表板,其中更详细地显示了关键系统指标:
基本上,这是诊断潜在问题所需的最低指标集。尽管如此,我们还是希望看到一些高级网络统计信息,例如开放端口的数量或网络错误。与磁盘运行状况相关的指标也会派上用场。
此外,Coroot最近还添加了另一个很棒的功能,即云成本监控:
这使得估算各种云提供商(AWS、GCP、Azure)的成本和节点利用率变得轻而易举,并且您的具有 FinOps 意识的团队成员也很高兴。这是一个安全且有用的功能,因为 Coroot 无需任何控制台访问即可检测节点类型。
最后,我们想指出的是,Coroot 支持 Pyroscope,这是一个用于分析应用程序并将 CPU 时间可视化为火焰图的系统。图形可以直接在其界面内呈现。
Coroot 的优点和缺点
事实证明,Coroot 是一个非常方便的可观测性工具,具有广泛的优势:
- 其清晰、全面的服务交互方案;您可以查看每个容器的状态和衡量指标。
- 您可以筛选 Pod 并查看每个命名空间中链接了哪些应用程序。
- 用于监控节点和自定义警报的便捷功能。
- 提供了对 Pyroscope 的支持,以及在 Coroot 界面中渲染其图形的选项。
我们可以提到的缺点是:
- 您不能从监视中显式排除任何 Pod,这有时更可取。假设项目中的 Pod 经常被 cron 作业启动和关闭。在这种情况下,您可能不需要跟踪它们的指标并将它们提供给 Prometheus。通过在实际代理中加入过滤器,可以在一定程度上缓解这一缺点。尽管如此,事实证明,您不能在代理中为每个资源设置任何例外(即,对于部署、有状态副本集和命名空间)。
- 用户界面相当基本,当然还有改进的余地。但由于该项目正在积极开发中,因此界面可能会随着时间的推移而得到增强。也许就像它的竞争对手 Caretta 一样,Coroot 将在某个时候开始使用 Grafana 来渲染指标。
Coroot 备择方案
- Caretta 使用类似的基于 eBPF 的指标收集系统和 Grafana 仪表板形式的“界面”。然而,该工具的开发过程缓慢,其仪表板的性能相当差:它上面的信息可能会呈现错误,并且会给浏览器带来很高的负载。总的来说,根据我们的经验,该工具可以得到更好的优化。
- Suricata 并不完全是一个 SLO/SLA 监控项目,但它的功能有些相似。它的代理检查流量,在此基础上构建指标,还可以显示服务到服务交互的图表。该系统非常复杂,因为 Suricata 需要一个 ELK 堆栈,并将许多第三方对象导入 Kibana 以可视化图形。
结论
Coroot 似乎是一个相当强大的解决方案,用于以简单易配置但全面的方式监控应用程序和基础设施。对于不需要复杂系统并希望使用 SLO、通知和请求跟踪快速设置监视的小型企业和团队来说,它可能成为必不可少的 SRE 部分。