Obsuite

Obsuite 查看完整档案

填写现居城市  |  填写毕业院校滴滴云计算有限公司  |  Obsuite 编辑 obsuite.didiyun.com/product/enterprise/ 编辑
编辑

Obsuite是来自滴滴的可观测性智能中台。包含滴滴夜莺和滴滴Logi两个子品牌;有开源、企业两个版本;利用指标和日志两种分析手段;覆盖资源、应用、业务多层次监控和分析。
微信服务号:Obsuite;
Github:https://github.com/didi/night...(滴滴夜莺)、https://github.com/didi/Logi-...(滴滴Logi-KafkaManager);
B站教学视频/直播回放:https://space.bilibili.com/44...

个人动态

Obsuite 发布了文章 · 3月27日

滴滴OCE派奖啦!

OCE限时邀请有礼,只等你来!2021年3月16日-4月30日, 邀请在生产环境中使用Obsuite(包括滴滴夜莺、滴滴Logi)且未申请OCE认证的企业用户,即可收获桔厂牛年抱枕、雷蛇专属游戏鼠标垫、电脑挂灯等一众好礼,特别的礼只为特别的你,活动详情请戳下方图片进行了解。image

查看原文

赞 0 收藏 0 评论 0

Obsuite 发布了文章 · 3月5日

想看新指标?教你轻松写prober插件

prober插件通过API方式采集打点数据,目前已有插件:

  • elasticsearch
  • github
  • haproxy
  • mongodb
  • mysql
  • nginx
  • prometheus
  • rabbitmq
  • redis
  • tengine
  • zookeeper

prober插件是使用telegraf

