企业版

Flashcat企业版,是快猫星云以开源夜莺为内核打造的统一可观测平台,是国内顶级互联网公司可观测性实践的产品化落地,赋能千行百业快速构建统一的可观测性体系和数据驱动的稳定性治理框架。

Flashcat 企业版,以开源夜莺监控(Nightingale)为内核,是一个从数据、到平台、再到场景真正一体化的统一观测平台,并将国内顶级互联网公司的可观测性实践和方法论融入产品中,是业务稳定性保障,特别是故障处理的真帮手。

落地好一个现代化的观测平台,有以下三个关键要素:

数据

巧妇难为无米之炊。一个新的观测平台落地,有一半的难度可能来源于监控数据的采集和获取。

数据采集在当前都有哪些普遍的问题?

  1. 传统的监控采集方案不适应云和容器环境的数据采集

    云上的服务组件如RDS、LoadBalancer等,都有自己的监控采集通道,很多组件的关键指标或宿主的指标,外部的采集器难以直接获取。而容器随时产生,随时消亡的特点,也是传统以物理机为中心的采集器难以适应的。

  2. 新的采集方案质量良莠不齐,管理成本高

    适应Kubernetes和容器环境的配套监控系统是Prometheus,Prometheus依赖各种exporter导出采集对象特别是组件类对象的数据,而exporter大家都可以提供,导致采集的数据不同,由于种类繁多管理起来也很麻烦。

  3. Metrics、Logging、Tracing各类数据的采集方案差异大,有没有统一的采集方案?

    在OpenTelemetry的标准下,一个完善的可观测性方案至少包括Metrics、Logging、Tracing三个维度,针对这三类数据的采集,如果也能由一个agent来完成,那将更为理想,这有助于从采集侧提升不同维度数据间的关联性,同时可以降低采集器的维护成本。

  4. 落地一个新的观测平台要不要把已有的采集方案推倒重来?

    推倒重来成本太高,无论是部署agent/exporter,还是安装日志采集器,特别是需要研发在代码中嵌入sdk的方案,落地一次非常不易。如果引进一个新的监控系统需要把这些工作重做一遍,可能很多人会望而却步。特别是在还没确认新产品的效果前就去做这个事情,无异于一次巨大冒险。

Flashcat的数据输入方法

  1. 针对数据采集的问题,Flashcat开源了配套的All-in-one的采集器Categraf,能够用一个agent,通过简单修改配置的方式,采集各类监控对象的Metrics,用户不再需要满世界去找各种exporter,并担心采集器的质量问题。Categraf 也能够采集Logging、Tracing的数据,实现了统一采集的方案。另外Categraf 配合 Flashcat,具有中心端的采集配置管理、下发、网络设备采集模版、网络拨测等能力。

All-in-one 的监控数据采集器

  1. 针对云组件的数据采集问题,和重新部署采集方案的成本问题,Flashcat采用了数据源集成的方案,能够集成各种开源监控工具和主流云厂商的云监控以及日志服务,以阿里云为例,Flashcat 可以无缝集成 SLS、云监控、Arms、云托管的Prometheus 等(目前已有30多种数据源)。

各维度数据源集成

通过实现All-in-one的采集器Categraf,并集成丰富的云数据源和常用数据源来解决数据输入的问题,这就是Flashcat的数据输入方法。

平台

一套趁手的炊具是好厨师的必备。Flashcat建设了一套工程师爱用的监控平台。

在平台建设方面,Flashcat 遵循以下方法:

  1. 功能完备

    作为一个现代化的观测平台,Flashcat集数据采集、可视化、监控告警、OnCall、数据分析为一体,支持 Metrics、Logging、Tracing、Events 各类维度的数据打通和分析,是一个从数据、到平台、再到场景真正一体化的统一观测平台。此外,Flashcat所抽象的北极星灭火图等概念,让可观测性数据以更以被理解的维度呈现,有效的提升故障的发现速度和定位速度。

  2. 架构灵活扩展

    Flashcat平台可以随着所处理的数据量的增加而水平扩展,架构设计上高可用、无单点。Flashcat创新性的支持中心-边缘部署模式,用户可以在中心端统一管理多个边缘Region的监控数据采集,在中心端对所有的边缘Region的数据进行统一的可视化分析和配置告警。同时当中心端和边缘端网络中断时,边缘端可以独立闭环工作。此外对于不适合传输到中心端的监控数据,也可以保存在边缘端,本地化处理。

  3. 开源开放

    Flashcat平台的输入输出,都支持OpenAPI,可以方便的和已有的工具和生态结合,比如在数据输入上,Flashcat支持三十余种数据源,比如Prometheus/Zabbix/Grafana/ELK/Jaeger/阿里云SLS/AWS cloudwatch/阿里云监控等等,Flashcat平台中的所有数据、功能、操作,都提供了完备的API。此外,Flashcat 兼容 OpenTelemetry 协议,兼容 Grafana 和 Prometheus,与云原生生态紧密集成。

