柴少鹏的官方网站 技术在分享中进步,水平在学习中升华

Prometheus监控Kubernetes(七)

#通过前面一系列章节的了解,现在我们已经具备了全面监控Kubernetes的理论知识了。

一、kubernetes_sd_config(虽然是翻译官网但是别忽略好好看一看)

1.1、 单说<kubernetes_sd_config>的配置:

     Kubernetes SD配置允许从Kubernetes的REST API检索抓取目标,并始终与集群状态保持同步。可以将以下角色类型之一配置为发现目标:

node

      node角色为每个群集节点发现一个目标,其地址默认为Kubelet的HTTP端口。 目标地址默认为Kubernetes节点对象的第一个现有地址,按照NodeInternalIP,NodeExternalIP,NodeLegacyHostIP和NodeHostName的地址类型顺序。可用的元标签:

__meta_kubernetes_node_name: node对象的名称。
__meta_kubernetes_node_label_<labelname>: 来自节点对象的每个标签。
__meta_kubernetes_node_labelpresent_<labelname>: 对于节点对象中的每个标签,为true。
__meta_kubernetes_node_annotation_<annotationname>: 来自节点对象的每个注释。
__meta_kubernetes_node_annotationpresent_<annotationname>: 对于来自节点对象的每个注释,为true。
__meta_kubernetes_node_address_<address_type>: 每个节点地址类型的第一个地址(如果存在)。

      此外,该节点的实例标签将设置为从API服务器检索到的节点名称。

service 

      service角色发现每个服务的每个服务端口的目标。 这通常用于监视服务的黑盒。 该地址将设置为服务的Kubernetes DNS名称以及相应的服务端口。可用的元标签:

__meta_kubernetes_namespace: service对象的名称空间。
__meta_kubernetes_service_annotation_<annotationname>: 来自service对象的每个注释。
__meta_kubernetes_service_annotationpresent_<annotationname>: service对象的每个注释为“ true”。
__meta_kubernetes_service_cluster_ip: service的群集IP地址。(不适用于外部名称类型的服务)
__meta_kubernetes_service_external_name: service的DNS名称。(适用于外部名称类型的服务)
__meta_kubernetes_service_label_<labelname>: service对象中的每个标签。
__meta_kubernetes_service_labelpresent_<labelname>: 对于service对象的每个标签为true。
__meta_kubernetes_service_name: service对象的名称。
__meta_kubernetes_service_port_name: service服务端口的名称。
__meta_kubernetes_service_port_protocol: 目标service端口的协议。

pod

       容器角色发现所有容器并将其容器公开为目标。 对于容器的每个声明的端口,将生成一个目标。 如果容器没有指定的端口,则会为每个容器创建无端口目标,以通过重新标记手动添加端口。可用的元标签:

__meta_kubernetes_namespace: pod对象的名称空间。
__meta_kubernetes_pod_name: 容器对象的名称。
__meta_kubernetes_pod_ip: 容器对象的容器IP。
__meta_kubernetes_pod_label_<labelname>: 来自pod对象的每个标签。
__meta_kubernetes_pod_labelpresent_<labelname>: 对于来自pod对象的每个标签,为true。
__meta_kubernetes_pod_annotation_<annotationname>: 来自pod对象的每个注释。
__meta_kubernetes_pod_annotationpresent_<annotationname>: 对于Pod对象中的每个注释,为true。
__meta_kubernetes_pod_container_init: 如果容器是InitContainer,则为true
__meta_kubernetes_pod_container_name: 目标地址指向的容器的名称。
__meta_kubernetes_pod_container_port_name: 容器端口的名称。
__meta_kubernetes_pod_container_port_number: 容器端口号。
__meta_kubernetes_pod_container_port_protocol: 容器端口的协议。
__meta_kubernetes_pod_ready:  为Pod的就绪状态设置为true或false。
__meta_kubernetes_pod_phase: 在生命周期中设置为Pending, Running, Succeeded, Failed or Unknown。
__meta_kubernetes_pod_node_name: Pod调度到的节点的名称
__meta_kubernetes_pod_host_ip: Pod对象的当前主机IP。
__meta_kubernetes_pod_uid: Pod对象的UID。
__meta_kubernetes_pod_controller_kind: Pod控制器的对象种类。
__meta_kubernetes_pod_controller_name: Pod控制器的名称。

endpoints

      端点角色从列出的服务端点中发现目标。 对于每个端点地址,每个端口都发现一个目标。 如果端点由Pod支持,则该Pod的所有其他未绑定到端点端口的容器端口也将被发现为目标。可用的元标签:

__meta_kubernetes_namespace: endpoints 对象的名称空间。
__meta_kubernetes_endpoints_name: 端点对象的名称
对于直接从端点列表中发现的所有目标(未从基础容器额外推断出的所有目标),将附加以下标签:
    __meta_kubernetes_endpoint_hostname: 端点的主机名。
    __meta_kubernetes_endpoint_node_name: hosting端点的节点的名称。
    __meta_kubernetes_endpoint_ready: 为端点的就绪状态设置为true或false。
    __meta_kubernetes_endpoint_port_name: 端点端口的名称。
    __meta_kubernetes_endpoint_port_protocol: 端点端口的协议。
    __meta_kubernetes_endpoint_address_target_kind: 端点地址目标的种类。
    __meta_kubernetes_endpoint_address_target_name: 端点地址目标的名称。
如果端点属于服务,则会附加角色:服务发现的所有标签。对于由容器支持的所有目标,将附加角色的所有标签:pod discovery。

ingress

     ingress角色发现每个入口的每个路径的目标。 这通常对黑盒监视入口很有用。 该地址将设置为入口规范中指定的主机。可用的元标签:

__meta_kubernetes_namespace: ingress对象的名称空间。
__meta_kubernetes_ingress_name: ingress对象的名称。
__meta_kubernetes_ingress_label_<labelname>: 来自ingress对象的每个标签。
__meta_kubernetes_ingress_labelpresent_<labelname>: 对于来自ingress对象的每个标签,为true。
__meta_kubernetes_ingress_annotation_<annotationname>: 来自ingress对象的每个注释。
__meta_kubernetes_ingress_annotationpresent_<annotationname>: 对于来自ingress对象的每个注释,为true。
__meta_kubernetes_ingress_scheme: 入口的协议方案,如果设置了TLS配置,则为https。 默认为http。
__meta_kubernetes_ingress_path: 入口规范的路径。 默认为/。

请参阅以下有关Kubernetes发现的配置选项:

#访问Kubernetes API的信息。

#API服务器地址。如果保留为空,则Prometheus被假定为在集群内部运行,并且将自动发现API服务器,并使用Pod的CA证书和承载令牌文件位于/var/run/secrets/kubernetes.io/serviceaccount/。
[ api_server: <host> ]

#应该发现的实体的Kubernetes角色。
role: <role>
#用于向API服务器进行身份验证的可选身份验证信息。请注意,“ basic_auth”,“ bearer_token”和“ bearer_token_file”选项是互斥的。
#password和password_file是互斥的。
#可选的HTTP基本身份验证信息。
basic_auth:
  [ username: <string> ]
  [ password: <secret> ]
  [ password_file: <string> ]

#可选的承载令牌认证信息。
[ bearer_token: <secret> ]

#可选的承载令牌文件认证信息。
[ bearer_token_file: <filename> ]

#可选的代理URL。
[ proxy_url: <string> ]

#TLS配置。
tls_config:
  [ <tls_config> ]

#可选的名称空间发现。 如果省略,则使用所有名称空间。
namespaces:
  names:
    [ - <string> ]

其中<role>必须是endpoints, service, pod, node, or ingress。

有关为Kubernetes配置Prometheus的详细示例,请参见此示例Prometheus配置文件:https://github.com/prometheus/prometheus/blob/release-2.13/documentation/examples/prometheus-kubernetes.yml

可能希望查看第三方Prometheus Operator,它可以自动在Kubernetes上设置Prometheus:https://github.com/coreos/prometheus-operator

二、完整的部署流程

2.1 Prometheus部署

# kubectl create namespace prometheus

namespace/prometheus created

Prometheus:

#vim prometheus-rbac.yaml   

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: prometheus
rules:
- apiGroups: [""]
  resources:
  - nodes
  - nodes/proxy
  - services
  - endpoints
  - pods
  verbs: ["get", "list", "watch"]
