k8s1.18.3的prometheus监控安装及配置告警通知

1、环境：这里是双master和两个node节点，Centos7.6，k8s安装步骤请移步这里安装：

2、持久化安装prometheus
我们prometheus采用nfs挂载方式来存储数据，同时使用configMap管理配置文件。并且我们将所有的prometheus存储在kube-system命名空间上。
3、将所有的prometheus的yaml文件放到一个目录下
mkdir /opt/prometheus -p && cd /opt/prometheus
4、生成配置文件文件

cat >> prometheus.configmap.yaml <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
  namespace: kube-system
data:
  prometheus.yml: |
    global:
      scrape_interval: 15s
      scrape_timeout: 15s
    scrape_configs:
    - job_name: 'prometheus'
      static_configs:
      - targets: ['localhost:9090']
EOF

# 配置文件解释（这里的configmap实际上就是prometheus的配置）
上面包含了3个模块global、rule_files和scrape_configs

其中global模块控制Prometheus Server的全局配置
scrape_interval:表示prometheus抓取指标数据的频率，默认是15s，我们可以覆盖这个值
evaluation_interval:用来控制评估规则的频率，prometheus使用规则产生新的时间序列数据或者产生警报

rule_files模块制定了规则所在的位置，prometheus可以根据这个配置加载规则，用于生产新的时间序列数据或者报警信息，当前我们没有配置任何规则，后期会添加

scrape_configs用于控制prometheus监控哪些资源。由于prometheus通过http的方式来暴露它本身的监控数据，prometheus也能够监控本身的健康情况。在默认的配置有一个单独的job，叫做prometheus，它采集prometheus服务本身的时间序列数据。这个job包含了一个单独的、静态配置的目标；监听localhost上的9090端口。
prometheus默认会通过目标的/metrics路径采集metrics。所以，默认的job通过URL：http://localhost:9090/metrics采集metrics。收集到时间序列包含prometheus服务本身的状态和性能。如果我们还有其他的资源需要监控，可以直接配置在该模块下即可

5、创建configmap资源对象
]# kubectl apply -f prometheus.configmap.yaml
获取资源对象
]# kubectl get configmaps -n kube-system |grep prometheus

配置文件创建完成，如果以后我们有新的资源需要被监控，我们只需要将ConfigMap对象更新即可，现在我们开始创建prometheus的Pod资源

cat > prometheus.deploy.yaml <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus
  namespace: kube-system
  labels:
    app: prometheus
spec:
  selector:
    matchLabels:
      app: prometheus
  template:
    metadata:
      labels:
        app: prometheus
    spec:
      serviceAccountName: prometheus
      containers:
      - image: prom/prometheus:v2.4.3
        name: prometheus
        command:
        - "/bin/prometheus"
        args:
        - "--config.file=/etc/prometheus/prometheus.yml"
        - "--storage.tsdb.path=/prometheus"
        - "--storage.tsdb.retention=30d"
        - "--web.enable-admin-api"  # 控制对admin HTTP API的访问，其中包括删除时间序列等功能
        - "--web.enable-lifecycle"  # 支持热更新，直接执行localhost:9090/-/reload立即生效
        ports:
        - containerPort: 9090
          protocol: TCP
          name: http
        volumeMounts:
        - mountPath: "/prometheus"
          subPath: prometheus
          name: data
        - mountPath: "/etc/prometheus"
          name: config-volume
        resources:
          requests:
            cpu: 100m
            memory: 512Mi
          limits:
            cpu: 100m
            memory: 512Mi
      securityContext:
        runAsUser: 0
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: prometheus
      - configMap:
          name: prometheus-config
        name: config-volume



---
apiVersion: v1
kind: Service
metadata:
  namespace: kube-system
  name: prometheus
  labels:
    app: prometheus
spec:
  type: NodePort
  selector:
    app: prometheus
  ports:
  - name: http
    port: 9090
    targetPort: http
    nodePort: 31002

EOF

我们在启动程序的时候，除了指定prometheus.yaml(configmap)以外，还通过storage.tsdb.path指定了TSDB数据的存储路径、通过storage.tsdb.rentention设置了保留多长时间的数据，还有下面的web.enable-admin-api参数可以用来开启对admin api的访问权限，参数web.enable-lifecyle用来开启支持热更新，有了这个参数之后，prometheus.yaml(configmap)文件只要更新了，通过执行localhost:9090/-/reload就会立即生效

我们添加了一行securityContext，，其中runAsUser设置为0，这是因为prometheus运行过程中使用的用户是nobody，如果不配置可能会出现权限问题

NFS搭建步骤

for i in k8s-master01 k8s-master02 k8s-node01 k8s-node02;do ssh root@$i "yum install nfs-utils rpcbind -y";done
接着我们在任意一台机器上搭建nfs，其他的服务器主要是挂载
我这里使用192.168.1.134

NFS服务器操作如下
mkdir -p /nfs/kubernetes
systemctl start rpcbind
systemctl enable rpcbind
systemctl enable nfs
echo "/nfs/kubernetes  *(rw,no_root_squash,sync)" >>/etc/exports
其他k8s节点直接启动rpcbind并且挂载目录就可以
systemctl start rpcbind
systemctl enable rpcbind
mkdir /nfs/kubernetes -p
mount -t nfs 192.168.1.134:/nfs/kubernetes /nfs/kubernetes

6、prometheus.yaml文件对应的ConfigMap对象通过volume的形式挂载进Pod，这样ConfigMap更新后，对应的pod也会热更新，然后我们在执行上面的reload请求，prometheus配置就生效了。除此之外，对了将时间数据进行持久化，我们将数据目录和一个pvc对象进行了绑定，所以我们需要提前创建pvc对象

cat >prometheus-volume.yaml <<EOF
apiVersion: v1
kind: PersistentVolume
metadata:
  name: prometheus
spec:
  capacity:
    storage: 10Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  nfs:
    server: 192.168.1.134
    path: /nfs/kubernetes/prometheus

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: prometheus
  namespace: kube-system
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

EOF

