容器中prometheus数据存储

一、容器Prometheus简介

Prometheus是据存一套开源的系统监控报警框架。如今越来越多的容器公司开始广泛使用Prometheus来提供近实时的、基于动态云环境和容器微服务、据存服务以及应用程序的容器内省监控。同时也用于监控传统架构的据存资源。

Prometheus作为新一代的容器云原生监控系统，拥有易于管理、据存查询功能强大、容器便于可视化、据存存储高效以及操作简单等特点。容器

在Prometheus之前市面已经出现了很多的据存监控系统，如Zabbix、容器Open-Falcon等。据存下表通过多维度展现了各自监控系统的容器优缺点

Prometheus是一个开源系统监控和警报工具包，最初是在SoundCloud构建的。自2012年成立以来，许多公司和组织都广泛运用了Prometheus，该项目拥有非常活跃的开发人员和用户社区。它现在是一个独立的开源项目，独立于任何公司进行维护。为了强调这一点，Prometheus在2016年加入了云计算基金会，成为继Kubernetes之后的第二个托管项目。

Prometheus有以下几个主要特点：

Prometheus生态系统包含多个组件，其中许多是可选的：

大多数Prometheus组件都是用Go编写的，因此易于构建和部署为静态二进制文件。

下图说明了Prometheus的架构及其生态系统组件：

Prometheus直接或通过pushgateway抓取metrics。将数据存储在本地，并对这些数据运行规则，以便从现有数据聚合和记录新时间序列，或者生成警报。Grafana或其他API consumers可以用来将抓取的数据可视化。

Prometheus非常适合记录任何纯数字时间序列。它既适用于machine-centric监控，也适用于高度动态的service-oriented的架构监控。在微服务的领域，其对多维数据抓取和查询的支持是一种特别的优势。

Prometheus是您在中断期间也能正常使用并快速诊断问题的系统，是十分值得信赖的伙伴。每个Prometheus服务器都是独立的，而不依赖于网络存储或其他远程服务。当基础结构的其他部分损坏时，您仍可以依靠它来进行监控，并且无需设置广泛的基础结构也可使用它,在故障的情况下，仍可以查看系统可用的统计信息。如果您需要100%精确的统计数据的话，Prometheus可能不能完全满足您的需求，如果是这种情况，您可以运用其他系统来抓取和分析这部分需要精确的数据，然后将Prometheus用于余下的监控环节。

二、两大容器管理平台,Kubernetes与OpenShift有什么区别

容器化是开发和部署应用的热门趋势，因为它们是加速开发的有效方式。容器的使用量在过去几年呈指数增长。

但是，跨基础架构管理容器可能会变得十分复杂，所以容器管理平台对于任何企业来说都是必不可少的工具。Kubernetes和OpenShift是市场上最受欢迎的两个容器管理平台。而OpenShift是基于Kubernetes的，那么二者之间到底有哪些区别呢？

OpenShift是由红帽（Red Hat）开发的容器化软件解决方案。他们的主要产品是OpenShift容器平台，这是基于Kubernetes管理的平台即服务（PaaS）。它是用Go和AngularJS编写的，并且有Apache许可证。

OpenShift Origin是红帽基于开源的云平台，允许开发人员构建，测试和部署云应用。该系统在Kubernetes核心之上添加工具，以实现更快的应用开发，轻松部署和扩展。

该平台除了可扩展外，还支持Go，Node.js，Ruby，Python，PHP，Perl和Java，允许用户添加对其他语言的支持。关于可扩展性，该平台可以自动或手动扩展容器化应用。

OpenShift提供的一些功能包括：

在整个应用程序生命周期中的安全性-安全性检查内置于容器堆栈中。

平台上包含的内置监控功能是Prometheus，一种数据库和应用监控软件。你可以在Grafana仪表板上实时显示应用。

集中式策略管理-跨集群的单个控制台为用户提供了实施策略的集中位置。

兼容性-OpenShift是Certified Kubernetes计划的一部分，因此允许与Kubernetes容器工作负载兼容。

使用OpenShift的好处包括：

快速的应用开发-平台流传输和自动化容器管理过程，从而增强了DevOps过程。应用开发的这种加速意味着你可以更快地进入市场，从而提高竞争力。

没有供应商锁定提供与供应商无关的开源平台，这意味着用户可以根据需要将其容器流程迁移到新的操作系统，而无需重新进行容器化编排。

自助服务配置- OpenShift允许用户集成他们最常使用的工具，例如，视频游戏开发人员在开发与多个操作系统兼容的游戏时可以使用此功能。

Kubernetes是一个开源容器即服务（CaaS）编排系统，用于自动化容器化应用的部署，扩展和管理，从而改进应用程序开发过程。Kubernetes的一些功能包括：

Kubernetes的好处包括：

由于OpenShift基于Kubernetes，因此它们有很多共同之处。但是，两个平台之间存在一些差异。让我们对OpenShift和Kubernetes功能进行比较：

基础

虽然两者都基于Linux，但每个产品都在不同的环境中运行：

Kubernetes在其可运行的操作系统方面更加灵活。但是，包管理器应该是RPM，这意味着选择合适的Linux发行版。因此最好在Fedora，Ubuntu或Debian上运行它。Kubernetes可以部署在任何主要的IaaS平台上，例如AWS，Azure，GCP、阿里云、IBM云平台等。

