设计网站需要哪些流程,可以赚钱做任务的网站,小程序登录后怎么退出,黄埔网站建设哪家好作者#xff1a;向军涛、雷万钧 来源#xff1a;2023 上海 KubeCon 分享 可观测性来源
在 Kubernetes 集群上#xff0c;各个维度的可观测性数据#xff0c;可以让我们及时了解集群上应用的状态#xff0c;以及集群本身的状态。 Metrics 指标#xff1a;监控对象状态的量… 作者向军涛、雷万钧 来源2023 上海 KubeCon 分享 可观测性来源
在 Kubernetes 集群上各个维度的可观测性数据可以让我们及时了解集群上应用的状态以及集群本身的状态。 Metrics 指标监控对象状态的量化信息通常会以时序数据的形式采集和存储。Events这里特指的是 Kubernetes 集群上所报告的各种事件他们是以 Kubernetes 资源对象的形式存在。Auditing审计是与用户 API 和安全相关的一些事件。Logs日志是应用和系统对它们内部所发生各种事件的详细记录。Traces链路主要记录了请求在系统中调用时的链路信息。
告警规则
接下来介绍一下几个可观测性维度上我们是如何实现告警的。
metrics
在云原生监控领域Prometheus 是被广泛使用的它可以说是一个事实上的标准。
对于一个单独的集群来说或者说是集群自己管理指标存储的场景我们直接部署一个 Prometheus就可以提供指标采集、存储、查询和告警的功能。当然也可以额外部署一个 Ruler 组件来专门进行规则的评估和告警这样可以减轻 Prometheus 组件的负担。 我们还会面临指标数据托管的场景因为有一些集群会有轻量化的需求它需要将指标数据托管到一个 host 集群上或者是托管到专门的服务上。
Prometheus 是支持 Agent 模式的这个模式下的 Prometheus 可以将指标进行采集然后推送到一个主集群上进行存储。在主集群上我们需要提供指标存储和查询的功能当然告警也需要在主集群上进行这时候的告警不只是要实现针对每个集群的单独告警还需要支持多集群关联告警。 Prometheus Operator 作为管理 Prometheus 的 Kubernetes 原生方式为部署和配置 Prometheus 提供了极大的便利。比如 Prometheus Operator 定义了一个 ServiceMonitor CRD我们可以用它来方便的配置拉取指标的 targets。
另外 Prometheus Operator 还定义了一个 PrometheusRule CRD 来配置告警规则但目前仍然存在一些不足
配置粒度大导致对并发更新的支持不足。可配置性不够比如不支持禁用告警规则。对多租户和多集群场景的支持较差。
为了让规则配置更加灵活并且能够更好的应用到多集群和多租户的场景我们引入了三个新的 CRDs。这些 CRDs 以规则组为配置单元配置粒度更加细化可配置性也得到了增强。
RuleGroup项目级别的资源只对所在项目的指标生效。ClusterRuleGroup集群级别的资源其生效范围是其实例所在集群的指标。GlobalRuleGroup特殊资源支持对多个指定集群的指标生效。 上方是 RuleGroup 的一个实例。
每个规则组都是一个配置单元可以包含有关联关系的多个规则。
在单个规则的结构上我们保留了 PrometheusRule CRD 中原始的规则结构以确保和上游 PrometheusRule 的兼容性。
在 RuleGroup 的实例当中我们可以通过设置一个资源标签来启用或者禁用整个规则组也可以在规则配置中进行单个规则的禁用或启用。
另外我们还提供了一个 exprBuilder以针对一些典型的告警场景通过简单的配置即可进行规则表达式的自动化构建。
exprBuilder 提供了配置 Prometheus 查询表达式的便捷方法涵盖了工作负载和节点的各种指标告警。
工作负载 类型Deployment、StatefulSet、DaemonSet。指标工作负载的 CPU、内存、网络和副本。 节点不适用于 RuleGroup 实例 指标节点的 CPU、内存、网络、磁盘、pod 使用率等。
RuleGroupClusterRuleGroup 和 GlobalRuleGroup 的实例可以组合成 PrometheusRule 的实例。在此过程中会添加一些指标数据访问的限制。比如 RuleGroup 被合并生成到 PrometheusRule 实例中时它会将 exprBuilder 构建成 Prometheus 查询表达式同时也会将 namespace 的条件注入到表达式中以限制规则可以访问的指标。 在多集群告警的场景下还会涉及到 PrometheusRule 的跨集群同步。在这个同步过程中我们会将 cluster 条件注入规则表达式中这样可以限制规则访问的集群指标。 无论采用哪种指标存储管理模式在数据侧评估告警规则的效率会更高。如果一个集群自己管理指标存储那么同一集群的 Ruler 可以直接加载这些规则然后进行评估和告警RuleGroup 和 ClusterRuleGroup 的更新也会及时反馈到 Ruler 组件内部。 如果一个集群将指标数据托管到一个主集群上在这个集群上仍然会有 RuleGroup 和 ClusterRuleGroup 合并生成 PrometheusRule 的过程不过生成的 PrometheusRule 会被同步到主集群上由主集群的 Ruler 进行评估和告警。这是因为在同步的过程中规则表达式中已经注入了 cluster 的过滤条件所以能够正常的对该集群的指标数据进行评估并决定是否告警。
如果有多个集群将数据托管到一个主集群上那么可以在主集群上配置多个 Ruler 来分担压力。在 KubeSphere 的某些版本中可以根据多集群的规模来动态的扩展 Ruler 以及相关的查询组件以确保告警评估过程高效运行。 由新定义的规则资源触发的告警不仅包含指标标签还将通过以下标签丰富告警信息以方面故障定位
alerttype区分不同的告警来源。cluster用于多集群方案快速定位告警对象。severity对告警执行分级控制。rule_group在规则组和告警之间建立有效的关系。rule_level在规则组和告警之间建立有效的关系。
events
接下来介绍一下事件告警规则的实现方式。
Kubernetes 事件通常表示集群中的某些状态变化作为 Kubernetes 资源对象其保留时间有限。kube-events 项目中的 exporter 组件可以导出这些事件进行长期存储并通过评估事件规则生成与 Alertmanager 兼容的告警。这些规则可以过滤掉告警、关键事件或者用户感兴趣的事件。
事件规则 CRD 定义了基于事件的告警配置
condition它类似于一个 sql 语句的 where 部分通过我们实现的 event-rule-engine 来提供语法支持用于支持更灵活的事件过滤方式。labels添加到告警中的额外标签。annotations关于告警的详细信息。 在 KubeSphere 中事件规则实例中的 kubesphere.io/rule-scope 标签可用于限制规则的生效范围
cluster适用于集群中的所有事件。workspace适用于属于同一工作区的多个命名空间中的事件。必须在规则实例中指定 workspace 标签。namespace规则实例所在的 namespace 需要与事件涉及对象所在的 namespace 相匹配。
audit events
接下来介绍一下审计告警规则的实现方式。
在 Kubernetes 集群中是通过审计事件记录了所有 API 的调用包含了请求响应信息和用户信息。审计组件在提供审计导出功能的时候还可以根据相关的规则进行灵活的配置。
审计规则 CRD 定义了过滤审计事件的配置这些事件将被长期存储或生成告警发送给用户。每个审计规则实例可包含多个规则。
定义了四种类型的规则
rule真正完整的规则带有条件字段也是之前的类似 sql 的表达式。macro精简规则可被其他宏或规则调用。list列表可被宏或规则调用。alias只是一个变量的别名。
如何配置接收告警通知
所有的告警都将通过通知系统实时准确地发送给用户。KubeSphere 团队开源的 Notification Manager 是一个多租户的云原生通知管理工具它支持多种通知渠道比如微信、钉钉、飞书、邮件、Slack、Pushover、WeCom、Web hook 以及短信平台阿里、腾讯、华为等等。
下面就来通过 Notification Manager快速地搭建出一套云原生的多租户通知系统。
Notification Manager 会接收来自 Prometheus、Alertmanager 发出的警告消息、K8s 产生的审计消息以及 K8s 本身的事件。在规划中我们还会实现接入 Prometheus 的告警消息和接入 Cloud Event 。消息在进入缓存之后会经过静默、抑制、路由、过滤、聚合最后进行实际的通知并记录在历史中。 下面是对每个步骤的解析
静默Silence
静默的作用是在特定的时间段阻止特定的告警发送具有时效性。可以通过配置时间段或者 Cron 表达式来设置静默规则的生效时间。当然也可以设置永久生效的静默规则。
静默规则有两种级别全局级别和租户级别。全局级别的静默规则作用于所有的告警租户级别的租户级别只作用于需要发送给某个租户的告警。
抑制Inhibit
抑制的作用是通过某些特定的告警去阻止其他告警的发送。一个节点宕机之后会发送大量告警而这些告警不利于我们排查原因我们可以通过设置抑制规则不再发送这部分告警给用户。
路由Route
告警、事件、审计都是由一个个标签组成的路由的本质就是根据标签寻找需要接收标签的接收器。换句话说路由的作用就是根据告警信息去寻找要把告警发送给哪个用户用户又通过什么方式去接收告警。
那么如何去定义用户接收告警的方式
Notification Manager 引入了一个 Receiver 的概念。
Receiver 用于定义通知格式和发送通知的目的地。接收器包含以下信息通知渠道信息如电子邮件地址、Slack channel 等生成通知消息的模板过滤告警的标签选择器。
Receiver 分为两类全局级别和租户级别。
全局级别的 Receiver 会接收所有的告警消息租户级别的 Receiver 只会接收租户有权限访问的 namespace 下产生的告警消息。
有两种方式把告警和 Receiver 匹配起来
路由匹配用户可以制定一个路由规则然后把特定的告警路由到特定的 Receiver 上。根据 namespace 标签匹配对于没有 namespace 标签的告警会全部发送到全局级别的 Receiver对于有 namespace 标签的告警会根据标签的值发送到有权限访问 namespace 租户创建的 Receiver 上。
这是一个路由规则我们可以通过标签选择器去选择需要路由的告警然后可以把这些告警路由到指定租户的所有 Receiver 上或者把它路由到某一个指定的 Receiver 上。更进一步我们可以选择某一些类型的 Receiver比如我们可以把告警路由到所有的 Email Receiver而不把它路由到 wechat Receiver。 对于这两种模式有三种协同方式分别是
All同时使用两种方式匹配。路由优先优先使用路由规则匹配未匹配成功的使用自动匹配。只使用路由使用路由规则未匹配到 Receiver则不发送通知。
过滤Filter
每个用户对告警的需求是不一样的我们需要为每个选定的 Receiver 过滤掉无效或不感兴趣的告警。这就是 Filter 的作用。
实现 Filter 的方式有两种一种是通过在 Receiver 中设置标签选择器过滤掉不重要的通知对于单个通知有效另一种是定义租户级别的静默规则对部分通知进行静默。
聚合Aggregation
告警匹配到了对应的 Receiver就可以通过设定的规则将同一 Receiver 需要发送的告警做一个聚合。
聚合的作用有两个
聚合告警消息便于归档方便用户定位故障。减少调用频次避免被微信、钉钉等禁言节省资源。
模板Template
到了这一步告警发送之前的所有准备工作已经完成了接下来就要向用户发送通知。
首先我们需要根据告警消息生成一条通知消息根据不同的 Receiver 生成不同的消息。我们支持用户自定义通知模板用户可以定义全局模板也可以为每个接收者定义模板。同时我们支持用户自定义语言包然后实现语言切换。Notification Manager 为大家提供了内置的相关函数可以实现语言的翻译功能。
Config
现在一切都准备就绪是时候向用户发送通知了但我们还缺少一些关键信息例如SMTP 服务器和用于发送电子邮件的电子邮件地址用于向 Slack 频道发送通知的 Slack APP 令牌飞书的 AppID 和 AppSecret因此我们需要定义这些信息。
Config 就是用来定义发送通知消息所必需的一些信息的同样分为全局类型和租户类型两种。
对于全局级别的 Receiver默认情况下会选择全局级别的 Config。对于租户级别的 Receiver默认选择当前租户的创建的 Config。如果当前租户未创建 Config会选择全局级别的 Config。
同时也支持 Receiver 通过标签选择器去指定 Config。
通过发送配置和接收配置分离的模式我们可以最大限度的实现配置复用同时可以实现多租户的通知设置。 举个简单的例子比如对邮箱这种通知模式整个公司可能只有一个 SMTP 服务器这样就可以设置一个全局级别的 Email Config然后所有的租户只配置一个 Receiver 就可以了。
至此我们就完整的搭建了一个多租户的云原生通知系统然后就可以给用户发送通知了。 本文由博客一文多发平台 OpenWrite 发布