- apiGroups:
  - extensions
  resources:
  - ingresses
  verbs: ["get", "list", "watch"]
- nonResourceURLs: ["/metrics"]
  verbs: ["get"]
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus
  namespace: prometheus
---
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: prometheus

博文来自:www.51niux.com

#prometheus.rbac.yml定义了Prometheus容器访问k8s apiserver所需的ServiceAccount、ClusterRole以及ClusterRoleBinding。

下面是针对上面的配置文件详解:

apiVersion: rbac.authorization.k8s.io/v1beta1   #指定api版本,此值必须在kubectl apiversion中,RBAC 使用 rbac.authorization.k8s.io API 组来驱动鉴权操作,允许管理员通过 Kubernetes API 动态配置策略。
kind: ClusterRole    #指定创建资源的角色为ClusterRole,ClusterRole对象可以授予整个集群范围内资源访问权限
metadata:   ##资源的元数据/属性
    # 此处的 "namespace" 被省略掉是因为 ClusterRoles 是没有命名空间的。
  name: prometheus   #资源的名字,在同一个namespace中必须唯一
rules:
- apiGroups: [""]  # "" 指定核心 API 组
#ClusterRole 可以授予的权限和 Role 相同,但是因为 ClusterRole 属于集群范围,所以它也可以授予以下访问权限:集群范围资源 (比如 nodes),非资源端点(比如 “/healthz”)
  resources:
  - nodes
  - nodes/proxy
  - services
  - endpoints
  - pods
  verbs: ["get", "list", "watch"]  #允许读取在“核心”API Group中定义的那些资源
- apiGroups:
  - extensions
  resources:
  - ingresses
  verbs: ["get", "list", "watch"]  #允许读取在“extensions”API Group中定义的ingresses
- nonResourceURLs: ["/metrics"]  #允许在非资源端点 “/metrics” 上发起 “GET”请求(必须在 ClusterRole 绑定 ClusterRoleBinding 才生效)
  verbs: ["get"]
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus
  namespace: prometheus
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: prometheus
roleRef:  #roleRef 里的内容决定了实际创建绑定的方法。kind 可以是 Role 或 ClusterRole,name 将引用你要指定的 Role 或 ClusterRole 的名称
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole   
  name: prometheus   ## 这里的名称必须与你想要绑定的 Role 或 ClusterRole 名称一致
subjects:
- kind: ServiceAccount
  name: prometheus
  namespace: prometheus

# kubectl create -f  prometheus-rbac.yaml

clusterrole.rbac.authorization.k8s.io/prometheus created
serviceaccount/prometheus created
clusterrolebinding.rbac.authorization.k8s.io/prometheus created

# vim prometheus-config-configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
  namespace: prometheus
data:
  prometheus.yml: |
    global:
      scrape_interval:     15s
      evaluation_interval: 15s
    scrape_configs:

    - job_name: 'kubernetes-apiservers'
      kubernetes_sd_configs:
      - role: endpoints
      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:
      - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
        action: keep
        regex: default;kubernetes;https

    - job_name: 'kubernetes-nodes'
      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

    - 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

    - 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

    - job_name: 'kubernetes-services'
      kubernetes_sd_configs:
      - role: service
      metrics_path: /probe
      params:
        module: [http_2xx]
      relabel_configs:
      - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_probe]
        action: keep
        regex: true
      - source_labels: [__address__]
        target_label: __param_target
      - target_label: __address__
        replacement: blackbox-exporter.example.com:9115
      - source_labels: [__param_target]
        target_label: instance
      - action: labelmap
        regex: __meta_kubernetes_service_label_(.+)
      - source_labels: [__meta_kubernetes_namespace]
        target_label: kubernetes_namespace
      - source_labels: [__meta_kubernetes_service_name]
        target_label: kubernetes_name

    - job_name: 'kubernetes-ingresses'
      kubernetes_sd_configs:
      - role: ingress
      relabel_configs:
      - source_labels: [__meta_kubernetes_ingress_annotation_prometheus_io_probe]
        action: keep
        regex: true
      - source_labels: [__meta_kubernetes_ingress_scheme,__address__,__meta_kubernetes_ingress_path]
        regex: (.+);(.+);(.+)
        replacement: ${1}://${2}${3}
        target_label: __param_target
      - target_label: __address__
        replacement: blackbox-exporter.example.com:9115
      - source_labels: [__param_target]
        target_label: instance
      - action: labelmap
        regex: __meta_kubernetes_ingress_label_(.+)
      - source_labels: [__meta_kubernetes_namespace]
        target_label: kubernetes_namespace
      - source_labels: [__meta_kubernetes_ingress_name]
        target_label: kubernetes_name

    - job_name: 'kubernetes-pods'
      kubernetes_sd_configs:
      - role: pod
      relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
        action: replace
        target_label: __metrics_path__
        regex: (.+)
      - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
        action: replace
        regex: ([^:]+)(?::\d+)?;(\d+)
        replacement: $1:$2
        target_label: __address__
      - action: labelmap
        regex: __meta_kubernetes_pod_label_(.+)
      - source_labels: [__meta_kubernetes_namespace]
        action: replace
        target_label: kubernetes_namespace
      - source_labels: [__meta_kubernetes_pod_name]
        action: replace
        target_label: kubernetes_pod_name

#prometheus-config-configmap.yaml定义了prometheus的配置文件,以configmap的形式使用。

#下面是针对上面的一些配置进行的注释说明:

# 用于发现API SERVER
    - job_name: 'kubernetes-apiservers'
#发现endpoints,它是从列出的服务端点发现目标,这个endpoints来自于Kubernetes中的service,每一个service都有对应的endpoints,
#这里是一个列表可以是一个IP:PORT也可以是多个,这些IP:PORT就是service通过标签选择器选择的POD的IP和端口。
#所以endpoints角色就是用来发现server对应的pod的IP的kubernetes会有一个默认的service,
#通过找到这个service的endpoints就找到了api server的IP:PORT,那endpoints有很多,我怎么知道哪个是api server呢这个就靠source_labels指定的标签名称了。    
      kubernetes_sd_configs:
      - role: endpoints
#通过什么形式来连接,默认是https      
      scheme: https
# 下面这个ca_file和token_file的路径都是默认的,你可能默认设置能用么?其实可以,因为每一个运行起来的POD kubernetes都会为其
# 创建一个serviceaccout的Secret并且挂载到下面的目录上,里面就有ca.crt和token这两个文件,你可以自己启动一个POD,然后通过
# kubectl describe pods 来查看,一定会在Volumes下面有一个default-token-XXX的东西,并且Mounts里面有下面的目录。      
      tls_config:
        ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
      bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
# 下面的含义是源标签__meta_kubernetes_namespace等如果其值为default;kubernetes;https标签顺序和值要对应。换句话说就是
# 当__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name三者对应的
# 值为default、kubernetes、https则进行保留,而且该endpoints对应的地址为api server的地址。
# 
# __meta_kubernetes_namespace 端点对象的命名空间,在不同对象上这个标签的含义不同,在角色是endpoints中这个是端点对象的名称空间
# __meta_kubernetes_service_name 端点对象的服务名称
# __meta_kubernetes_endpoint_port_name 端点的端口名称
# 
# kubernetes默认在default名称空间有一个叫做kubernetes的service,所以这个service的有3个设置对应的就是下面三个标签
# __meta_kubernetes_namespace 值为default
# __meta_kubernetes_service_name 值为kubernetes
# __meta_kubernetes_endpoint_port_name 值为https      
      relabel_configs:
      - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
        action: keep
        regex: default;kubernetes;https

#配置针对kubelet的服务发现以及对标签的处理,是获取kubelet上/metrics接口数据来获取node的资源使用情况        
    - job_name: 'kubernetes-nodes'
      kubernetes_sd_configs:
# 使用node角色,它使用默认的kubelet提供的http端口来发现集群中每个node节点。那具体地址是什么呢?
# 地址类型有四种NodeInternalIP, NodeExternalIP, NodeLegacyHostIP 和 NodeHostName,默认为这四个中第一个可用的地址。
# 那么这里为什么使用node角色呢?因为node角色就是用来发现kubelet的
# __meta_kubernetes_node_name:节点对象的名字
# __meta_kubernetes_node_label_<labelname>:表示节点对象上的每一个标签
# __meta_kubernetes_node_annotation_<annotationname>:表示节点对象上的每一个annotation
# __meta_kubernetes_node_address_<address_type>:如果存在,那么将是每一个节点地址类型的第一个地址
# Node模式,Prometheus会自动发现Kubernetes中所有Node节点的信息并作为监控的目标Target。 
# 而这些Target的访问地址实际上就是Kubelet的访问地址,并且Kubelet实际上直接内置了对Promtheus的支持      
      - 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:
# 保留(.+)匹配到的内容,去掉__meta_kubernetes_node_label_,实际上就是把(.+)当做新标签,然后老标签的值给这个新标签,
# 这里没有设置source_labels,则表示匹配所有标签      
      - action: labelmap
        regex: __meta_kubernetes_node_label_(.+)
#下面就是将replacement: 中的值kubernetes.default.svc:443赋予给__address__标签
      - target_label: __address__
        replacement: kubernetes.default.svc:443
#下面就是将__meta_kubernetes_node_name的值变成${1}的形式传给replacement:中的$1,然后赋给标签__metrics_path__   
      - source_labels: [__meta_kubernetes_node_name]
        regex: (.+)
        target_label: __metrics_path__
        replacement: /api/v1/nodes/${1}/proxy/metrics  

#抓取服务端点,整个这个任务都是用来发现node-exporter和kube-state-metrics-service的,这里用的是endpoints角色,
#这是通过这两者的service来发现的后端endpoints。另外需要说明的是如果满足采集条件,那么在service、POD中定义的labels也会被采集进去        
    - job_name: 'kubernetes-service-endpoints'
      kubernetes_sd_configs:
      - role: endpoints
      relabel_configs:
# 重新打标仅抓取到的具有 "prometheus.io/scrape: true" 的annotation的端点,意思是说如果某个service具有prometheus.io/scrape = true annotation声明则抓取
# annotation本身也是键值结构,所以这里的源标签设置为键,而regex设置值,当值匹配到regex设定的内容时则执行keep动作也就是保留,其余则丢弃.
# node-exporter这个POD的service里面就有一个叫做prometheus.io/scrape = true的annotations所以就找到了node-exporter这个POD    
      - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
        action: keep
        regex: true
#重新设置scheme匹配源标签__meta_kubernetes_service_annotation_prometheus_io_scheme也就是prometheus.io/scheme annotation
# 如果源标签的值匹配到regex则把值替换为__scheme__对应的值        
      - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
        action: replace
        target_label: __scheme__
        regex: (https?)
# 应用中自定义暴露的指标,也许你暴露的API接口不是/metrics这个路径,那么你可以在这个POD对应的service中做一个
# "prometheus.io/path = /mymetrics" 声明,下面的意思就是把你声明的这个路径赋值给__metrics_path__
# 其实就是让prometheus来获取自定义应用暴露的metrices的具体路径,不过这里写的要和service中做好约定
# 如果service中这样写 prometheus.io/app-metrics-path: '/metrics' 那么你这里就要__meta_kubernetes_service_annotation_prometheus_io_app_metrics_path这样写        
      - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]
        action: replace
        target_label: __metrics_path__
        regex: (.+)
# 暴露自定义的应用的端口,就是把地址和你在service中定义的 "prometheus.io/port = <port>" 声明做一个拼接
# 然后赋值给__address__,这样prometheus就能获取自定义应用的端口,然后通过这个端口再结合__metrics_path__来获取
# 指标,如果__metrics_path__值不是默认的/metrics那么就要使用上面的标签替换来获取真正暴露的具体路径        
      - 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
        
# 下面是自动发现service,不过如果要想监控service则需要安装blackbox-exporter        
    - job_name: 'kubernetes-services'
      kubernetes_sd_configs:
      - role: service
      metrics_path: /probe
# 生成__param_module="http_2xx"的label,如果是TCP探测则使用 module: [tcp_connect]      
      params:
        module: [http_2xx]
      relabel_configs:
# 为了让service可以被探测到,那需要在service的annotation中增加 prometheus.io/scrape: true 声明
# 也就是只保留prometheus.io/scrape: true的service      
      - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_probe]
        action: keep
        regex: true
# 用__address__这个label的值创建一个名为__param_target的label为blackbox-exporter,值为内部service的访问地址,作为blackbox-exporter采集用        
      - source_labels: [__address__]
        target_label: __param_target
# 用blackbox-exporter的service地址值”prometheus-blackbox-exporter:9115"替换原__address__的值        
      - target_label: __address__
        replacement: blackbox-exporter.example.com:9115
      - source_labels: [__param_target]
        target_label: instance
# 下面主要是为了给样本添加额外信息        
      - action: labelmap
        regex: __meta_kubernetes_service_label_(.+)
      - source_labels: [__meta_kubernetes_namespace]
        target_label: kubernetes_namespace
      - source_labels: [__meta_kubernetes_service_name]
        target_label: kubernetes_name  
        
# 下面是对ingresses监控,不过如果要想监控ingresses则需要安装blackbox-exporter
    - job_name: 'kubernetes-ingresses'
      kubernetes_sd_configs:
      - role: ingress
      
# 抓取POD进行监控
    - job_name: 'kubernetes-pods'
      kubernetes_sd_configs:
      - role: pod
      relabel_configs:
# POD的 annotation 中含有"prometheus.io/scrape: true" 的则保留,意思就是会被Prometheus抓取,不具有这个的POD则不会被抓取      
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true
# 获取POD的 annotation 中定义的"prometheus.io/path: XXX"定义的值,这个值就是你的程序暴露符合prometheus规范的metrics的地址
# 如果你的metrics的地址不是 /metrics 的话,通过这个标签,那么这里就会把这个值赋值给 __metrics_path__这个变量,因为prometheus
# 是通过这个变量获取路径然后进行拼接出来一个完整的URL,并通过这个URL来获取metrics值的,
#因为prometheus默认使用的就是 http(s)://X.X.X.X/metrics这样一个路径来获取的。        
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
        action: replace
        target_label: __metrics_path__
        regex: (.+)
# 这里是端口信息,因为你的程序很有可能在容器中并不是以80端口运行的,那么就需要做一个拼接http(s)://x.x.x.x:xx/metrics
# __address__在prometheus中代表的就是实例的IP地址,而POD中的annotation 中定义的"prometheus.io/port: XX"就是你程序
# 被访问到的端口,最终在prometheus中将会被显示为 instance=X.X.X.X:XX这样        
      - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
        action: replace
        regex: ([^:]+)(?::\d+)?;(\d+)
        replacement: $1:$2
        target_label: __address__
# 下面主要是为了给样本添加额外信息         
      - action: labelmap
        regex: __meta_kubernetes_pod_label_(.+)
      - source_labels: [__meta_kubernetes_namespace]
        action: replace
        target_label: kubernetes_namespace
      - source_labels: [__meta_kubernetes_pod_name]
        action: replace
        target_label: kubernetes_pod_name

博文来自:www.51niux.com

#prometheus是如何识别apiserver的呢?举个例子:

# kubectl describe svc kubernetes

Name:              kubernetes  #__meta_kubernetes_service_name
Namespace:         default     #__meta_kubernetes_namespace
Labels:            component=apiserver
                   provider=kubernetes
Annotations:       <none>
Selector:          <none>
Type:              ClusterIP
IP:                10.96.0.1
Port:              https  443/TCP  #__meta_kubernetes_endpoint_port_name
TargetPort:        6443/TCP
Endpoints:         192.168.1.135:6443
Session Affinity:  None
Events:            <none>

# kubectl apply -f prometheus-config-configmap.yaml

configmap/prometheus-config created

# vim prometheus-dep.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus-dep
  namespace: prometheus
spec:
  replicas: 1
  selector:
    matchLabels:
      app: prometheus-dep
  template:
    metadata:
      labels:
        app: prometheus-dep
    spec:
      containers:
      - image: prom/prometheus:v2.16.0
          imagePullPolicy: IfNotPresent 
        name: prometheus
        command:
        - "/bin/prometheus"
        args:
        - "--config.file=/etc/prometheus/prometheus.yml"
        - "--storage.tsdb.path=/prometheus"
        #- "--storage.tsdb.retention=1d"  #storage.tsdb.retention: 已被废弃,改为使用storage.tsdb.retention.time
        - "--storage.tsdb.retention.time=1d"
        ports:
        - containerPort: 9090
          protocol: TCP
        volumeMounts:
        - mountPath: "/prometheus"
          name: data
        - mountPath: "/etc/prometheus"
          name: config-volume
        resources:
          requests:
            cpu: 1000m
            memory: 1000Mi
          limits:
            cpu: 2000m
            memory: 4000Mi
      serviceAccountName: prometheus
      imagePullSecrets:
        - name: regsecret
      volumes:
      - name: data
        emptyDir: {}
      - name: config-volume
        configMap:
          name: prometheus-config