注：
#nfs
server nfs服务器ip
path 挂载点，提前挂在好，确保可以写入

7、这里通过一个简单的NFS作为存储后端创建一个pv & pvc
kubectl create -f prometheus-volume.yaml

8、我们这里还需要创建rbac认证，因为prometheus需要访问k8s集群内部的资源

cat >>prometheus-rbac.yaml <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus
rules:
- apiGroups:
  - ""
  resources:
  - nodes
  - services
  - endpoints
  - pods
  - nodes/proxy
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - configmaps
  - nodes/metrics
  verbs:
  - get
- nonResourceURLs:
  - /metrics
  verbs:
  - get
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: prometheus
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus
subjects:
- kind: ServiceAccount
  name: prometheus
  namespace: kube-system
EOF

8、由于我们要获取的资源，在每一个namespace下面都有可能存在，所以我们这里使用的是ClusterRole的资源对象，nonResourceURLs是用来对非资源型metrics进行操作的权限声明
kubectl create -f prometheus-rbac.yaml

我们将ConfigMap volume rbac 创建完毕后，就可以创建prometheus.deploy.yaml了，运行prometheus服务
kubectl create -f prometheus.deploy.yaml

#这里1/1 状态为Running即可，需要等待一会。
现在我们prometheus服务状态是已经正常了，但是我们在浏览器是无法访问prometheus的 webui服务。那么我们查看service
kubectl get svc -n kube-system |grep prometheus

这里定义的端口为31002,我们直接在浏览器上任意节点输入ip+端口即可，云服务器需要放开安全组端口，虚拟机需要开放防火墙端口。

9、我们可以查看一下当前监控规则
Status–>Targets

10、我们查看一下数据，是否收集到数据

二、Prometheus监控Kubernetes 集群节点及应用

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

1）Kubernetes节点的监控；比如节点的cpu、load、fdisk、memory等指标
2）内部系统组件的状态；比如kube-scheduler、kube-controller-manager、kubedns/coredns等组件的运行状态
3）编排级的metrics；比如Deployment的状态、资源请求、调度和API延迟等数据指标
监控方案
Kubernetes集群的监控方案主要有以下几种方案
1）Heapster:Herapster是一个集群范围的监控和数据聚合工具，以Pod的形式运行在集群中
2）Kubelet/cAdvisor之外，我们还可以向Heapster添加其他指标源数据，比如kube-state-metrics，Heapster已经被废弃，使用metrics-server代替
cAvisor:cAdvisor是Google开源的容器资源监控和性能分析工具，它是专门为容器而生，本身也支持Docker容器，Kubernetes中，我们不需要单独去安装，cAdvisor作为kubelet内置的一部分程序可以直接使用
Kube-state-metrics:通过监听API Server生成有关资源对象的状态指标，比如Deployment、Node、Pod，需要注意的是kube-state-metrics只是简单的提供一个metrics数据，并不会存储这些指标数据，所以我们可以使用Prometheus来抓取这些数据然后存储
metrics-server:metrics-server也是一个集群范围内的资源数据局和工具，是Heapster的代替品，同样的，metrics-server也只是显示数据，并不提供数据存储服务
不过kube-state-metrics和metrics-server之前还有很大不同的，二者主要区别如下
1.kube-state-metrics主要关注的是业务相关的一些元数据，比如Deployment、Pod、副本状态等
2.metrics-service主要关注的是资源度量API的实现，比如CPU、文件描述符、内存、请求延时等指标

监控集群节点

首先需要我们监控集群的节点，要监控节点其实我们已经有很多非常成熟的方案了，比如Nagios、Zabbix，甚至可以我们自己收集数据，这里我们通过prometheus来采集节点的监控指标，可以通过node_exporter获取，node_exporter就是抓取用于采集服务器节点的各种运行指标，目前node_exporter几乎支持所有常见的监控点，比如cpu、distats、loadavg、meminfo、netstat等，详细的监控列表可以参考github repo

这里使用DeamonSet控制器来部署该服务，这样每一个节点都会运行一个Pod，如果我们从集群中删除或添加节点后，也会进行自动扩展

cat >>prometheus-node-exporter.yaml<<EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
  namespace: kube-system
  labels:
    name: node-exporter
    k8s-app: node-exporter
spec:
  selector:
    matchLabels:
      name: node-exporter
  template:
    metadata:
      labels:
        name: node-exporter
        app: node-exporter
    spec:
      hostPID: true
      hostIPC: true
      hostNetwork: true
      containers:
      - name: node-exporter
        image: prom/node-exporter:v0.16.0
        ports:
        - containerPort: 9100
        resources:
          requests:
            cpu: 0.15
        securityContext:
          privileged: true
        args:
        - --path.procfs
        - /host/proc
        - --path.sysfs
        - /host/sys
        - --collector.filesystem.ignored-mount-points
        - '"^/(sys|proc|dev|host|etc)($|/)"'
        volumeMounts:
        - name: dev
          mountPath: /host/dev
        - name: proc
          mountPath: /host/proc
        - name: sys
          mountPath: /host/sys
        - name: rootfs
          mountPath: /rootfs
      tolerations:
      - key: "node-role.kubernetes.io/master"
        operator: "Exists"
        effect: "NoSchedule"
      volumes:
        - name: proc
          hostPath:
            path: /proc
        - name: dev
          hostPath:
            path: /dev
        - name: sys
          hostPath:
            path: /sys
        - name: rootfs
          hostPath:
            path: /

EOF

1、创建node-exporter并检查pod
kubectl create -f prometheus-node-exporter.yaml
kubectl get pod -n kube-system -o wide|grep node

#这里我们可以看到，我们有4个节点，在所有的节点上都启动了一个对应Pod进行获取数据
node-exporter.yaml文件说明

由于我们要获取的数据是主机的监控指标数据，而我们的node-exporter是运行在容器中的，所以我们在Pod中需要配置一些Pod的安全策略

hostPID:true
hostIPC:true
hostNetwork:true

#这三个配置主要用于主机的PID namespace、IPC namespace以及主机网络，这里需要注意的是namespace是用于容器隔离的关键技术，这里的namespace和集群中的namespace是两个完全不同的概念