(https://www.influxdata.com/time-series-platform/telegraf/T)) 插件接口封装而成,你可以:

  • 直接封装一个telegraf
  • 写一个telegraf插件,然后再封装成prober插件

接下来用src/modules/monapi/plugins/demo为例,介绍插件的开发。

Telegraf插件 开发


安全提示

需要实现一个这样的接口类型:

下面是demo插件的实现:

这样就有了一个telegraf的插件, 接下来将它封装成 prober 插件。

插件中Gather方法中的acc是一个接口,具体的实例由运行环境提供的, 在prober中运行插件时,acc的实现在src/modules/prober/manager/accumulator.go

Prober


prober会定期从monapi获取collectRule列表,检查更新自己的插件实例。

  • create rule collector
  • update rule collector
  • delete rule collector

其中,update rule是由delete old,create new来实现的。

monapi之所以需要加载插件,是因为需要获取插件的参数描述,这样才能渲染出合适的UI界面,方便用户输入。 这是demo的参数描述:

有关ui的信息描述,放在了structField的tag中,详细的tag如下:

这样,mapapi拿到结构体后,就可以知道如何渲染,填充结构体里的参数,然后将用户输入的数据存入数据库后,分发到各个prober上执行。

prober获取规则后,通过插件的TelegrafInput方法,将rule转换成telegraf.Input实例。

测试


src/modules/monapi/plugins/demo/demo_test.go

部署

内置编译

  • 修改src/modules/monapi/plugins/all/all.go,添加demo
  • 重新编译monapi & prober

外挂加载

将自己的插件编译成动态库文件(.so), 复制到monapi &prober工作目录下的plugins/

观看视频讲解www.bilibili.com/video/BV1MK…

查看原文

赞 0 收藏 0 评论 0

Obsuite 发布了文章 · 2月25日

滴滴 Kafka 服务体系建设,实战干货都在这里!

Obsuite·云讲堂第一期直播即将上线,欢迎大家于2月27日20:00进入腾讯会议849 182 609,观看直播~张亮老师将带给您精心准备的滴滴Kafka服务体系建设实战干货!

image

查看原文

赞 0 收藏 0 评论 0

Obsuite 发布了文章 · 2月4日

滴滴夜莺社区文章有奖征集

1、活动时间:2021年1月1日-2021年3月31日

2、参与方式:在思否等技术社区专栏撰写发布标题带有“滴滴夜莺”的最佳实践/行业应用文章,私信提交文章链接。

3、文章内容:包括源码解析、最佳实践这两个方向,解读您对滴滴夜莺代码的理解,滴滴夜莺在你所在公司行业的使用心得、场景。

4、活动奖品:

5、活动规则:

  • 滴滴云将有权决定文章是否符合活动要求,并且视文章的质量、传播度以及影响范围酌情派发奖品;
  • 优秀的内容会被展示在滴滴夜莺(Nightingale)官方Github页面、Obsuite公众号等官方渠道;
  • 请您务必注意,您撰写/发布的文章或不得含有涉黄涉恐涉暴等违法违规信息,也不得撰写/发布任何侵害他人合法权益的文章,否则滴滴云有权取消您的活动参与资格并追究您的法律责任;
  • 如您对本次活动内容与规则有任何疑问,请您联系obsuite@didiglobal.com
查看原文

赞 0 收藏 0 评论 0

Obsuite 发布了文章 · 2月1日

云讲堂 | 5期视频带你全面了解滴滴Logi-KafkaManager

Obsuite·云讲堂:滴滴Logi-KafkaManager系列教程包含5期内容,分别是:产品介绍、主要概念讲解、用户体验地图、运维体验地图、本地环境搭建。

  • 第1期产品介绍:将全面讲解滴滴Logi-KafkaManager的发展历程、产品设计、体验地图及未来规划。
  • 第2期主要概念讲解:将讲解Kafka基本概念和Kafka运维管控的相关概念。
  • 第3期用户体验地图:将讲解生产消费概述、资源申请、生产/消费示例和监控告警的内容。
  • 第4期运维体验地图:将讲解运维管控概述、集群接入、指标监控、集群运维、资源治理的内容。
  • 第5期本地环境搭建:将讲述如何在本地快速搭建滴滴Logi-KafkaManager的本地开发环境,及核心代码模块的主要内容。

教程链接:Obsuite·云讲堂 滴滴Logi,点击即可观看。

查看原文

赞 0 收藏 0 评论 0

Obsuite 发布了文章 · 1月29日

滴滴Logi-KafkaManager开源之路:一站式Kafka集群指标监控与运维管控平台

导读

从2019年4月份计划开源到2021月1月14号完成开源,历时22个月终于修成正果,一路走来实属不易,没有前端、设计、产品,我们找实习生、合作方、外部资源支持,滴滴Kafka服务团队人员也几经调整,内部迭代了3个大版本,我们最终还是克服重重困难做到了!一经开源获得了社区用户广泛的认可,截止当前Star达到1150,钉钉用户突破540人,滴滴开源Logi-KafkaManager一站式Kafka监控与管控平台阅读1W+UV。

01滴滴Logi-KafkaManager简介

Kafka作为滴滴大数据消息队列,每天承载万亿级消息的生产与消费,面对100GB/S+峰值采集流量,服务了公司内近千Kafka用户,托管了数十Kafka集群,数万Kafka Topic,单集群>300+Broker。历经四年打磨沉淀,围绕滴滴Logi-KafkaManager打造了滴滴Kafka平台服务体系,内部满意度达到90分。

滴滴LogI-KafkaManager是面向Kafka用户、Kafka运维人员打造的共享多租户Kafka云平台,专注于Kafka资源申请、运维管控、监控告警、资源治理等核心场景。一经开源广受社区用户喜爱,免费体验地址:http://117.51.150.133:8080/kafka,账户admin/admin,欢迎Star。

02为什么要开发

滴滴Logi-KafkaManager

滴滴内部有几十个kafka集群,450+的节点,每周500+UV用户,需要完成topic创建、申请、指标查看等操作;每天运维人员还有大量topic管控、治理、集群运维操作。因此我们需要构建一个Kafka的管控平台来承载这些需求。我们调研了社区同类产品,在监控指标的完善程度、运维管控的能力、服务运营的理念都无法很好的满足我们的需求。

03滴滴Logi-KafkaManager功能亮点

产品化设计之关注点分离

业界开源的KafkaManager定位是一个面向运维人员的监控工具,在滴滴我们定位是全托管Kafka服务工具型平台产品,针对的人群区分为Kafka用户、Kafka运维。

  • Kafka用户:关注的是Topic相关的操作,Topic资源申请与扩容、Topic指标监控、Topic消费告警、Topic消息采样、Topic消费重置等。  
  • Kafka运维:关注的是Kafka集群相关的操作,集群监控、集群安装、集群升级、集群Topic迁移、集群容量规划等。

Kafka业务运行过程数据化

作为消息中间件,Kafka最核心的能力就是消息的生产、消费,用户高频的问题都与此相关,作为服务提供方,我们需要详细的感知Topic的生产消费在服务端各个环节耗时,快速界定到底是服务端还是客户端问题,如果是服务端问题,出在哪个环节,如下图所示:

  • 请求队列排队时间(RequestQueueTimeMs)
  • Broker本地处理时间(LocalTime)
  • 请求等待远程完成时间(RemoteTimeMs) 
  • 请求限流时间(ThrottleTimeMs)
  • 响应队列排队时间(ResponseQueueTimeMs)
  • 响应返回客户端时间(ResponseSendTimeMs)
  • 接收到请求到完成总时间(TotalTimeMs)

通过将这些服务端运行指标,以Topic粒度呈现,显著的提升了服务用户的效率,如下图所示:

Kafka服务保障强管控

Kafka各语言客户端版本众多,官方也只有精力维护Java版的SDK,滴滴受限于服务人力,没有进行客户端版语言与版本管控,服务端拓展实现强管控客户端元信息的能力。

  • 拓展服务端能力,强感知客户端的链接地址,协议类型,方便后续引擎对用户行为的感知与强管控。

  • 拓展实现Kafka服务端的安全认证能力,通过账号机制记录应用元信息,包括人员信息、业务信息、权限信息;通过Topic创建管控,记录压缩类型、Partiton、Quota等元信息,在服务端实现了对客户生产、消费能的强管控。

最佳实践之专家服务沉淀

多年Kafka服务运营经验,我们沉淀了大量的服务保障最佳实践,结合应用场景,截止目前构建了以下几项专家服务,后续我们会持续打磨与完善。

  • Topic集群分布不均迁移:不同broker上leader数目不均;同一个broker上不同磁盘leader分布不均;同一个topic在broker上不同磁盘分布不均。我们需要发现热点,给用户推荐迁移计划。

  • Partitont不足扩容提示:根据单Partition承载流量,按照业务场景与底层硬件资源进行主动扩容提示,扩容标准:滴滴的实践是TPS场景:单Partition 3MB/S;IOPS场景:单Partition 10条/S。

  • Topic无效资源下线:针对线上持续一个月Topic无流量,无生产消费链接的资源,通知用户进行主动资源释放。

04  滴滴Logi-KafkaManager架构

平台设计之初,我们就基于开源的理念进行平台建设,遵循了依赖精简、分层架构、能力API化、100%兼容历史开源版本的原则,整体架构如下:

  • 资源层:滴滴Kafka引擎和KafkaManager除了 zookpeer之外只依赖msyql,依赖精简,部署方便;
  • 引擎层:当前滴滴kafka引擎版本是2.5,我们在此基础上开发了一些自己的特性,如磁盘过载保护、IO线程池分离、Topic创建资源分配优化等功能,并且完全兼容开源社区的 0.10.X kafka版本;
  • 网关层:引擎层之上滴滴设计了网关层,提供了安全管控、topic 限流、服务发现、降级能力;
  • 服务层:基于kafkaGateway我们在滴滴Logi-KafkaManager上提供了丰富的功能,主要有:topic管理、集群监控、集群管控能力;
  • 平台层:分别针对普通用户和运维用户,提供不同的功能集合,尽可能的将一些日常使用中的高频操作在平台上进行承接,降低用户的使用成本,同时核心能力API化,方便用户生态对接。

写在最后

项目开源只是万里长征的第一步,产品还需要持续的打磨与建设,但行好事莫问前程,感谢那些曾经为这个项目付出努力的童鞋们,特别是当前团队的兄弟们,过去一年非常不容易,开源的技术梦想让我们紧密的团结在一起,以此文向开源的领路人章文嵩致敬!

滴滴Logi-KafkaManager是2021年团队开源梦想的一小步,是滴滴Logi日志服务套件整体开源计划的重要组成部分,欢迎关注Obsuite公众号或者加入Logi滴滴用户钉钉群,给我们的产品提出宝贵意见,也欢迎小桔子们推荐给有需要的技术童鞋!

查看原文

赞 0 收藏 0 评论 0

Obsuite 发布了文章 · 1月27日

关注直播 走近滴滴夜莺K8S监控组件

Obsuite·新生记第二期直播即将上线,欢迎大家于1月30日20:00进入腾讯会议213 975 828 观看直播~

宁阳阳老师带您走进滴滴夜莺K8S监控组件,解锁新功能~

image

查看原文

赞 0 收藏 0 评论 0

Obsuite 发布了文章 · 1月27日

滴滴开源Logi-KafkaManager 一站式Kafka监控与管控平台

导读: LogI-KafkaManager脱胎于滴滴内部多年的Kafka运营实践经验,是面向Kafka用户、Kafka运维人员打造的共享多租户Kafka云平台。专注于Kafka运维管控、监控告警、资源治理等核心场景,经历过大规模集群、海量大数据的考验。内部满意度高达90%的同时,还与多家知名企业达成商业化合作。

滴滴内部统一使用 kafka 作为大数据的数据通道,当前滴滴共有几十个 kafka 集群,450+ 的节点,20k+ 的 kafka topic,每天2w亿+的消息量;每周500+UV用户,需要完成 topic 创建、申请、指标查看等操作;每天运维人员还有大量集群、topic运维操作。因此我们需要构建一个Kafka的管控平台来承载这些需求。

在平台建设的初期,我们调研了社区同类产品的使用情况,在调研中发现,外部同类产品无论在监控指标的完善程度、运维管控的能力亦或是使用的体验、还是整体的安全管控上都无法很好的满足我们的需求,因此自建滴滴 kafka 云管控平台势在必行。

经过前期产品同学的反复调研和设计、中期研发同学高质量的实现、后期针对用户体验反馈的持续迭代,kafka 云平台上线后广受内部用户和运维人员的好评,使用满意度达到90分。与此同时,还进行了开源(https://github.com/didi/Logi-KafkaManager)免费体验地址:http://117.51.150.133:8080/kafka ,账户admin/admin。

1.需求分析

在 Kafka 云平台建设的初期,我们对之前所面临的问题和需求进行了归纳分析,主要有以下几点:

数据安全性

由于绝大多数用户使用的kafka topic 都会由公共集群来承载数据的生产和消费,而当前 kafka 引擎在 topic 级别的安全管控手段较为薄弱,任何人只要知道kafka集群地址和相应的topic便可进行消费。这无疑会造成数据泄漏的安全风险,因此数据的安全性成首要被解决的问题。

服务的稳定性

滴滴内部绝大部分的 topic 是在共享集群上,共享集群下多 topic 之间存在着相互影响的问题。如某个 topic 的流量突增可能会大面积地影响其他 topic ,从而导致业务的抖动和集群的不稳定。因此在共享集群下,kafka 服务的稳定性也成为了一个必须被解决的问题。

用户使用友好性

滴滴内部每周有大量的用户需要进行 topic 的创建、消费、扩partiton、指标查看等操作,用户高频使用的功能需要做的足够的友好和容易上手,这样才能最大的简化用户的操作和减低日常开发和运维人员的答疑成本。因此用户高频操作的平台化支撑,则成为接下来需要解决的问题。

问题定位高效性

在日常使用 kafka topic 的过程中,会有大量的问题需要查看和定位,如:消息生产和消费的速度、消息堆积的程度、partition的均匀度、topic的分布信息、broker的负载信息、副本的同步信息等,如何使用户和运维人员快速高效的定位问题、处理问题,是重点需要解决的问题。

运维管控便利性

在日常的运维中,会存在着大量的集群、topic的运维操作,如:集群的部署、升级、扩缩容、topic的迁移、leader rebalance等高频高危的操作,怎么样在提升运维操作效率的同时,还要保证高危操作不会影响集群稳定性,这个也是需要去重点考虑。

2.整体设计

从以上的需求分析可以看出,滴滴 kafka 云平台建设需要解决的问题比较多元,因此在设计之初就需要对整体有一个清晰的思路和规划,为此我们定义了一个核心设计原则,并对业务进行了合理的分层用以指导我们后续的产品设计和代码开发。

▍1. 核心设计原则

在平台的整体设计上,我们制定了“一点三化”的设计原则:

  • 一点:以安全和稳定为核心点,建设 kafka 的网关系统,针对 topic 的生产/消费提供安全校验,同时提供多租户的隔离方案解决共享集群下多 topic 相互影响的问题;
  • 平台化:着重建设 kafka 云平台,反复进行需求调研和产品设计,提炼用户和运维的高频操作,将这些操作都通过平台实现,降低用户的使用成本;
  • 可视化:提升topic/集群监控、运维过程中指标的可观察性,所有指标尽量能在平台上可以直观体现,方便使用者及时感知集群运行状态,快速定位问题;
  • 专家化:将日常集群运维的经验沉淀在平台上,形成专家服务能力和智能化能力,进一步降低 kafka 集群的维护成本,提升整体稳定性。

▍2. 业务分层架构

在滴滴 kafka manager 具体的业务设计上,我们采取分层设计,从下至上分为以下几层:

  • 资源层:滴滴 kafka 引擎和 kafka manager 除了 zookpeer 之外只依赖 msyql,依赖精简,部署方便;
  • 引擎层:当前滴滴 kafka 引擎版本是2.5,我们在此基础上开发了一些自己的特性,如磁盘过载保护,并且完全兼容开源社区的 kafka;
  • 网关层:引擎层之上我们设计了网关层,网关层的设计非常巧妙,主要提供:安全管控、topic 限流、服务发现、降级能力,具体详见后文“安全性”的内容;
  • 服务层:基于kafka gateway 我们在 kafka manager 上提供了丰富的功能,主要有:topic 管理、监控管理、集群管理等;
  • 平台层:对外提供了一套 web 平台,分别针对普通用户和运维用户,提供不同的功能页面,尽可能的将一些日常使用中的高频操作在平台上进行承接,降低用户的使用成本。

▍3. 应用逻辑架构

在实际的应用部署和关联上,整体的 kafka manager 和 kafka 引擎、kafka gateway 之间的逻辑关系比较简单,具体如下图所示:

  • kafka gateway 包括两大块功能:服务发现、元数据网关,详细介绍见后面的元数据网关设计一节。
  • kafka manager 提供我们开发的特色功能,如:topic管理、监控管理、集群管理,以及相应的 web 平台,普通用户和研发运维人员日常操作接触最多,最高频的操作都将这上面完成。

3.安全性

以kafka 数据的安全性和集群使用过程中的稳定性保障是我们在构思和设计整个 kafka 云平台时首要考虑的问题,为此我们设计了一套 kafka 元数据网关和多租户的隔离模型来解决这些问题。

▍1. 元数据网关设计

用户在接入原始的 kafka 集群时没有安全管控,无法有效的管理用户的使用行为,对数据安全和集群稳定性造成严重的风险,因此我们设计了一套 kafka 集群元数据网关系统来解决安全问题。

kafka gateway 系统除了解决数据的安全风险还附带了以下作用:

  • 提供 kafka 集群的服务发现服务节点,这样用户在使用 kafka 集群服务时,当 kafka cluster boostrap 地址变更时,则不需要用户改动 kafka 的连接地址,不用重启 kafka client,保障集群的变更对用户透明;
  • 提供 kafka topic 生产和消费的限流能力,避免用户无限制的使用集群的流量,流量大的用户会耗尽系统资源从而影响其他用户的使用,造成集群的节点故障;

需要注明说明一点,kafka gateway 的设计很巧妙的将这些功能实现在 kafka 引擎内部。因为 kafka 作为一个消息系统,其本身流量是非常的巨大,如果 kafka gateway 作为一个单独应用存在,所有流量都先通过 gateway 再进入 kafka 引擎,则对 kafka gateway 机器资源的消耗是非常巨大的,基本等同于需要增加一倍的机器资源,并且整个流程的耗时也会增加。所以在设计之初,就把 kafka gateway 和 kafka 引擎合在一起,这便是滴滴 kafka 引擎的特色能力所在。

搭建好 kafka gateway 系统之后,用户使用 kafka topic 的流程变为如下:

  • 在 kafka manager 上申请租户(appid),获取到对应的租户密码(app-password);
  • 利用 appid 申请创建新的 topic,或者申请已存在的 topic 的生产和消费权限;
  • 使用 kafka client 时设置好对应的 appid 和 app-password,相应的 topic 鉴权,限流都在 kafka broker 端完成。

▍2. 多租户隔离模型

在滴滴内部,绝大部分的 topic 是在共享集群上的,在没有管控的情况下,topic 的各个分区是随机的分布在不同的 broker 上,随着集群中 topic 数量的增加,topic 流量的变大,某个具体 topic 的抖动有可能会影响到其他的 topic,因此共享集群下的 topic 隔离就是非常必要的,为此我们结合 kafka gateway 在 kafka manager 上设计了一套多租户隔离模型来解决这个问题,具体操作如下:

  • 对将kafka 集群中的各个 broker 进行划分,一组 broker 被分成一个 region,这个 region 在业务上被抽象为一个逻辑集群;
  • 用户在申请创建新的 topic 时需要选择一个逻辑集群,这样 topic 的分区只能创建在一个逻辑集群上,也就是一组 broker 上;
  • 具体 topic 消息的生产和消费就只会和一组 broker 发生关系,如果某个 topic 的抖动也只会影响特定 broker 上的其他 topic,从而将影响限定在一定的范围内。

4. 平台化

滴滴 kafka manager 平台建设之初就把易用性作为主要目标,因此在产品设计上非常注重用户的使用体验,前期通过反复的用户调研和内部讨论,最终提炼出普通用户和运维用户的高频操作,将这些操作都通过平台实现,降低用户的使用成本。

  • 方便的日常用户使用

用户只关注自己的Topic的信息(默认),以减少不必要信息的干扰;

足够的指标信息,以保证用户能自助解决问题的同时减少不必要信息的干扰;

  • 高效的运维操作

提炼用户、运维人员创建Topic、调整配额、扩展分区、集群迁移、集群重启等高频运维操作,将高频操作平台化,简化用户操作,大大降低运维成本。

提供整体集群直观的全局视角,以提高排查问题的效率以及对集群规模的直观感知,并提供详尽的局部视角,以提高排查问题的效率;

  • 友好的生态

内部版本与滴滴监控系统打通,开源版本与滴滴开源的夜莺监控告警系统打通,集成监控告警、集群部署、集群升级等能力,形成运维生态,凝练专家服务,使运维更高效。

  • 体贴的细节

kafka 云平台的建设,它有着自己的设计理念,如:应用、权限、限流等;kafka 集群的 broker 和 topic 的上也存在着各种指标,操作任务,审批流程等,这些都会对用户的使用造成困惑。虽然产品同学在反复的体验和持续的优化迭代,但是为了进一步的方便用户使用,我们在各种用户可能感觉到困惑指标含义的地方,设置了大量的提示说明,让用户不用出页面就可以基本解决问题,整个使用过程力争如丝般顺滑。

  • 出众的颜值

常见的内部工具型产品往往都是以满足功能和需求为主,很多都是功能在页面上的堆砌,kafka 云平台在建设之初,在产品设计和前端开发上也力求更高的标准,最终整体的风格相比以往提升巨大,一上线就被用户称赞为 “大厂出品” ,相比目前几款主流开源的 kafka 管理平台,在页面美观程度上大大超出其他同类产品,可以说是“我花开后百花杀”。

5. 可视化

运维人员在日常进行kafka 集群维护和稳定性保障过程中,对集群和 topic 的各项指标都非常关注,因此指标采集展示的准确性和及时性变得非常重要。为此我们将指标的可视化也作为 kafka manager 建设的核心目标。

  • 黄金指标定义

针对 broker 和 topic 日常监控和诊断问题过程中最主要的指标进行筛选,这些指标被定义为黄金指标,如:topic 的 messageIn、byteIn等,并在平台的相关页面上进行高优高亮展示,便于用户在日常使用过程中,快速诊断和定位集群可能存在的问题。同时我们还根据 broker 和 topic 的指标监控,制定了一套用于快速识别其运行状态的健康分算法,将多个指标进行加权计算,最终得到一个健康分数值,健康分的高低则直观的展示了 broker 和 topic 实际运行过程中的状态,便于用户和运维快速从多个 broker 和 topic 中识别。

  • 业务过程数据化

增加基于 topic 生产消费各环节的耗时统计,支持动态开启与关闭,帮助用户自助排查问题;关键指标业务运行过程化,不同分位数性能指标的监控,方便历史问题回溯诊断。

  • 服务端强管控

服务端记录客户端连接版本和类型,连接强感知,集群强管控,元信息的基石;controller 强管控,指定的主机列表,记录 controller 历史运行节点;记录 topic 的压缩格式,应用与业务元信息,业务强感知。

6.专家化

基于之前全面的kafka数据采集,和运维同学在日常操作过程中的一些经验总结,我们将高频的问题和操作沉淀形成特有的专家服务,来智能诊断 kafka 集群和 topic 的健康状态,并提供对应的处理方案。

kafka manager 的专家服务能提供了以下功能:

  • 分区热点迁移

a.背景:

Kafka只具备Topic迁移的能力,但是不具备自动均衡的能力,Region内部分Broker压力非常大,但是部分Broker压力又很低,高低不均。如果不立即处理,轻则无法继续承接用户的需求,重则由于部分Broker压力过大导致集群出现稳定性问题。

b.解决方案:

i. 在滴滴 kafka 引擎上增加 topic 在不同磁盘上分布的指标;

ii. kafka manager 通过定时采集的 topic 指标来分析 topic在不同磁盘上的分布均匀度;

iii. 针对不均匀的 topic 发起迁移操作,并在迁移时进行流量控制,保证迁移不会影响集群的稳定性。

  • 分区不足扩容

a.背景:

kafka 集群的 topic 相关的元信息存储在 zookpeer 上,最终由 controller 将其同步到各个broker。如果元信息过大,controller 同步的压力就会随之上升成为整个集群的瓶颈点,如果遇到某台 broker 出现问题,整个集群的数据同步就非常慢,从而影响稳定性。

b.解决方案:

i. 在用户申请创建 topic 的时候,平台进行分区数的管控,分区数不能设置的特别大,然而随着 topic 流量的上升,topic 分区可能不足。如果遇到 topic 流量突增,超过了单分区能承载的能力,会导致分区所在的Broker出现压力,如cpu和load升高等问题,客户端也会出现发送堆积的情况。

ii. 基于现有的机型以及客户端的消费发送能力的压测,我们定义了单分区的承载流量,同时我们实时对每个 topic 的流量进行监控,当某个 topic 的峰值流量持续的达到和超过阈值之后,会对该 topic 进行标记或者告警,定义为分区不足的 topic。

iii. 针对监控发现出来的分区不足的 topic,由运维人员手动进行扩分区,或者 kafka manager 根据当前集群整个容量情况自动进行扩分区。

  • topic资源治理

a.背景:

公共集群中用户申请创建的 topic,它们的使用情况是各不相同的,还存在着部分 topic 根本不使用还占据集群元数据的情况,这对本来就十分拥挤的公共集群造成很大的资源浪费和稳定性风险,因此针对集群中的不使用的 topic进行治理就非常必要。

b.解决方案:

i. 实时对集群中所有 topic 的流量进行采集监控,智能的分析 topic 的流量趋势,如果发现 topic 的流量持续在一段时间内为0,则进行标记或者告警。

ii. 针对监控发现的一定周期无流量、无生产消费链接的topic,进行通知和下线清理操作。

7.同类对比

我们来和外部类似的产品进行一个简要的功能对比如下:

经过简单的对比,我们可以看到,经过平台化、可视化、智能化、安全建设之后,滴滴kafka manager在安全性、用户体验、监控、运维管控上都有着显著的优势,也提供了很多特色的功能,极大的方便了用户和运维人员的日常使用,欢迎大家Star和体验https://www.didiyun.com/production/logi-KafkaManager.html

8.展望

Logi-Kafka-Manager 已在滴滴内部上线使用,未来我们除了在平台化、可视化、智能化基础上持续改进,还会在以下几个方面持续努力:

  • 平滑的跨集群迁移

我们将基于 MirrorMaker + KafkaGateWay 打造一套 kafka Topic 跨集群平滑迁移能力,在 kafka manager 平台上为 kafka topic 运维管控提供更为高效的迁移能力,进一步提升运维效率。

  • 更多的指标监控

进一步的支持 kafka 2.5+ 最新版本的管控,并且新增更多的关键指标的监控,从而让 kafka manager 指标展示和问题定位的能力更强大。

  • 持续回馈开源社区

作为在滴滴内部经过大量复杂场景验证过的 kafka 管控平台,我们会持续对其进行核心业务抽象,剥离滴滴内部依赖,回馈社区,我们也希望热心的社区同学和我们交流想法,共同提升滴滴 Logi-KafkaManager 的功能和体验

开源团队

查看原文

赞 0 收藏 0 评论 0

Obsuite 发布了文章 · 1月23日

7年沉淀之作--滴滴Logi日志服务套件

01 日志服务面临的挑战

随着中美摩擦的升级,国内开源文化的兴起,各大互联网公司以及各行业头部企业,纷纷走向开源、安全、自主、可控的发展路线。基于开源引擎 Kafka/ElasticSearch,构建了日志基础设施的基础架构共识:

  • 日志采集能力:服务端、客户端、Web、数据库的日志搜集工作;
  • 日志ETL能力:日志实时ETL、ETL链路监控,ETL链路质量度量;
  • 日志检索能力:全文搜索能力、日志上下文还原能力;
  • 日志分析能力:Adhoc的日志OLAP能力。

随着日志流量、日志任务持续增加,使得“日志时效性、运维友好性、服务稳定性、数据安全性”问题变得非常棘手,如:

1)日志采集阶段面临的挑战

  • 需要支持物理机、虚拟机、容器化场景,以服务粒度进行日志采集;支持弹性动态扩缩容;
  • 需要支持海量、数十万Agent监控、运维、多版本管理;
  • 需要支持共享多租户分级保障模型;
  • 需要针对任务级别提供丰富的指标,故障诊断和自愈能力。

2)日志ETL阶段面临的挑战

  • ETL语义表达要简单清晰可运维,同时与底层基础设施解耦,对SQL表达方式是强需求;
  • ETL链路涉及多个环节,各自有自己的指标体系,口径不统一,问题定位与排查成本很高;
  • ETL链路涉及日志存储与计算,在Quota内端到端弹性扩缩能力充满了技术挑战。

