#prometheus

前面的课程中我们学习了用自定义的方式来对 Kubernetes 集群进行监控，但是还是有一些缺陷，比如 Prometheus、AlertManager 这些组件服务本身的高可用，当然我们也完全可以用自定义的方式来实现这些需求，我们也知道 Prometheus 在代码上就已经对 Kubernetes 有了原生的支持，可以通过服务发现的形式来自动监控集群，因此我们可以使用另外一种更加高级的方式来部署 Prometheus：Operator 框架。

前面的课程中我们使用 Prometheus 采集了 Kubernetes 集群中的一些监控数据指标，我们也尝试使用promQL语句查询出了一些数据，并且在 Prometheus 的 Dashboard 中进行了展示，但是明显可以感觉到 Prometheus 的图表功能相对较弱，所以一般情况下我们会一个第三方的工具来展示这些数据，今天我们要和大家使用到的就是grafana。

上节课我们和大家学习了怎样用 Promethues 来监控 Kubernetes 集群中的应用，但是对于 Kubernetes 集群本身的监控也是非常重要的，我们需要时时刻刻了解集群的运行状态。

对于集群的监控一般我们需要考虑以下几个方面：

• Kubernetes 节点的监控：比如节点的 cpu、load、disk、memory 等指标
• 内部系统组件的状态：比如 kube-scheduler、kube-controller-manager、kubedns/coredns 等组件的详细运行状态
• 编排级的 metrics：比如 Deployment 的状态、资源请求、调度和 API 延迟等数据指标

上一节我们和大家介绍了Prometheus的数据指标是通过一个公开的 HTTP(S) 数据接口获取到的，我们不需要单独安装监控的 agent，只需要暴露一个 metrics 接口，Prometheus 就会定期去拉取数据；对于一些普通的 HTTP 服务，我们完全可以直接重用这个服务，添加一个/metrics接口暴露给 Prometheus；而且获取到的指标数据格式是非常易懂的，不需要太高的学习成本。

在前面一文Kubernetes使用Prometheus搭建监控平台中我们知道了怎么使用Prometheus来搭建监控平台，也了解了grafana的使用。这篇文章就来说说报警系统的搭建，有人说报警用grafana就行了，实际上grafana对报警的支持真的很弱，而Prometheus提供的报警系统就强大很多，今天我们的主角就是AlertManager。

prometheus2.0正式版已经发布了，新增了很多特性，特别是底层存储性能提升了不少：https://prometheus.io/blog/2017/11/08/announcing-prometheus-2-0/。

在将之前监控平台升级到2.0 的过程中还是有一些坑的，因为有很多参数已经更改了，还不清除怎么在kubernetes上搭建prometheus监控平台的，可以查看前面的文章Kubernetes使用Prometheus搭建监控平台

本文章中涉及到的yaml文件可以在github中查看。

最近在测试环境搭建了Kubernetes集群环境，迁移了部分测试环境的应用，由于测试集群性能不是很好，有时会遇到集群资源不够的情况，一般情况下我们是直接通过Dashboard的资源统计图标进行观察的，但是很显然如果要上到生产环境，就需要更自动化的方式来对集群、Pod甚至容器进行监控了。Kubernetes内置了一套监控方案：influxdb+grafana+heapster。但由于之前我们的应用的业务监控使用的是Prometheus，所以这里准备使用Prometheus来完成k8s的集群监控。