**：
重點：
apiversion: v1
kind: configmap
metadata:
name: alert-config
namespace: kube-ops
data:
config.yml: |-
global:
# 在沒有報警的情況下宣告為已解決的時間
resolve_timeout: 5m # 配置郵件傳送資訊
smtp_smarthost: 'smtp.163.com:25'
smtp_from: '[email protected]'
smtp_auth_username: '[email protected]'
smtp_auth_password: '《郵箱驗證碼》'
smtp_hello: '163.com'
smtp_require_tls: false
# 所有報警資訊進入後的根路由，用來設定報警的分發策略
route:
# 這裡的標籤列表是接收到報警資訊後的重新分組標籤，例如，接收到的報警資訊裡面有許多具有 cluster=a 和 alertname=latncyhigh 這樣的標籤的報警資訊將會批量被聚合到乙個分組裡面
group_by: ['alertname', 'cluster']
# 當乙個新的報警分組被建立後，需要等待至少group_wait時間來初始化通知，這種方式可以確保您能有足夠的時間為同一分組來獲取多個警報，然後一起觸發這個報警資訊。
group_wait: 30s
# 當第乙個報警傳送後，等待'group_interval'時間來傳送新的一組報警資訊。
group_interval: 5m
# 如果乙個報警資訊已經傳送成功了，等待'repeat_interval'時間來重新傳送他們
repeat_interval: 5m
# 預設的receiver：如果乙個報警沒有被乙個route匹配，則傳送給預設的接收器
receiver: default
# 上面所有的屬性都由所有子路由繼承，並且可以在每個子路由上進行覆蓋。
routes:
- receiver: email
group_wait: 10s
match:
team: node
receivers:
- name: 'default'
email_configs:
- to: '[email protected]'
send_resolved: true
- name: 'email'
email_configs:
- to: '[email protected]'
send_resolved: true
alertmanager郵件告警
alertmanager郵件告警 這篇文章是基於之前部落格進行開展的 關於計畫任務的乙個小需求 利用了prometheus 下 process exporter對crond計畫任務程序監控的，grafana內建的監控報警有點醜，如下圖 而且配置不夠靈活，沒有分組，靜默等東西配置。所以就有了這個ale...
Alertmanager告警規則編寫案例（十二）
首先要將一些類似的監控項規劃到乙個分組，在定義表示式 告警級別 告警詳細內容，在告警詳細內容中一定要熟練使用監控項自身的標籤，這樣就可以在告警內容中讓管理員一眼知道什麼觸發了告警 expr指定表示式，在使用邏輯符號匹配閾值 告警內容中要熟練運用各種標籤，標籤都是監控項中自帶的，value標籤就是當前...
spring boot mybatis配置檔案開發
之前寫了乙個註解版開發的，現在在乙個配置檔案開發。我直接把 貼下面 根據id查詢單個資訊 public orders getorders integer id 新增單個資訊 mybatis config.xml的配置 insert into orders user id,number,oreatet...