prometheus-dep.yaml定义了prometheus的部署,这里使用–storage.tsdb.retention参数,监控数据只保留1天,因为最终监控数据会统一汇总。 limits资源限制根据集群大小进行适当调整。

# kubectl apply -f  prometheus-dep.yaml

deployment.apps/prometheus-dep created

# vim prometheus-svc.yaml

kind: Service
apiVersion: v1
metadata:
  name: prometheus-svc
  namespace: prometheus
spec:
  type: NodePort
  ports:
  - port: 9090
    targetPort: 9090
    nodePort: 30090
  selector:
    app: prometheus-dep

prometheus-svc.yaml定义Prometheus的Service,需要将Prometheus以NodePort、LoadBalancer或Ingress暴露到集群外部,这样外部的Prometheus才能访问它。这里采用的NodePort,所以只需要访问集群中有外网地址的任意一台服务器的30090端口就可以使用prometheus。

#注意:但是上面只是一个例子,实际场景呢可以用LoadBalancer,这样就不会因为Pod重启漂移而导致你的nodeip发送变化,而你接收端要进行变更,但是呢如果你担心你这个pod乱飘导致其他Node节点资源不足,可以绑定到某个Node上,这样就可以用NodePort方式了。

# kubectl create -f prometheus-svc.yaml

service/prometheus-svc created

2.2 kube-state-metrics

prometheus部署成功后,接着再部署kube-state-metrics作为prometheus的一个exporter来使用,提供deployment、daemonset、cronjob等服务的监控数据。

# vim kube-state-metrics-rbac.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: kube-state-metrics
  namespace: prometheus
---

apiVersion: rbac.authorization.k8s.io/v1
# kubernetes versions before 1.8.0 should use rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  namespace: prometheus
  name: kube-state-metrics-resizer
rules:
- apiGroups: [""]
  resources:
  - pods
  verbs: ["get"]
- apiGroups: ["extensions"]
  resources:
  - deployments
  resourceNames: ["kube-state-metrics"]
  verbs: ["get", "update"]
---

apiVersion: rbac.authorization.k8s.io/v1
# kubernetes versions before 1.8.0 should use rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: kube-state-metrics
rules:
- apiGroups: [""]
  resources:
  - configmaps
  - secrets
  - nodes
  - pods
  - services
  - resourcequotas
  - replicationcontrollers
  - limitranges
  - persistentvolumeclaims
  - persistentvolumes
  - namespaces
  - endpoints
  verbs: ["list", "watch"]
- apiGroups: ["extensions"]
  resources:
  - daemonsets
  - deployments
  - replicasets
  verbs: ["list", "watch"]
- apiGroups: ["apps"]
  resources:
  - statefulsets
  verbs: ["list", "watch"]
- apiGroups: ["batch"]
  resources:
  - cronjobs
  - jobs
  verbs: ["list", "watch"]
- apiGroups: ["autoscaling"]
  resources:
  - horizontalpodautoscalers
  verbs: ["list", "watch"]
---

apiVersion: rbac.authorization.k8s.io/v1
# kubernetes versions before 1.8.0 should use rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: kube-state-metrics
  namespace: prometheus
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: kube-state-metrics-resizer
subjects:
- kind: ServiceAccount
  name: kube-state-metrics
  namespace: prometheus
---

apiVersion: rbac.authorization.k8s.io/v1
# kubernetes versions before 1.8.0 should use rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: kube-state-metrics
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kube-state-metrics
subjects:
- kind: ServiceAccount
  name: kube-state-metrics
  namespace: prometheus

kube-state-metrics-rbac.yaml定义了kube-state-metrics访问k8s apiserver所需的ServiceAccount和ClusterRole及ClusterRoleBinding。

# kubectl create -f  kube-state-metrics-rbac.yaml

serviceaccount/kube-state-metrics created
role.rbac.authorization.k8s.io/kube-state-metrics-resizer created
clusterrole.rbac.authorization.k8s.io/kube-state-metrics created
rolebinding.rbac.authorization.k8s.io/kube-state-metrics created
clusterrolebinding.rbac.authorization.k8s.io/kube-state-metrics created

# vim kube-state-metrics-dep.yaml

apiVersion: apps/v1
# Kubernetes versions after 1.9.0 should use apps/v1
# Kubernetes versions before 1.8.0 should use apps/v1beta1 or extensions/v1beta1
# addon-resizer描述:https://github.com/kubernetes/autoscaler/tree/master/addon-resizer
kind: Deployment
metadata:
  name: kube-state-metrics
  namespace: prometheus
spec:
  selector:
    matchLabels:
      k8s-app: kube-state-metrics
  replicas: 1
  template:
    metadata:
      labels:
        k8s-app: kube-state-metrics
    spec:
      serviceAccountName: kube-state-metrics
      containers:
      - name: kube-state-metrics
        image: quay.io/coreos/kube-state-metrics:v1.9.5
        ports:
        - name: http-metrics
          containerPort: 8080
        - name: telemetry
          containerPort: 8081
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          timeoutSeconds: 5
      - name: addon-resizer
          #因为你知道的网络原因,这里使用阿里云的镜像源
        #image: gcr.io/bskiba-gke-dev/addon-resizer:1.8.7
        image: registry.cn-hangzhou.aliyuncs.com/google_containers/addon-resizer:1.8.7
        resources:
          limits:
            cpu: 100m
            memory: 30Mi
          requests:
            cpu: 100m
            memory: 30Mi
        env:
          - name: MY_POD_NAME
            valueFrom:
              fieldRef:
                fieldPath: metadata.name
          - name: MY_POD_NAMESPACE
            valueFrom:
              fieldRef:
                fieldPath: metadata.namespace
        command:
          - /pod_nanny
          - --container=kube-state-metrics
          - --cpu=100m
          - --extra-cpu=1m
          - --memory=100Mi
          - --extra-memory=2Mi
          - --threshold=5
          - --deployment=kube-state-metrics

kube-state-metrics-dep.yaml定义了kube-state-metrics的部署。

插件伸缩 Addon Resizer: Addon resizer 是一个很有趣的小插件。如果用户在上述的场景中使用了Metrics Server,Metrics Server的资源占用量会随着集群中的Pod数量的不断增长而不断上升。Addon resizer 容器会以Sidecar的形式监控与自己同一个Pod内的另一个容器(在本例中是Metrics Server)并且垂直的扩展或收缩这个容器。Addon resizer能依据集群中节点的数量线性地扩展Metrics Server,以保证其能够有能力提供完整的metrics API服务。官网github地址:https://github.com/kubernetes/autoscaler/tree/master/addon-resizer

# kubectl create -f  kube-state-metrics-dep.yaml

deployment.apps/kube-state-metrics created

# vim kube-state-metrics-svc.yaml

apiVersion: v1
kind: Service
metadata:
  name: kube-state-metrics
  namespace: prometheus
  labels:
    k8s-app: kube-state-metrics
  annotations:
    prometheus.io/scrape: 'true'
spec:
  ports:
  - name: http-metrics
    port: 8080
    targetPort: http-metrics
    protocol: TCP
  - name: telemetry
    port: 8081
    targetPort: telemetry
    protocol: TCP
  selector:
    k8s-app: kube-state-metrics

kube-state-metrics-svc.yaml定义了kube-state-metrics的暴露方式,这里只需要使用默认的ClusterIP就可以了,因为它只提供给集群内部的promethes访问。

# kubectl create -f  kube-state-metrics-svc.yaml

service/kube-state-metrics created

k8s集群中的prometheus监控到这儿就已经全部OK了,接下来还需要做的是汇总数据、展示数据及告警规则配置。

2.3 部署-数据汇总(注意后面哪些是可以不做的哈,只是列出用pod如何做)

#个人还是推荐在物理机或者ECS机器上面部署prometheus-server用联邦模式进行k8s集群的数据采集和用altermanager集群模式进行报警。