场景

不是有了上等的食材和趁手的炊具就一定能做好一道菜。

不是有了上等的食材和趁手的炊具就一定能做好一道菜

好的产品一定是在某个场景下符合了用户的需求,离开场景谈产品,属于无的放矢。稳定性保障特别是故障处理是Flashcat明确针对的场景之一。结合场景实现产品是Flashcat在设计上做了最多考虑的地方,举例几点:

1. 场景拆解

为了做好场景的产品设计,Flashcat对故障处理的场景做了拆解,拆解完后每个点上需要什么变得很明确。Flashcat 重点关注在故障发现故障定位这两个最迫切、最关键的环节,同时为日常排查提供高效的支撑。

故障处理场景拆解

2. 确保永远先于用户发现问题

Flashcat中设计了北极星系统,用于量化业务指标的健康状态和用户体验的质量。之所以叫北极星就因为这些指标就是稳定性工作的指引,是发现真故障的第一标准,是所有指标里的VIP指标。Flashcat在产品实现上会让各种资源和功能围绕北极星指标来运行,而不是将指标所需的功能散落到各个功能系统里。

针对北极星指标,预置有智能检测智能报警功能,用户基本无需配置,当北极星指标发生波动时,会第一时间被检测到,并通知相关的技术团队,真正做到技术团队先于用户发现问题。

北极星-智能报警

再比如,北极星指标实际就是最为核心的业务指标,无论是活动值守、日常巡检都是最佳选择,Flashcat针对北极星做了一键生成大屏的功能,让大屏的配置简单到极致。

北极星-大屏

3. 引导技术人员快速收敛和确定故障范围

Flashcat中的另一个VIP指标是灭火图,用来量化IT系统层面的全局健康状态,并可以回放任意时刻的历史状态,产品设计上的考虑和北极星一致。

灭火图-首页

4. 止损是第一要务:引导技术人员第一时间寻找故障的关键特征和引发故障的关键事件

故障处理中的首要原则是止损,而不是“根因定位”。有效的止损途径是确定故障的关键特征和关键事件,并以此信息为基础来决策止损预案。而“根因定位”是止损后再考虑的方向。因此Flashcat会在故障定位的路径上引导用户去做关键特征和关键事件的分析,这也是Flashcat在持续增强的方向。

比如,北极星发生报警指示业务异常,此时可以做的事情是:

  1. 分析关键特征:看异常出现在什么范围,如果异常只局限在多活的某个单元内,切流即可快速止损;
  2. 分析关键特征:定位到受影响的模块,查看模块异常日志的分布,如异常日志只出现在模块的部分实例上或集中在某些来源ip上,则只要在容量允许的情况下摘除这些实例,或封禁异常的来源ip即可;
  3. 定位关键事件:定位到受影响的模块,查看相应模块的变更记录,将正在进行的变更回滚止损;

此时不应首先做的事情是分析异常出现的根本原因,如debug代码,分析代码逻辑等。这类工作可能严重影响服务的恢复,应该在止损后进行,或是以上分析手段都失效后的无奈选择。

5. 预置最佳实践,并沉淀用户经验:让故障定位需要的下一步信息或应该看到的信息即时可得

Flashcat 中预置了典型的故障定位路径,如从异常的Metrics点击下钻查看具体的日志信息,从日志中依据traceid或接口信息向后trace,在trace到的异常模块上又能够跳转查看模块的Metrics或Logging信息。同时,Flashcat也支持用户设置自定义的定位路径,如故障分析每到一步,下一步“老师傅”们会看哪一个信息,可以把这个下一步的入口牵引到这里,这样下一次即使“小白”来了,也能够顺利的走完这个定位过程。

如,在异常的灭火图模块上,配置事件墙(变更等关键生产事件)的入口,并预置好准确的参数,下次看到这个模块异常,就可以快速查看这个模块相关的变更信息。这类可沉淀经验的产品能力,能够让产品越用越有价值,服务的稳定性保障能力也可以从依赖人,逐步转为依赖工具。

Flashcat发现故障,输出关键特征、关键事件

总结

  1. Flashcat 帮助技术人员屏蔽了使用多个分散的监控工具带来的不便,轻松监控多云多Region,从业务、到应用、基础设施,开箱即用。
  2. Flashcat 内置了故障处理的最佳实践,当业务受损时,Flashcat 总能第一时间发现,并和 IT 系统深入联动,辅助技术团队快速展开调查。
  3. Flashcat 支持物理机、网络设备、容器、K8s,微服务、主流云产品,无论采用什么样的 IT 架构,只需要一套 Flashcat 平台。

赋数据以含义

