云原生监控配置自建alertmanager实现告警
当前k8s的主流监控软件主要是prometheus，为了能够更好的监控腾讯云上的tke集群，腾讯云也推出了prometheus的服务，叫做云原生监控，云原生监控可以一键监控我们的tke集群，当然也支持配置告警，云原生监控的告警也是采用的alertmanager，这里是支持自建的和默认配置的，如果你没有自己部署alertmanager，云原生监控会在后台部署一个alertmanager来进行告警配置和发生，但是默认部署的alertmanager为了适配腾讯云，告警渠道暂时只有腾讯云的消息发生渠道和webhook。
但是有的时候我们需要将告警发生到自己的聊天软件，如slack，企业微信，邮箱等，那么这里就需要用到自建的alertmanager来实现了，今天我们来说下如何在云原生监控里面配置自建的alertmanager发生告警到我们的企业微信上。
1. 部署alertmanager
首先我们在我们的集群部署一个alertmanager，然后通过一个内网的LoadBalancer类型service来暴露服务提供给云原生监控实例进行调用。
apiVersion: apps/v1
kind: Deployment
metadata:
name: alertmanager
namespace: monitor
spec:
progressDeadlineSeconds: 600
replicas: 1
revisionHistoryLimit: 10
selector:
matchLabels:
k8s-app: alertmanager
qcloud-app: alertmanager
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
type: RollingUpdate
template:
metadata:
creationTimestamp: null
labels:
k8s-app: alertmanager
qcloud-app: alertmanager
spec:
containers:
- args:
- --config.file=/etc/alertmanager/config.yml
- --storage.path=/alertmanager/data
image: prom/alertmanager:v0.15.3
imagePullPolicy: Always
name: alertmanager
resources:
limits:
cpu: 500m
memory: 1Gi
requests:
cpu: 250m
memory: 256Mi
securityContext:
privileged: false
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts:
- mountPath: /etc/alertmanager
name: alertcfg
dnsPolicy: ClusterFirst
imagePullSecrets:
- name: qcloudregistrykey
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
volumes:
- configMap:
defaultMode: 511
name: alertmanager
name: alertcfg这里还需要部署下对应的alertmanager的configmap，这里需要配置下告警消息接受的企业微信渠道，具体企业应用申请方式可以百度下，对应的企业微信应用秘钥等获取可以参考下面注释说明，这里我是申请了个人的企业微信来测试告警接收。
apiVersion: v1
data:
config.yml: |
global:
resolve_timeout: 5m
route:
group_by: ['alertname']
group_interval: 1m
group_wait: 10s
receiver: default-receiver
repeat_interval: 1m
receivers:
- name: default-receiver
wechat_configs:
- corp_id: 'ww0c31105f29c8' # 企业信息("我的企业"--->"CorpID"[在底部])
to_user: '@all' # 所有人就是@all，或者是指定人
agent_id: '100002' # 企业微信("企业应用"-->"自定应用"[Prometheus]--> "AgentId")
api_secret: 'BXllYvWYXBy4HH9itlPzd9T-e2JfWP9E' # 企业微信("企业应用"-->"自定应用"[Prometheus]--> "Secret")
send_resolved: true #问题解决了要发信息
kind: ConfigMap
metadata:
labels:
addonmanager.kubernetes.io/mode: EnsureExists
kubernetes.io/cluster-service: "true"
name: alertmanager
namespace: monitor这里我们附上给163邮箱发生告警的配置，如果想用邮箱接受告警，可以用下面这个cm配置。
apiVersion: v1
data:
config.yml: |
global:
resolve_timeout: 5m
smtp_smarthost: 'smtp.163.com:25'
smtp_from: 'nwx_qdlg@163.com'
smtp_auth_username: 'nwx_qdlg@163.com'
smtp_auth_password: 'HYLVOJCTU' #这里的密码是邮箱的授权码，可以去邮箱设置进行获取
smtp_require_tls: false
route:
group_by: ['alertname']
group_interval: 1m
group_wait: 10s
receiver: default-receiver
repeat_interval: 1m
receivers:
- name: default-receiver
email_configs:
- to: "niewx_qdlg@163.com"
kind: ConfigMap
metadata:
labels:
addonmanager.kubernetes.io/mode: EnsureExists
kubernetes.io/cluster-service: "true"
name: alertmanager
namespace: monitor这里给alertmanager部署一个service提供给云原生监控实例访问，service部署完后，alertmanager的访问入口是10.0.0.143:9093
apiVersion: v1
kind: Service
metadata:
annotations:
service.cloud.tencent.com/direct-access: "true"
service.kubernetes.io/loadbalance-id: lb-n1jjuq
service.kubernetes.io/qcloud-loadbalancer-clusterid: cls-b3mg1p92
service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-ktam6hp8
name: alertmanager
namespace: monitor
spec:
clusterIP: 172.16.56.208
externalTrafficPolicy: Cluster
ports:
- name: 9093-9093-tcp
nodePort: 32552
port: 9093
protocol: TCP
targetPort: 9093
selector:
k8s-app: alertmanager
qcloud-app: alertmanager
sessionAffinity: None
type: LoadBalancer
status:
loadBalancer:
ingress:
- ip: 10.0.0.143到这里我们自建的alertmanager就部署完成了，下面我们来部署下对应的云原生监控实例。
2. 创建云原生监控实例
我们在容器服务的控制台点击云原生监控创建实例，这里需要点击高级设置，然后点击添加alertmanager，输入你部署的alertmanager的service访问入口10.0.0.143.9093。
这里需要注意的是现在云原生监控如果你在创建的时候选择的是默认部署的alertmanager，暂时还不支持界面切换到自建的alertmanager，如果需要切换需要提交工单找工程师进行切换，所以这里建议在创建的时候就选择自建的alertmanager。
实例创建完成后，在实例基本信息会显示你配置的自建alertmanager和prometheus等查询地址信息
3. 关联tke集群
云原生监控实例创建完之后，其实prometheus服务并未监控任何k8s集群，我们需要将tke集群来加入到我们的云原生监控进行数据采集，我们在关联集群中关联我们的tke集群即可。
关联集群后，我们可以在控制台看到我们的关联集群信息，可以点击target去查看采集状态是否健康
我们也可以到prometheus的查询界面进行数据的查询，看下tke集群的监控是否是否采集到了prometheus。
点击数据查询，如果有结果返回，说明prometheus采集tke集群的监控数据成功了。
4. 配置告警
下面我们来进行告警规则的编写和配置，我们这里测试下节点内存使用率的告警，为了能够更好触发告警，这里节点的内存使用率超过了10%，我们就来告警，首先我们在prometheus的ui页面进行promsql编写告警规则。
100 - (node_memory_MemFree_bytes{endpoint !="target"}+node_memory_Cached_bytes+node_memory_Buffers_bytes) / node_memory_MemTotal_bytes * 100 > 10
这里我们可以用上面的sql查询出内存使用率大于10%的节点，接下来我们去云原生监控的告警配置控制台配置下告警
- 规则名称：告警规则的名称，不超过40个字符。
- PromQL：告警规则语句。
- 持续时间：满足上述语句所描述的条件的时间，达到该持续时间则会触发告警。
- Label：对应每条规则添加 Prometheus 标签。
- 告警内容：告警触发后通过邮件或短信等渠道发送告警通知的具体内容，这里配置的告警内容如下
{{$labels.cluster}}的{{$labels.instance}} 节点的内存超出告警阈值10% ，当前内存使用率为 {{$value}} ，请及时关注处理！！！5. 企业微信查看告警
[FIRING:3] NodeMemoryUsage (node.rules cls-b3mg1p92 tke node-exporter kube-system mem alert-7pjasfmm tke-node-exporter)
node.rules 测试tke集群node节点内存告警 alert-7pjasfmm
Alerts Firing:
Labels:
- alertname = NodeMemoryUsage
- alertName = node.rules
- cluster = cls-b3mg1p92
- cluster_type = tke
- instance = 10.0.0.10
- job = node-exporter
- namespace = kube-system
- node = mem
- notification = alert-7pjasfmm
- pod = tke-node-exporter-xnfvb
- service = tke-node-exporter
Annotations:
- alertName = node.rules
- content = cls-b3mg1p92的10.0.0.10 节点的内存超出告警阈值10% ，当前内存使用率为 52.578219305872885 ，请及时关注处理！！！
- describe = 测试tke集群node节点内存告警
- notification = alert-7pjasfmm
Source: /graph?g0.expr=100+-+%28node_memory_MemFree_bytes%7Bendpoint%21%3D%22target%22%7D+%2B+node_memory_Cached_bytes+%2B+node_memory_Buffers_bytes%29+%2F+node_memory_MemTotal_bytes+%2A+100+%3E+10&g0.tab=1
Labels:
- alertname = NodeMemoryUsage
- alertName = node.rules
- cluster = cls-b3mg1p92
- cluster_type = tke
- instance = 10.0.0.157
- job = node-exporter
- namespace = kube-system
- node = mem
- notification = alert-7pjasfmm
- pod = tke-node-exporter-vcnjl
- service = tke-node-exporter
Annotations:
- alertName = node.rules
- content = cls-b3mg1p92的10.0.0.157 节点的内存超出告警阈值10% ，当前内存使用率为 34.298334259939 ，请及时关注处理！！！
- describe = 测试tke集群node节点内存告警
- notification = alert-7pjasfmm
Source: /graph?g0.expr=100+-+%28node_memory_MemFree_bytes%7Bendpoint%21%3D%22target%22%7D+%2B+node_memory_Cached_bytes+%2B+node_memory_Buffers_bytes%29+%2F+node_memory_MemTotal_bytes+%2A+100+%3E+10&g0.tab=1
Labels:
- alertname = NodeMemoryUsage
- alertName = node.rules
- cluster = cls-b3mg1p92
- cluster_type = tke
- instance = 10.0.0.3
- job = node-exporter
- namespace = kube-system
- node = mem
- notification = alert-7pjasfmm
- pod = tke-node-exporter-vpcmf
- service = tke-node-exporter
Annotations:
- alertName = node.rules
- content = cls-b3mg1p92的10.0.0.3 节点的内存超出告警阈值10% ，当前内存使用率为 31.307402547932455 ，请及时关注处理！！！我们到我们的企业微信中prometheus应用查看下告警是否发生，查看是可以收到告警信息的，说明我们已经成功通过自建的alertmanager发生告警到企业微信成功。
6. 邮箱接收告警
下面我们将告警的阈值改为内存使用率超过50%，集群的alertmanagerconfigmap改成邮箱的配置信息，用邮箱接受告警看看是什么样，这里默认应该只有一个节点会发送告警，下面我们测试下。
从上面的promsql查询结果看，只有10.0.0.10内存使用率超过了50%，所以我们的邮件只收到10.0.0.10这个节点的告警邮件，说明通过alertmanager发送告警到我们邮箱已经成功。