3)日志存储面临的挑战

  • Kafka磁盘IO热点导致的集群生产消费雪崩;
  • Topic资源隔离差,流量突增、回溯消费,影响集群稳定性;
  • Kafka有大量的集群和topic的操作需要平台来承接社区Kafka-Manager能力缺失。

4)日志检索面临的挑战

  • ElasticSearch受制于元信息瓶颈,集群Shard数无法突破数十万级,需要解决扩展性问题;
  • ElasticSearch集群资源多租户与查询隔离体系的缺失,是稳定性的最大杀手;
  • ElasticSearch端到端立体化监控体系缺失,运维保障能力不足,需要解决运维友好性问题。

5)日志分析面临的挑战

  • 亿级明细数据级的Adhoc查询分析能力;
  • 亿级基数维度列高精去重场景能力的支撑;
  • 端到端立体化监控体系的缺失,运维保障能力不足,需要解决运维友好性问题。

02 滴滴Logi日志服务套件

伴随着企业数字化转型、业务全面上云的进程,微服务、容器化等技术的快速发展,业务对稳定、易用的日志基础设施提出了三大迫切需求:

  • 服务保障的需要:全链路追踪是稳定性保障的重要抓手;
  • 业务运营的需要:A/B TEST、活动运营分析、端上用户行为分析、精准营销,对百MB/S日志的秒级收容能力,TB级日志的秒级搜索能力强烈诉求;
  • 业务安全的需要:识别攻击源进行资产止损,安全审计与溯源,TB级别日志Adhoc分析能力。