prometheus-server:

       prometheus-server和前面prometheus的步骤基本相同,需要针对configmap、数据存储时间(一般为30d)、svc类型做些许改变,同时增加 rule.yaml。

      prometheus-server不需要kube-state-metrics。prometheus-server可以部署在任意k8s集群,或者部署在K8s集群外部都可以。

      prometheus-rbac.yaml (内容和上面的一致,namespace为prometheus-server)

# kubectl create namespace prometheus-server

namespace/prometheus-server created

# vim prometheus-server-rbac.yaml

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: prometheus-server
rules:
- apiGroups: [""]
  resources:
  - nodes
  - nodes/proxy
  - services
  - endpoints
  - pods
  verbs: ["get", "list", "watch"]
- apiGroups:
  - extensions
  resources:
  - ingresses
  verbs: ["get", "list", "watch"]
- nonResourceURLs: ["/metrics"]
  verbs: ["get"]
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus-server
  namespace: prometheus-server
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: prometheus-server
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus-server
subjects:
- kind: ServiceAccount
  name: prometheus-server
  namespace: prometheus-server

# kubectl create -f  prometheus-server-rbac.yaml

clusterrole.rbac.authorization.k8s.io/prometheus-server created
serviceaccount/prometheus-server created
clusterrolebinding.rbac.authorization.k8s.io/prometheus-server created

# vim prometheus-server-config-configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-server-config
  namespace: prometheus-server
data:
  prometheus.yml: |
    global:
      scrape_interval: 30s
      scrape_timeout: 30s
      evaluation_interval: 30s
    alerting:
      alertmanagers:
      - static_configs:
        - targets:
          - alertmanager-svc.prometheus-server.svc.cluster.local:80
        scheme: http
        timeout: 10s
    rule_files:
    - "/etc/prometheus/rule/rule.yml"
    scrape_configs:
    - job_name: federate_test01
      honor_labels: true
      params:
        match[]:
        - '{job=~"kubernetes-.*"}'
      scrape_interval: 30s
      scrape_timeout: 30s
      metrics_path: /federate
      scheme: http
      static_configs:
      - targets:
        - 192.168.1.137:31090
        labels:
          k8scluster: offline_51niux_k8s

博文来自:www.51niux.com

注意下面的labels,这个是自己定义的,它的作用在于给每一条刮取过来的监控数据都加上一个 k8scluster: offline_51niux_k8s 的Key-Value,offline一般指定为集群环境。这样我们可以在多个集群数据中区分该条数据是属于哪一个k8s集群,这对于后面的展示和告警都非常有利。

# vim prometheus-server-rule-configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-server-rule-config
  namespace: prometheus-server
data:
  rule.yml: |
    groups:
    - name: kubernetes
      rules:
      - alert: PodDown
        expr: kube_pod_status_phase{phase="Unknown"} == 1 or kube_pod_status_phase{phase="Failed"} == 1
        for: 1m
        labels:
          severity: error
          service: prometheus_bot
          receiver_group: "{{ $labels.k8scluster}}_{{ $labels.namespace }}"
        annotations:
          summary: Pod Down
          k8scluster: "{{ $labels.k8scluster}}"
          namespace: "{{ $labels.namespace }}"
          pod: "{{ $labels.pod }}"
          container: "{{ $labels.container }}"

      - alert: PodRestart
        expr: changes(kube_pod_container_status_restarts_total{pod !~ "analyzer.*"}[10m]) > 0
        for: 1m
        labels:
          severity: error
          service: prometheus_bot
          receiver_group: "{{ $labels.k8scluster}}_{{ $labels.namespace }}"
        annotations:
          summary: Pod Restart
          k8scluster: "{{ $labels.k8scluster}}"
          namespace: "{{ $labels.namespace }}"
          pod: "{{ $labels.pod }}"
          container: "{{ $labels.container }}"

      - alert: NodeUnschedulable
        expr: kube_node_spec_unschedulable == 1
        for: 5m
        labels:
          severity: error
          service: prometheus_bot
          receiver_group: "{{ $labels.k8scluster}}_{{ $labels.namespace }}"
        annotations:
          summary: Node Unschedulable
          k8scluster: "{{ $labels.k8scluster}}"
          node: "{{ $labels.node }}"

      - alert: NodeStatusError
        expr: kube_node_status_condition{condition="Ready", status!="true"} == 1
        for: 5m
        labels:
          severity: error
          service: prometheus_bot
          receiver_group: "{{ $labels.k8scluster}}_{{ $labels.namespace }}"
        annotations:
          summary: Node Status Error
          k8scluster: "{{ $labels.k8scluster}}"
          node: "{{ $labels.node }}"

      - alert: DaemonsetUnavailable
        expr: kube_daemonset_status_number_unavailable > 0
        for: 5m
        labels:
          severity: error
          service: prometheus_bot
          receiver_group: "{{ $labels.k8scluster}}_{{ $labels.namespace }}"
        annotations:
          summary: Daemonset Unavailable
          k8scluster: "{{ $labels.k8scluster}}"
          namespace: "{{ $labels.namespace }}"
          daemonset: "{{ $labels.daemonset }}"

      - alert: JobFailed
        expr: kube_job_status_failed == 1
        for: 5m
        labels:
          severity: error
          service: prometheus_bot
          receiver_group: "{{ $labels.k8scluster}}_{{ $labels.namespace }}"
        annotations:
          summary: Job Failed
          k8scluster: "{{ $labels.k8scluster}}"
          namespace: "{{ $labels.namespace }}"
          job: "{{ $labels.exported_job }}"

rule.yaml定义了告警规则。此文件中定义了 PodDown、PodRestart、NodeUnschedulable、NodeStatusError、DaemonsetUnavailable、JobFailed 共6条规则。

# vim prometheus-server-dep.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus-server-dep
  namespace: prometheus-server
spec:
  replicas: 1
  selector:
    matchLabels:
      app: prometheus-server-dep
  template:
    metadata:
      labels:
        app: prometheus-server-dep
    spec:
      containers:
      - image: prom/prometheus:v2.16.0
        name: prometheus-server
        command:
        - "/bin/prometheus"
        args:
        - "--config.file=/etc/prometheus/config/prometheus.yml"
        - "--storage.tsdb.path=/prometheus"
        - "--web.console.libraries=/usr/share/prometheus/console_libraries"
        - "--web.console.templates=/usr/share/prometheus"
        - "--storage.tsdb.retention=30d"
        - "--web.enable-lifecycle"
        ports:
        - containerPort: 9090
          protocol: TCP
        volumeMounts:
        - name: "data"
          mountPath: "/prometheus"
        - name: "server-config-volume"
          mountPath: "/etc/prometheus/config"
        - name: "rule-config-volume"
          mountPath: "/etc/prometheus/rule"
        resources:
          requests:
            cpu: 250m
            memory: 100Mi
      serviceAccountName: prometheus-server
      volumes:
      - name: data
        #emptyDir: {} #volumes.data这里使用的是emptyDir,这样其实不妥,应该单独挂载一块盘来存储汇总数据。可使用pv实现。
        hostPath:
          path:  /data/prometheus
      - name: server-config-volume
        configMap:
          name: prometheus-server-config
      - name: rule-config-volume
        configMap:
          name: prometheus-server-rule-config
      nodeSelector:
        service-type: prometheus

#mkdir /data/prometheus   -p  #实际场景这应该是一个挂载盘哈,但是你怎么知道它飘到哪个node节点呢?那就需要设置跟节点绑定了。

# chmod 777 /data/prometheus  #不授权的话有下面的错误:

component=activeQueryTracker msg="Error opening query log file" file=/prometheus/queries.active err="open /prometheus/queries.active: permission denied"
panic: Unable to create mmap-ed active query log

# kubectl create -f  prometheus-server-dep.yaml

deployment.apps/prometheus-server-dep created

#如果Pod启动有问题可以使用:# kubectl describe pods 容器名   -n prometheus-server 或者# kubectl logs pods 容器名   -n prometheus-server排查一下问题。

# vim prometheus-server-svc.yaml

kind: Service
apiVersion: v1
metadata:
  name: prometheus-server-svc
  namespace: prometheus-server
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 9090
  selector:
    app: prometheus-server-dep

 # kubectl create -f  prometheus-server-svc.yaml

service/prometheus-server-svc created

