运维工具如此割裂,九招帮你统一纳管
背景
在运维工具这个江湖中,出现了众多独行侠客,各怀绝技,各自为战。这些开源监控软件如同武林中的各派门派:SkyWalking 以精湛的追踪功夫独步武林;Prometheus 以灵活的告警机制纵横江湖;ELK 则如同黯然销魂掌,以卓越的日志分析、数据可视化技能令人叹为观止。
门派各自捍卫领地,争夺资源,却忽略了武林大势。江湖中有人指出,如果这些侠客们能够携手共进,共同面对武林变局,必定能够形成无敌的联合之势。
直到江湖中出现了一位侠客,号称能“以一抵十”,同时击退 SkyWalking、Sentry、Prometheus、OpenSearch 等各派高手,让运维团队从“对运维工具的运维”工作中解放出来,并提升产、研、运团队的整体效能。
这位侠客便是「观测云」,它是一款面向开发、运维、测试及业务团队的实时数据监测平台,能够统一满足云、云原生、应用及业务上的监测需求,快速实现基础设施、中间件、应用层和业务层的可观测。基础设施监测、日志与指标管理、应用性能监测、用户访问监测、可用性监测、系统级安全巡检、场景和仪表板等均为「观测云」的可观测解决方案,通过统一的数据采集、全面的数据监控、无缝的关联分析、自定义的场景搭建、高度的可编程性及敏捷的成员协作,为用户提供最迅速、最轻松、最全面、最自由的系统可观测平台。
笔者今天就给大家分享这样一个 case:观测云用九招帮助某客户替换掉 5 套监控平台。
客户个例
该客户为一家中小型的金融方案提供商,客户的 DevOps 团队分为前端、后端、运维等几个小组,大家各司其职、密切合作,不断地推出新产品、新功能以满足业务需求。
根据双方的两次技术交流,该客户向观测云团队反馈了监控现状:前端、后端、运维三个小组使用了 5 个以上运维工具/服务,包括:Sentry、SkyWalking、Prometheus+Grafana、OpenSearch 订阅服务(AWS)、AWS CloudWatch 等。
显然,分散的监控带来了数据割裂,每个小组都用自己的数据来评价系统问题,容易造成“本位主义”,团队难以对故障/异常的原因快速达成一致。且数个自建的平台也给运维团队带来了较重的运维负担。
监控分散带来的诸多问题
在与客户团队进行充分沟通后,观测云提出有信心帮助客户进行监控整合,替换掉多套开源监控工具。客户对观测云“统一平台,提升团队整体协同效率”的价值主张非常认可,迅速组织团队开始进入技术验证阶段。双方经过为期两周的交流和互动,实现了全部场景的验证。
观测云的价值主张——统一平台,提升团队整体协同效率
关键招数
在为期两周的验证过程中,客户的前端、后端、运维小组一共有 8 位同事参与了此项工作。最终双方总结出多个关键场景,并成功向客户的决策层进行了汇报,获得决策层高度认可。下面跟大家分享一下观测云打动客户的九大招数。
招数 1:主机/容器的监控
在主机和容器监控方面,该客户原先使用 Prometheus+Grafana 的组合。而观测云则是依靠 DataKit 采集器进行主机/容器的对象和指标采集。
l 如果是主机方式,采用一条 sh 语句即可进行一键式安装;
一条命令安装 DataKit 采集器
l 如果是 k8s 方式,则通过 yaml 文件进行配置。
通过 yaml 文件管理采集器和对应插件的安装
当安装完 DataKit ,主机/容器的对象属性、指标即可展现在观测云上。观测云提供了蜂窝图等看板,通过颜色来展示主机/容器的健康度,方便客户在大量基础设施的情况下快速对亚健康的主机/容器进行分析。
在 DataKit 安装时可以选择开启 ebpf 采集器,以实现基础之间的网络通信分析,客户可以观察到 TCP 重传、时延等情况,充分了解集群内的网络状况。
主机/容器的监控
招数 2:AWS 各服务监控
客户的基础设施均部署在 AWS 上,并且使用了大量 PaaS 服务,但原先通过 CloudWatch 的监控覆盖并不完整。在本次使用观测云期间,我们推荐客户使用了观测云 Func 服务模块,该模块是基于 Python 的脚本开发、管理、执行平台,在官方脚本市场中已经包含了数十个 AWS 服务的监控脚本。
用户只需要选择对应的脚本进行简单修改(填写 AK/SK、Region、修改默认采集指标)等操作,并开启定时任务,即可轻松将 AWS 服务的对象和监控指标在观测云平台界面上进行展示。
AWS 各服务监控
观测云当前已支持的数十个 AWS 服务
招数 3:日志的采集与分析
客户原先使用 AWS OpenSearch 订阅服务来处理业务系统中的重要日志。在使用观测云期间,客户使用了观测云的冷、热分级存储,将最近 30 天的日志存储在 GuanceDB (观测云高性能 OLAP 列存数据库)中,冷日志通过观测云转存到 AWS S3 中进行备份,并且在审计等需要查询历史日志的场景下,无需解冻即可直接从观测云界面上进行查询,取得了效率/成本的完美平衡。
除此之外,客户日常还需要对日志黑名单进行管理,并基于一些业务关键字的组合来实现及时的故障通知。这些需求在观测云上均得到了很好的支持。
超出客户预期的是,观测云的日志除了和链路 tracing 数据进行关联之外,还和主机、容器等数据进行了自动关联。客户在分析日志的时候可以轻松点击标签查看对应主机/容器的运行指标,大大提升了 troubleshooting 的速度。
观测云日志分析
招数 4:用户体验数据(RUM)的采集和分析
客户前端团队原先使用 Sentry 进行用户体验的分析,主要关注接口的性能、会话重放等功能,但没有实现和后端 APM 的关联追踪分析。
观测云则提供了 session、view、action、error、LongTask 等多个角度的 RUM 元数据采集和分析,帮助客户了解用户的实际体验。
“会话重放”在观测云上得到良好的支持,并且提供了多种级别模式来对敏感数据进行脱敏,确保不会顾此失彼(即在复现用户故障现场的同时导致用户的敏感数据泄露)。
前端 RUM 与后端 APM 的关联追踪,则依靠 SDK 自动向 HTTP request Header 中添加的追踪参数来实现,客户无需在代码中进行埋点即可实现前后端的数据关联分析。
对用户体验数据进行采集和分析
招数 5:链路追踪
客户后端开发团队原先使用 SkyWalking 对链路进行追踪,但由于产品迭代的压力较大,未能投入精力去实现 Tracing 和 Log 的关联分析。
观测云通过对 DDTrace/OpenTelemetry/SkyWalking 等主流 APM 方案的良好支持,将客户的链路数据进行实时收集,并指导客户调整 Log 输出格式,很快便实现了客户期待已久的 Tracing+Log 关联分析。
此外,由于观测云采集的数据默认提供了非常多的扩展字段,客户可以使用 key:value 的查询方式根据任意扩展字段进行搜索分析,以便对疑似异常的现象进行探索,灵活性十足。
招数 6:统一告警
在统一告警方面,客户主要关注对主机运行指标的监控,日志关键字的监控,所有的告警会通过钉钉发送群通知,并通过 PagerDuty 实现电话通知。
观测云提供了十余种“监控器”,包含阈值监测、日志监测、进程监测、应用性能监测等,完全满足了客户对故障预警的需求。此外,事件模板可自定义、与 PagerDuty 轻松对接也让客户原有的使用习惯得以保留。
观测云的统一告警
招数 7:灵活、易用的仪表板
客户原先使用 Grafana 进行仪表板的绘制,运维小组主要关注的是容器运行、AWS 服务监控等仪表板,前端小组则需要经常响应产品团队的需求,帮助产品团队进行业务看板的绘制。
观测云在仪表板方面既有二十多种图表,又提供了灵活易用的图表绘制交互体验。对于产品、运营同学完全可以采用拖拉拽式的方式来构建图表样式,通过下拉菜单来筛选自己关注的指标和查询条件,实现图表的绘制;对于运维、开发同学来说,则可以使用 DQL 语句来进行各种观测数据的查询。无论是指标、链路还是日志,采用的是同一种查询语法,并且兼容了 promQL 的写法,让客户能轻松从原有的数据分析平台过渡到观测云。在短短的两周时间内,客户团队自行配置了 30+ 仪表板,得到了客户决策层的肯定。
招数 8:数据的高效、安全分享
由于客户的业务是属于金融服务,因此对数据安全非常看重。在过往工作过程中,团队通过截图、远程协助、发送日志等方式进行协作,不仅效率较低而且十分容易导致数据泄露。
观测云提供了快照分享功能,让客户能够将经过筛选过后的数据保存为快照,分享给其他同事,后者打开快照能进行一定程度的交互分析。在此过程中,观测云能够对指定数据进行脱敏,并且设置快照的有效期/访问 IP 白名单/加密访问等,让客户不会有数据泄露方面的担忧。
招数 9:从用户 ID 出发的立体化分析
在观测云的助力下,客户实现了从用户 ID 出发的全链路追踪。根据 userID 和时间段很容易找到报障用户的访问会话,从前端关联分析到后端链路、日志、主机/ Pod /容器基础资源/数据库中间件运行情况等,真正实现立体化、全访问的分析。产品、研发、运维同学终于可以用同一套工具来进行问题分析,快速对问题结论达成一致。
回顾
回顾历史,秦国的“统一度量衡”推动了经济和社会的繁荣发展。而云原生时代,同样需要有统一监控平台来实现监控数据的统一、团队分析视角的统一、数据标准的统一。
在双方向客户决策的汇报过程中,我们还汇报了观测云相对于国外商业产品的优势:数百万字的中文文档能让客户团队轻松上手,完善的国际化支持又能适应海外员工的使用需求。对于商用客户,观测云还提供多元化的技术服务,例如定期例会、最佳实践专题分享等,确保客户在使用强大的产品功能的同时,能够感受到观测云技术服务的温度。
评论