首先

这篇文章是解释什么的？

我之前在另一篇文章中已经提到过，自从出现 Prometheus 以来已经过了一段时间。
随着监控环境的种类增多，也出现了一些提高便利性和可用性的新点子。

本文旨在讨论在2023年秋季引入基于Kubernetes (k8s)环境的Prometheus监控，并推荐一些在引入时值得考虑的开源软件(OSS)。

为了突出介绍软件的特点，有时可以与其他开放源代码软件进行比较，但这并不是否定它们的存在。监视系统的稳定运行是最重要的，认为“因为老旧所以不好”并不一定是正确的想法。

此外，在本文中，“Prometheus”不仅仅指教义的OSS产品名称，还可能指代下面这样广泛范围的软件套件。

• Prometheus と互換性のある類似のソフトウェア…たとえば Mimir など。

 

Prometheus と併用される機会が多い監視用ソフトウェア…たとえば Grafana や Loki など。

在使用K8s之前最好了解相关知识。

如果你已经知道的话，请跳过。

操作者模式 zhě

K8s的一个优点是“通过声明式描述可以在结果一致性中部署资源”的思想。
作为一个容易理解的例子，有StatefulSet。StatefulSet资源是一种“这样部署Pod”这样的“声明”。
当K8s用户将StatefulSet注册到集群中时，将会根据StatefulSet的要求来部署Pod。然而，StatefulSet并不包含“具体如何部署”的步骤。考虑步骤是K8s的标准提供的“控制器”的角色。

按照Operator pattern的解决方案，提供了以下构成要素来扩展这种”controller”的运用思路。

• operator と呼ばれる、特定の挙動を示す Pod。

 

カスタムリソース (CR : Custom Resource) と呼ばれるリソース。また、それを定義するカスタムリソース定義 (CRD : Custom Resource Definition)

先前示範的StatefulSet资源在K8s世界中是天生的，而CR则允许operator实施者自由使用CRD进行定义。

操作者会监视用户注册的资源（包括CR），并根据需要自行添加、删除、修改等。对于高级的实现层operator，如果集群内出现资源不一致的情况，它还会尝试自我修复。

操作模式在目前的 K8s 实际运营中已经成为必不可少的一部分。
通过让运算符负责详细的步骤，维护工作量将被大大减少。

需要注意的开源软件产品

现在我们来说正题。虽然介绍起来没完没了，但是我想让大家一定要注意的是下面这两个开源软件。

• grafana-operator

 

grafana-agent-operator

我将对每个进行概述。每个都有官方网站的文件可供参考，深入了解请查阅相关资料。

Grafana运算符

对于对系统监控感兴趣的人来说，不需要解释Grafana。

grafana-operator 提供了名为 “Grafana” 的 CRD。一旦将符合其要求的 CR 注册到 K8s 中，它将为我们部署必要的资源，如带有 grafana 的 Pod 和用于外部公开的 Ingress。

此外，我们还提供了名为“DataSource”和“Dashboard”的CRD。如果你使用过Grafana，可能会感到耳熟能详，即在Grafana的用户界面上，我们可以手动进行注册操作，但现在可以将这些注册操作委托给操作员完成。操作员具有一定的自我修复能力，如果有人在用户界面中错误地删除了DataSource或Dashboard，操作员也会重新生成它们。

在之前的grafana-operator中，只能在同一个集群上注册一个Grafana CR。
在多个团队共享K8s集群的环境中（即所谓的多租户环境），实际上使用起来有些棘手。
但从2023年春季升级v5开始，可以在同一个集群上部署多个Grafana CR。
由于这是最近的更新，因此在网上仍然有很多关于旧版本v4的信息，可能会导致一段时间的混乱，但我认为很快就会解决的。

Grafana 的开发主体不是 GrafanaLab，而是 GitHub 上的贡献者，并没有特定的公司推动。然而，从使用企业来看，包括 Red Hat 在内的大公司也在其中，因此可以认为短期内被放弃的可能性较低。

Grafana可以通过Helm chart进行部署，但考虑到operator的自我修复能力，引入grafana-operator也是值得考虑的。

 

Grafana 代理 Operator

Grafana Agent 是什么？

在介绍Grafana Agent Operator之前，也许需要解释一下“Grafana Agent是什么”。如果您已经了解，请跳过此段。

我之前在一篇文章中也提到了Grafana Agent。

说到Grafana，它以其可视化工具而闻名，但是grafana-agent与可视化工具并没有直接的联系。这是因为Grafana的开发者GrafanaLabs公司提供了grafana-agent。这样很容易引起误解。

Grafana Agent 提供的功能大致如下。

• remote write 機能を有効にした Prometheus と同等機能

 

• Loki へのログ記録を目的とした場合の Promtail と同等機能

 

(その他機能ありますが、本稿では割愛します)

在 Grafana-Agent 出现之前，我们需要使用多个组件来进行针对 Prometheus 的数据爬取。将这些组件合并为一个组件是 Grafana Agent 的优势，这也是对传统方法的改进之处。管理少量的组件会更容易且轻松。

此外，我认为应该在进行实际测试后再进行讨论，但使用grafana-agent相比传统方法更倾向于减少资源消耗。

另外，Grafana Agent 自身并不依赖于 K8s。
它可以在本地环境中或其他容器运行环境（如docker等）中使用。

 

Grafana Agent 操作员的优势

Grafana Agent Operator的优势与其他operator相同。

GrafanaAgent という CR で Grafana Agent を K8s クラスタ内にデプロイできます。

MetricsInstance LogInstance 等々の CR で、Grafana Agent へ与える設定を指定できます。

 

结论和额外的话题

最近介绍了一些备受关注的开源软件，假设从2023年秋季开始将Prometheus监控新引入K8s集群。

对于已经建立起来的 Prometheus 监控环境，是否应该将其替换为这些呢？正如前文所述，我认为这是一个困难的问题。

通过安装Grafana Operator，可能可以提高现有环境的便利性，而无需破坏现有环境。

就grafana-agent-operator而言，可能存在与现有环境冲突的必需CRD。即使考虑进行迁移，也需要谨慎进行。

由于其重要性，监视关系在某种程度上需要谨慎，可能存在倾向于通过复制过去成功案例来确保风险的情况。
另一方面，软件中的 “后出拳” 通常具有压倒性优势，因此后来者的解决方案（大多数情况下）更为优秀。
过去和现在都需要进行综合评估。