扩展AlertManager集成钉钉助力Istio on ACK可观测性监控能力

本文涉及的产品
性能测试 PTS,5000VUM额度
可观测监控 Prometheus 版,每月50GB免费额度
应用实时监控服务-用户体验监控,每月100OCU免费额度
简介: 阿里云容器服务Kubernetes(简称ACK)支持一键部署Istio,可以参考[文档](https://help.aliyun.com/document_detail/89805.html)在ACK上部署使用Isito。Istio on ACK提供了丰富的监控能力,为网格中的服务收集遥测数据,其中Mixer是负责提供策略控制和遥测收集的Istio组件。使用Prometheus进行监控是Istio

阿里云容器服务Kubernetes(简称ACK)支持一键部署Istio。Istio on ACK提供了丰富的监控能力,为网格中的服务收集遥测数据,其中Mixer是负责提供策略控制和遥测收集的Istio组件。使用Prometheus进行监控是Istio提供的监控能力之一。

告警能力在Prometheus的架构中被划分成两个独立的部分:Prometheus负责产生告警,而Alertmanager负责告警产生后的后续处理。如下所示,通过在Prometheus中定义告警规则,Prometheus会周期性的对告警规则进行计算,如果满足告警触发条件就会向Alertmanager发送告警信息。
图片.png

Alertmanager作为一个独立的组件,负责接收并处理来自Prometheus Server(也可以是其它的客户端程序)的告警信息。Alertmanager可以对这些告警信息进行进一步的处理,比如当接收到大量重复告警时能够消除重复的告警信息,同时对告警信息进行分组并且路由到正确的通知方,Prometheus内置了对邮件、Slack等多种通知方式的支持,同时还支持与Webhook的集成,以支持更多定制化的场景。例如,完全可以通过Webhook与钉钉机器人进行集成,从而通过钉钉接收告警信息。同时AlertManager还提供了静默和告警抑制机制来对告警通知行为进行优化。

以下介绍如何扩展AlertManager集成钉钉,并通过AlertManager帮助实现Istio on ACK在可观测性监控方面的能力。

通过Webhook集成钉钉

    1. 单击钉钉群右上角群设置图标,进入群设置页面。单击群机器人,进入群机器人页面,选择需要添加的机器人。此处选择自定义机器人。
    1. 在机器人详情页面,单击添加,进入添加机器人页面。

图片.png

    1. 填写完配置群机器人信息后,单击完成添加。
    1. 单击复制,复制webhook地址。

图片.png

部署AlertManager并对接钉钉

    1. 登录容器服务管理控制台。 在Kubernetes菜单下,单击左侧导航栏中的应用 > 无状态,进入 无状态(Deployment)页面。
    1. 选择目标集群,命名空间选为istio-system,单击右上角使用模板创建。
    1. 根据以下信息配置模板,完成后单击创建。
配置 说明
集群 选择目标集群。
命名空间 选择资源对象所属的命名空间,默认是 default。此处选择istio-system。
示例模板 此处选择自定义。
模板 填写以下自定义内容。

自定义YAML内容如下:

apiVersion: v1
kind: Service
metadata:
  name: dingtalkservice
  labels:
    app: dingtalkservice
    service: dingtalkservice
spec:
  ports:
  - port: 8060
    name: http
  selector:
    app: dingtalkservice
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: dingtalkservice
  labels:
    app: dingtalkservice
    version: v1
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: dingtalkservice
        version: v1
    spec:
      containers:
      - name: prometheus-webhook-dingtalk
        image: timonwong/prometheus-webhook-dingtalk
        imagePullPolicy: IfNotPresent
        args:
        - --ding.profile=webhook1={替换为上述步骤中复制的webhook地址}
        ports:
        - containerPort: 8060
---
kind: ConfigMap
apiVersion: v1
metadata:
  name: alertmanager
data:
  config.yml: |-
    global:
      resolve_timeout: 5m
    templates:
    - '/etc/alertmanager-templates/*.tmpl'
    route:
      group_by: ['alertname', 'cluster', 'service']
      group_wait: 30s
      group_interval: 5m
      repeat_interval: 1m
      receiver: webhook_alert 
      routes:
      - match:
          severity: info
        receiver: webhook_alert
      - match:
          severity: warning
        receiver: webhook_alert
    receivers:
    - name: webhook_alert
      webhook_configs:
      - url: 'http://dingtalkservice:8060/dingtalk/webhook1/send'
        send_resolved: false
---
apiVersion: v1
kind: Service
metadata:
  annotations:
    prometheus.io/scrape: 'true'
    prometheus.io/path: '/metrics'
  labels:
    name: alertmanager
  name: alertmanager
spec:
  selector:
    app: alertmanager
  type: ClusterIP
  ports:
  - name: alertmanager
    protocol: TCP
    port: 9093
    targetPort: 9093
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: alertmanager
spec:
  replicas: 1
  selector:
    matchLabels:
      app: alertmanager
  template:
    metadata:
      name: alertmanager
      labels:
        app: alertmanager
    spec:
      containers:
      - name: alertmanager
        image: prom/alertmanager:v0.15.0
        args:
          - '--config.file=/etc/alertmanager/config.yml'
          - '--storage.path=/alertmanager'
        ports:
        - name: alertmanager
          containerPort: 9093
        volumeMounts:
        - name: config-volume
          mountPath: /etc/alertmanager
        - name: alertmanager
          mountPath: /alertmanager
      serviceAccountName: prometheus
      volumes:
      - name: config-volume
        configMap:
          name: alertmanager
      - name: alertmanager
        emptyDir: {}    
    1. 创建成功之后,单击左侧导航栏中的应用 > 容器组,选择相应的集群和命名空间istio-system, 可以看到如下类似的运行中的alertmanager和dingtalkservice容器组。

图片.png

创建Prometheus告警规则配置项

    1. 登录 容器服务管理控制台。在Kubernetes菜单下,单击左侧导航栏中的应用配置 > 配置项,选择相应的集群与命名空间istio-system,点击右上角的创建按钮,进入创建配置项页面。
    1. 输入配置项名称:prom-rules1。
    1. 添加配置项,名称为rule1.yaml,值为如下内容:
groups:
- name: fake
  rules:
    - alert: rules-alert
      expr: |
        histogram_quantile(0.99, sum by(source_app, source_version, destination_service, destination_version, le) (irate(istio_request_duration_seconds_bucket[1m])) ) > 3
      for: 1m
      labels:
        alertname: "request-duration-3"
      annotations:
        summary: "Request duration gt 3"
        from: "{{ $labels.source_app }}:{{ $labels.source_version }}"
        to: "{{ $labels.destination_service }}:{{ $labels.destination_version }}"

该规则描述过去1分钟内99%请求时延超过3s时会发出告警。

    1. 点击确定按钮。

集成AlertManager到Istio中

阿里云容器服务Kubernetes(简称ACK)支持一键部署Istio。
默认部署中的Prometheus服务没有对接AlertManager,需要按照如下步骤进行配置。

    1. 登录容器服务管理控制台。
    1. 在 Kubernetes 菜单下,单击左侧导航栏的应用 > 发布,进入发布页面。
    1. 单击Helm,选择所需的集群,选择待更新的Istio,单击操作列的更新。

图片.png

    1. 在弹出的对话框中,对Istio的Prometheus参数进行修改:
配置 说明
enabled true或者false,表示是否启用Prometheus 收集度量日志。默认情况下启用,即值为true。
replicaCount prometheus容器组的副本数,默认值为1。
persist true或者false,表示是否启用持久化存储。设置为true时,必须指定TSDB实例地址。
tsdbEndpoint TSDB实例地址,启用持久化存储时必须指定。
retention 默认的数据保留时间,8760h0m0s即为24*365小时,即1年
scrapeInterval 全局默认抓取时间间隔,默认为15s
prometheusRulesConfigMap 告警规则配置项的名称
alerting 配置对接的AlertManager服务,配置如下代码所示
  alerting:
    alertmanagers:
    - static_configs:
      - targets: ["alertmanager:9093"]

图片.png

    1. 修改完毕之后,单击更新

告警规则触发验证

在Prometheus控制台上,点击Alerts页签,可以看到如下类似内容。
图片.png

同时,相应的钉钉群也会收到类似的告警信息,如下所示。
图片.png

总结

在阿里云Kubernetes容器服务基础之上,快速搭建一套用于连接、管理以及安全化微服务的开放平台Istio,为应用引入和配置多个相关服务。使用Prometheus进行监控是Istio提供的监控能力之一,通过扩展AlertManager集成钉钉助力Istio on ACK可观测性监控能力。

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
14天前
|
监控 jenkins Linux
从 Jenkins 持续集成出发:探究如何监控员工电脑屏幕
Jenkins 在企业信息化管理中用于自动化构建、测试和部署,提高开发效率。本文讨论了其重要性,并从技术角度探讨了屏幕监控的可能性,但明确反对非法监控,强调应合法合规地管理企业和尊重员工隐私。
56 12
|
28天前
|
存储 Prometheus 运维
在云原生环境中,阿里云ARMS与Prometheus的集成提供了强大的应用实时监控解决方案
在云原生环境中,阿里云ARMS与Prometheus的集成提供了强大的应用实时监控解决方案。该集成结合了ARMS的基础设施监控能力和Prometheus的灵活配置及社区支持,实现了全面、精准的系统状态、性能和错误监控,提升了应用的稳定性和管理效率。通过统一的数据视图和高级查询功能,帮助企业有效应对云原生挑战,促进业务的持续发展。
34 3
|
29天前
|
开发框架 JavaScript 前端开发
TypeScript 是一种静态类型的编程语言,它扩展了 JavaScript,为 Web 开发带来了强大的类型系统、组件化开发支持、与主流框架的无缝集成、大型项目管理能力和提升开发体验等多方面优势
TypeScript 是一种静态类型的编程语言,它扩展了 JavaScript,为 Web 开发带来了强大的类型系统、组件化开发支持、与主流框架的无缝集成、大型项目管理能力和提升开发体验等多方面优势。通过明确的类型定义,TypeScript 能够在编码阶段发现潜在错误,提高代码质量;支持组件的清晰定义与复用,增强代码的可维护性;与 React、Vue 等框架结合,提供更佳的开发体验;适用于大型项目,优化代码结构和性能。随着 Web 技术的发展,TypeScript 的应用前景广阔,将继续引领 Web 开发的新趋势。
37 2
|
1月前
|
传感器 前端开发 Android开发
在 Flutter 开发中,插件开发与集成至关重要,它能扩展应用功能,满足复杂业务需求
在 Flutter 开发中,插件开发与集成至关重要,它能扩展应用功能,满足复杂业务需求。本文深入探讨了插件开发的基本概念、流程、集成方法、常见类型及开发实例,如相机插件的开发步骤,同时强调了版本兼容性、性能优化等注意事项,并展望了插件开发的未来趋势。
40 2
|
1月前
|
SQL 开发框架 .NET
突破T-SQL限制:利用CLR集成扩展RDS SQL Server的功能边界
CLR集成为SQL Server提供了强大的扩展能力,突破了T-SQL的限制,极大地拓展了SQL 的应用场景,如:复杂字符串处理、高性能计算、图像处理、机器学习集成、自定义加密解密等,使开发人员能够利用 .NET Framework的丰富功能来处理复杂的数据库任务。
|
3月前
|
监控 关系型数据库 MySQL
zabbix agent集成percona监控MySQL的插件实战案例
这篇文章是关于如何使用Percona监控插件集成Zabbix agent来监控MySQL的实战案例。
83 2
zabbix agent集成percona监控MySQL的插件实战案例
|
4月前
|
监控 前端开发 JavaScript
ARMS集成监控代码
【8月更文挑战第24天】
89 6
|
4月前
|
缓存 安全 Java
Java服务器端技术:Servlet与JSP的集成与扩展
Java服务器端技术:Servlet与JSP的集成与扩展
42 3
|
4月前
|
存储 Prometheus 监控
Grafana 与 Prometheus 集成:打造高效监控系统
【8月更文第29天】在现代软件开发和运维领域,监控系统已成为不可或缺的一部分。Prometheus 和 Grafana 作为两个非常流行且互补的开源工具,可以协同工作来构建强大的实时监控解决方案。Prometheus 负责收集和存储时间序列数据,而 Grafana 则提供直观的数据可视化功能。本文将详细介绍如何集成这两个工具,构建一个高效、灵活的监控系统。
505 1
|
3月前
|
运维 Kubernetes 监控
Loki+Promtail+Grafana监控K8s日志
综上,Loki+Promtail+Grafana 监控组合对于在 K8s 环境中优化日志管理至关重要,它不仅提供了强大且易于扩展的日志收集与汇总工具,还有可视化这些日志的能力。通过有效地使用这套工具,可以显著地提高对应用的运维监控能力和故障诊断效率。
393 0