该知名火锅连锁企业是中国领先的餐饮企业，上千家门店遍布全球，由于门店餐饮行业的特殊性，需要靠前部署服务，所以在每家餐厅中，会部署相应的服务器，及相应 IT 设备，本地会运行POS、会员、下单等业务。公司有众多的餐厅门店，各个门店业务流量不同，门店的 IT 设备由于城市、开业时间等因素，其型号也不相同，服务器、应用程序分散式部署，给应用管理、IT 运维、以及先于门店发现问题，带来了极大的挑战。
所以迫切需要一个针对连锁餐饮门店的监控解决方案，以便完善监控覆盖度，及时发现并治理IT有隐患门店，提升门店IT的整体稳定性。
核心痛点
- 如何高效的集中监控所有的门店？
- 如何度量、发现、治理有 IT 隐患的门店？
- 如何让总部 IT 团队先于门店发现故障？
需求分析
1. 监控覆盖度不全
- 当前虽然有多套监控系统，但是存在监控数据不全，监控系统分散的问题，出现问题时，无法有效的收集数据进行分析；
- 门店的监控数据包括底层硬件、系统、网络、中间件、应用、交换机/防火墙、餐厅IT设备等，目前有部分监控数据还是缺失的，且需要跨团队沟通推进补齐监控采集，存在一定的推动成本；
2. 监控治理的手段不足
- 由于餐厅门店的特点，监控对象存在差异性，导致单个门店报警散发、报警频繁，无法进行有效收敛；
- 平时疲于报警，且可观测数据的不足，无法及时感知门店IT运行状况，无法及时发现趋势性问题，无法有效发现有IT隐患的“低质量”门店；
3. 进行IT“低质量”门店治理的抓手不足
- 门店的IT设施，横跨多个技术团队，有沟通、推进的成本，做为门店IT运维团队，如何推进门店IT治理，缺乏有效的手段；
方案简介
- 利用 Flashcat 的 All-in-One 采集器，统一了硬件、系统、进程等指标，并融合了公司其他内部采集系统，所有监控数据汇总一处，统一分析、处理；
- 利用“数据驱动”的理念，构建了门店 IT 质量量化体系，及时发现和治理有隐患的门店；
- 利用 Flashcat 层次化、多样化的可视化系统，构建了整个公司门店 IT 质量可视化方案，可以集中查看全局稳定性状态，同时，能够层层下钻，定位异常原因；
结合上面的需求分析，以及Flashcat的产品能力，我们围绕统一的“监控采集”、“数据驱动”的理念治理“低质量”门店，并制定了详细解决方案。
统一的监控采集
监控采集的要求
- 由于门店IT环境资源有限，我们既需要覆盖全部采集对象，同时采集器还能够尽量轻量化，少占用系统资源；
- 同时，公司的其他团队也采集了有业务特色的指标（比如餐厅Wi-Fi的信号质量，采集后存放在云存储中），需要我们一起来集成；
监控采集具体方案
- 针对业务特点，我们需要使用Categraf 监控采集器，来完成基础监控数据的采集。Categraf是一款开源采集器，能够实现All in One的监控指标采集，支持底层硬件、网络、系统、进程、各个中间件、业务等各个维度监控数据的采集；
- 门店数据库中，有门店的订单、POS、会员等实时数据，这部分我们也使用Categraf采集器的能力进行业务指标提取；
- 餐饮门店还有一些其他类型的指标，比如餐厅IT设备（Wi-Fi信号质量等），这部分指标由应用团队通过Pad应用进行采集，统一上传到云存储。之后，我们将云存储中的数据进行统一的时序化处理，处理后的数据打上对应的餐厅标签，然后录入到时序库中；
最终，所有的监控指标，都统一到了同一个时序数据库中。
其中的挑战
由于有上千家门店，且每个门店有自己的交换机、防火墙，实际上，这相当于有上千个微型IDC，给监控采集的配置带来了很大的挑战，主要包括：
- 需要集中化的管理上千台机器的采集配置；
- 部分的采集，比如防火墙、交换机的采集，每个餐厅是差异化的，这需要对上千个餐厅的网络配置进行有效管理，否则会难以维护；
- 各个餐厅的硬件设备存在差异（比如品牌、型号等等），需要采集器支持多种品牌类型的硬件设备；
- 业务指标如何采集；
应对方法
- 针对采集配置的问题：这里我们使用了Flashcat的“采集配置下发”功能，实现集中式的采集配置管理，对于数据库、业务进程的采集，全局可以一份采集模板。用户在Flashcat平台上配置/更新采集策略， Categraf 采集器会自动更新同步，从而实现平台化集中式管理，比如可以使用该功能对门店的所有机器添加一个“进程采集能力（procstat）”；
- 餐厅差异化的采集：Flashcat 目前支持了“网络设备”采集管理，在“网络设备”管理里，可以管理各个防火墙、交换机的配置信息，并能复用对应型号的硬件采集模板，提升运维效率；
- 业务指标采集：我们不仅需要关注餐厅IT基础指标，也需要关注门店的业务运营指标，运营指标波动（突增、突降），也会从业务层面反映业务稳定性。在实施时，我们目前从门店数据库，提取了门店“火锅下单”、“会员登录”等数据，通过这些数据，生成监控视图。同时，餐厅的业务指标一般具有非常强的规律性，我们可以使用基于算法的报警模型，对这些数据进行训练，并进行智能报警；
发现、治理IT“低质量”门店
“低质量”门店指存在IT隐患的门店，比如数据库性能隐患、硬件隐患、网络隐患等，或者是系统维护时漏掉的门店，环境不一致，导致程序运行性能下降，这里涉及到三个层面的问题：
- 如何具体定义IT“低质量”门店？
- 如何发现IT“低质量”门店？
- 如何治理IT“低质量”门店？
在这里，我们使用“数据驱动”的理念，制定了对应的解决方案。
定义IT“低质量”门店
这里我们需要有能够“量化”的数据来定义低质量门店，通过量化数据的高低，来进行门店IT质量的评价。同时，通过量化数据，我们还可以进行“数据驱动”，倒推各个相关团队，对得分低的环节及时进行治理。
一个餐厅门店的IT系统，包括硬件、系统、网络、中间件、业务进行、其他IT设施等等多个维度，每个维度都有几十、上百项监控指标，我们遵循哪些指标可能直接影响业务运行的原则，从这些指标中，抽取最可能直接影响业务运行的指标，来表示这个维度的健康度，健康度得分低，则为IT“低质量”门店，我们初步制定的评价指标，主要包括以下几个大的指标维度：
| 指标维度 | 说明 |
|---|---|
| 归零指标 | 该指标一旦异常，表示业务程序不可用，门店IT评分立即归零 |
| 系统维度 | 从系统层衡量门店IT健康度 |
| 数据库维度 | 衡量餐厅门店的数据库健康度（如慢查询、大表等等） |
| 网络维度 | 从网络连通性层面，衡量门店健康度 |
| 进程维度 | 从JVM维度，来衡量业务进程的健康度 |
| 硬件维度 | 从硬件维度（如物理机磁盘），来衡量门店健康度 |
| 中间件维度 | 从中间件维度，来衡量门店健康度 |
| 其他维度 | 如Wi-Fi信号质量 |
每个大的维度，又可以拆分多个具体的指标项，指标权重相加，就表示各个维度的健康度得分，具体指标项如下：
| 指标维度 | 具体指标项（权重） | 指标项说明 |
|---|---|---|
| 归零指标 | 进程存活 | 任何一个关键进程不存活，扣分 |
| 磁盘写满 | 磁盘写满，扣分 | |
| 数据库未启动 | 数据库未启动，扣分 | |
| 系统维度（权重占比 xx%） | NTP（权重占比 xx%） | 误差超过正负xxxms，扣分 |
| CPU负载（权重占比 xx%） | load 5 超过xx， 扣分 | |
| … | … | |
| … | … | |
| … | … | |
| 数据库维度（权重占比 xx%） | 数据库慢查询(权重占比 xx%) | 每秒xx个慢查询，扣分 |
| … | … | |
| … | … | |
| … | … | |
| … | … | |
| 网络维度（权重占比 xx%） | 门店到公网连通性 （权重占比 xx%） | 丢包率不为x，扣分 |
| … | … | |
| 进程维度（权重占比 xx%） | … | … |
| … | … | |
| 硬件维度（权重占比 xx%） | … | … |
| … | … | |
| 中间件维度（权重占比 xx%） | … | … |
| … | … | |
| 其他维度（权重占比 xx%） | … | … |
于是，整个门店的IT健康度，就可以用各个维度项的得分，加权起来得到：
门店IT健康度（满分100分） = 系统维度 + 数据库维度 + 网络维度 + 进程维度 + 硬件维度 + 中间件维度 + 其他维度确定好评价指标后，我们进行对应指标的提取、处理工作，将相关的监控指标，转化为“得分指标”。在计算最终的评价分数过程中，有一些特殊情况需要区别对待，比如：
- 有些指标，可能由于不同的门店，指标有差异，比如硬件、磁盘，可能由于门店服务器型号的差异、种类的差异（SSD磁盘、机械磁盘），原始监控指标是不同的，这时候我们需要对这些指标进行归一化处理，将处理后对监控数据参与到评分计算中。
- 还有部分指标，在某些时间段不希望参与评分（比如数据库在夜间可能进行正常的归档操作，业务进程在夜间可能进行程序升级等等），此时我们也需要对指标进行相应的处理，避免预期内的系统维护，影响整体评分。
发现IT“低质量”门店
每个门店的监控完善后，单店的监控指标预计超过5000个，乘以1500家门店，就有750w个监控指标，如何从海量的监控指标中发现异常数据，是个非常有挑战的工作。而且，不同的角色，关注的数据层次也有所不同：
- 专项运维人员（比如数据库运维人员），关注的是数据库维度的指标，想看到具体某个异常门店的数据库全部监控指标；
- 门店运维管理人员：关注的是餐厅整体的健康状态，期望能看到具体异常的餐厅，以及异常的维度（是系统异常还是数据库异常）；
- 公司管理人员：关注的是全体餐厅的IT运营质量及趋势；
针对上面情况，结合Flashcat的产品能力，我们将监控数据分为三个层次：
- 一般监控数据
- 核心指标项（参与IT健康度评分的指标项）
- 门店整体健康度
通过层次化的数据展示，以及层次间数据的相互关联，来满足不同群体的需求，产生的效果如下：
- 能够层次化展示餐厅门店的IT质量，满足不同的角色对于门店IT质量的可视化需求；
- 下钻关联的能力，可以支持层层下钻，找到异常餐厅，以及具体的异常原因；
- 多样化的可视化效果，可以灵活的展示异常餐厅的地理分布、异常趋势变化等，便于问题的定位排查；
比如一个典型的层次化视图如下：
由下往上：
- 仪表盘：仪表盘中的数据最为详尽，可以展示单个门店某个子系统的全部指标，一般用于排查具体问题，比如排查一个门店数据库的异常，一般一线运维人员会关注这些信息，但仪表盘也有其不足，即不能快速的看到全局数据，不能快速的从上千家门店中，筛选出异常的门店；
- 灭火图：展示门店某个系统的健康度，比如上图，一个卡片表示一个门店“网络”（或者是数据库…）的健康度，当某个门店网络的核心指标异常时，该门店“网络”的灭火图就会自动“飘红”，灭火图的优势是可以展示某个维度的所有“核心指标”，能看到这个维度的全部餐厅状态，并快速筛选异常门店，但缺点是数据不如仪表盘详尽；
- 北极星：可以一眼看到全局信息，比如通过“蜂窝图”，一眼可以看到异常门店。
由上往下： 在进行问题定位时，我们可以实现从上往下（从全局到局部），层层下钻，找到问题的原因。
- 从北极星中找到异常的门店，如果我们想了解具体的异常信息，可以下钻到灭火图；
- 灭火图告诉我们XX维度中，哪些门店哪个核心指标发生了异常，以及异常前的状态；
- 灭火图可以进一步下钻，定位具体餐厅，下钻到具体XX维度的仪表盘，从而帮助我们找到具体原因；
北极星还具有多样化的数据展示能力：
- 通过“表格”的形式，我们可以实时看到数据排名，找到得分最低的门店，重点治理；
- 通过“时序图”的形式，可以看到问题发展的趋势，更容易找到问题规律；
- 我们还能自动根据餐厅坐标，生成基于地图数据的动态大屏，更好的呈现门店健康度，如下图，是基于全国地图/省份地图的餐厅坐标：
北极星的报警/报表能力：
- 实时监控报警：可以基于北极星、灭火图，以及具体的指标曲线，配置报警策略，实时发现问题，便于运维一线团队及时跟进；
- 每周报表：我们还支持数据导出的功能，每周餐厅各维度的数据，可以导出成csv，可以供相关团队使用（比如用于发送定期周报等等）；
治理IT“低质量”门店
发现问题要及时治理，才是我们方案的初衷，但在实际的治理中，做为门店稳定性的负责人，我们往往需要推动不同的技术团队：
- 完善相关的指标覆盖度；
- 跟进平台发现的问题，及时跟进治理；
- 推动相关团队完善、遵循运维规范；
跨团队的沟通、推进，是成本较高的工作，这里，我们利用“数据驱动”的思路，将“门店IT情况”每周汇总、低质量门店跟进等数据生成相关周报，推送给各个团队及其负责人，由上向下进行治理，落实工作跟进；
总结
在落地Flashcat的过程中，遇到了很多挑战：
- 首先是方案设计的核心理念是什么？怎么定义低质量，怎么推进治理？在方案确认的过程中，逐渐完善了方案，利用“数据驱动”的思想推动整体方案落地，利用数据，来对低质量门店进行量化，利用数据来驱动问题的治理；
- 其次是数据的统一采集，涉及到上千家门店，其实就是上千个微型的数据中心，需要对上千个数据中心，上千台机器进行采集配置下发，是有很大挑战的，这里Flashcat的采集管理、网络管理，可以很好的解决。同时像业务指标、其他团队的监控指标，Flashcat 都统一对其进行时序化处理，将数据统一在一个数据库中，进行相关性分析；
- 数据的层级化、多样化展示有很大挑战，Flashcat构建了餐饮门店完善的监控可视化解决方案：
- 层级化：由于餐厅的特点，我们既需要关注全局状态，也需要查看局部的差异，传统的“类Grafana”样式的仪表盘很难做到层次化的展示，主要的问题在于，“类Grafana”的仪表盘往往是静态配置，关联关系也是静态配置的，而餐厅是动态的，我们需要根据餐厅的开店/关店，实时动态调整。而在Flashcat中，表示餐厅状态的“灭火图”就是动态生成的。 而且Flashcat的北极星-灭火图-仪表盘的层级设计，非常符合餐饮门店业务的 全局-异常餐厅-细节问题，这样的场景；
- 多样化：北极星支持蜂窝图、时序图、表格图等多种样式，帮助我们展示现状，分析趋势，同时可以基于坐标数据自动生成相关地图大屏，展示全国、各省、市的餐厅健康状态，便于企业内部呈现，引起相关领导及业务方的重视；
- 完善的数据加工能力，像业务营业期/维护期的处理，不同硬件类型数据统一化处理，这里对于一个标准化监控产品是没有相关能力的，这里Flashcat团队制定了相关的监控数据加工方案，实现了预期效果；