大家下午好自我介绍一下我是向军涛来自青云科技今天我会和我的同事雷万军一起为大家分享一个议题一匹的名字是使用Kubernetes的原生方式实现多机群告警我们会分为三个部分为大家介绍首先是简要介绍一下Kubernetes机群上可观测性的几个维度它们是告警的数据来源然后是在几个可观测性维度上我们是如何实现告警的最后介绍一下如何配置接收告警通知在Kubernetes机群上各个维度的可观测性数据可以让我们其实的了解机群上应用的状态以及机群本身的状态Messick指标它是监控对相状态的量化信息通常会实施数据的形式采集和存储Event这里特指的是Kubernetes机群上所报告的各种事件它们是以Kubernetes支援对相的形式存在然后是Auditing 审计它是与用户API和安全相关的一些事件Logs日治是应用和系统对它们内部所发生各种事件的详细记录Trace 链路它主要记录了请求在系统中调用时的链路信息接下来介绍一下几个可观测性维度上我们是如何实现告警的首先是指标这个维度我们知道在云原生监控领域普伦米修是被广泛使用的它可以说是一个事实上的标准对于一个单独的机群来说或者说是机群自己管理指标存储的场景我们可以直接部署一个普伦米修就可以提供指标采集存储和查询告警的功能当然我们也可以额外部署一个Ruler的组件来专门进行规则的评估和告警这样可以减轻普伦米修师组件的负担当然我们还会面临指标数据拖管的场景因为有一些机群会有清亮化的需求它需要将指标数据拖管到一个House的机群上或者是拖管到专门的服务上因为普伦米修师他是支持AZIN的模式的这个模式下的普伦米修师他主要提供了指标的采集然后会推送到一个组继群上进行存储在组继群上我们需要提供指标的存储和查询的功能当然告警也需要在组继群上进行这时候的告警就不只要实现针对每个机群的单独告警还需要支持多机群关联告警在Kubernetes机群让我们通常是使用普伦米修师operator来管理普伦米修师普伦米修师operator可以让我们非常方便的部署和配置普伦米修师比如普伦米修师operator他定义了一个Service Monitor这个CRD我们可以用它来方便地配置拉取指标的target然后他还定义了普伦米修师入CRD它可以用来配置规则当我们在使用普伦米修师入来配置告警规则的时候也遇到了一些问题右侧图是一个普伦米修师入的实力我们可以看到它的配置力度会比较大一个实力当中可以配置多个规则组当我们同时更新一个实力的多个规则组的时候它就会有并发的问题然后是可配置性不够在实际的我们配置告警规则进行告警生效后然后通常还会有进用规则的时候或者是进用之后在启用的需求这时候我们就需要提供我们就需要有一个配置可以去进用这个规则另外就是在多组互和多集群的场景下使用普伦米修制度这个CRD我们不能很好的去控制它规则生效的范围所以为了让规则配置更加灵活并且能够更好地应用到多集群和多组互的场景我们引入了三个新的CRD然后它们是以规则组为配置单元它的那个配置力度细化了然后可配置性也得到了增强第一个是Rook Group它是一个项目级别的资源它只会对它所在项目的指标生效第二个Cluster Rook Group它是一个Cluster级别的资源它的生效范围是实力所在的集群的指标另外还定义了一个Global Rook Group它是一个特殊的资源它可以支持对多个指定集群的指标生效右侧图它是Rook Group的一个实力这里每个这里的这个Group这个规则组是一个配置单元它可以包含有关联关系的多个规则在单个规则的结构上我们是保留了普伦米就是入CRD当中的规则结构的这是为了保持和普伦米修饰入的兼容性然后在Rook Group的实力当中我们可以通过设置一个资源标签来启用或者禁用整个规则组也可以在规则配置当中进行单个规则的禁用或者启用另外我们还提供了一个Expressing Builder它可以针对一些典型的告警场景通过简单的配置来进行规则表达式的自动构建这个Expressing Builder它主要覆盖了一些对节点和工作负载的各种指标进行告警的场景在工作负载方面主要支持Department, State of the setDemon set这些工作负载类型然后它的指标告警的指标可以是CPU内存和网络方面的指标也可以是工作负载的比如说副本异常率的这类指标然后节点方面主要是支持Cluster Group和Global Group这两种支援类型指标可以是节点的CPU内存网络和存储等方面的指标也可以是节点的比如说POD的使用率这类指标在我们的实现当中Cluster Group和Global Group它是可以合并生成为普伦比修斯路的实力的在这个过程当中一些指标数据访问的限制会被添加到规则里面比如说Rook Group它被合并生成到普伦比修斯路实力的时候除了它会将Expressing Builder构建成表达式之外它还会将Lim Space的条件注入到表达式当中这样能够限制这个规则它可以访问的指标另外在多集群高级的场景下还会涉及到普伦比修斯路的跨集群同步在这个同步过程中我们也会将Cluster条件注入到规则表达式当中这样可以限制规则访问的集群指标然后不管是哪种指标存储的管理模式高级规则的评估一般最好是在数据这一次进行如果一个集群它是自己管理指标自己管理指标存储在Rook Group和Cluster Rook Group合并生成普伦比修斯路实力之后它就可以被同一集群的Rook Group直接加载这些规则进行评估和高级Rook Group和Cluster Rook Group的更新也会及时地反馈到Rook Group的组件内部如果一个集群它将指标数据拖管到一个组集群上在这个集群上仍然会有Rook Group和Cluster Rook Group合并生成普伦比修斯路的过程不过生成的普伦比修斯路它会被同步到组集群上由组集群的Ruler进行评估和高级由于同步的过程中规则表达是当中已经注入了Cluster Rook Group的条件所以能够正常地对该集群的指标数据进行评估决定是否高级通常会有多个集群将数据拖管到一个组集群上这时候组集群可以配置多个Ruler来分担压力固批Sphere的一些版本上它可以根据多集群的规模来动态的扩展Ruler以及相关的查询组件然后这样可以确保高级评估过程可以高效地运行由指标产生的高整消息通常会包含指标的一些标签这标签它可以反映高警对象的信息由于高警它不止来自于监控指标所以我们引入了一个Alert Type的标签然后可以标记高警来源的类型在多集群模式下高警消息的Cluster标签这个是可以方便我们快速地定位高警对象然后下边的Rule Group和Rule Lever标签它可以将高警消息和我们前面定义的规则组实力跟好的关联起来在那个高警我们收到高警通之后可以我们不仅可以促至高警对象然后也可以方便地对规则组或者规则进行优化接下来介绍一下事件高警规则的实现方式我们知道Cobalitis Event通常反映了Cobalitis集群对一些关键性状态变化它们是以Cobalitis对象的形式存在但是通常保留时间有限我们的Cobalitis项目中Exporter组建可以将这些Event导出来然后进行长期存储Rule Lever组建这可以针对这些Event的进行高警它支持配置专门的事件规则然后可以过滤出一些关键性的事件或者是用户感兴趣的事件然后以高警消息的形式通知给用户这里我们的事件规则是通过一个Rule CRD来进行定义的右侧图是一个规则的势力然后规则中有一个关键的属性Condition它类似于一个撕口语句的Ware部分然后它的语法是由我们的Event Rule engine然后提供支持的它能够以一种非常灵活的方式来过滤事件它的Lever是可以配置一些额外的标签这些标签会被添加到高警消息当中然后Lotting是主要用来配置高警的详细信息它们的Values是可以被模板化的然后用2%可以直接调用Event对象中的制断属性在事件规则中我们支持通过一个Rule Scope的标签来限制规则的生效范围常规的是Lames-based和Class-2级别的规则Lames-based级别表示规则实力规则实力所在的Lames-based需要与Event设计的对象所在的Lames-based要相匹配然后Class-2级别表示对所在集群的所有Event级别都生效比较特别的是有一个Walk-space级别Walk-space它在Coupis Field当中是组织多个Lames-based的一个逻辑单元在规则中我们添加这样一个Walk-space的标签然后这个规则就可以只对这个Walk-space下所有的Lames-based事件都生效然后接下来介绍一下关于省级高级规则的实现方式在Coupalitis集群中它是通过省级事件记录了所有API的调用包含了请求响应信息和用户的一些信息我们的省级组建在提供省级导出的功能的时候还可以根据相关的规则进行灵活的配置关于省级规则它也是通过一个专门的RuCR的进行定义它在高级方面和事件规则类似也是一个Condition属性用来过滤省级信息然后深层高警消息通知给用户接下来是关于通知配置这一部分我们请我的同事刘万军为大家做一下详细介绍好的 下面有我继续给大家分享我们都知道人类有三大中级哲学问题我是谁我从哪里来我要到哪里去对于高警这个问题就变成了高警是什么高警从哪里来高警要到哪里去那么高警是什么这个问题我相信大家都应该知道的我们就不在这里追数了然后刚才我的同事被大家解答了高警从哪里来的问题那么下面我就为大家解答高警要到哪里去的问题高警要到哪里去很显然高警要到用户手里去那高警要如何到用户手里去这里就需要用到我们的通知系统通知系统是干嘛的呢通知系统就是实时准确地把高警发送给用户那么这个时候我们就需要构建出一套通知系统Notification Manager是一个多族户的云原生通知管理工具它支持了很多种的通知渠道比如说微信叮叮飞书邮件SparkPushoverWebhook短信平台等等那么我们下面就来通过Notification Manager这个工具来快速地搭建出一套云原生的多族户通知系统首先我们来看一下我们的Notification Manager对于高警的处流程在Notification Manager说到高警以后我们会经过缓存静默抑制路由过滤聚合等一系列的操作最终我们会把高警通知的形式发送给用户下面我们对于每个阶段做一个详细的介绍静默静默的作用是什么呢静默的作用就是在特定的时间段阻止特定的高警发送静默一般来讲它是有实效性的那么我们可以通过时间段或者是通过去写这种Coron的这种表达式来设置我们的静默规则的生效时间当然了我们也可以去设置这种永久性的生效的这种静默规则那么静默规则它是分为两种的全局级别和租户级别两种全局级别的静默规则它是作用于所有的高警的租户级别的静默规则它是作用于需要发送给某个租户的高警的在这个阶段我们应用的是全局级别的静默规则意志的作用是什么意志就是说我们可以通过某些特定的高警去阻止其他的高警的发送举个简单的例子比如说我们的几点当机了这个时候我们会收到这种各种各样的高警比如说POD被驱逐了然后我们的RANNIS不生效了这各种各样的高警但实际上这些大量的高警它是无效的因为它是由于几点当机引起的那么所以这种这些高警这上是没有意义的我们这个时候把这些高警发送给用户它不仅仅是造成这种资源的浪费而且还对用户去定位故障造成了一定的干扰那么这个时候我们就可以通过抑制规则去把这些无效的高警阻止它发送只把这种有效的信息发送给用户路由路由是干什么的路由就是我们的通知最终是要发送给用户的那么路由的作用就是我们要根据我们的高警信息去找到我们要把这个高警发送给哪个用户用户呢又通过哪一种方式去接收到这个高警那么首先呢这个时候我们就需要去考虑一个事情我们如何去定义用户接收高警的方式呢比如说我可以用户希望通过一个邮箱去接收高警或者用户希望通过Select Channel去接收高警那么我们如何去定义这种方式呢引入了一个叫Receiver的概念那什么是Receiver呢Receiver就定义了用户去接收高警信息的一些相关的信息它包含了一些主要的信息比如说用户接收高警信息所需要的关键信息比如说邀项地址Select Channel我们的WeChat的绘画这些信息然后呢它包括了我们去生成通知消息的模板的相关信息最后呢Receiver还可以去定义过滤我们的通知的标签选择器对于这部分我们在后面会提到那么我们有了Receiver以后呢我们如何把Receiver和我们的高警关联起来呢首先Receiver分为两类一类是全局级别的一类是租户级别的全局级别的Receiver呢会接收所有的高警信息租户级别的Receiver只会接收租户有全线访问的Name Space下产生的高警信息那么我们有两种方式把高警和Receiver匹配起来第一种呢是路由匹配用户呢可以制定一个路由规则然后把特定的高警路由到特定的Receiver上第二种呢是根据Name Space标签匹配那么对于没有Name Space标签的高警呢它会全部发送到我们的全局级别的Receiver那么对于有Name Space标签的租户呢那么它就会根据Name Space标签的值也就是说这个高警来源的Name Space把它发送到有全线访问这个Name Space的租户创建的Receiver上大家可以看一下这是一个路由规则然后这个路由规则呢首先我们可以通过标签选择器去选择出我们需要路由的高警然后呢我们可以把这些高警路由到指定的租户的所有Name SpaceReceiver上或者呢把它路由到某一个指定的Receiver上更进一步呢我们可以选择某一些类型的Receiver比如说我们可以把路由到所有的Email Receiver而不把它路由到这种WeChat的Receiver上那么这两种路由规则我们是如何去共同的作用的呢我们是可以设置它们两个的优先级的首先呢其实三种模式第一种是也就是说我们会同时使用路由匹配和Name Space匹配第二种呢是路由优先也就是说我们首先使用路由规则去匹配Receiver如果这个时候呢没有匹配到Receiver那么我们就会使用Name Space 标签匹配第三种呢是指使用路由也就是说当我们使用路由规则没有匹配到Receiver的时候这个时候是不会被发送的对于每一个租户同样的告警实际上它的意义是不同的有的用户可能不太关注这个告警他不太希望收到这个告警消息那甚至呢对于同一个租户它下面的不同的这种Receiver它其实对于接收告警的策略也是不一样的比如说我可能希望我的EmailReceiver所有的这种告警消息但是呢我希望那些级别比较严重的比如说Aero级别或者Critical级别的告警要通过更实实的方式比如说短信或者是WeChat这种方式来通知给用户那么这个时候呢我们就可能需要支持租户级别的告警过滤功能那么我们有两种方式可以实现租户级别的告警过滤功能首先是我们上面提到的租户级别的静默规则租户级别的静默规则呢只会作用于发送到某一特定租户的告警那么就根据这一特性呢我们就可以制定一些租户级别的这种静默规则来实现这种租户级别的过滤第二种方式我们今天提到了Receiver里面是可以定义标签选择器的根据这个标签选择器呢它会选择与我标签选择器匹配的这些告警来发送当然这一步呢我们的所有的告警都会找到了它对应的Receiver那么我们需要呢到了这一步我们就可以通过我们设定的规则把同一Receiver需要发送的告警做一个聚合那么聚合的作用是什么呢聚合的作用主要是两个第一个是聚合告警聚合发送以后呢用户可以更方便地去定位故障也说同一类或者说同一同一种的这种告警比如说我们拿这个let name告警名称去分组那么同样的告警发送给用户的话用户可以更容易地去更容易去定位故障另外一种呢就是说对于某些有调用评次限制的这种Receiver比如说微信比如说钉钉他们都是有这种调用评次限制的那对于这种Receiver呢聚合发送是可以节省调用次数的这就是聚合的作用那到了这一步呢我们的告警发送之前的所有准备工作已经完成了那么我们要开始实施的真正地去发送告警那么发送告警之前呢我们要做一件事情就是我们需要根据我们的告警消息去生成一个通知消息我们不可能把原生的这种告警去直接发送给用户因为这样可毒性会很差那么所以呢我们会根据告警消息去生成一个通知消息我们会根据不同的Receiver去生成不同的通知消息比如说我们的EmailReceiver我们会默认地生成一个HTML格式的这种告警消息我们的这种WeChatReceiver我们会默认生成一个markdown格式的这种通知消息对于我们的这种费输我们就默认生成一个复文版格式的这种通知消息同时呢我们支持用户去自定义这种通知模板然后通过通知模板呢去定义用户想要的这种通知消息我们支持对于同一类的这种Receiver去设置一个通知模板比如说我们可以给所有的EmailReceiver去设置一个通知模板我们也可以给某一个特定的Receiver去设置单独的通知模板同时呢我们是支持用户自定义语言包然后实现语言切换的Nortico Manager为大家提供了内置的相关函数可以实现语言的翻译功能模板准备好了以后呢我们就通知消息准备好了以后我们就要发送给用户了但是我们要怎么发送呢比如说我的Receiver是个Email那我要怎么发呢我可能需要一个发送方的邮箱和对应的SMTP服务器的信息如果我的Receiver是一个Select Channel那我需要什么我需要一个Select APP token那么首先我们就需要去定义这些信息然后呢还要把这些信息和我们的Receiver关联起来那么我们如何去定义这些信息呢我们就需要一个Config这个概念Config就是用来定义我们发送我们的通知消息所必须的一些信息的那么Config是如何和我们的Receiver关联起来呢同样的我们的Config是可以分为两种类型的是全局类型的第二种是租户类型的那么对于全局级别的Receiver默认情况下它是会选择全局级别的这种Config对于租户级别的Receiver它会去默认选择当前租户的创建的这种Config如果当前租户会创建Config那它会选择这种全局级别的Config我们也支持对于每个Receiver它可以去通过标签选择器去指定它想要使用的Config那么使用这种发送配置和接触配置分离的模式呢我们可以最大限度的实现配置附用同时呢我们可以实现这种多租户的这种通知设置举个简单的例子比如说对于邮箱这种通知模式那么我们整个公司可能只有一个SMT服务器那么对这种情况下我们可以设置一个全局级别的这种Email的Config然后所有的租户只需要配置一个Receiver就可以了那么对于其他的比如说Slack那么我们可能对于不同的这种部门或者不同的这种team它可能需要使用不同的Slack APP去发送不同的消息然后这个时候我们也可以通过这种方式来实现那么有了这个我们的Receiver会有了Receiver有了Config我们就自然的可以发送了我们发送我们的通知了那么至此呢我们就完整的搭建了一个多租户的原生通知系统然后我们可以给用户发送通知了然后呢以上就是我们今天分享的全部内容然后下面的话进入问答事件大家有什么问题你好我刚才看到你们那个用Promius Operator来做的是吧就每个机群佈一个然后再有个主机群那这样的话其实业界有那种像Promius Federation还有它那个Sanos这些都能够做一个聚合还有刚才您说的数据分类聚合最终那个告警什么的就是您这边这个发案的优势是在哪个地方呢我们这边是其实是可以做就是在那个多机群模式下它是可以做那个多机群的数据聚合的如果是单纯的联邦的那种Federated的它是就是会相当于是每个机群的规则是一样的嘛就是它是就只能还是在就是只针对它单个机群的数据生效每个规则还有一个就是你们那个如果主机群的这个Aprilite真的荡掉了或者这些挂掉了那你们这个告警信息岂不是就是发不出去了或者说你们有其他的高可用机制吗这个Operator它是一个Department它本身是高可用的对它本身是有多富人那如果真的是完全不可用比如说我机器就停电了下电了这种情况下是真的告警就完全发不出去了是吗它能发只是可能你那个配置就是你新的规则它不能生效在这种情况下好的还有我刚才看到那个你们是在Class的和Port的之间还有一层对在Name Space之间还有一个叫做Work Space这个Work Space你们自己定义的一个类似于CRD支援吗对它类似于一个就是租户它是得把多个Name Space合在一起的叫一个Work Space是这样的吗对好的 谢谢我来补充一下这个问题就是说您刚才说的是社区有Prompto 4的Federation也有Tanos然后呢其实我们的多级群的监控数据发上来是发到我们的管理的Tanos里边的但是Tanos它是有一些扩展性的问题所以我们做了一个Visor的项目来去把Tanos的弱点给它规避了但是Visor的项目呢没有开源所以就没有跟大家聊这个事情对然后其实我们是给Tanos做了一些优化然后使它更容易的可扩展包括它的Injector Router然后Compact Store这些东西我们都做了一些优化对您好老师然后我的一个问题其实是涉及到两个就是关于你的规则和一个那个高警的事就是我看到一直在提多族户以及在提那个规则范围的定义但是我觉得它基于普伦米修斯的光基于普伦米修斯的Label来过滤其实就可以了吧就比如所有数据会聚在一个中心处之后通过Label进行那个你的规则的高警的异常的检测以及那个我甚至觉得后面的那个Notification Manager就跟Order Manager没有区别对然后它中间的能力基本上也都是Order Manager类似的能力我不知道这里你们那个完全重做的原因是什么我回答一下那个规则方面的规则方面的我们是就是是在那个我们引入了那个新的CRD主要是为了方便一方面是为了方便配置因为另一方面是普伦米修斯入它有一些限制刚刚我们也聊到它那个在比如说启用规则金融规则这些方面它是不支持的另外还就是我们因为我们是就是会提供一个那个多用户的那个API然后它普伦米修斯入它在并发上比如说我因为它一个普伦米修斯入是有会配置多个入格入铺的然后它在并发上也支持有限就是我们可能就如果遇到并发就只能去重视然后通知吧我回答一下你刚才的问题就是ELECT MANAGY有现成的功能为什么我们要做NOTIC MANAGY呢首先ELECT MANAGY不是多做户的其次呢ELECT MANAGY不支持用CRD金配置它是用的配置文件这种情况下它去做配置就特别麻烦还有一个问题呢就是ELECT MANAGY的问题就是它所支持那种通知渠道其实非常少的我们之前也给ELECT MANAGY提过然后想把这种这种WeChat这种东西给它夹进去但是他们是不接收的所以说呢在基于这些这种原因呢我们需要重新有自己的一套这种通知管理平台至于你说这个他们去我们做NOTIC MANAGY最开始的初中是替代ELECT MANAGY可以这么说吧那我可能还有一个问题就是现在像那个规则的检测现在就是已经PromiseOS不是之前可能说是存储能力太弱没办法把数据进行聚合但现在已经有很多那个RemoteRide的方式其实PromiseOS后面有大量的可以进行无线序列存储的那个存储库来那个支持比如那个Vector and Matrix像类似于这些东西的话我在想你们的那个高警规则以及通知为什么要放在那么靠前就比如说规则需要落到那个单个集群内而不是在最终通过那个PromiseOSLabel再进行那个相对应的规则设定和过滤这个规则放在就是比如说一个集群他放在一个Lame Space就是为了与我们的那个多租户管理系统匹配就是这个因为你这个比如说我们定义的那个Rook Roof它首先是属于一个Lame Space然后这个Lame Space肯定就是它比如说它某个租户它的这个Lame Space下有权限但是它在其它的其它的比如说其它的资源它是没有权限的这样我们就是直接在那个Lame Space这些它有权限来配置规则然后整个规则我们会就是通不到那个数据设这样它就可以直接进行高警它就不需要去给这个用户去配置其它的权限了老师呢把PPT切到前面前面几张吗其实我的问题是顺着这个同学的问题往下问的就是还是那个关于再往前对 再往前对过了对 就继续这个对 其实我想问的问题也是类似的就是如果你是为了从全线的角度考虑的话那你把这个高警规则放到每个足户下那最后集群Global集群或者是说统一的对我就假设最后的数据会就在Global集群那最后在这里的话是每个ProM就是它自己就是产生高警然后将高警统一发送给Global集群吗还是说你将指标你将指标汇集到Global集群再通过Global集群的WhateverRuler之类的工具去产生新的高警吗高警是在就是这种模式下高警是在组织群上产生的OK那这时候会不会产生另外一个问题就是毕竟我是remote right我数据是一波一波上来的那如果我数据其实没有然后你验证的是数据的数据的准确性就是某指标大于某个预指那会不会其实数据没有正确或者是完整的批量产生上来那我可能Count了一个数据就产生了错误那这种情况会不会发生呢就是说你那个规则规则内部它是涉及到多个指标的比如说我算的是这个组互下的Port的数量但可能因为我remote right的过程中我的数据可能没有因为网络的问题可能没有及时的传上来但是刚好到了一个循环周期那我就高警了那其实整个这时候数据可能是零对吧它真实的基讯中并不是这个数据那我是不是其实会产生一个误告呢这个方面首先从规则这一次来说因为它不是说比如说一个规则表达式它执行一次它就立马产生高警它是需要一个持续时间的在这个持续时间内它是需要一直满足条件然后才会高警这一方面另外就是对于你说的集群本身它数据比如说remote right它没法写成功这一块我们也是有高警的就是说如果你没写成功它是会有高警的所以通过意志来告诉我说因为数据没有产生所以后面的高警其实是误告的就没有必要再发给我了是这样说的对我还有一个事其实从Coopersphere这个产品的角度上想问一个问题就是我看到社区版上面其实包括notification manager这些组建其实是没有UI化的或者是我的信息太之后了我看到的社区版是没有UI化的那我比较好奇就是在你们的比如说企业版或者是更高级的版本里这部分东西是有UI化的就是刚才那个挺复杂的notification manager这些receiver configure这些配置是有UI化的因为我感觉那台满男变得就是用体验上是满是有的对 是有的那我们今天的会议就到此为止谢谢大家