另外我们还需要将主机/dev、/proc、/sys这些目录挂在到容器中，这些因为我们采集的很多节点数据都是通过这些文件来获取系统信息

比如我们在执行top命令可以查看当前cpu使用情况，数据就来源于/proc/stat，使用free命令可以查看当前内存使用情况，其数据来源是/proc/meminfo文件

另外如果是使用kubeadm搭建的，同时需要监控master节点的，则需要添加下方的相应容忍

      - key: "node-role.kubernetes.io/master"
        operator: "Exists"
        effect: "NoSchedule
node-exporter容器相关启动参数

        args:
        - --path.procfs     #配置挂载宿主机（node节点）的路径
        - /host/proc
        - --path.sysfs      #配置挂载宿主机（node节点）的路径
        - /host/sys
        - --collector.filesystem.ignored-mount-points
        - '"^/(sys|proc|dev|host|etc)($|/)"'
在我们的yaml文件中加入了hostNetwork:true会直接将我们的宿主机的9100端口映射出来，从而不需要创建service 在我们的宿主机上就会有一个9100的端口

容器的9100--->映射到宿主机9100

      hostNetwork: true
      containers:
      - name: node-exporter
        image: prom/node-exporter:v0.16.0
        ports:
        - containerPort: 9100
上面我们检查了Pod的运行状态都是正常的，接下来我们要查看一下Pod日志，以及node-exporter中的metrics

使用命令kubectl logs -n 命名空间 node-exporter中Pod名称检查Pod日志是否有额外报错
#接下来，我们在任意集群节点curl 9100/metrics
curl 127.0.0.1:9100/metrics|head

只要metrics可以获取到数据说明node-exporter没有问题

服务发现

我们这里四个节点都运行了node-exporter程序，如果我们通过一个Server来将数据收集在一起，用静态的方式配置到prometheus就会显示一条数据，我们得自己在指标中过滤每个节点的数据，配置比较麻烦。 这里就采用服务发现
在Kubernetes下，Prometheus通过Kubernetes API基础，目前主要支持5种服务发现，分别是node、Server、Pod、Endpoints、Ingress
需要我们在Prometheus配置文件中，添加如下三行

    - job_name: 'kubernetes-node'
      kubernetes_sd_configs:
      - role: node

#通过制定Kubernetes_sd_config的模式为node，prometheus就会自动从Kubernetes中发现所有的node节点并作为当前job监控的目标实例，发现的节点/metrics接口是默认的kubelet的HTTP接口

接下来我们更新配置文件
kubectl apply -f prometheus.configmap.yaml

curl -X POST http://10.0.0.18:9090/-/reload
#热更新刷新配置（需要等待一小会）
接着访问我们的地址
http://192.168.1.4:31002/target
这个端口要和service对上
现在我们可以看到已经获取到我们的Node节点的IP，但是由于metrics监听的端口是10250而并不是我们设置的9100，所以提示我们节点属于Down的状态
这里我们就需要使用Prometheus提供的relabel_configs中的replace能力了，relabel可以在Prometheus采集数据之前，通过Target实例的Metadata信息，动态重新写入Label的值。除此之外，我们还能根据Target实例的Metadata信息选择是否采集或者忽略该Target实例。这里使用__address__标签替换10250端口为9100

这里使用正则进行替换端口

    - job_name: 'kubernetes-node'
      kubernetes_sd_configs:
      - role: node
      relabel_configs:
      - source_labels: [__address__]
        regex: '(.*):10250'
        replacement: '${1}:9100'
        target_label: __address__
        action: replace

接下来我们更新一下配置
curl的时候可以多更新几次，顺便等待一会
kubectl apply -f prometheus.configmap.yaml
curl -X POST http://10.0.0.18:9090/-/reload #多执行几次
然后查看状态正常了。
目前状态已经正常，但是还有一个问题就是我们的采集数据只显示了IP地址，对于我们监控分组分类不是很方便，这里可以通过labelmap这个属性来将Kubernetes的Label标签添加为Prometheus的指标标签，在文件prometheus.configmap.yaml 后添加

      - action: labelmap
        regex: __meta_kubernetes_node_label_(.+)

添加了一个action为labelmap，正则表达式是__meta_kubernetes_node(.+)的配置，这里的意思就是表达式中匹配的数据也添加到指标数据的Label标签中去。
kubectl apply -f prometheus.configmap.yaml
curl -X POST http://10.0.0.18:9090/-/reload #多执行几次

实际上就是获取我们的标签

对于Kubernetes_sd_configs下面可用的元标签如下

__meta_kubernetes_node_name: 节点对象的名称

_meta_kubernetes_node_label: 节点对象中的每个标签
_meta_kubernetes_node_annotation: 来自节点对象的每个注释
_meta_kubernetes_node_address: 每个节点地址类型的第一个地址(如果存在) 关于kubernetes_sd_configs更多信息可以查看官方文档: kubernetes_sd_config

#prometheus configmap 监控完整配置如下,可以直接拷贝
apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
  namespace: kube-system
data:
  prometheus.yml: |
    global:
      scrape_interval: 15s
      scrape_timeout: 15s
    scrape_configs:
    - job_name: 'prometheus'
      static_configs:
      - targets: ['localhost:9090']
    - job_name: 'kubernetes-node'
      kubernetes_sd_configs:
      - role: node
      relabel_configs:
      - source_labels: [__address__]
        regex: '(.*):10250'
        replacement: '${1}:9100'
        target_label: __address__
        action: replace
      - action: labelmap
        regex: __meta_kubernetes_node_label_(.+)
    - job_name: 'kubernetes-cadvisor'
      kubernetes_sd_configs:
      - role: node
      scheme: https
      tls_config:
        ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
      bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
      relabel_configs:
      - action: labelmap
        regex: __meta_kubernetes_node_label_(.+)
      - target_label: __address__
        replacement: kubernetes.default.svc:443
      - source_labels: [__meta_kubernetes_node_name]
        regex: (.+)
        target_label: __metrics_path__
        replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor

