在prometheus 使用心得文章中有简单提到prometheus 的高可用方案，尝试了联邦、remote write 之后，我们最终选择了 thanos 作为监控配套组件，利用其全局视图来管理我们的多地域/上百个集群的监控数据。本文主要介绍 thanos 的一些组件使用和心得体会。

监控系统的历史悠久，是一个很成熟的方向，而Prometheus作为新生代的开源监控系统，慢慢成为了云原生体系的事实标准，也证明了其设计很受欢迎。本文主要分享在prometheus实践中遇到的一些问题和思考

概述 在k8s中节点会通过docker pull机制获取外部的镜像，那么什么时候清除镜像呢？k8s运行的容器又是什么时候清除呢? api-server: 运行在master，无状态组件，go自动内存垃圾回收 controller-manager: 运行在master,无状态组件，go自动内存垃圾回收，owner机制提供resource垃圾回收 scheduler: 运行在master，无状态组件...

线上排查pod 问题一般有两种方式，kubectl log或者kubectl exec调试。如果你的 log 写不够优雅，或者需要排除网络问题必须进容器，就只能 exec 了。

在Kubernetes 中，系统和应用程序的健康检查任务是由 kubelet 来完成的，本文主要讨论kubelet中 probemanager 相关的实现原理。

本文转自：[链接] 架构 Kubelet 架构图 Generic Runtime Manager：这是容器运行时的管理者，负责于 CRI 交互，完成容器和镜像的管理 在 CRI 之下，包括两种容器运行时的实现 {代码...} Kubelet 通过 CRI 接口跟外部容器运行时交互，它包括 CRI Server: 这是 CRI gRPC server，监听在 unix socket 上面 Streaming Server:...

如果你的 node 突然 notready，或者 pod状态异常时，你会 describe node 或describe pod 来查看原因，你可能会看到这一行报错:

当时调研cortex其实是因为看到了Weave Cloud这个商业产品中的监控模块介绍，weave也叫weave works，官方地址是：[链接]，是一个专注于容器微服务的paas平台。

Dockbix意为docker+zabbix，即使用zabbix来监控docker容器的插件或者模块，既然有专业的cadvisor、prometheus等容器监控方案，为什么还要用传统的zabbix呢？

Prometheus提供了本地存储，即tsdb时序数据库，本地存储给Prometheus带来了简单高效的使用体验，prometheus2.0以后压缩数据能力也得到了很大的提升。可以在单节点的情况下满足大部分用户的监控需求。

Prometheus自带了一个web服务，包括一个默认的dashboard，可以使用表达式查询并进行图表可视化，默认服务的地址为：[链接]:9090

运行命令：docker run --name prometheus -d -p 127.0.0.1:9090:9090 prom/prometheus暴露服务： [链接]:9090/

表达式的结果可以在浏览器中显示为图形，也可以显示为表格数据，或者由外部系统通过 HTTP API 调用。通过PromQL用户可以非常方便地查询监控数据，或者利用表达式进行告警配置

Prometheus的配置可以用命令行参数、或者配置文件，如果是在k8s集群内，一般配置在configmap中（以下均为prometheus2.7版本）

Prometheus从exporter拉取数据，或者间接地通过网关gateway拉取数据（如果在k8s内部署，可以使用服务发现的方式），它默认本地存储抓取的所有数据，并通过一定规则进行清理和整理数据，并把得到的结果存储到新的时间序列中，采集到的数据有两个去向，一个是报警，另一个是可视化。PromQL和其他API可视化地展示收集的数据...

Prometheus从2016年加入CNCF，到2018年8月毕业，现在已经成为Kubernetes的官方监控方案，接下来的几篇文章将详细解读Promethues(2.x)

概述 已经有了cadvisor、heapster、metric-server，几乎容器运行的所有指标都能拿到，但是下面这种情况却无能为力： 我调度了多少个replicas？现在可用的有几个？ 多少个Pod是running/stopped/terminated状态？ Pod重启了多少次？ 我有多少job在运行中 而这些则是kube-state-metrics提供的内容，它基于client-go开发，轮...

Core metrics(核心指标)：从 Kubelet、cAdvisor 等获取度量数据，再由metrics-server提供给 Dashboard、HPA 控制器等使用。

从 v1.8 开始，资源使用情况的监控可以通过 Metrics API的形式获取，具体的组件为Metrics Server，用来替换之前的heapster，heapster从1.11开始逐渐被废弃。

Horizontal Pod Autoscaling，简称HPA，是Kubernetes中实现POD水平自动伸缩的功能。自动扩展主要分为两种:

概述 该项目将被废弃（RETIRED） Heapster是Kubernetes旗下的一个项目，Heapster是一个收集者，并不是采集 1.Heapster可以收集Node节点上的cAdvisor数据：CPU、内存、网络和磁盘 2.将每个Node上的cAdvisor的数据进行汇总 3.按照kubernetes的资源类型来集合资源，比如Pod、Namespace 4.默认的metric数据聚合时间间隔是1分...

为了解决docker stats的问题(存储、展示)，谷歌开源的cadvisor诞生了，cadvisor不仅可以搜集一台机器上所有运行的容器信息，还提供基础查询界面和http接口，方便其他组件如Prometheus进行数据抓取，或者cadvisor + influxdb + grafna搭配使用。

传统虚机监控一般采用类似Zabbix的方案，但容器出现之后，再使用Zabbix agent来采集数据的话就显得有些吃力了，如果每个容器都像OS那样监控，则metric数量将会非常巨大，而且这些数据很可能几分钟之后就没有意义了（容器已经停止或漂移），且容器的指标汇总更应该是按照APP甚至POD维度。

随着越来越多的线上服务docker化，对容器的监控、报警变得越来越重要，容器监控有多种形态，有些是开源的（如promethues)，而另一些则是商业性质的(如Weave)，有些是集成在云厂商一键部署的（Rancher、谷歌云），有些是手动配置的，可谓百花齐放。

Kubernetes的官方文档中并没有对apiVersion的详细解释，而且因为K8S本身版本也在快速迭代，有些资源在低版本还在beta阶段，到了高版本就变成了stable。

Terraform是一款开源工具，出自HashiCorp公司，著名的Vagrant、Consul也出自于该公司。其主要作用是：让用户更轻松地管理、配置任何基础架构，管理公有和私有云服务，也可以管理外部服务，如GitHub，Nomad。