到这儿,数据采集和数据汇总就已经OK了。Prometheus-server部署成功之后,在浏览器中可以看到监控数据汇总信息了。

2.4 告警配置

# vim alertmanager-config-configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: alertmanager-config
  namespace: prometheus
data:
  config.yml: |
    global:
        resolve_timeout: 5m

        route:
          receiver: default
          group_wait: 30s
          group_interval: 5m
          repeat_interval: 4h
          group_by: ['alertname', 'k8scluster', 'node', 'container', 'exported_job', 'daemonset']
          routes:
          - receiver: send_msg_warning
                group_wait: 60s
                match:
                  severity: warning

        receivers:
        - name: default
          webhook_configs:
          - url: 'http://msg.x.com/xxx/'
                send_resolved: true
                http_config:
                  bearer_token: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

        - name: send_msg_warning
          webhook_configs:
          - url: 'http://msg.x.com/xxx/'
                send_resolved: true
                http_config:
                  bearer_token: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

# kubectl create -f alertmanager-config-configmap.yaml

configmap/alertmanager-config created

alertmanager-config-configmap.yaml定义了alertmanager的配置文件

route:路由。分级匹配,然后交给指定 receivers,其中route.group_by中的k8scluster是prometheus-server-config.yaml中自定义的标签

receivers:发送。这里使用webhook方式发送给自研的send_msg模块

email、wechat、webhook、slack等发送方式配置请见官网文档:https://prometheus.io/docs/alerting/configuration/

# kubectl create namespace alertmanager

namespace/alertmanager created

# vim alertmanager-config-configmap.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: alertmanager-dep
  namespace: alertmanager
spec:
  replicas: 1
  selector:
    matchLabels:
      app: alertmanager-dep
  template:
    metadata:
      labels:
        app: alertmanager-dep
    spec:
      containers:
      - image: prom/alertmanager:v0.20.0
        name: alertmanager
        args:
                - "--config.file=/etc/alertmanager/config.yml"
                - "--storage.path=/alertmanager"
                - "--data.retention=720h"
        volumeMounts:
        - mountPath: "/alertmanager"
          name: data
        - mountPath: "/etc/alertmanager"
          name: config-volume
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
          limits:
            cpu: 500m
            memory: 2500Mi
      volumes:
      - name: data
        emptyDir: {}
      - name: config-volume
        configMap:
          name: alertmanager-config

# kubectl create -f alertmanager-dep.yaml

deployment.apps/alertmanager-dep created

alertmanager-dep.yaml定义了Alertmanager的部署。

博文来自:www.51niux.com

三、采集的各项指标的含义(可直接忽略就是蛋疼的整理了下,大部分用不到,需要再网上查)

# kubectl get --raw /metrics  #从kube-apiserver拿到metrics信息

3.1 job="kubernetes-apiservers"

apiserver_admission_controller_admission_latencies_seconds_bucket   #apiserver准入控制器准入等待时间单位秒bucket,里面还有不同标签有2000多项
apiserver_request_latencies_bucket  #apiserver请求等待时间bucket,里面还有不同的label有2000多项
apiserver_response_sizes_bucket  #apiserver响应大小bucket,里面还有不同的label有800多项
apiserver_request_latencies_summary  #apiserver请求延迟summary,里面有不同的label有400多项
apiserver_admission_step_admission_latencies_seconds_bucket  #apiserver允许step允许等待时间单位为秒bucket,有400多不同label的项。 
apiserver_admission_controller_admission_latencies_seconds_count  #apiserver接纳控制器接纳等待时间秒数,有400多不同label的项。
apiserver_admission_controller_admission_latencies_seconds_sum  #apiserver准入控制器准入等待时间秒数总和,有400多不同label项。
apiserver_request_count  #apiserver请求计数,有不到400个不同label项。
reflector_list_duration_seconds  #reflector list持续时间单位为秒,有不到300个不同的label项。
reflector_items_per_list  #reflector items每个清单,有不到300个不同的label项。
reflector_watch_duration_seconds  #reflector watch持续时间单位为秒,有不到300个不同的label项。
reflector_items_per_watch  #有不到300个不同的label项。
apiserver_admission_step_admission_latencies_seconds_summary  #apiserver允许step允许等待时间秒摘要,有200多个不同的label项。
apiserver_request_latencies_summary_sum  #apiserver请求延迟汇总,有不到200个不同的label项。
apiserver_request_latencies_summary_count  #apiserver请求延迟次数汇总,有不到200个不同的label项。
apiserver_request_latencies_sum  #apiserver请求延迟总和,有不到200个不同的label项。
apiserver_request_latencies_count  #apiserver请求延迟次数总和,有不到200个不同的label项。
apiserver_response_sizes_count  #apiserver响应大小计数,有不到200个不同的label项。
apiserver_response_sizes_sum  #apiserver响应大小总和,有100多个不同的label项。
reflector_items_per_list_count   #有不到100个不同的label项。
reflector_last_resource_version  #有不到100个不同的label项。
reflector_lists_total  #有不到100个不同的label项。
reflector_items_per_watch_count  #有不到100个不同的label项。
reflector_watch_duration_seconds_count  #有不到100个不同的label项。
reflector_list_duration_seconds_sum  #有不到100个不同的label项。
reflector_items_per_watch_sum  #有不到100个不同的label项。
reflector_watch_duration_seconds_sum  #有不到100个不同的label项。
reflector_watches_total  #有不到100个不同的label项。
reflector_short_watches_total  #有不到100个不同的label项。
reflector_items_per_list_sum  #有不到100个不同的label项。
reflector_list_duration_seconds_count  #有不到100个不同的label项。
apiserver_admission_step_admission_latencies_seconds_sum  #有不到100个不同的label项。
apiserver_admission_step_admission_latencies_seconds_summary_count  #有不到100个不同的label项。
apiserver_admission_step_admission_latencies_seconds_count  #有不到100个不同的label项。
apiserver_admission_step_admission_latencies_seconds_summary_sum  #有不到100个不同的label项。
rest_client_request_latency_seconds_bucket  #有不到100个不同的label项。
apiserver_longrunning_gauge  #有50个不同的label项。
etcd_object_counts  #etcd对象计数,有50个不同的label项。
apiserver_registered_watchers  #apiserver注册watchers,有不到50个不同的label项。
apiserver_storage_data_key_generation_latencies_microseconds_bucket  #apiserver存储数据密钥生成延迟微秒级bucket,有不到20个不同的label项。
apiserver_client_certificate_expiration_seconds_bucket #apiserver客户端证书到期秒数bucket,有不到20个不同的label项。
rest_client_requests_total  #其余客户端请求总数,有8个不同的label项。
grpc_client_started_total  #grpc客户端启动总数,有6个不同的label项。
grpc_client_msg_sent_total  #grpc客户端msg发送总计,有6个不同的label项。
rest_client_request_latency_seconds_sum  #其余客户端请求延迟秒数总和,有6个不同的label项。
rest_client_request_latency_seconds_count  #其余客户端请求延迟秒数,有6个不同的label项。
grpc_client_handled_total  #grpc客户端处理的总计,有5个不同的label项。
apiserver_audit_level_total  #apiserver审核级别总计,有4个不同的label项。
admission_quota_controller_queue_latency  #准入配额控制器队列延迟,有3个不同的label项。
autoregister_queue_latency  #自动注册队列延迟,有3个不同的label项。
crdEstablishing_queue_latency  #crd建立队列延迟,有3个不同的label项。
autoregister_work_duration  #自动注册工作时间,有3个不同的label项。
http_response_size_bytes  #http响应大小字节,有3个不同的label项。
etcd_request_cache_get_latencies_summary  #etcd请求缓存获取延迟summary,有3个不同的label项。
APIServiceRegistrationController_work_duration  #APIServiceRegistrationController工作持续时间,有3个不同的label项
APIServiceOpenAPIAggregationControllerQueue1_work_duration  #APIServiceOpenAPIAggregationControllerQueue1的工作时间,有3个不同的label项
APIServiceRegistrationController_queue_latency  #APIServiceRegistrationController队列延迟,有3个不同的label项
DiscoveryController_queue_latency  #DiscoveryController队列延迟,有3个不同的label项
AvailableConditionController_work_duration  #AvailableConditionController工作时间,有3个不同的label项
APIServiceOpenAPIAggregationControllerQueue1_queue_latency  #APIServiceOpenAPIAggregationControllerQueue1队列延迟,有3个不同的label项
etcd_request_cache_add_latencies_summary  #etcd请求缓存add延迟summary,有3个不同的label项
http_request_size_bytes  #http请求大小字节,有3个不同的label项
AvailableConditionController_queue_latency  #AvailableConditionController队列延迟,有3个不同的label项
DiscoveryController_work_duration  #DiscoveryController的工作时间,有3个不同的label项
http_request_duration_microseconds  #http请求持续时间微秒,有3个不同的label项
admission_quota_controller_work_duration  #admission_quota控制器的持续工作时间,有3个不同的label项
crdEstablishing_work_duration  #crd建立连接的工作时间,有3个不同的label项
apiserver_current_inflight_requests  #apiserver当前进行中的请求,有两个不同的label项
get_token_fail_count  #get token失败计数
scrape_duration_seconds  #采集时间单位为秒
APIServiceRegistrationController_depth  #APIServiceRegistrationController深度
AvailableConditionController_queue_latency_count  #AvailableConditionController队列延迟计数
AvailableConditionController_retries  #AvailableConditionController重试
AvailableConditionController_work_duration_count  #AvailableConditionController工作持续时间计数
admission_quota_controller_work_duration_count  #admission_quota_controller工作持续时间计数
apiserver_client_certificate_expiration_seconds_sum  #apiserver客户端证书到期秒数总和
AvailableConditionController_work_duration_sum  #AvailableConditionController工作持续时间总和
etcd_helper_cache_miss_count  #etcd helper缓存未命中计数
DiscoveryController_queue_latency_count  #DiscoveryController队列延迟计数
APIServiceOpenAPIAggregationControllerQueue1_depth  #APIServiceOpenAPIAggregationControllerQueue1深度
APIServiceRegistrationController_adds
admission_quota_controller_adds
etcd_request_cache_get_latencies_summary_count  #etcd请求缓存获取延迟汇总计数
http_request_duration_microseconds_sum  #http请求持续时间微秒总和
autoregister_work_duration_count  #自动注册工作时间计数
APIServiceOpenAPIAggregationControllerQueue1_queue_latency_count  #APIServiceOpenAPIAggregationControllerQueue1队列延迟计数
autoregister_queue_latency_sum  #自动注册队列延迟总和
autoregister_retries  #自动注册重试
DiscoveryController_work_duration_count  #DiscoveryController工作持续时间计数
APIServiceRegistrationController_queue_latency_sum  #APIServiceRegistrationController队列延迟总和
APIServiceOpenAPIAggregationControllerQueue1_adds
AvailableConditionController_depth
AvailableConditionController_queue_latency_sum
APIServiceRegistrationController_work_duration_count
apiserver_audit_event_total  #apiserver审核事件总计
etcd_request_cache_add_latencies_summary_count
etcd_helper_cache_entry_count
apiserver_storage_data_key_generation_failures_total  #apiserver存储数据密钥生成失败总数
DiscoveryController_adds
admission_quota_controller_queue_latency_count
admission_quota_controller_work_duration_sum
etcd_helper_cache_hit_count
up
kubernetes_build_info  #kubernetes构建信息
http_response_size_bytes_count
crdEstablishing_retries
process_resident_memory_bytes
http_response_size_bytes_sum
DiscoveryController_retries  #DiscoveryController重试
admission_quota_controller_queue_latency_sum
AvailableConditionController_adds
etcd_request_cache_get_latencies_summary_sum
http_request_size_bytes_count
process_start_time_seconds
APIServiceOpenAPIAggregationControllerQueue1_retries
admission_quota_controller_depth
apiserver_storage_envelope_transformation_cache_misses_total
autoregister_work_duration_sum
crdEstablishing_work_duration_sum
apiserver_client_certificate_expiration_seconds_count
DiscoveryController_queue_latency_sum
APIServiceOpenAPIAggregationControllerQueue1_queue_latency_sum
apiserver_storage_data_key_generation_latencies_microseconds_sum
autoregister_depth
APIServiceOpenAPIAggregationControllerQueue1_work_duration_count
crdEstablishing_queue_latency_sum
apiserver_storage_data_key_generation_latencies_microseconds_count
DiscoveryController_work_duration_sum
etcd_request_cache_add_latencies_summary_sum
APIServiceOpenAPIAggregationControllerQueue1_work_duration_sum
scrape_samples_scraped
APIServiceRegistrationController_queue_latency_count
APIServiceRegistrationController_retries
APIServiceRegistrationController_work_duration_sum