我们还可以去Graph里面看一下数据

我们这里也可以自定义规则

容器监控

cAdvisor是一个容器资源监控工具，包括容器的内存，CPU，网络IO，资源IO等资源，同时提供了一个Web页面用于查看容器的实时运行状态。
cAvisor已经内置在了kubelet组件之中，所以我们不需要单独去安装，cAdvisor的数据路径为/api/v1/nodes//proxy/metrics
action 使用labelkeep或者labeldrop则可以对Target标签进行过滤，仅保留符合过滤条件的标签。

    - job_name: 'kubernetes-cadvisor'
      kubernetes_sd_configs:
      - role: node
      scheme: https
      tls_config:
        ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
      bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
      relabel_configs:
      - action: labelmap
        regex: __meta_kubernetes_node_label_(.+)
      - target_label: __address__
        replacement: kubernetes.default.svc:443
      - source_labels: [__meta_kubernetes_node_name]
        regex: (.+)
        target_label: __metrics_path__
        replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor

ls_config配置的证书地址是每个Pod连接apiserver所使用的地址，基本上写死了。并且我们在配置文件添加了一个labelmap标签。在最下面使用了一个正则替换了cAdvisor的一个metrics地址
证书是我们Pod启动的时候kubelet给pod注入的一个证书，所有的pod启动的时候都会有一个ca证书注入进来
如要想要访问apiserver的信息，还需要配置一个token_file
修改完成之后，我们需要configmap并且使用curl进行热更新(过程比较慢，需要等待会)
kubectl apply -f prometheus.configmap.yaml
curl -X POST http://10.0.0.18:9090/-/reload #多执行几次

现在我们可以到Graph路径下面查询容器的相关数据

这里演示查询集群中所有Pod的CPU使用情况，查询指标container_cpu_usage_seconds_total并且查询1分钟之内的数据
这里演示一下使用函数rate和不使用函数的一个过滤功能
container_cpu_usage_seconds_total{image!=" “,pod_name!=” “}
rate(container_cpu_usage_seconds_total{image!=” “,pod_name!=” “}[1m])
执行下方命令，过滤1分钟内的数据
rate(container_cpu_usage_seconds_total{image!=” “,pod_name!=” "}[1m])

还可以使用sum函数,pod在1分钟内的使用率，同时将pod名称打印出来

Api-Service 监控

apiserver作为Kubernetes最核心的组件，它的监控也是非常有必要的，对于apiserver的监控，我们可以直接通过kubernetes的service来获取。
kubectl get svc --all-namespaces
上面的service是我们集群的apiserver内部的service的地址，要自动发现service类型的服务，需要使用role为Endpoints的kubernetes_sd_configs (自动发现)，我们只需要在configmap里面在添加Endpoints类型的服务发现
刷新配置文件

更新完成后，我们可以看到kubernetes-apiserver下面出现了很多实例，这是因为我们这里使用的Endpoints类型的服务发现，所以prometheus把所有的Endpoints服务都抓取过来了，同样的我们要监控的kubernetes也在列表中。

这里我们使用keep动作，将符合配置的保留下来，例如我们过滤default命名空间下服务名称为kubernetes的元数据，这里可以根据__meta_kubernetes_namespace和__mate_kubertnetes_service_name2个元数据进行relabel

 - job_name: kubernetes-apiservers
      kubernetes_sd_configs:
      - role: endpoints
      relabel_configs:
      - action: keep
        regex: default;kubernetes;https
        source_labels:
        - __meta_kubernetes_namespace
        - __meta_kubernetes_service_name
        - __meta_kubernetes_endpoint_port_name
      scheme: https
      tls_config:
        ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        insecure_skip_verify: true
      bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token

#参数解释
action: keep #保留哪些标签
regex: default;kubernetes;https #匹配namespace下的default命名空间下的kubernetes service 最后https协议
可以通过kubectl describe svc kubernetes查看到
刷新配置

#这个过程比较慢，可能要等几分钟,可以多reload几次
curl -X POST http://10.0.0.18:9090/-/reload #多执行几次

接下来我们还是前往Greph上查看采集到的数据
sum(rate(apiserver_request_count[1m]))
#这里使用的promql里面的rate和sun函数，意思是apiserver在1分钟内请求的数

如果我们要监控其他系统组件，比如kube-controller-manager、kube-scheduler的话就需要单独手动创建service，因为apiserver服务默认在default，而其他组件在kube-steam这个namespace下。其中kube-sheduler的指标数据端口为10251，kube-controller-manager对应端口为10252

Service 监控

apiserver实际上是一种特殊的Service，现在配置一个专门发现普通类型的Service
这里我们对service进行过滤，只有在service配置了prometheus.io/scrape: "true"过滤出来

- job_name: 'kubernetes-service-endpoints'
      kubernetes_sd_configs:
      - role: endpoints
      relabel_configs:
      - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
        action: replace
        target_label: __scheme__
        regex: (https?)
      - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]
        action: replace
        target_label: __metrics_path__
        regex: (.+)
      - source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]
        action: replace
        target_label: __address__
        regex: ([^:]+)(?::\d+)?;(\d+)
        replacement: $1:$2
      - action: labelmap
        regex: __meta_kubernetes_service_label_(.+)
      - source_labels: [__meta_kubernetes_namespace]
        action: replace
        target_label: kubernetes_namespace
      - source_labels: [__meta_kubernetes_service_name]
        action: replace
        target_label: kubernetes_name

Serivce自动发现参数说明 （并不是所有创建的service都可以被prometheus发现）

#1.参数解释
relabel_configs:
-source_labels:[__meta_kubernetes_service_annotation_prometheus_io_scrape]
action: keep 
regex: true  保留标签
source_labels: [__meta_kubernetes_service_annotation_prometheus_io_cheme]

这行配置代表我们只去筛选有__meta_kubernetes_service_annotation_prometheus_io_scrape的service，只有添加了这个声明才可以自动发现其他service

#2.参数解释
  - source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]
    action: replace
    target_label: __address__
    regex: ([^:]+)(?::\d+)?;(\d+)
    replacement: $1:$2
