Kubernetes(k8s)监控报警之使用Prometheus和alertmanager及node_exporter和kube-state-metrics
一，监控报警
系统搭建完后，必然处在变化之中，而监控报警就是以一个全局的视角，实时的看待一个系统的变化，并对异常变化做出响应。
系统构成
计算机应用系统的构成，常常由基础设施，应用服务，以及业务模型构成。
那么监控报警，就可以分为三个方面，即
基础设施监控报警
应用服务监控报警
业务模型监控报警
而对于有些场景，还有用户体检的监控
而对于捕捉变化的手段常有
1，日志。格式化或半格式化的文本记录
2，调用链的追踪
3，metrics。基于时间序列的数据点
这里我们说的Kubernetes监控报警之Prometheus和alertmanager主要关注点在于metrics的实现方式。
二，metrics
metrics也就是数据点，
是一个基于时间序列的数据，简单的metris就是一个key，一个value，一个timestamp。
比如：http_request_total（key） 30000(value) 32874387583(timestamp)
而Prometheus还引入了一个概念，叫label。
Prometheus的metrics形如：
http_request_total{instance，http_method，http_code} 30000(value) 32874387583(timestamp)
我们可以根据label进行metrics的筛选
三，拉模式与推模式
上图是Prometheus的架构图
那么metrics，也就是数据点，从哪来呢？
对于metrics方式的监控报警手段，常常有两种方法可以收集到metrics数据。
一种是，上游应用程序将数据点，通过接口，直接写入到监控报警系统，这种称之为推模式。
而另一种是，监控报警系统定期到上游系统进行数据采集，这种称之为拉模式。
Prometheus常用的数据收集手段是拉模式。而对于不方便拉取的场景，比如job的运行。Prometheus也提供pushgateway的缓冲器，程序可以把数据点推给pushgateway，然后Prometheus在去pushgateway上进行数据拉取。
四，架构链条
现在就清楚了，我们的目的就是要把k8s的metrics通过Prometheus收集存储起来，并通过这些metrics进行监控图形的绘制展示，以及报警消息的发送。整个过程，是这样一个链条：
k8s<------Prometheus------>alertmanager------->电话，飞书，邮件等报警通道
--->grafana监控图形绘制
架构图如下所示：
五，实现
Prometheus想要实现拉取k8s的metrics，一般有这样几种部署方式：
1，使用prometheus-operator
项目在：https://github.com/prometheus-operator/prometheus-operator
可以获得简单自动的安装体验，目前项目处在beta阶段
2，使用Prometheus in k8s cluster
所谓in cluster 就是把Prometheus部署在k8s里面，比如给Prometheus以及和他相关的组件都部署在k8s的某一个namespace下。
3，由于某种原因，不能部署in cluser，或者已经有Prometheus集群了，想要接入K8S进来。那么也可以把Prometheus独立部署，在Prometheus服务发现的配置是指定k8s的api server地址就可以了。
我们使用了第2种方式。
六，操作
对于in cluster 模式，在操作方法上，也可以分为两种。一种是使用helm chart方法，集成安装。
一种是使用原始的yaml文件，进行apply。
我们使用的是，应用原始yaml文件进行安装。
操作命令非常简单，就是执行了三条命令：
1，kubectl create ns kube-ops
2，kubectl create configmap pro-config --from-file=proconfig/ -n kube-ops
3，kubectl apply -f .
当然，这里的 . 这个目录里包含了我们所有的yaml文件，这些yaml文件全部在我们的git仓库里：
https://github.com/mmgithub123/prometheus-monitoring-alertmanager-on-kubernetes
那么这三条命令的背后都发生了什么呢？
七，过程细节
首先我们需要知道K8S最根本的概念，也就是控制器，或者说控制理论以及跟随控制理论而产生的声明式API。
我们这些yaml文件，可以认为是我们的一些期望声明，那么K8S拿到这些yaml文件，也就是我们的期望声明后，就会以一种状态机控制器的模式，帮我们实现期望。而我们自己不用关心实现的过程，也就是说不用自己一个个的敲命令。
在展开具体的细节之前，我们在来看一下，我们的需求是什么，也就是说，我们做了什么期望声明，也就是为什么写了https://github.com/mmgithub123/prometheus-monitoring-alertmanager-on-kubernetes里面的这些yaml。
对于k8s集群的监控一般我们需要考虑以下几个方面，从大到小，从外到内，从粗到细，可以分为：
1，k8s基础设施的监控：比如节点的 cpu、load、disk、memory 等指标
2，k8s内部系统组件的状态：比如 kube-scheduler、kube-controller-manager，etcd，apiserver， kubelet，kube-proxy,kubedns/coredns等组件的监控
3，编排级的监控：比如 Deployment 的状态、pod的状态，daemonset的状态，资源的请求，调度情况和 API 延迟等的监控。
4，容器级的监控: 容器的状态，容器的资源使用情况。
对于这四种需求，我们的实现分别是：
1，使用node-exporter实现节点级别基础设施metrics的收集
2，因为我们使用的华为云CCE，我们拿不到master的数据，也就是kube-scheduler、kube-controller-manager，etcd的监控。但我们可以对apiserver进行监控
3，使用kube-state-metrics实现编排级别的监控
4，使用cadvisor实现容器级别的监控，目前cadvisor 已集成进kubelet
这也解释了，我们在https://github.com/mmgithub123/prometheus-monitoring-alertmanager-on-kubernetes里面那些文件之所以被创建的原因。
1，文件node_exporter_daemonset.yaml和node_exporter_service.yaml 用来发布node-exporter
2，文件kube-state-metrics-deployment.yaml和kube-state-metrics-svc.yaml 用来发布kube-state-metrics
3，文件alert-manager-svc.yaml，alert-manager-deployment.yaml ，alert-manager-configmap.yaml用来发布alertmanager
4，文件propod.yaml，prosvc.yaml，prosa.yaml用来发布Prometheus
八，yaml级别的拆解
首先，对于k8s里的项目，我们需要知道一些基本概念，比如CronJob,DaemonSet,Deployment,Job,Node
PersistentVolume,PersistentVolumeClaim,Pod,ReplicaSet,ReplicationController,Service,StatefulSet,Namespace,Horizontal Pod Autoscaler,Endpoint,Secret,ConfigMap
接下来，我会简单说明一下，这些概念的基本idea和使用场景
原文：https://www.cnblogs.com/mmgithub123/p/14967421.html