Juju重新想象了安全、可靠和大规模地操作软件的世界。Juju实现了模型驱动运营的承诺。不可否认的是，优秀的可观察性是运营软件良好的关键要素，这就是为什么魅力运营商生态系统长期以来为运营商提供运行各种开源监控软件的能力。我们把这些运营商统称为日志、指标和警报（LMA）栈。
随着云原生软件和微服务的出现，以及由此带来的系统复杂性的增加，我们决定是时候创建运行在Kubernetes上的下一代LMA了。它需要能够监控运行在Kubernetes、虚拟机、裸机或边缘的工作负载。
回到绘图板，我们还重新评估了哪些组件将成为这个新的云原生LMA的一部分。最终的设计是由Grafana实验室主导或大量参与的开源项目组成。让我们来告诉你为什么。
关于Juju的一些东西......
Juju采用了一种根本不同的方法来构建和运营基础设施。Juju不关注底层组件，如虚拟机、子网或容器，而是将用户的注意力集中在操作应用程序上，其余的由它来处理。
任何Juju部署的核心是一个控制器，它知道一组底层云以及它所管理的模型和应用程序的状态。Juju中的模型本质上是相关应用程序组的工作区，而应用程序则被称为Charmed Operators。
Charmed Operator包括了解如何安装、配置、集成和一般操作软件的代码。它使用代理与Juju控制器进行通信，Juju控制器是在你部署应用程序时自动提供的。Juju的优势在于，无论你的底层云是AWS、Azure、OpenStack、VMware、Kubernetes等，Charmed Operators的功能都一样。使用Juju，你总是只需要一个juju deploy foo ，就能胜任软件的操作，用户体验和工具在不同的云中是一致的，并能在它们之间实现无缝集成。
Charmhub上有一个不断增长的Charmed Operators的集合。去看看吧!
适用于新的云原生世界的新LMA
新的LMA堆栈，我们称之为 "LMA2"，有以下设计目标:
- 质量和可靠性:正常运行时间和可靠性是任何软件都必须的，但对你的监控软件来说更是如此。如果你的监控软件不能正常运行，不能告诉你还有什么问题，那它到底有什么用？
- 可扩展性:监控有很强的网络效应。因此，如果有足够的资源，LMA2应该能够扩展到监测大量的软件，使你的运营团队对你的基础设施和应用程序有最深入的了解。
- 资源效率:LMA2应该能够在边缘和数据中心运行，需要尽可能少的计算资源来完成其任务。
- 可组合性:LMA2应该由一组高质量的Charmed Operators组成，这些Charmed Operators被设计成可以独立工作，也可以更好地一起工作。
- 凝聚的用户体验:LMA2应确保为终端用户提供一致的、有凝聚力的体验，其工具的设计是为了共同工作--用一个用户界面来可视化所有类型的遥测数据。LMA2还应该在遥测上创建一致的元数据，以便遥测的上下文（"它来自哪里？"）可以用来跨越遥测类型的孤岛--从指标到日志，从日志到警报--同时利用所有地方的相同元数据。
- 一致的操作员体验:遵循类似理念的各种软件在操作、故障模式、依赖性和陷阱方面感觉相似。这种一致性对减少操作员的认知负担有很大帮助。
- 监测范围:虽然从日志、指标和警报开始（毕竟这是 "LMA "名称的字面意思），但还有其他类型的遥测在云原生环境中是非常宝贵的，如分布式跟踪和合成监控。LMA2的设计应考虑到可扩展性，因此它可以增加处理其他类型遥测的能力。反过来说，很多软件不是云原生的，甚至不是在云上运行的。LMA2应该能够监控Kubernetes边界以外的软件。例如，仅仅关注Canonical产品，LMA应该能够监控Ceph、Charmed OpenStack、使用MAAS运行的裸机或LXD上的容器或虚拟机。
- 易操作性:我们希望LMA2成为一个感觉像设备的监控堆栈，尽可能少地转动旋钮，开箱即用，功能强大。我们希望完全消除设置Juju工作负载监控的麻烦；它应该像建立几个Juju关系一样简单。
- 展示Juju模型的声明性能力:如果某些功能或集成可以充分建模为魅力运算符之间的关系，就应该这样做。而且，关系必须是有语义的。通过观察Juju模型，你应该直观地理解两个符咒相关的结果是什么。
上述设计目标是雄心勃勃的，而我们对我们的努力所形成的结果感到高兴我们的成功在很大程度上要归功于Prometheus、Grafana和Grafana Loki项目的惊人质量，以及它们的理念与LMA2的设计目标的一致性，所以让我们更深入地探讨这个问题。
Grafana、Prometheus、Alertmanager、Loki的救援
在Canonical，开源是我们DNA的一部分。Juju和整个Charmed Operator生态系统都是开源的。在这一点上，我们与Grafana人的看法是一致的，他们是优秀的开源公民，对社区的反应非常积极，总体来说，与他们合作很愉快。
建立在Grafana生态系统上的许多好理由
但是，当然，不仅人要好，软件也要好!由Grafana实验室领导和贡献的开源项目并没有让人失望!简而言之，我们决定通过合成Grafana项目来构建LMA2的原因如下（不一定按重要性排序！）:
- 开源软件做得好。
- 易于集成的组件。
- 资源效率。
- 共享的支持组件。
- 对象存储的使用方式的直接性。
- 一致的理念和用户体验（直到 "Loki是日志的普罗米修斯"）。
- 良好的性能和可扩展性。
- 覆盖遥测类型（指标、日志、分布式跟踪、合成监控等）。
- 与Grafana Agent的良好代理故事：它能带来巨大的冲击!
为了扩展上述内容，Prometheus、Alertmanager和Grafana一直是LMA2上一次迭代的主打产品，再次依靠它们简直是不费吹灰之力：最终用户的熟悉度、质量、易用性、设计理念的一致性、资源效率--这一切都在那里！。
Loki：一个令人耳目一新的日志分析方法
Loki，"日志的普罗米修斯"，已经取代Graylog成为LMA2中的首选日志分析组件。我们进行了详细的评估，其中包括操作的便利性、与其他LMA2组件整合的便利性、依赖性的稀少性和可扩展性。看到Loki 2.0取消了专门的索引存储，进一步减少了LMA2的占用空间，我们感到非常兴奋。此外，Loki使用对象存储，而不是复杂的数据库，这对于可靠性和易操作性来说是非常好的。在一致的用户体验方面，Loki在Grafana中整合得非常好，LogQL对Prometheus用户来说感觉非常熟悉。
Grafana Agent：一个遥测收集的大户
Grafana Agent也值得一提，让人爱不释手。监控从网络效应中获益匪浅：你一起监控的越多，就越容易找到相关性和根本原因。遥测收集的便利性有助于实现这种网络效应：一个能够收集和转发指标、日志和分布式跟踪的代理，可以大大降低将我们的监控推广到许多系统的成本和复杂性。我们非常喜欢Grafana代理，所以我们将用它来建立LMA2的自我监控能力。我们预见了两种自我监控的模式：一种是将数据发送到远程的LMA2堆栈（可以认为它像Prometheus联盟，但针对整个堆栈），另一种是堆栈自我监控，用于独立的部署。
一张图片胜过千言万语
Juju的声明性特点很适合用图形来表示。
上面是一个承载LMA2栈的Juju模型的图形表示。为了便于阅读，Grafana Agent和各种组件之间的监控关系没有被描绘出来。
在这里，你可以看到一张图，表示在Juju模型中部署LMA2，以及各种Charmed Operators之间如何相互作用。(请注意，图中的一切还没有实现）。
如前所述，Grafana Agent对堆栈的自我监控是我们期待尽快实现的。同样地，我们正在努力打造一个Ingress控制器（Juju社区称之为创建Charmed Operator的过程），这样我们就可以在MicroK8s集群之外暴露出各种需要监控或接收数据的端点，因为出于弹性的原因，我们希望LMA2托管在一个专门的MicroK8s集群中，并尽可能地与它监控的工作负载共享基础设施。需要暴露在MicroK8s集群之外的端点是:
- Loki push_api端点
- Prometheus、Alertmanager和Grafana的Web界面
- Prometheus的remote_write（注意：我们目前不打算实施对Prometheus federation或remote_read的支持，但如果出现这种情况......)
而这仅仅是个开始
关于遥测类型，新的云原生LMA2的工作目前集中在指标、日志和警报方面。但可观察性的内容不止这些，尤其是在云原生环境中。在 "什么是可观察性？"页面上，我们浏览了其他一些遥测类型，如分布式跟踪，或终端用户和合成监控。Grafana生态系统有一些项目，比如Grafana Tempo和k6，都符合这些要求，这让我们相信，随着LMA2的发展和能力的提高，它将能够利用具有这种一致理念和质量的项目，就像今天的Prometheus、Grafana和Loki一样。
我们想用LMA2追求的另一个方向是高可扩展性和可用性。我们正饶有兴趣地看着Cortex为Prometheus的体验带来多租户和弹性，而Loki已经具备了我们在这个层面所需要的很多能力。