#指定一个抓取的端口，有的service可能有多个端口（比如之前的redis）。默认使用的是我们添加是使用kubernetes_service端口

#3.参数解释
  - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
    action: replace
    target_label: __scheme__
    regex: (https?)
#这里如果是https证书类型，我们还需要在添加证书和token

为什么那么多service只有coreDNS可以被收集到呢？
上面也说了，我们有过滤条件，只有复合条件的才进行过滤
core DNS serviceYaml 文件包含true参数，所以会被匹配到

继续重复步骤，刷新配置
kubectl apply -f prometheus.configmap.yaml
curl -X POST http://10.0.0.18:9090/-/reload #多执行几次

Grafana 安装并监控k8s集群

Grafana是一个跨平台的开源的度量分析和可视化工具，可以通过将采集的数据查询然后可视化的展示，并及时通知。
由于Prometheus自带的web Ui图标功能相对较弱，所以一般情况下我们会使用一个第三方的工具来展示这些数据

Grafana介绍
grafana 是一个可视化面包，有着非常漂亮的图片和布局展示，功能齐全的度量仪表盘和图形化编辑器，支持Graphite、Zabbix、InfluxDB、Prometheus、OpenTSDB、Elasticasearch等作为数据源，比Prometheus自带的图标展示功能强大很多，更加灵活，有丰富的插件
我们这里使用deployment持久化安装grafana

cat >>grafana_deployment.yaml <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: grafana
  namespace: kube-system
  labels:
    app: grafana
    k8s-app: grafana
spec:
  selector:
    matchLabels:
      k8s-app: grafana
      app: grafana
  revisionHistoryLimit: 10
  template:
    metadata:
      labels:
        app: grafana
        k8s-app: grafana
    spec:
      containers:
      - name: grafana
        image: grafana/grafana:5.3.4
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 3000
          name: grafana
        env:
        - name: GF_SECURITY_ADMIN_USER
          value: admin
        - name: GF_SECURITY_ADMIN_PASSWORD
          value: jiangwenhui
        readinessProbe:
          failureThreshold: 10
          httpGet:
            path: /api/health
            port: 3000
            scheme: HTTP
          initialDelaySeconds: 60
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 30
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /api/health
            port: 3000
            scheme: HTTP
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        resources:
          limits:
            cpu: 300m
            memory: 1024Mi
          requests:
            cpu: 300m
            memory: 1024Mi
        volumeMounts:
        - mountPath: /var/lib/grafana
          subPath: grafana
          name: storage
      securityContext:
        fsGroup: 472
        runAsUser: 472
      volumes:
      - name: storage
        persistentVolumeClaim:
          claimName: grafana
EOF

这里使用了grafana 5.3.4的镜像，添加了监控检查、资源声明，比较重要的变量是GF_SECURITY_ADMIN_USER和GF_SECURITY_ADMIN_PASSWORD为grafana的账号和密码。
由于grafana将dashboard、插件这些数据保留在/var/lib/grafana目录下，所以我们这里需要做持久化，同时要针对这个目录做挂载声明，由于5.3.4版本用户的userid和groupid都有所变化，所以这里添加了一个securityContext设置用户ID
image_1ddnv749l17k7ucdel1m4v17jjea.png-56.5kB
现在我们添加一个pv和pvc用于绑定grafana

cat >>grafana_volume.yaml <<EOF
apiVersion: v1
kind: PersistentVolume
metadata:
  name: grafana
spec:
  capacity:
    storage: 10Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  nfs:
    server: 192.168.1.134
    path: /nfs/kubernetes/grafana
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: grafana
  namespace: kube-system
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

EOF

这里配置依旧使用NFS进行挂载使用

现在我们还需要创建一个service，使用NodePort

cat >>grafana_svc.yaml<<EOF
apiVersion: v1
kind: Service
metadata:
  name: grafana
  namespace: kube-system
  labels:
    app: grafana
spec:
  type: NodePort
  ports:
    - port: 3000
    targetPort: 3000
    nodePort: 31001
  selector:
    app: grafana
EOF

由于5.1(可以选择5.1之前的docker镜像，可以避免此类错误)版本后groupid更改，同时我们将/var/lib/grafana挂载到pvc后，目录拥有者可能不是grafana用户，所以我们还需要添加一个Job用于授权目录

cat > grafana_job.yaml <<EOF
apiVersion: batch/v1
kind: Job
metadata:
  name: grafana-chown
  namespace: kube-system
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: grafana-chown
        command: ["chown", "-R", "472:472", "/var/lib/grafana"]
        image: busybox
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - name: storage
          subPath: grafana
          mountPath: /var/lib/grafana
      volumes:
      - name: storage
        persistentVolumeClaim:
          claimName: grafana
EOF

这里使用一个busybox镜像将/var/lib/grafana目录修改为权限472

#需要先创建pv和pvc  (这里是需要安装顺序来创建)
# kubectl create -f grafana_volume.yaml
persistentvolume/grafana created
persistentvolumeclaim/grafana created
# kubectl create -f grafana_job.yaml
job.batch/grafana-chown created
# kubectl apply -f grafana_deployment.yaml
deployment.apps/grafana created
# kubectl create -f grafana_svc.yaml

然后我们在任意集群中的节点访问端口为31001
这里的集群密码就是上面我们创建deployment里面设置的变量，我这里用户设置为admin密码admin
通过ingress-nginx代理域名
创建完成后我们打开grafana的dashboard界面

登陆到grafana就显示到了我们的引导界面
第一次创建grafana需要添加数据源

类型选择prometheus
这里的地址我们填写下面的url
http://prometheus.kube-system.svc.cluster.local:9090
这里的prometheus代表service名称
kube-system代表命名空间


数据源添加完毕后，接下来添加New dashboard

这里我们可以自定义模板，或者可以使用别人写好的模板 （写好的模板后面是需要我们自己修改的）

grafana提供了很多模板，类似和docker镜像仓库一下。导入模板也极其简单。点击上方的Dashboard

