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，具有中心端的采集配置管理、下发、网络设备采集模版、网络拨测等能力。

2. 针对云组件的数据采集问题，和重新部署采集方案的成本问题，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也支持用户设置自定义的定位路径，如故障分析每到一步，下一步“老师傅”们会看哪一个信息，可以把这个下一步的入口牵引到这里，这样下一次即使“小白”来了，也能够顺利的走完这个定位过程。

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

总结

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