0%

全局配置

参考官网:https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kubernetes_sd_config

global:
  # How frequently to scrape targets by default.
  [ scrape_interval:  | default = 1m ]
 
  # How long until a scrape request times out.
  [ scrape_timeout:  | default = 10s ]
 
  # How frequently to evaluate rules.
  [ evaluation_interval:  | default = 1m ]
 
  # The labels to add to any time series or alerts when communicating with
  # external systems (federation, remote storage, Alertmanager).
  external_labels:
    [ :  ... ]
 
# Rule files specifies a list of globs. Rules and alerts are read from
# all matching files.
rule_files:
  [ -  ... ]
 
# A list of scrape configurations.
scrape_configs:
  [ -  ... ]
 
# Alerting specifies settings related to the Alertmanager.
alerting:
  alert_relabel_configs:
    [ -  ... ]
  alertmanagers:
    [ -  ... ]
 
# Settings related to the remote write feature.
remote_write:
  [ -  ... ]
 
# Settings related to the remote read feature.
remote_read:
  [ -  ... ]

更改指标标签

更改标签的时机:抓取前修改、抓取后修改、告警时修改

  • 采集数据之前,通过relabel_config
  • 采集数据之后,写入存储之前,通过metric_relabel_configs
  • 在告警前修改标签,通过alert_relabel_configs

JOB配置

- job_name: prometheus
  honor_labels: false
  kubernetes_sd_configs:
  - role: endpoints
    namespaces:
      names:
      - monitoring
  scrape_interval: 30s
  relabel_configs:
  - action: keep
    source_labels:
    - __meta_kubernetes_service_label_prometheus
    regex: k8s
  - source_labels:
    - __meta_kubernetes_endpoint_address_target_kind
    - __meta_kubernetes_endpoint_address_target_name
    separator: ;
    regex: Pod;(.*)
    replacement: ${1}
    target_label: pod
  - source_labels:
    - __meta_kubernetes_namespace
    target_label: namespace
  • kubernetes_sd_configs:使用这个配置可以自动发现 k8s 中 node、service、pod、endpoint、ingress,并为其添加监控,更多的内容可以直接查看官方文档。__meta_kubernetes_xxxxx具体什么意思都可以在官网找到。
  • endpoints:采用endpoints方式采集,每创建一个 service 就会创建一个对应的 endpoint,通过endpoint方式可以将service下所有的pod都采集到。
  • 下面配置的意思是只有 service 的标签包含 prometheus=k8s,k8s 才会对其对应的 endpoint 进行采集。所以我们后面要为 Prometheus 创建一个 service,并且要为这个 service 加上 prometheus: k8s 这样的标签。
  - action: keep
    source_labels:
    - __meta_kubernetes_service_label_prometheus
    regex: k8s
  • 下面配置意识是如果 __meta_kubernetes_endpoint_address_target_kind 的值为 Pod,__meta_kubernetes_endpoint_address_target_name 的值为 prometheus-0,在它们之间加上一个 ; 之后,它们合起来就是 Pod;prometheus-0。使用正则表达式 Pod;(.*) 对其进行匹配,那么 ${1} 就是取第一个分组,它值就是 prometheus-0,最后将这个值交给 pod 这个标签。因此这一段配置就是为所有采集到的监控指标增加一个 pod=prometheus-0 的标签。如果 __meta_kubernetes_endpoint_address_target_kind 的值不是 Pod,那么不会添加任何标签。
- source_labels:
    - __meta_kubernetes_endpoint_address_target_kind
    - __meta_kubernetes_endpoint_address_target_name
  separator: ;
  regex: Pod;(.*)
  replacement: ${1}
  target_label: pod
  • 没有指定 url,Prometheus 会采集默认的 url /metrics

定义告警规则

groups:
- name: example
  rules:
  - alert: HighRequestLatency
    expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5
    for: 10m
    labels:
      severity: page
    annotations:
      summary: High request latency

参考官网: https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/

  • for:Prometheus将在每次发出警报之前检查警报在10分钟内是否继续处于活动状态
  • labels:允许指定一组附加标签来附加到警报。任何现有的冲突标签都将被覆盖。标签值可以模板化。
  • annotations:指定了一组信息标签,可用于存储更长的附加信息,例如警报说明或运行手册链接。注释值可以模板化。

模板化

标签和注释值可以使用控制台模板进行模板化。该$labels 变量保存警报实例的标签键/值对。可以通过$externalLabels变量访问已组态的外部标签。该 $value变量保存警报实例的评估值。