3.2 job="kubernetes-cadvisor"

查看信息类型地址:https://github.com/google/cadvisor/blob/master/metrics/testdata/prometheus_metrics

container_tasks_state  #gauge类型,容器特定状态的任务数,根据不同的pod_name和state有600+的不同label.
container_memory_failures_total  #counter类型,内存分配失败的累积计数,根据不同的pod_name和state有600+的不同label.
container_network_receive_errors_total  #counter类型,容器网络接收时遇到的累计错误数。
container_network_transmit_bytes_total  #counter类型,容器发送传输的累计字节数。
container_network_transmit_packets_dropped_total  #counter类型,容器传输时丢弃的累计包数
container_network_transmit_packets_total  #counter类型,传输数据包的累计计数
container_network_transmit_errors_total  #counter类型,传输时遇到的累积错误数
container_network_receive_bytes_total  #counter类型,收到的累计字节数
container_network_receive_packets_dropped_total  #counter类型,接收时丢弃的累计数据包数
container_network_receive_packets_total  #counter类型,收到的累计数据包数
container_spec_cpu_period  #gauge类型,容器的CPU period。
container_spec_memory_swap_limit_bytes  #容器swap内存交换限制字节
container_memory_failcnt  #counter类型,内存使用次数达到限制
container_spec_memory_reservation_limit_bytes  #容器规格内存预留限制字节
container_spec_cpu_shares  #gauge类型,
container_spec_memory_limit_bytes  #容器规格内存限制字节
container_memory_max_usage_bytes  #gauge类型,以字节为单位记录的最大内存使用量
container_cpu_load_average_10s  #gauge类型,最近10秒钟内的容器CPU平均负载值。
container_memory_rss  #gauge类型,容器RSS的大小(以字节为单位)
container_start_time_seconds  #gauge类型,从Unix纪元开始的容器开始时间(以秒为单位)。
container_memory_mapped_file  #gauge类型,内存映射文件的大小(以字节为单位)
container_cpu_user_seconds_total  #conter类型,累计CPU user 时间(以秒为单位)
container_memory_cache  #gauge类型,内存的cache字节数。
container_memory_working_set_bytes  #gague类型,当前工作集(以字节为单位)
container_cpu_system_seconds_total  #conter类型,累计CPU system时间(以秒为单位)
container_memory_swap  #gauge类型,容器交换使用量(以字节为单位)
container_memory_usage_bytes  #gauge类型,当前内存使用情况(以字节为单位),包括所有内存,无论何时访问
container_last_seen  #gauge类型,上一次export看到此容器的时间
container_fs_writes_total  #counter类型,累计写入次数
container_fs_reads_total   #counter类型,类型读取次数
container_cpu_usage_seconds_total  #counter类型,累计消耗CPU的总时间
container_fs_reads_bytes_total  #容器读取的总字节数
container_fs_writes_bytes_total  #容器写入的总字节数
container_fs_sector_reads_total  #counter类型,扇区已完成读取的累计计数
container_fs_inodes_free  #gauge类型,可用的Inode数量
container_fs_io_current  #gauge类型,当前正在进行的I/O数
container_fs_io_time_weighted_seconds_total  #counter类型,累积加权I/O时间(以秒为单位)
container_fs_usage_bytes  #gauge类型,此容器在文件系统上使用的字节数
container_fs_limit_bytes  #gauge类型,此容器文件系统上可以使用的字节数
container_fs_inodes_total  #gauge类型,inode数
container_fs_sector_writes_total  #counter类型,扇区写入累计计数
container_fs_io_time_seconds_total  #counter类型,I/O花费的秒数累计
container_fs_writes_merged_total  #counter类型,合并的累计写入数
container_fs_reads_merged_total  #counter类型,合并的累计读取数
container_fs_write_seconds_total  #counter类型,写花费的秒数累计
container_fs_read_seconds_total   #counter类型,读花费的秒数累计
container_cpu_cfs_periods_total  #counter类型,执行周期间隔时间数
container_cpu_cfs_throttled_periods_total  #counter类型,节流周期间隔数
container_cpu_cfs_throttled_seconds_total  #counter类型,容器被节流的总时间
container_spec_cpu_quota  #gauge类型,容器的CPU配额
machine_memory_bytes  #gauge类型,机器上安装的内存量
scrape_samples_post_metric_relabeling
cadvisor_version_info
scrape_duration_seconds
machine_cpu_cores  #gauge类型,机器上的CPU核心数
container_scrape_error  #gauge类型,如果获取容器指标时出错,则为1,否则为0
scrape_samples_scraped

