有些时候,两件东西搭配起来的效果太好了,以至于你都纳闷,为很么一开始人们为什么会把它们分开, 就像花生酱跟巧克力合在一起做成的Reese的纸杯花生巧克力(一种北美很流行的零食)。而考虑到kubernetes同Prometheus的结合体,这也让我自然而然的想到了waveworkers,一个对容器和微服务的网络,监控以及管理的实现。

Weaveworks的技术负责人Tom Wilkie,最近在他的博客日志“Prometheus和kubernets:完美搭配”里深入研究了公司在最近六个月里用两种完美搭配的云原生技术所做的一些实践, 并对“weaveworks如何使用Prometheus监控weave云”做了演示(所谓的weave云是指在运行在aws上的kubernets集群)。

为了进一步挖掘Weaveworks对Prometheus的应用,Brian Brazil与Tom一同就Weaveworks如何发现Prometheus,他们在这个平台上做了怎样的改进,下一步如何发展以及什么时候他们知道Prometheus同Kubernetes是一个完美搭配等问题进行了面对面的讨论。欢迎继续阅读了解细节。

采访最早发表在

https://prometheus.io/blog/2017/02/20/interview-with-weaveworks/
 

Weaveworks面对面


作为Prometheus用户系列采访的延续,来自Weaveworks的Tom Wilkie将谈论他们是怎样选择Prometheus以及如何构建它的。 

问: 您能给我们介绍下Weaveworks么?

Tom: Weaveworks提供weave云,这是一种通过开源项目以及软件来提供微服务可操作化的服务。

Weave 云由以下构成:

  • Weave Scope, 可视化服务

  • Weave Flux, 持续部署服务

  • Weave Net, 容器sdn服务

  • weave cortex, 开源项目,分布式Prometheus监控服务

你可以免费试用weave云60天。 也请通过blog twitter 以及slack来关注我们公司产品的近况

问: 你们在使用Prometheus之前是用什么做监控的呢?

Tom: weave cloud一开始是一个比较简洁的实现,也因此没有设置监控系统。我们团队在以前使用了诸如Munin以及Nagios等传统工具。 Weave云一开始就定位于多租户,主机版本的scope。Scope包括了对cpu以及内存的基本监控,所以你可以认为这就是我们的监控。当然我们还需要监控Scope的东西

问: 你们为什么决定采用Prometheus呢?

Tom: 我们之前使用了很多google sre的东西, 所以我们在borgmon方面有充足的经验。同样,作为前soundcloud的用户,我们也积累了很多Prometheus的经验。 我们基于kubernets构建服务,也一直在寻求一些能配合动态调度特性的东西,所以说Prometheus是一个自然而然的选择。 我们也甚至撰写了以“为什么kubenets跟prometheus能很好合作”开头的系列文章。

问: 你们是如何实现转变的呢?

当我们开始prometheus时, kubernets的服务发现还只是一个PR,也因此没有很多文档在外面。 我们通过自己编译的方式运行了一阵子,基本上就是在泥泞中摸索,直到我们自己搞出来。最终我们也在伦敦Prometheus meetup上就这一经历做了演讲,也发表了一系列的博客文章。我们基本上试遍了每一种运行prometheus的选项, 我们开始用一些整合配置来线下构建我们自己的容器镜像,然后把它们全部放在一个同Grafana以及Alert manager同一层的的单一pod里。我们用一些临时的In-pod存储来保存时间序列类的数据。然后又将这些数据分散到些不同的模块中,所以当我们在改变控制面板的时候,我们并不需要重启Prometheus,也不会丢失历史记录。 近来我们使用上游镜像,并将配置保存到kubernets的配置映射中,这样当我们改变配置的时候,CI也会自动更新。我们在prometheus Pod 中用一个小型容器来监控配置文件,一旦发现改变就会通知Prometheus 这意味着我们并不需要非常频繁的重启Prometheus,也能够在不影响存储的情况下离开,也不会丢失历史记录。 

周期性丢失Prometheus的历史记录仍然一直困扰着我们, 而现行的所有解决方案诸如kubrnetes体积快或者周期性S3的备份,都不甚完美。基于我们在使用Prometheus来监控Scope服务时取得了不错的效果,我们决定去构建一个云原生,分布式版本的Prometheus,让我们能够在升级或主机失效时迁移时能够不丢失历史记录。 这一切的一切就是我们研发Weave Cortex的动机。

问: 自从你们转变之后,你看到了什么样的改进呢?

Tom: 让我们忘记Cortex一会, 当引入Alert Manager高可用时我们感到非常兴奋,当然这主要还是因为它是第一个运用wave mesh(我们的消息同步协调层)实现的外部项目。

我也同样热衷于Fabian对kubernetes服务发现所做的两处改动,这解决了一个我们在监控Consul Pods时很棘手的问题,就是如何在一个Pod里检索多个接口。

当然也不能忘了我自己的一个小项目,远程写特性,Prometheus通过它形成一个weavecortex自身的关键模块,来实现检索目标以及发送样本给我们。

问: 你认为weaveworks同Prometheus会有怎样的未来呢?

Tom: 我个人认为weave cortex就是他们眼下的未来。我们主要用它做内部扩展,也通过它实现了不错的查询性能。 它现在也在实际生产环境中被用户所使用,同时很快我们也会在在引入对报警以及上游Prometheus特征实现匹配的支持,我们将会在此基础上发布一个beta版本,然后在今年年中发布稳定版本。

作为Cortex的一部分,我们研发了一种智能Prometheus表达式浏览器,它能够实现对promql的自动补充以及包括了一个Jupyter-esque记事本。我们很期待能把这些产品带到大家的面前,然后开源它们。

我自己也有一个小的周边项目,Loki,它能识别Prometheus服务,对open tracing进行检索, 让分布式跟踪加更容易和健壮。 我会在三月底柏林举行的kubercon/CNCDCon上进一步谈论它。

 

原文链接:https://www.cncf.io/blog/2017/02/24/prometheus-user-profile-dynamically-helping-weaveworks-accelerate-cloud-native-application-development

09-01 00:20