滴滴Logi日志服务套件在滴滴内部经过7年多的沉淀打磨,针对日志采集、日志存储、日志计算、日志检索、日志分析各个环节,在组件能力上PAAS化建设、在引擎稳定性与扩展性上进行针对性的优化,架构如下:

具有如下优势:

  • 开源自主可控:Logi-Agent、Logi-LogX、Logi-KafkaManager、 Logi-ElasticSearchManager 各PAAS套件计划全开源;
  • 引擎稳定可靠:Agent 40MB/S的单任务采集性能,可控资源的隔离能力;LogX采集任务的实时ETL秒级延迟、计算性能的极致优化;滴滴kafka百GB/S的实时流量;滴滴ElasticSearch数十PB的索引存储集群稳定性99.95%;
  • 服务运营沉淀:数十万日志服务任务端到端全链路保障日志数据的及时性、完整性、可观察性、运维友好性;资源的弹性调度与分级保障能力的产品化沉淀;
  • 平台专业易用:分钟级完成日志全链路的端到端自助接入;SQL模板+UDF的个性化清洗能力支持;百TB级数据秒级的检索体验。

》Logi-Agent介绍

Logi-Agent致力于打造企业级的数据采集平台,负责公司多端、多态数据的采集,架构如下:

滴滴Logi-Agent线上规模10W部署节点,130GB/s的日志采集量,20000+日志采集任务,单任务最大采集能力40MB/S。