打破可观测数据孤岛,被理解的数据才有价值!Flashcat 建立了分层的信息系统,自上而下,从业务到应用、再到基础设施,从指标到日志再到链路追踪,每一层每一类数据都赋予业务/服务的含义,让数据成为普遍可识别的信息。并保留故障处理所需的核心信息,屏蔽无效信息。基于有效信息提供全局立体的业务/服务状态视角,故障处理不再只见树木不见森林。

让沉淀可持续

结合服务稳定性保障的经验和方法论,预置故障处理的最佳实践,智能识别常见的故障特征,引导用户完成故障定位的最佳路径。
日常的服务梳理不再是写到文档后束之高阁,可以直接沉淀到系统中,变成故障定位所需的信息发挥价值。
每一次服务故障都可以促进系统中信息和路径的优化,知识和技能可以进入沉淀和发挥价值的良性循环,让参与故障处理的门槛不断降低,更多的人可以参与进来。

用量化来协同

基于北极星指标量化故障,用数据说话,服务稳定性保障不再是一笔糊涂账,让保障工作在团队间形成共识。
基于北极星的量化建立故障响应流程,让系统驱动起故障处理的相关团队,并基于平台信息快速同步和有效协同;

使建设变简单

基于数据集成能力,打通主流的可观测系统,聚合变更、报警数据,和现有系统形成互补增益的关系,企业已有的基础设施无需推倒重来;
可部署在企业内部,但由快猫团队负责维护,企业只需要控制权限,并专注通过UI或API使用系统即可;

企业版

从 Open-Falcon 到 Nightingale、Categraf,快猫星云技术团队在监控领域已经深耕十年之久,支持和服务了数千家企业,是开源监控的行业引领者。我们看到很多公司从开源监控受益,也看到很多公司因为缺乏行业最佳实践,在可观测性体系建设中走了不少弯路,包括如何选型工具和构建平台,如何对可观测性数据进行治理,如何利用好可观测性数据,打通各个维度数据之间的串联关系,快速定位和止损故障。

快猫星云创始团队,均来自于阿里、百度、滴滴,快猫星云以开源夜莺为内核打造的统一可观测平台,是国内顶级互联网公司可观测性实践和服务稳定性保障方法论的产品化落地,我们致力于帮助企业快速构建统一的可观测性体系以及构建数据驱动的稳定性治理框架。下面是企业版与开源版的对比说明,您可以联系我们进一步了解企业版更多信息。
北极星
业务指标实时看板:支持可视化大屏、指标异常波动智能检测
灭火图
IT系统可用性实时看板:支持实时度量应用/基础设施健康状态,智能设定可用性目标
事件墙
发布变更和异常事件看板:支持收集和展示当前发生的重要事件,如变更、报警、运营事件
日志分析
支持日志收集、提取、查看、分析等,自动推荐和快速定位故障原因和特征
On-Call 值班中心
支持告警聚合、降噪、认领、升级、排班、协同
数据源管理
Prometheus
ElasticSearch
Jaeger
OpenSearch
ClickHouse
阿里云 SLS
腾讯云 CLS
Zabbix
InfluxDB
MySQL/Oracle/PostgreSQL/SQLServer
SkyWalking
Zipkin
数据采集器
指标(Metrics)采集
日志(Logging)采集
Tracing 数据收集
物理机/虚拟机数据采集
容器/K8s数据采集
交换机/网络设备数据采集
常用中间件/数据库数据采集
Windows 数据采集
数据采集规则集中管理和下发
仪表盘
内置仪表盘模版
导入Grafana模版
指标仪表盘
日志仪表盘
多数据源支持
告警管理
指标(Metrics)阈值告警
主机(Host)失联告警/时间偏移告警
告警规则管理:屏蔽、订阅、记录规则
活跃告警/历史告警管理
内置众多告警策略模版
日志(Logging)告警
智能告警
内置电话/短信通道(阿里云/腾讯云)
告警聚合降噪
告警升级
告警自愈
告警自愈脚本管理,自愈脚本和告警规则关联管理
分布式链路追踪
Jaeger 数据源
SkyWalking 数据源
Zipkin 数据源
Elastic APM 数据源
阿里云 SLS trace 数据源
Pinpoint 数据源
基础设施
主机分组、标签管理
主机基础元信息(metadata)展示和管理
内置多种基础设施的数据采集规则模版
主机扩展元信息(metadata)展示和管理
Categraf 采集规则集中管理和下发
人员组织
用户管理
团队管理
组织管理
角色管理
权限管理
系统配置
数据源自定义配置
通知媒介、通知渠道、通知模版自定义配置
单点登录自定义配置(OAuth、LDAP、OIDC、CAS等)
操作审计
支持关键操作和敏感操作的审计记录
技术支持
技术支持获取途径
技术支持响应级别
专家解决方案
咨询实施
方案
支持
开源版
GitHub Issue
一周
企业版
专项支持群、视频会议
7×12
7×12 专家技术支持
开源版
Flashcat
Flashduty