这里面的模板都是公共的，可以免费使用

点进去任意一个模板后，我们可以看到ID，复制ID然后在返回grafana
我这里添加一个监控Kubernetes集群。显示整体群集CPU、内存、磁盘使用情况以及单个pod统计信息。
https://grafana.com/grafana/dashboards/8588
点击导入模板

在这里我们输入8588或者url，会自动跳转到配置页面
https://grafana.com/grafana/dashboards/8588

选择好数据源之后，我们在点击Import即可

这里就会将模板8588给我们导入进行
这里就会获取我们prometheus里面的数据了

现在的模板还没有进行保存，我们要点击保存一下

现在就保存下来了。

目前我们导入模板之后是无法直接使用的。
这里无法显示是由于模板定义的标签，我们prometheus并没有这个数据元，所以说我们要对模板进行修改！
在修改之前我们先设置一下时区，grafana默认走的是浏览器时区，但是prometheus使用的是UTC时区

修改默认模板 (我这里使用的是8588模板，下面模板修改请根据我的操作步骤进行操作)。
grafana模板修改
前面的步骤必须和我相同，否则这里可能会无法出现值
首先我们进行编辑 Cluster memory usage (集群内存使用率)

计算方式就是(整个集群的内存-(整个集群剩余的内存以及Buffer和Cached))/整
(sum(node_memory_MemTotal_bytes) - sum(node_memory_MemFree_bytes + node_memory_Buffers_bytes+node_memory_Cached_bytes)) / sum(node_memory_MemTotal_bytes) * 100

这里要说明一点，这里填写的是PromSQL，也就是说是可以在prometheus查询到的。 如果查询不到grafana也是会获取不到数据的
这里在prometheus是可以获取到的

Cluster memory usage 配置如下 (集群内存使用率)
sum(sum by (container_name)( rate(container_cpu_usage_seconds_total{image!=""}[1m] ) )) / count(node_cpu_seconds_total{mode=“system”}) * 100

Cluster filesystem usage 集群文件系统使用率
(sum(node_filesystem_size_bytes{device=“tmpfs”}) - sum(node_filesystem_free_bytes{device=“tmpfs”}) ) / sum(node_filesystem_size_bytes{device=“tmpfs”}) * 100

这里我们就获取到数据了。