》Logi-Kafka介绍

基于用户、研发、运维不同视角的高频场景PAAS化,提升运维友好性、引擎可观察性、用户便利性,已开源https://github.com/didi/kafka... 500+免费用户,体验地址: http://117.51.146.109:8080/ ,账号密码:admin/admin

滴滴Kafka集群规模500+,60GB/S的流量,共享多租户大集群场景的历练(CPU利用率峰值30%,磁盘50%),SLA承诺99.95%,引擎基于2.5版本进行了40+特性增强,磁盘过载保护,分区动态迁移,业务线程隔离是滴滴特色功能,稳定性的重要抓手!

》Logi-LogX介绍

LogX面向服务以MB/S作为Quota的单位,以SreamingSQL+UDF作为ETL表达载体,支持以Quota为单位的动态扩、缩容能力,以任务为单位,构建通道端到端性能、及时性、完整性指标体系。

滴滴20000+StreamingSQL ETL 任务,单任务最大流量500MB/S,端到端ETL延迟90分位小于2Min,具备分钟级动态扩缩容能力。

》Logi-ElasticSearch介绍

业界最专业的ElasticSearch-Manager,基于用户、研发、运维不同视角的高频场景PAAS化,沉淀了全托管特色的索引服务。

提供了基于索引模板的容量规划特性,集群磁盘利用率30%→65%,开源准备中。