3.3 job="kubernetes-nodes"

storage_operation_duration_seconds_bucket
kubelet_runtime_operations_latency_microseconds  #summary类型,(不建议使用)运行时操作的延迟(以微秒为单位)。 按操作类型细分
rest_client_request_latency_seconds_bucket
kubelet_docker_operations_latency_microseconds  #summary类型,(不建议使用)Docker操作的延迟(以微秒为单位)。 按操作类型细分。
kubelet_runtime_operations  #counter类型,(不建议使用)按操作类型划分的运行时操作累计数。
kubelet_runtime_operations_latency_microseconds_count
apiserver_storage_data_key_generation_latencies_microseconds_bucket
kubelet_runtime_operations_latency_microseconds_sum
apiserver_client_certificate_expiration_seconds_bucket
kubelet_docker_operations_latency_microseconds_sum
kubelet_docker_operations  #counter类型,(已弃用)按操作类型分类的Docker操作的累计数量。
kubelet_docker_operations_latency_microseconds_count
rest_client_requests_total  #counter类型,HTTP请求数,按状态码,方法和主机划分。
kubelet_cgroup_manager_latency_microseconds  #summary类型,(不建议使用)cgroup Manager操作的延迟(以微秒为单位)。 按方法细分。
storage_operation_duration_seconds_sum
storage_operation_duration_seconds_count
kubelet_network_plugin_operations_latency_microseconds  #summary类型,(不建议使用)网络插件操作的延迟(以微秒为单位)。 按操作类型细分。
volume_manager_total_volumes  #gauge类型,Volume Manager中的卷数
kubelet_pod_worker_latency_microseconds  #summary类型,(不建议使用)延迟(以微秒为单位)以同步单个Pod。 按操作类型细分:创建,更新或同步
kubelet_docker_operations_errors  #counter类型,(已弃用)按操作类型分类的Docker操作错误累计数。
kubelet_runtime_operations_errors  #counter类型,(不建议使用)按操作类型累计的运行时操作错误数。
rest_client_request_latency_seconds_count
rest_client_request_latency_seconds_sum
http_request_size_bytes  #summary类型,HTTP请求大小(以字节为单位)。
kubelet_pleg_relist_latency_microseconds  #summary类型,(已弃用)重新列出PLEG中的Pod的延迟(以微秒为单位)。
kubelet_pod_worker_start_latency_microseconds  #summary类型,(已弃用)从看到容器到开始工作的等待时间(以微秒为单位)。
kubelet_cgroup_manager_latency_microseconds_sum
kubelet_network_plugin_operations_latency_microseconds_sum
http_request_duration_microseconds  #summary类型,HTTP请求延迟(以微秒为单位)。
kubelet_cgroup_manager_latency_microseconds_count
http_response_size_bytes  #summary类型,HTTP响应大小(以字节为单位)。
kubelet_pod_start_latency_microseconds  #summary类型,(已弃用)单个Pod从挂起到运行的延迟(以微秒为单位)。
kubelet_containers_per_pod_count  #histogram类型,每个pod的容器数。
kubelet_network_plugin_operations_latency_microseconds_count
kubelet_pleg_relist_interval_microseconds  #summary类型,(已弃用)在PLEG中重新上市之间的间隔(以微秒为单位)。
kubelet_pod_worker_latency_microseconds_sum
kubelet_pod_worker_latency_microseconds_count
storage_operation_errors_total  #counter类型,存储操作错误总数。
process_resident_memory_bytes  #gauge类型,驻留内存大小(以字节为单位)。
kubelet_certificate_manager_client_expiration_seconds  #gauge类型,证书生命周期的量度。 该值是证书自UTC 1970年1月1日起过期的秒数。
kubelet_running_container_count  #gauge类型,当前正在运行的容器数
http_request_size_bytes_sum
kubelet_pleg_relist_latency_microseconds_count
http_request_duration_microseconds_count
kubelet_pod_worker_start_latency_microseconds_count
kubelet_pleg_relist_interval_microseconds_sum
scrape_samples_scraped
process_open_fds
kubelet_pod_worker_start_latency_microseconds_sum
apiserver_storage_data_key_generation_failures_total  #counter类型,失败的数据加密密钥(DEK)生成操作的总数。
http_request_size_bytes_count
kubelet_running_pod_count  #gauge类型,当前运行的pod数
kubelet_node_config_error  #gauge类型,如果节点遇到与配置相关的错误,则此指标为true(1),否则为false(0)。
kubelet_pod_start_latency_microseconds_count
apiserver_storage_data_key_generation_latencies_microseconds_count
kubelet_pleg_relist_latency_microseconds_sum
process_virtual_memory_bytes
scrape_samples_post_metric_relabeling
process_start_time_seconds
kubelet_pod_start_latency_microseconds_sum
apiserver_client_certificate_expiration_seconds_sum
kubelet_containers_per_pod_count_count
http_response_size_bytes_count
kubernetes_build_info
http_response_size_bytes_sum
apiserver_audit_event_total  #counter类型,生成审计事件的计数器,并将其发送到审计后端。
kubelet_containers_per_pod_count_sum
kubelet_pleg_relist_interval_microseconds_count
apiserver_storage_envelope_transformation_cache_misses_total  #counter类型,访问密钥解密密钥(KEK)时缓存未命中总数。
scrape_duration_seconds
apiserver_storage_data_key_generation_latencies_microseconds_sum
http_request_duration_microseconds_sum
apiserver_client_certificate_expiration_seconds_count

3.4 job="kubernetes-pods"

#这里部署的是nginx_ingress_controller  下面是查询这些metric类型和意思的网址:

https://github.com/kubernetes/ingress-nginx/blob/master/internal/ingress/metric/collectors/nginx_status_test.go

https://www.gitmemory.com/issue/kubernetes/ingress-nginx/2924/483591581

nginx_ingress_controller_nginx_process_connections  #gauge类型,状态为{active, reading, writing, waiting}的当前客户端连接数
nginx_ingress_controller_nginx_process_connections_total  #counter类型,状态为{accepted, handled(已接受,已处理)}的连接总数
nginx_ingress_controller_config_last_reload_successful  #gauge类型,nginx_ingress_controller_config最后一次加载成功的时间
nginx_ingress_controller_nginx_process_write_bytes_total #counter类型,nginx_ingress_controller nginx进程写入字节总数
nginx_ingress_controller_config_hash  #gauge类型,实际正在运行配置散列
nginx_ingress_controller_config_last_reload_successful_timestamp_seconds   #gauge类型,上一次成功重新配置的时间戳。
nginx_ingress_controller_nginx_process_num_procs  #gauge类型,进程数
nginx_ingress_controller_nginx_process_oldest_start_time_seconds  #gauge类型,从1970/01/01开始的秒数
nginx_ingress_controller_nginx_process_virtual_memory_bytes  #guage类型,正在使用的内存字节数
nginx_ingress_controller_success  #counter类型,Ingress控制器重新加载操作的累积数量
nginx_ingress_controller_nginx_process_read_bytes_total  #counter类型,读取的字节数
nginx_ingress_controller_nginx_process_cpu_seconds_total  #counter类似,CPU使用时间(以秒为单位)
nginx_ingress_controller_nginx_process_requests_total  #counter类型,客户请求总数
nginx_ingress_controller_nginx_process_resident_memory_bytes  #gauge类型,正在使用的内存字节数

3.5 job="kubernetes-service-endpoints"

coredns的查看指标地址:https://github.com/DataDog/integrations-core/blob/master/coredns/tests/fixtures/metrics.txt


作者:忙碌的柴少 分类:prometheus 浏览:1015 评论:0
留言列表
发表评论
来宾的头像