接下来我们配置集群中Pod cpu使用率。
sum by (pod)(rate(container_cpu_usage_seconds_total{image!=" “, pod_name!=” “}[1m]))
下面显示的地方配置
{{ pod }}

集群pod 内存使用率。
sort_desc(sum (container_memory_usage_bytes{image!=” “, pod_name!=” "}) by(pod))
下面显示的名称同样也是{{ pod }}

最后我们配置一下Pod 网络监控。

1.入口流量
sort_desc(sum by (pod) (rate (container_network_receive_bytes_total{name!=""}[1m]) ))

2.出口流量
sort_desc(sum by (pod) (rate (container_network_transmit_bytes_total{name!=""}[1m]) ))

#监控时间为1分钟

效果图如下 记得点击保存。

所有的PromSQL都是可以在prometheus获取到数据的。

Prometheus AlertManager 实战

AlerManager 简介
Prometheus包含了一个报警模块，那就是AlertManager，主要用于接受Prometheus发送的告警信息，它支持丰富的告警通知渠道，而且很容易做到告警信息进行去重，降噪，分组等，是一个前卫的告警通知系统
安装 AlerManager
prometheus配置文件官方文档
https://prometheus.io/docs/alerting/configuration/
首先，我们需要先指定配置文件 ，这里我们还是创建一个ConfigMap资源对象

cat >> prometheus-alert-conf.yaml <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: alert-config
  namespace: kube-system
data:
  config.yml: |-
    global:
      # 在没有报警的情况下声明为已解决的时间
      resolve_timeout: 5m
      # 配置邮件发送信息
      smtp_smarthost: 'smtp.126.com:465'
      smtp_from: '[email protected]'
      smtp_auth_username: '[email protected]'
      smtp_auth_password: '授权码'
      smtp_hello: '126.com'
      smtp_require_tls: false
    # 所有报警信息进入后的根路由，用来设置报警的分发策略
    route:
      # 这里的标签列表是接收到报警信息后的重新分组标签，例如，接收到的报警信息里面有许多具有 cluster=A 和 alertname=LatncyHigh 这样的标签的报警信息将会批量被聚合到一个分组里面
      group_by: ['alertname', 'cluster']
      # 当一个新的报警分组被创建后，需要等待至少group_wait时间来初始化通知，这种方式可以确保您能有足够的时间为同一分组来获取多个警报，然后一起触发这个报警信息。
      group_wait: 30s

      # 当第一个报警发送后，等待'group_interval'时间来发送新的一组报警信息。
      group_interval: 5m

      # 如果一个报警信息已经发送成功了，等待'repeat_interval'时间来重新发送他们
      repeat_interval: 5m

      # 默认的receiver：如果一个报警没有被一个route匹配，则发送给默认的接收器
      receiver: default

      # 上面所有的属性都由所有子路由继承，并且可以在每个子路由上进行覆盖。
      routes:
      - receiver: email
        group_wait: 10s
        match:
          team: node
    receivers:
    - name: 'mail'
      email_configs:
      - to: '[email protected],[email protected]'
        send_resolved: true

EOF

授权密码申请，自行搜索百度步骤：邮箱获取授权密码。
我们现在创建alertmanager的配置文件。如下图已经显示alert-config

现在我们在之前的prometheus pod的yaml文件中添加这个容器
这里我们将上面创建的aler-config这个configmap资源对象volume的形式挂载到/etc/alertmanager目录下去，然后在启动参数中指定–config.file=/etc/alertmanager/config.yml

cat alermanager.deployment.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: alertmanager
  namespace: kube-system
  labels:
    k8s-app: alertmanager
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
    version: v0.14.0
spec:
  replicas: 1
  selector:
    matchLabels:
      k8s-app: alertmanager
      version: v0.16.1
  template:
    metadata:
      labels:
        k8s-app: alertmanager
        version: v0.16.1
      annotations:
        scheduler.alpha.kubernetes.io/critical-pod: ''
    spec:
      priorityClassName: system-cluster-critical
      containers:
        - name: prometheus-alertmanager
          image: "prom/alertmanager:v0.16.1"
          imagePullPolicy: "IfNotPresent"
          args:
            - --config.file=/etc/alertmanager/alertmanager.yml
            - --storage.path=/data
            - --web.external-url=/
          ports:
            - containerPort: 9093
          readinessProbe:
            httpGet:
              path: /#/status
              port: 9093
            initialDelaySeconds: 30
            timeoutSeconds: 30
          volumeMounts:
            - name: config-volume
              mountPath: /etc/config
            - name: storage-volume
              mountPath: "/data"
              subPath: ""
          resources:
            limits:
              cpu: 10m
              memory: 50Mi
            requests:
              cpu: 10m
              memory: 50Mi
      volumes:
        - name: config-volume
          configMap:
            name: alert-config
        - name: storage-volume
          persistentVolumeClaim:
            claimName: alertmanager

cat alertmanager-pvc.yaml 
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: alertmanager
  namespace: kube-system
  labels:
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: EnsureExists
spec:
  # 使用自己的动态PV
  storageClassName: managed-nfs-storage 
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: "2Gi"

cat alertmanager-service.yaml
piVersion: v1
kind: Service
metadata:
  name: alertmanager
  namespace: kube-system
  labels:
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
    kubernetes.io/name: "Alertmanager"
spec:
  ports:
    - name: http
      port: 80
      protocol: TCP
      targetPort: 9093
  selector:
    k8s-app: alertmanager 
  type: "ClusterIP"

部署，创建PV，configmap，deployment，service
kubectl apply -f alertmanager-pvc.yaml
kubectl apply -f prometheus-alert-conf.yaml
kubectl apply -f alermanager.deployment.yaml
kubectl apply -f alertmanager-service.yaml
AlertManager容器启动之后，我们还需要在Prometheus中配置下AlertManager的地址，让Prometheus能够访问AlertManager

kubectl apply -f prometheus.configmap.yaml #更新文件

#确保更新配置没有报错（刷新比较慢可以等等）
现在prometheus alertmanager并没有告警的规则，还需要我们添加报警规则
Prometheus 报警规则
上面我们将prometheus和alertmanager进行了关联，但是现在并没有报警规则，所以这里还需要配置一些报警规则。让prometheus触发报警
#首先在prometheus.configmap.yaml文件中添加报警规则，下面的文件就是prometheus报警的规则文件
rule_files:
- /etc/prometheus/rules.yml

报警规则允许基于Prometheus表达式语言来定义报警规则条件，并在出发报警时发送给外部。
我们上面已经将/etc/promtehus进行挂载了，所以这里只需要修改prometheus-configmap就可以了。

  rules.yml: |
    groups:
    - name: memeory_rules
      rules:
      - alert: 内存炸了
        expr: (node_memory_MemTotal_bytes - node_memory_MemFree_bytes - node_memory_Buffers_bytes - node_memory_Cached_bytes) / (node_memory_MemTotal_bytes )* 100 > 90
        for: 1m
        labels:
          severity: warning
        annotations:
          summary: "{{ $labels.instance }} 内存炸了"
          description: "{{ $labels.instance }} 内存炸了，当前使用率为 {{ $value }}"               
      - alert: TCP连接数过高
        expr: node_sockstat_TCP_alloc > 1024 
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.instance }} TCP连接数过高"
          description: "{{ $labels.instance }} TCP连接数过高，当前连接数 {{ $value }}"
      - alert: TCP连接数过高
        expr: node_sockstat_TCP_alloc > 1024 
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.instance }} TCP连接数过高"
          description: "{{ $labels.instance }} TCP连接数过高，当前连接数 {{ $value }}"
      - alert: 主机状态
        expr: up == 0
        for: 1m
        labels:
          status: 非常严重
        annotations:
          summary: "{{$labels.instance}}:服务器宕机"
          description: "{{$labels.instance}}:服务器延时超过5分钟"
      - alert: CPU使用情况
        expr: 100-(avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) by(instance)* 100) > 70
        for: 1m
        labels:
          status: 一般告警
        annotations:
          summary: "{{$labels.mountpoint}} CPU使用率过高！"
          description: "{{$labels.mountpoint }} CPU使用大于70%(目前使用:{{$value}}%)"
      - alert: 内存使用
        expr: 100 -(node_memory_MemTotal_bytes -node_memory_MemFree_bytes+node_memory_Buffers_bytes+node_memory_Cached_bytes ) / node_memory_MemTotal_bytes * 100> 90
        for: 1m
        labels:
          status: 严重告警
        annotations:
          summary: "{{$labels.mountpoint}} 内存使用率过高！"
          description: "{{$labels.mountpoint }} 内存使用大于80%(目前使用:{{$value}}%)"
      - alert: IO性能
        expr: 100-(avg(irate(node_disk_io_time_seconds_total[1m])) by(instance)* 100) < 70
        for: 1m
        labels:
          status: 严重告警
        annotations:
          summary: "{{$labels.mountpoint}} 流入磁盘IO使用率过高！"
          description: "{{$labels.mountpoint }} 流入磁盘IO大于70%(目前使用:{{$value}})"
      - alert: 流入网络
        expr: ((sum(rate (node_network_receive_bytes_total{device!~'tap.*|veth.*|br.*|docker.*|virbr*|lo*'}[5m])) by (instance)) / 100) > 102400
        for: 1m
        labels:
          status: 严重告警
        annotations:
          summary: "{{$labels.mountpoint}} 流入网络带宽过高！"
          description: "{{$labels.mountpoint }}流入网络带宽持续2分钟高于100M. RX带宽使用率{{$value}}"
      - alert: 流出网络
        expr: ((sum(rate (node_network_transmit_bytes_total{device!~'tap.*|veth.*|br.*|docker.*|virbr*|lo*'}[5m])) by (instance)) / 100) > 102400
        for: 1m
        labels:
          status: 严重告警
        annotations:
          summary: "{{$labels.mountpoint}} 流出网络带宽过高！"
          description: "{{$labels.mountpoint }}流出网络带宽持续2分钟高于100M. RX带宽使用率{{$value}}"
      - alert: TCP会话
        expr: node_netstat_Tcp_CurrEstab > 2000
        for: 1m
        labels:
          status: 严重告警
        annotations:
          summary: "{{$labels.mountpoint}} TCP_ESTABLISHED过高！"
          description: "{{$labels.mountpoint }} TCP_ESTABLISHED大于2000%(目前使用:{{$value}}%)"
      - alert: 磁盘容量
        expr: 100-(node_filesystem_free_bytes{fstype=~"ext4|xfs"}/node_filesystem_size_bytes {fstype=~"ext4|xfs"}*100) > 90
        for: 1m
        labels:
          status: 严重告警
        annotations:
          summary: "{{$labels.mountpoint}} 磁盘分区使用率过高！"
          description: "{{$labels.mountpoint }} 磁盘分区使用大于90%(目前使用:{{$value}}%)"

#配置相关参数说明
  rules.yml: |
    groups:
    - name: test
      rules:  #规则
      - alert: 内存炸了 #报警名称(内存报警)
        expr: (node_memory_MemTotal_bytes - (node_memory_MemFree_bytes + node_memory_Buffers_bytes + node_memory_Cached_bytes)) / node_memory_MemTotal_bytes * 100 > 90 #规则表达式
        for: 1m  #等待1分钟执行查询条件
        labels:
          team: node   #当我们触发报警后，带有team=node的标签，并且这里走的是我们alertmanager node标签，这里对应的就是我们的email接收器
        annotations:  #指定另外一组标签，不会将这个标签当做我们告警的身份标示（不会在我们报警信息里操作）这里主要是用于额外的展示，例如发送给邮件里面>的报警信息
          summary: "{{ $labels.instance }}：High Memory Usage detected"   #label标签，instance代表节点名称
          description: "{{ $labels.instance }}: Memory usage us avive 90% (current value is :: {{ $value }})" #描述：相当于报警信息 $value代表当前值

expr所执行的命令是可以在prometheus上获取到数据的。
kubectl apply -f prometheus.configmap.yaml
kubectl get pod -n kube-system -o wide |grep prometheus
prometheus-68bc4d87dc-zjpbw 1/1 Running 1 9m22s 10.244.3.138 k8s-master02
curl -X POST http://10.244.3.138:9090/-/reload
curl -X POST http://10.244.3.138:9090/-/reload 等待一会。

报警说明
本次报警大概意思是当服务器内存百分比大于90的时候，就进行报警，并且通过labels标签关联team:node (这里team=node是在我们alertmanager里面配置的接收器，默认是default)，并且报警内容添加主机和当前内存使用率。
检查alertmanager发送告警失败

解决方法：

配置alertmanager的时候，都是根据网上的教程来配置的。

因为我是用QQ邮箱来发送告警的，所以alertmanager.yml的邮箱配置如下：

global:
resolve_timeout: 5m
smtp_smarthost: 'smtp.qq.com:465'
smtp_from: '[email protected]'
smtp_auth_username: '[email protected]'
smtp_auth_password: 'xxxxxxxxxx'
smtp_require_tls: false

 

注意事项：

1.需要先登录QQ邮箱，开通smtp功能，并获取授权码。smtp_auth_password填写的信息，就是授权码，而非QQ邮箱的登录密码！

2.smtp.qq.com:465 ，端口使用465。其他资料说用587端口也可以。（如果是云服务器，25端口通常是被服务商封闭的，所有也不能使用25端口）
 报错信息：
msg="Notify for alerts failed" num_alerts=1 err="*notify.loginAuth failed: 530 Must issue a STARTTLS command first."
3.smtp_require_tls: false 必须加上，因为smtp_require_tls默认为true。

接下来我们访问prometheus，点击alerts，就可以看到我们添加的NodeMemoryUsage
我这里将脚本改成>90
当前值已经大于我们设置的90%，现在已经出发报警。

K8S的Kafka监控

部署获取kafka信息插件`cat kafka-exporter.yaml
apiVersion: v1
kind: Service
metadata:
name: kafka-exporter
namespace: kafka
labels:
k8s-app: kafka-exporter
spec:
selector:
k8s-app: kafka-exporter
ports:

• name: kafka-exporter
  port: 9308
  protocol: TCP
  type: ClusterIP

---

apiVersion: apps/v1
kind: Deployment
metadata:
name: kafka-exporter
namespace: kafka
labels:
k8s-app: kafka-exporter
spec:
replicas: 1
selector:
matchLabels:
k8s-app: kafka-exporter
template:
metadata:
labels:
k8s-app: kafka-exporter
spec:
containers:
- name: kafka-exporter
image: danielqsj/kafka-exporter:latest
imagePullPolicy: IfNotPresent
args: ["–kafka.server=kafka-0.kafka.kafka.svc.cluster.local:9092"]
resources:
requests:
memory: 100M
volumeMounts:
- name: tz-config
mountPath: /etc/localtime
readOnly: true
volumes:
- name: tz-config
hostPath:
path: /usr/share/zoneinfo/Asia/Shanghai`

在prometheus.configmap.yaml文件添加如下内容

• job_name: ‘kafka-service.kafka’
  static_configs:
  - targets: [“kafka-exporter.kafka.svc.cluster.local:9308”] #service 名字+命名空间
  labels: instance: instance-of-kafka

kubectl apply -f prometheus.configmap.yaml
此时的prometheus容器用的还是旧配置，为了让配置生效，要把prometheus的pod删除，这样K8S自动创建的新pod就用上了新的配置，找出prometheus的pod：kubectl get pods -n kube-system
等待新的pod被自动创建；
接下来登录Grafana，配置监控页面，做模板导入操作：在导入模板的页面输入编号7589：
选择数据源的时候，要选prometheus：此时如果您的kafka有消息的收发，就可以立即看到数据了：

持续更新中。。。。