自研ElasticSearch-GateWay,提供跨集群访问,多版本兼容,租户定义与安全,DSL审核与分析等重大拓展实用特性,支撑了滴滴50亿次/天的数据读取,1200W/S的数据写入,是ES引擎平滑升级2.3.3->6.6.1->7.6.1的基石组件。

滴滴ElasticSearch集群规模3500+,8PB存储,共享多租户大集群(1000+实例,60W Shard,CPU利用率峰值45%,磁盘60% )场景的历练。

SLA承诺99.95%,引擎基于7.6.1版本进行了150+特性增强,写入性能是社区版本2倍。

FastIndex 50TB索引1小时完成构建,已开源(https://github.com/didi/ES-Fastloader)。

自研DCDR,提供了集群间索引高可用的能力,为线上50+主搜场景提供了异地多活的能力,累积向ES社区贡献 30+PR。

03 滴滴Logi应用案例

滴滴Logi在滴滴内部服务的场景非常丰富,在故障定位、日志分析、日志服务、业务运营、安全审计、日志资产、日志大屏等场景都有深度实践。

限于篇幅接下来会围绕着日志服务LogInsight和业务运营魔镜这两个方面详细展开,分析基于滴滴Logi能够产生的业务价值。

》LogInsight

LogInsight基于滴滴Logi的能力,主打云端日志存储解决方案,针对云化和容器化后面临的日志存储与分析的诉求,提供了日志冷备、资源管理、日志检索等能力。

  • 显著降低日志使用、存储成本 全托管、弹性伸缩,免运维 冷备存储,约0.02元/GB/月,显著降低存储开销,支持1-365天自定义存储时间;
  • 快速发现、定位问题,提高业务稳定 基于大数据流式计算实现接口性能与错误日志的统计分析,提供接口调用关系、拓扑关系、上下游流量分析、服务错误定位、错误聚类等功能;安全可靠
  • 安全可靠 可用性不低于99.9%,每天可处理上百TB日志量 数据实时采集,分钟级落盘,日志存储不丢失满足日志审计需求。

》魔镜

魔镜是专业的场景化用户行为智能分析平台,提供从数据采集、存储、计算、分析到运营推广的全流程解决方案。

  • 场景化分析模型 用户留存分析,用户轨迹分析,用户画像分析;
  • 基础服务能力 核心指标可实时查当日数据,实时计算,秒级产生数据,大盘支持集成报表;
  • 数据分析能力 非研发人员可自建指标,支持多类型可视化报表,支持数据导出随心分析,支持omega数据上报数据;
  • 多产品满意度调研 支持多组织多产品结构,支持线上自动化配置,支持抽奖,提高参与度。

基于滴滴Logi日志服务套件,滴滴Logi不仅能够更好的满足日志场景企业普遍的运维可观察性、应用可观察性诉求,也能够更好的满足业务运营、安全审计、日志分析、日志挖掘等不同场景全方位的需求。

滴滴Logi的整体开源计划如下,欢迎大家关注。

在生产环节使用开源版的企业用户,可以加入OCE,我们会额外给予更好的支持,比如专属的技术沙龙、企业一对一的交流机会、专属的答疑群等。OCE申请入口在Obsuite公众号的菜单里,点击【OCE认证】也可直接申请。

查看原文

赞 0 收藏 0 评论 0

认证与成就

  • 获得 0 次点赞
  • 获得 0 枚徽章 获得 0 枚金徽章, 获得 0 枚银徽章, 获得 0 枚铜徽章

擅长技能
编辑

(゚∀゚ )
暂时没有

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 1月22日
个人主页被 665 人浏览