OpenShift可以安装在Red Hat Enterprise Linux（RHEL）和Red Hat Enterprise Linux Atomic Host（RHELAH）以及Fedora和CentOS上。OpenShift Dedicated允许在云中创建自己的集群，特别是基于AWS。

Rollout

这两种产品在Rollout方面都很复杂：

Kubernetes运行平台的多样性意味着有无数的解决方案可以在本地创建Kubernetes集群。大多数都基于Rancher Kubernetes Everywhere（RKE）或kops等安装程序。

OpenShift可避免在首次Rollout后需要额外的组件。因此，它配备了基于Ansible的专有安装程序，可以使用最少的配置参数安装OpenShift。

Web UI

与通过基于Web的用户界面管理集群的能力相比，OpenShift和Kubernetes之间存在很大差异。

Kubernetes的仪表板必须单独安装，需要通过kube代理访问，以将本地机器的端口转发到集群的管理服务器。此外，它没有登录页面，但你需要手动创建承载令牌以提供身份验证和授权。所有这些复杂性导致Web UI对于真正的日常管理工作而言不是很有价值。

OpenShift的Web控制台有一个登录页面，可以轻松访问，甚至可以让你通过表单创建和更改大多数资源。虽然你无法通过Web管理集群，但可以可视化服务器，项目和集群角色。

集成镜像注册表

关于集成图像注册表的两个系统之间的关键区别：

使用Kubernetes，可以设置自己的Docker注册表，但没有集成镜像注册表的概念。

OpenShift附带了一个集成的镜像注册表，可以与Docker Hub或Red Hat一起使用。它甚至还有一个注册表控制台，可以在其中搜索与集群中项目相关的镜像和镜像流的信息。

Jenkins

虽然Kubernetes中不存在该概念，但可以部署自己的自定义Jenkins镜像。生成的组件是上传到镜像存储库的docker镜像。

OpenShift使用Pipeline构建，这是一种源到镜像构建的形式，它引用包含Jenkins的镜像，而Jenkins又监控ImageStreamsTags。当需要更新时，它可以启动Jenkins构建。

网络

Kubernetes没有本机网络解决方案，但提供可供第三方网络插件使用的接口。

OpenShift有一个开箱即用的本机网络解决方案OpenvSwitch，它提供三种不同的插件。

两者都是开源软件平台，来满足容器编排和应用开发。它们使得以简单易管理的方式部署和管理容器化应用成为可能。OpenShift Web控制台使其非常有用，允许直接通过它执行80％以上的任务。

虽然两者都有类似的核心（毕竟OpenShift内置了Kubernetes），OpenShift通过其开箱即用的功能使安装更容易。安装Kubernetes通常需要交钥匙解决方案或托管Kubernetes集群。

您选择的系统将取决于您的系统要求以及开发过程的关键灵活性或良好的Web界面。

三、Prometheus指标写入ES间断问题排查

由于Prometheus自身容量有限，不适合存储大量数据，所以需要将数据写入远端存储。由于我对ES比较熟悉，所以选择了ES作为远端存储，adapter为 prometheus-es-adapter。

环境搭建好后，很快就看到ES中已经有数据流入，就以为大功告成了，但第二天发现数据只写了半个小时就中断了。

通过初步排查后，发现是 prometheus-es-adapter挂掉了，原因是OOMKilled（内存溢出）,所以就将cpu增加到1000m，内存增加到1Gi，之后运行正常了。

但观察半天后，发现数据写入经常出现长时间间断，如下图：

由于我目前对Prometheus接触还比较少，于是带着问题去请教运维同学，运维同学检查完Prometheus配置后，指出可能是 remote_write.queue_config.capacity设置过小，导致大量数据来不及写入ES而被丢弃。下面默认capacity是10：

于是我将 remote_write.queue_config.capacity增大为1000：

但发现并没有起作用。这是把这个过程看成是生产者-消费者模式的话，那 Prometheus就是生产者， prometheus-es-adapter是消费者，既然问题不在Prometheus，很可能就在 prometheus-es-adapter这边。于是我按照说明文档，设置环境变量 DEBUG=true开启调试模式。

可以看到有日志正常输出，说明prometheus-es-adapter确实接收到了数据，并尝试写入ES，但为什么ES没有收到数据呢？（后来仔细观察，发现ES是有数据写入的，只不过速度很慢）

于是我猜想：是不是prometheus-es-adapter把数据写入了队列中，等待数据达到一定数量后再批量写入呢？或者是消费线程太少，导致消息处理不过来而造成大量堆积呢？如果是这样，那必定会占用大量内存，内存空闲率必然要不断下降，这也可以解释之前遇到的OOMKilled。

于是我通过 watch命令去监控 prometheus-es-adapter容器的内存空闲率：

下面两张图是观察了5分钟的结果，可以看到内存空闲率在不断下降。

于是我尝试着将 ES_WORKERS增加为20，果然一段时间后数据就追上来了。

这个问题的根本原因是：prometheus-es-adapter处理线程太少，导致数据不能及时写入ES而致使Prometheus队列爆满，数据被大量丢弃或堆积在prometheus-es-adapter的处理队列中。这也是为什么只有一段时间有数据的原因及prometheus-es-adapter发生OOMKilled的原因。

要解决这个问题，需要修改两个地方：

参考资料:云原生可观测性