# To insert a firing element's label values:
{{ $labels. }}
# To insert the numeric expression value of the firing element:
{{ $value }}

例子:

groups:
- name: example
  rules:
 
  # Alert for any instance that is unreachable for >5 minutes.
  - alert: InstanceDown
    expr: up == 0
    for: 5m
    labels:
      severity: page
    annotations:
      summary: "Instance {{ $labels.instance }} down"
      description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes."
 
  # Alert for any instance that has a median request latency >1s.
  - alert: APIHighRequestLatency
    expr: api_http_request_latencies_second{quantile="0.5"} > 1
    for: 10m
    annotations:
      summary: "High request latency on {{ $labels.instance }}"
      description: "{{ $labels.instance }} has a median request latency above 1s (current value: {{ $value }}s)"

Alertmanager是安装prometheus-operator时默认新增的自定义资源类型(CRD),我们可以直接在K8s中创建这样的资源。

创建alert-test.yaml

apiVersion: monitoring.coreos.com/v1
kind: Alertmanager
metadata:
  generation: 1
  labels:
    app: prometheus-operator-alertmanager
    chart: prometheus-operator-8.2.4
    heritage: Tiller
    release: prometheus-operator
  name: prometheus-operator-alertmanager-test
  namespace: monitoring
spec:
  baseImage: quay.io/prometheus/alertmanager
  version: v0.19.0
  portName: web
  replicas: 1
  retention: 120h
  routePrefix: /
  serviceAccountName: prometheus-operator-alertmanager
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - topologyKey: kubernetes.io/hostname
        labelSelector:
          matchLabels:
            app: alertmanager
            alertmanager: prometheus-operator-alertmanager-test
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          topologyKey: kubernetes.io/hostname
          labelSelector:
            matchLabels:
              app: alertmanager
              alertmanager: prometheus-operator-alertmanager-test
  storage:
    volumeClaimTemplate:
      selector: {}
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 1Gi
        storageClassName: nfs-client

针对以上配置文件简要说明:

  • 所有配置项可以从stable/prometheus-operator/templates/alertmanager/alertmanager.yaml获取,参考前文,prometheus-operator环境是使用helm安装的,可以通过命令helm fetch stable/prometheus-operator将所有配置下载到本地,然后参考。helm安装会默认安装一个Alertmanager服务,也是通过alertmanager.yaml安装的。
  • kind类型写Alertmanager,无需多言。
  • metadata.name指定你这个Alertmanager名称,可以通过命令查询
kubectl get alertmanager -n monitoring
  • spec.baseImage/version需要指定,不然默认使用的镜像版本可能跟helm安装时使用的版本不一致,导致你需要重新下载,部署就非常慢。
  • spec.storage指定你新部署的Alertmanager存储,建议指定。
  • spec.affinity需要指定一些label,Alertmanager对象本质还是一个StatefulSet对象,后面你为Alertmanager对象创建Service时需要通过Label选择。
  • spec.portName指定你端口的名称,这个后面配置和Prometheus关联的时候需要。建议保持默认。
  • metadata.namespace指定命名空间,这个后面配置和Prometheus关联的时候需要。建议保持默认。
  • spec.routePrefix指定路径前缀,这个后面配置和Prometheus关联的时候需要。建议保持默认。

过命令或者dashborad创建Alertmanager

kubectl create -f alert-test.yaml

注意:

现在创建这个,肯定会报错,类似MountVolume.SetUp failed for volume "config-volume" : secrets "alertmanager-XXXX-xX" not found

原因:(参考:https://yunlzheng.gitbook.io/prometheus-book/part-iii-prometheus-shi-zhan/operator/use-operator-manage-monitor

这是由于Prometheus Operator通过Statefulset的方式创建的Alertmanager实例,在默认情况下,会通过alertmanager-{ALERTMANAGER_NAME}的命名规则去查找Secret配置并以文件挂载的方式,将Secret的内容作为配置文件挂载到Alertmanager实例当中。因此,需要提前为Alertmanager创建相应的配置内容。

参考前文Alertmanager配置

我们创建alertmanager.yamltemplate_1.tmpl

然后用命令创建secretsecret名称格式:alertmanager-{ALERTMANAGER_NAME},例如我们前文指定的Alertmanager名称为prometheus-operator-alertmanager-test,那么这里secret名称为alertmanager-prometheus-operator-alertmanager-test

kubectl create secret generic alertmanager-prometheus-operator-alertmanager-test -n monitoring --from-file=alertmanager.yaml --from-file=template_1.tmpl

最后创建Alertmanager

创建Alertmanager的service

这里直接指定Service类型是NodePort,便于我们访问,实际应通过Ingress来做。

apiVersion: v1
kind: Service
metadata:
  labels:
    app: prometheus-operator-alertmanager
    chart: prometheus-operator-8.2.4
    heritage: Tiller
    release: prometheus-operator
  name: prometheus-operator-alertmanager-test
  namespace: monitoring
spec:
  ports:
  - name: web
    port: 9093
    protocol: TCP
    targetPort: 9093
  selector:
    alertmanager: prometheus-operator-alertmanager-test
    app: alertmanager
  sessionAffinity: None
  type: NodePort

注意:这里通过selector来选择,和创建Alertmanager配置中保持一致。

通过命令查询Service的映射端口

kubectl get svc -n monitoring

通过命令查询Service的映射端口,即可访问我们刚刚创建的Alertmanager.

现在Alertmanager上应该还没有任何通知,原因是还没有将我们创建的Alertmanager和Prometheus关联。

关联Prometheus

如何关联Prometheus呢?首先查看下prometheus-operator创建的Prometheus的配置,prometheus-operator也是通过自定义资源类型(CRD)prometheus来创建prometheus server的,直接通过命令查看。

kubectl get Prometheus prometheus-operator-prometheus  -n monitoring -o yaml
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  creationTimestamp: "2019-11-28T02:42:48Z"
  generation: 1
  labels:
    app: prometheus-operator-prometheus
    chart: prometheus-operator-8.2.4
    heritage: Tiller
    release: prometheus-operator
  name: prometheus-operator-prometheus
  namespace: monitoring
  resourceVersion: "6316434"
  selfLink: /apis/monitoring.coreos.com/v1/namespaces/monitoring/prometheuses/prometheus-operator-prometheus
  uid: de60d68f-6818-484d-ba30-4f381e7cb016
spec:
  alerting:
    alertmanagers:
    - name: prometheus-operator-alertmanager
      namespace: monitoring
      pathPrefix: /
      port: web
  baseImage: quay.io/prometheus/prometheus
  enableAdminAPI: false
  externalUrl: http://prom.deri.com/
  listenLocal: false
  logFormat: logfmt
  logLevel: info
  paused: false
  podMonitorNamespaceSelector: {}
  podMonitorSelector:
    matchLabels:
      release: prometheus-operator
  portName: web
  replicas: 1
  retention: 10d
  routePrefix: /
  ruleNamespaceSelector: {}
  ruleSelector:
    matchLabels:
      app: prometheus-operator
      release: prometheus-operator
  securityContext:
    fsGroup: 2000
    runAsNonRoot: true
    runAsUser: 1000
  serviceAccountName: prometheus-operator-prometheus
  serviceMonitorNamespaceSelector: {}
  serviceMonitorSelector:
    matchLabels:
      release: prometheus-operator
  storage:
    volumeClaimTemplate:
      selector: {}
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 2Gi
        storageClassName: nfs-client
  version: v2.13.1

Prometheus配置

  • spec.alerting.alertmanagers就是指定Prometheus将告警发给哪些alertmanagers。
  • spec.ruleSelector.matchLabels通过标签关联用户创建的自定义PrometheusRule。
  • spec.serviceMonitorSelector.matchLabels通过标签关联用户创建的自定义ServiceMonitor

使用命令编辑已有的Prometheus服务配置

kubectl edit Prometheus prometheus-operator-prometheus  -n monitoring

增加一个AlertmanagerEndpoint,其中namenamespacepathPrefixport和创建Alertmanager配置保持一致。

spec:
  alerting:
    alertmanagers:
    - name: prometheus-operator-alertmanager
      namespace: monitoring
      pathPrefix: /
      port: web
    - name: prometheus-operator-alertmanager-test
      namespace: monitoring
      pathPrefix: /
      port: web

Alertmanager简介及机制

Alertmanager处理由例如Prometheus服务器等客户端发来的警报。它负责删除重复数据、分组,并将警报通过路由发送到正确的接收器,比如电子邮件、Slack等。Alertmanager还支持groups,silencing和警报抑制的机制。

分组

分组是指将同一类型的警报分类为单个通知。当许多系统同时宕机时,很有可能成百上千的警报会同时生成,这种机制特别有用。

抑制(Inhibition)

抑制是指当警报发出后,停止重复发送由此警报引发其他错误的警报的机制。(比如网络不可达,导致其他服务连接相关警报)

沉默(Silences)

Silences是一种简单的特定时间不告警的机制。

默认配置

打开Alertmanager的页面,选择status页面,可以查看到当前的Config。这是使用Helm安装prometheus-operator时默认的配置,如何修改呢?

global:
  resolve_timeout: 4m
  http_config: {}
  smtp_hello: localhost
  smtp_require_tls: true
  pagerduty_url: https://events.pagerduty.com/v2/enqueue
  hipchat_api_url: https://api.hipchat.com/
  opsgenie_api_url: https://api.opsgenie.com/
  wechat_api_url: https://qyapi.weixin.qq.com/cgi-bin/
  victorops_api_url: https://alert.victorops.com/integrations/generic/20131114/alert/
route:
  receiver: "null"
  group_by:
  - job
  routes:
  - receiver: "null"
    match:
      severity: info
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 12h
receivers:
- name: "null"
templates: []

Alertmanager配置说明

参考https://www.jianshu.com/p/239b145e2acc

修改默认配置

默认配置由同命名空间下Secret挂载到POD中,所以只要修改了这个Secret就可以修改默认配置了。

alertmanager-prometheus-operator-alertmanager内容主要是alertmanager.yaml 经过Base64加密的。可以通过命令查看

kubectl edit  secret alertmanager-prometheus-operator-alertmanager -n monitoring

复制其中的alertmanager.yaml后面的字符串,然后使用命令查看原始值。

echo "Imdsb2JhbCI6IAogICJyZXNvbHZlX3RpbWVvdXQiOiAiNW0iCiJyZWNlaXZlcnMiOiAKLSAibmFtZSI6ICJudWxsIgoicm91dGUiOiAKICAiZ3JvdXBfYnkiOiAKICAtICJqb2IiCiAgImdyb3VwX2ludGVydmFsIjogIjVtIgogICJncm91cF93YWl0IjogIjMwcyIKICAicmVjZWl2ZXIiOiAibnVsbCIKICAicmVwZWF0X2ludGVydmFsIjogIjEyaCIKICAicm91dGVzIjogCiAgLSAibWF0Y2giOiAKICAgICAgImFsZXJ0bmFtZSI6ICJEZWFkTWFuc1N3aXRjaCIKICAgICJyZWNlaXZlciI6ICJudWxsIg==" | base64 -d
"global":
  "resolve_timeout": "5m"
"receivers":
- "name": "null"
"route":
  "group_by":
  - "job"
  "group_interval": "5m"
  "group_wait": "30s"
  "receiver": "null"
  "repeat_interval": "12h"
  "routes":
  - "match":
      "alertname": "DeadMansSwitch"
    "receiver": "null"

创建一个新的alertmanager.yaml文件,内容

global:
  resolve_timeout: 4m
receivers:
- name: webhook_alert
  webhook_configs:
  - send_resolved: true
    url: http://dingtalkservice:8060/dingtalk/webhook1/send 
route:
  group_by:
  - job
  - alertname
  - cluster
  - service
  group_interval: 5m
  group_wait: 30s
  receiver: webhook_alert
  repeat_interval: 12h
  routes:
  - match:
      severity: info
    receiver: webhook_alert
  - match:
      severity: warning
    receiver: webhook_alert
templates:
- '*.tmpl'

其中我们增加了webhook方式报警,配置最后增加了模板,所以我们还需要创建一个模板,如template_1.tmpl

{{ define "cluster" }}
    [错误订阅信息]{{ len .Alerts }}({{.GroupLabels.appid}}-{{.GroupLabels.service}}) 时间
    {{ range $i, $alert := .Alerts }}
        {{if eq $i 0}} 
            {{ $alert.StartsAt }}
        {{ end }}
    {{ end }}
{{ end }}
 
{{ define "alertemp.html" }}
    {{ range $i, $alert := .Alerts }}
        *报警名称:* {{ $alert.Labels.alertname }}
        *开始时间:* {{ $alert.StartsAt }}
        *错误信息:* {{ $alert.Annotations.errormessage }}
    {{ end }}
{{ end }}

上述模板参考:http://blog.microservice4.net/2018/12/05/alertmanager/

先删除原来的Secret

kubectl delete secret alertmanager-prometheus-operator-alertmanager -n monitoring

从刚刚文件创建新的Secret

kubectl create secret generic alertmanager-prometheus-operator-alertmanager -n monitoring --from-file=alertmanager.yaml --from-file=template_1.tmpl

创建完之后可以通过log命令查看后台有没有报错。

kubectl log alertmanager-prometheus-operator-alertmanager-0 alertmanager -n monitoring

也可以在Dashboard中查看日志。还可以在Alertmanager容器中查看
altermanager

最后在Alertmanager页面中查看Config是否更新。
altermanager

到此,已经完成Alertmanager默认配置的更新。

以上参考https://www.qikqiak.com/post/prometheus-operator-custom-alert/.

上述配置Webhook使用的钉钉来做通知

webhook通知机制

在Alertmanager中可以使用如下配置定义基于webhook的告警接收器receiver。一个receiver可以对应一组webhook配置。

name: 
webhook_configs:
  [ - , ... ]

每一项webhook_config的具体配置格式如下:

# Whether or not to notify about resolved alerts.
[ send_resolved:  | default = true ]
 
# The endpoint to send HTTP POST requests to.
url: 
 
# The HTTP client's configuration.
[ http_config:  | default = global.http_config ]

send_resolved用于指定是否在告警消除时发送回执消息。url则是用于接收webhook请求的地址。http_configs则是在需要对请求进行SSL配置时使用。

当用户定义webhook用于接收告警信息后,当告警被触发时,Alertmanager会按照以下格式向这些url地址发送HTTP Post请求,请求内容如下:

{
  "version": "4",
  "groupKey": <string>,    // key identifying the group of alerts (e.g. to deduplicate)
  "status": "<resolved|firing>",
  "receiver": <string>,
  "groupLabels": <object>,
  "commonLabels": <object>,
  "commonAnnotations": <object>,
  "externalURL": <string>,  // backlink to the Alertmanager.
  "alerts": [
    {
      "labels": <object>,
      "annotations": <object>,
      "startsAt": "<rfc3339>",
      "endsAt": "<rfc3339>"
    }
  ]
}

钉钉机器人

webhook机器人创建成功后,用户就可以使用任何方式向该地址发起HTTP POST请求,即可实现向该群主发送消息。目前自定义机器人支持文本(text),连接(link),markdown三种消息类型。

例如,可以向webhook地址以POST形式发送以下

{
     "msgtype": "markdown",
     "markdown": {
         "title":"Prometheus告警信息",
         "text": "#### 监控指标\n" +
                 "> 监控描述信息\n\n" +
                 "> ###### 告警时间 \n"
     },
    "at": {
        "atMobiles": [
            "156xxxx8827",
            "189xxxx8325"
        ], 
        "isAtAll": false
    }
 }

可以使用curl验证钉钉webhook是否能够成功调用:

$ curl -l -H "Content-type: application/json" -X POST -d '{"msgtype": "markdown","markdown": {"title":"Prometheus告警信息","text": "#### 监控指标\n> 监控描述信息\n\n> ###### 告警时间 \n"},"at": {"isAtAll": false}}' https://oapi.dingtalk.com/robot/send?access_token=xxxx
{"errcode":0,"errmsg":"ok"}

如果想把Alertmanager信息转到钉钉上去,需要做一个转换器。
转化器部署:可以在k8s中部署一个Deployment,然后创建一个Service给Alert manager使用。

整个报警链路

  1. 首先是Prometheus根据告警规则告警,如果增删改规则参考PrometheusRule
  2. Prometheus的告警经过Alertmanager静默、抑制、分组等配置到达Alertmanager
  3. AlterManager通过配置webhook,地址填钉钉转换器的地址。
  4. 钉钉转换器中webhook地址填写钉钉机器人webhook的地址。

Prometheus Alert 告警状态

这里说明一下 Prometheus Alert 告警状态有三种状态:InactivePendingFiring

  • Inactive:非活动状态,表示正在监控,但是还未有任何警报触发。
  • Pending:表示这个警报必须被触发。由于警报可以被分组、压抑/抑制或静默/静音,所以等待验证,一旦所有的验证都通过,则将转到 Firing 状态。
  • Firing:将警报发送到 AlertManager,它将按照配置将警报的发送给所有接收者。一旦警报解除,则将状态转到 Inactive,如此循环。

参考链接

PrometheusRule介绍

PrometheusRule是安装prometheus-operator时默认安装的自定义资源对象(CRD),用来管理Prometheus上的告警规则,后面增删改查规则都可以通过这个资源对象查询。

例如查询默认加入的规则,通过下面的命令可以查询。

[root@k8s-master prometheus-operator]# kubectl get PrometheusRule -n monitoring
NAME                                                       AGE
prometheus-operator-alertmanager.rules                     28m
prometheus-operator-etcd                                   28m
prometheus-operator-general.rules                          28m
prometheus-operator-k8s.rules                              28m
prometheus-operator-kube-apiserver.rules                   28m
prometheus-operator-kube-prometheus-node-recording.rules   28m
prometheus-operator-kube-scheduler.rules                   28m
prometheus-operator-kubernetes-absent                      28m
prometheus-operator-kubernetes-apps                        28m
prometheus-operator-kubernetes-resources                   28m
prometheus-operator-kubernetes-storage                     28m
prometheus-operator-kubernetes-system                      28m
prometheus-operator-kubernetes-system-apiserver            28m
prometheus-operator-kubernetes-system-controller-manager   28m
prometheus-operator-kubernetes-system-kubelet              28m
prometheus-operator-kubernetes-system-scheduler            28m
prometheus-operator-node-exporter                          28m
prometheus-operator-node-exporter.rules                    28m
prometheus-operator-node-network                           28m
prometheus-operator-node-time                              28m
prometheus-operator-node.rules                             28m
prometheus-operator-prometheus                             28m
prometheus-operator-prometheus-operator                    28m

也可以在Prometheus -> Dashboard -> Status -> Rules中查看
prometheusRules

Prometheus怎么识别这个资源对象

简单来说,类似标签选择器,定义的PrometheusRule资源对象,需要带有一些Labels,具体哪些可以参考默认生成的PrometheusRule,然后新建的也给加上。

prometheusRules

参考链接:https://www.qikqiak.com/post/prometheus-operator-custom-alert/

所有的Rules都有对应的文件,默认生成在prometheus容器内

/etc/prometheus/rules/prometheus-prometheus-operator-prometheus-rulefiles-0/

目录下,新增一个PrometheusRule资源,也会在该目录下自动生成一个YAML文件

因此我们可以不用管理配置文件,只需要管理PrometheusRuleprometheus-operator使得prometheus监控更加K8s.

创建新的PrometheusRule资源

myrule.yaml

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: myrule
  labels:
    app: prometheus-operator
    chart: prometheus-operator-8.2.4
    heritage: Tiller
    release: prometheus-operator
spec:
  groups:
  - name: my-node-time
    rules:
    - alert: myClockSkewDetected
      annotations:
        message: myClock skew detected on node-exporter {{`{{ $labels.namespace }}`}}/{{`{{ $labels.pod }}`}}. Ensure NTP is configured correctly on this host.
      expr: abs(node_timex_offset_seconds{job="node-exporter"}) > 0.03
      for: 2m
      labels:
        severity: warning

注意:上面配置中具体的规则只是拷贝了一个默认规则中的内容。

使用命令或者在dashboard中贴上以上YAML,即可创建。

kubectl create -f myrule.yaml

创建完之后,可以通过命令查看

kubectl get PrometheusRule -n monitoring

也可以在Prometheus -> Dashboard中查看,最后在Prometheus容器Rule目录下确认是否新生成一个myrule.yaml的配置文件。

介绍

首先我们先来了解下 Prometheus-Operator的架构图:
Prometheus-Operator

上图是Prometheus-Operator官方提供的架构图,其中Operator是最核心的部分,作为一个控制器,他会去创建PrometheusServiceMonitorAlertManager以及PrometheusRule4个CRD资源对象,然后会一直监控并维持这4个资源对象的状态。

其中创建的prometheus这种资源对象就是作为Prometheus Server存在,而ServiceMonitor就是exporter的各种抽象,exporter前面我们已经学习了,是用来提供专门提供metrics数据接口的工具,Prometheus就是通过ServiceMonitor提供的metrics数据接口去 pull 数据的,当然alertmanager这种资源对象就是对应的AlertManager的抽象,而PrometheusRule是用来被Prometheus实例使用的报警规则文件。

这样我们要在集群中监控什么数据,就变成了直接去操作 Kubernetes 集群的资源对象了,是不是方便很多了。上图中的 Service ServiceMonitor 都是 Kubernetes 的资源,一个 ServiceMonitor 可以通过 labelSelector 的方式去匹配一类 ServicePrometheus 也可以通过 labelSelector 去匹配多个ServiceMonitor

查看stable/prometheus-operator的默认值

helm inspect values stable/prometheus-operator

将默认配置导出,备用

helm inspect values stable/prometheus-operator > prometheus-operator.yaml

提前将配置中涉及到的镜像下载好

#!/bin/sh
docker pull hub.deri.org.cn/k8s_monitor/alertmanager:v0.19.0
docker tag hub.deri.org.cn/k8s_monitor/alertmanager:v0.19.0 quay.io/prometheus/alertmanager:v0.19.0
docker rmi hub.deri.org.cn/k8s_monitor/alertmanager:v0.19.0
 
docker pull hub.deri.org.cn/k8s_monitor/ghostunnel:v1.4.1 
docker tag hub.deri.org.cn/k8s_monitor/ghostunnel:v1.4.1 squareup/ghostunnel:v1.4.1
docker rmi hub.deri.org.cn/k8s_monitor/ghostunnel:v1.4.1 
 
docker pull hub.deri.org.cn/k8s_monitor/kube-webhook-certgen:v1.0.0 
docker tag hub.deri.org.cn/k8s_monitor/kube-webhook-certgen:v1.0.0  jettech/kube-webhook-certgen:v1.0.0
docker rmi hub.deri.org.cn/k8s_monitor/kube-webhook-certgen:v1.0.0 
 
docker pull hub.deri.org.cn/k8s_monitor/prometheus-operator:v0.34.0
docker tag hub.deri.org.cn/k8s_monitor/prometheus-operator:v0.34.0 quay.io/coreos/prometheus-operator:v0.34.0
docker rmi hub.deri.org.cn/k8s_monitor/prometheus-operator:v0.34.0
 
docker pull hub.deri.org.cn/k8s_monitor/configmap-reload:v0.0.1
docker tag hub.deri.org.cn/k8s_monitor/configmap-reload:v0.0.1 quay.io/coreos/configmap-reload:v0.0.1
docker rmi pull hub.deri.org.cn/k8s_monitor/configmap-reload:v0.0.1
 
docker pull hub.deri.org.cn/k8s_monitor/prometheus-config-reloader:v0.34.0
docker tag hub.deri.org.cn/k8s_monitor/prometheus-config-reloader:v0.34.0 quay.io/coreos/prometheus-config-reloader:v0.34.0
docker rmi hub.deri.org.cn/k8s_monitor/prometheus-config-reloader:v0.34.0
 
docker pull hub.deri.org.cn/k8s_monitor/hyperkube:v1.12.1
docker tag hub.deri.org.cn/k8s_monitor/hyperkube:v1.12.1 k8s.gcr.io/hyperkube:v1.12.1
docker rmi  hub.deri.org.cn/k8s_monitor/hyperkube:v1.12.1
 
docker pull hub.deri.org.cn/k8s_monitor/prometheus:v2.13.1
docker tag hub.deri.org.cn/k8s_monitor/prometheus:v2.13.1 quay.io/prometheus/prometheus:v2.13.1
docker rmi hub.deri.org.cn/k8s_monitor/prometheus:v2.13.1
 
docker pull hub.deri.org.cn/k8s_monitor/kube-state-metrics:v1.8.0
docker tag hub.deri.org.cn/k8s_monitor/kube-state-metrics:v1.8.0 quay.io/coreos/kube-state-metrics:v1.8.0
docker rmi hub.deri.org.cn/k8s_monitor/kube-state-metrics:v1.8.0
 
docker pull hub.deri.org.cn/k8s_monitor/node-exporter:v0.18.1
docker tag hub.deri.org.cn/k8s_monitor/node-exporter:v0.18.1 quay.io/prometheus/node-exporter:v0.18.1
docker rmi hub.deri.org.cn/k8s_monitor/node-exporter:v0.18.1
 
docker pull hub.deri.org.cn/k8s_monitor/k8s-sidecar:0.1.20
docker tag hub.deri.org.cn/k8s_monitor/k8s-sidecar:0.1.20 kiwigrid/k8s-sidecar:0.1.20
docker rmi hub.deri.org.cn/k8s_monitor/k8s-sidecar:0.1.20
 
docker pull hub.deri.org.cn/k8s_monitor/grafana:6.4.2
docker tag hub.deri.org.cn/k8s_monitor/grafana:6.4.2 grafana/grafana:6.4.2
docker rmi hub.deri.org.cn/k8s_monitor/grafana:6.4.2

用默认配置安装,指定了name、namespace等信息

helm install stable/prometheus-operator  --name prometheus-operator --namespace monitoring -f prometheus-operator.yaml --set grafana.adminPassword=admin

查看pod运行情况

kubectl get pod -n monitoring

修改Grafana的service类型为NodePort,便于访问测试

kubectl edit svc prometheus-operator-grafana -n monitoring

通过下面命令,查看绑定宿主机的端口 ,访问测试密码安装时指定了admin/admin

kubectl get svc -n monitoring

卸载

helm delete prometheus-operator
helm delete --purge prometheus-operator

Prometheus-Operator安装时会去创建PrometheusServiceMonitorAlertManager以及PrometheusRule4个CRD资源对象,卸载时一并删掉

kubectl delete crd prometheuses.monitoring.coreos.com
kubectl delete crd prometheusrules.monitoring.coreos.com
kubectl delete crd servicemonitors.monitoring.coreos.com
kubectl delete crd podmonitors.monitoring.coreos.com
kubectl delete crd alertmanagers.monitoring.coreos.com

修改prometheus-operator.yaml,配置ingress

# 例如AlterManager配置,默认情况enabled: false修改成true,hosts: []填入alterManager的域名
alertmanager:
  ingress:
    enabled: true
    hosts: ["alert.deri.com"]

修改prometheus-operator.yaml,配置数据持久化

# 例如AlterManager,默认如下,是被注释掉的,取消注释,并填入你的storageClassName
    storage: {}
    # volumeClaimTemplate:
    #   spec:
    #     storageClassName: gluster
    #     accessModes: ["ReadWriteOnce"]
    #     resources:
    #       requests:
    #         storage: 50Gi
    #   selector: {}
 
alertmanager:
  alertmanagerSpec:
    storage: 
      volumeClaimTemplate:
        spec:
          storageClassName: nfs-client
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 5Gi
        selector: {}

其它配置可以在默认配置prometheus-operator.yaml中查看并修改。

问题

问题一:

【摘自https://github.com/helm/charts/tree/master/stable/prometheus-operator

KubeProxy【改完重启kubelet、docker服务】

The metrics bind address of kube-proxy is default to 127.0.0.1:10249 that prometheus instances cannot access to. You should expose metrics by changing metricsBindAddress field value to 0.0.0.0:10249 if you want to collect them.

Depending on the cluster, the relevant part config.conf will be in ConfigMap kube-system/kube-proxy or kube-system/kube-proxy-config. For example:
kubectl -n kube-system edit cm kube-proxy
apiVersion: v1
data:
  config.conf: |-
    apiVersion: kubeproxy.config.k8s.io/v1alpha1
    kind: KubeProxyConfiguration
    # ...
    # metricsBindAddress: 127.0.0.1:10249
    metricsBindAddress: 0.0.0.0:10249
    # ...
  kubeconfig.conf: |-
    # ...
kind: ConfigMap
metadata:
  labels:
    app: kube-proxy
  name: kube-proxy
  namespace: kube-system

问题二:

在不同环境安装时发现结果不一样,所有配置都一样,可能原因:

由于上述是通过helm安装的,首先通过命令helm repo list检查源是否一致;

通过helm search | grep prometheus查看 CHART VERSION    APP VERSION 是否一致;

如果不一致通过helm repo update更新一下就可以了。

参考链接

安装htpasswd

htpasswd不是centos7自带的命令,需要使用yum安装。

yum install httpd-tools

选项

  • -c: 创建一个新的密码文件
  • -b: 在命令行中一并输入用户名和密码而不是根据提示输入密码
  • -D: 删除指定的用户
  • -n: 不更新密码文件,只将加密后的用户名密码输出到屏幕上
  • -p: 不对密码进行加密,采用明文的方式
  • -m: 采用MD5算法对密码进行加密(默认的加密方式)
  • -d: 采用CRYPT算法对密码进行加密
  • -s: 采用SHA算法对密码进行加密
  • -B: 采用bcrypt算法对密码进行加密(非常安全)

参数

  • 用户名: 要创建或者更新的用户名
  • 密码: 用户的新密码

创建用户,设置密码

用下面的三个操作,创建 basic-auth 用户 foo,密码 123456,将用户信息提交到 kubernetes

$ htpasswd -c auth foo
$ kubectl -n demo-echo create secret generic basic-auth --from-file=auth

注意其中命名空间demo-echosecret 与目标服务echo在同一个 namespace 中。

为目标服务设置 ingress

注意其中的basic-auth改成你的

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-echo-with-auth-basic
  annotations:
    # type of authentication
    nginx.ingress.kubernetes.io/auth-type: basic
    # name of the secret that contains the user/password definitions
    nginx.ingress.kubernetes.io/auth-secret: basic-auth
    # message to display with an appropriate context why the authentication is required
    nginx.ingress.kubernetes.io/auth-realm: 'Authentication Required - foo'
spec:
  rules:
  - host: auth-basic.echo.example
    http:
      paths:
      - path: /
        backend:
          serviceName: echo
          servicePort: 80

访问测试

ingress-nginx

原文链接