先说明，这个不是我的原创，只是用来笔记。
业务监控大盘的主要作用
业务监控大盘（以下简称大盘）的作用主要是2项。
- 直观显示业务核心指标的趋势，在日常运行和发布变更的过程中可以通过这些指标便捷地判断业务是否正常。
○ 业务指标 > 系统指标：业务指标出现问题，要第一时间确认是否是系统问题。系统指标出现问题，要第一时间评估对业务的影响。 - 当业务指标出现异动时，大盘可以帮助定位问题的原因，确定影响的范围。
○ 指标的选取和布局应体现出因果性、相关性。
○ 指标的维度要能帮助使用者收敛问题发生的点。单元 * 机房是一种常见的维度。
○ 指标的时效性要满足使用的需要，以及便捷性。流量、成功率等指标往往只需要秒级，错误码这类指标的分钟、秒级统计则各有适用场景。
题外话：这份建议介绍的只是自定义的业务监控大盘，通常是采用sunfire来配置。至于sunfire、eagleeye里开箱即用的系统监控，则不在讨论范畴。但是，系统监控的告警设置是一个重要的话题，不久就会做专门介绍，并且是FY24 Q3与Q4将开展的应用健康度治理活动的重要工具。
指标的选取
2.1 最常见的3种核心指标
● 流量
○ 多数业务域、业务场景都有若干个关键流量指标，比如正向交易的购物车查看、确认订单、创建订单。它们往往是故障等级定义的观测指标，或是与观测指标有因果关系、强相关性的其他指标。
○ 另外，除了类PV的原始流量指标以外，也会选取这类流量转换所带来的业务指标，比如创建的交易主订单量，它由创建订单请求产生。
○ 每个流量指标应细分为总流量（入口原始流量）、成功量、失败量（可选）、限流量（快速失败的一种，应该显式呈现）。
○ 产品动线，或是业务场景里强相关的一组流量指标可以放置在一个监控项，但不宜过多。这种情况下，一般会为这组流量指标再设置对应的成功量、成功率监控项。
○ 区分正常流量和压测流量。可以有包含正常和压测总流量的监控项，但应有单独的监控项或者大盘做区分。
● 成功率
○ 基于上述流量指标，设置配套的成功率指标。例如，创建订单请求量，就应有创建订单请求的成功率。系统接收到多少请求，它成功处理了多少，这是一类很实用的观察指标。
● RT
○ 基于上述流量指标，设置配套的RT指标。PV的RT是衡量用户体验的一项关键指标，同时它的激增往往意味着系统出现了问题。
2.2 其他常见指标
● 错误码
○ 应用的接口，一般对齐流量类型，设有较完善的错误码体系时，就应设置配套的监控项。这样可以在成功量、成功率下跌时快速地定位失败原因，所以错误码本质上是成功率的一个下钻指标。从大类来看，错误码主要有以下3种类型。
■ 限流：包括sentinel（接口、key限流）、noah（自适应限流），它们一般作为单独的监控项
■ 业务规则引起的失败：例如下单时商品售罄造成扣减库存失败，安全风控阻断的访问
■ 系统问题引起的失败：例如下游服务超时
○ 业务规则和系统问题的错误码一般直接放在一个监控项内，形式上是表格。
这里对限流多说一句，入口应用没有配置限流是绝对不可以的！入口应用的下游要为自己做限流，不能把自己的安全完全交给上游！
2.3 特色指标
除了上述常见的指标，能够反应业务流量的压力与负载，以及能够帮助排查问题的指标也可以纳入进大盘。这里举几个例子：
● buy2下单大盘的拆单比：用户提交订单时的平均主订单数，值越高意味着合并下单越多，系统处理单个请求的负载越高。
● taodetail详情大盘：平均SKU数量，值越高意味着库存、供应链系统的计算压力越大。
维度的设计
最常见的维度 - 单元/机房
单元*机房是最常见的维度，章节2.1里提到的3种核心指标都应设置按这个维度区分的监控项。
● 当个别单元*机房出现异常时，这类监控可以迅速帮助定位到是哪个单元*机房出现了问题。
● 每个单元*机房都存在许多差异性，最典型地是会对性能产生影响。通过区分单元*机房查看RT等指标，可以了解和印证同一套系统在不同单元*机房所表现出的差异性。
● 不要单独使用单元、机房作为维度，因为同一个单元会有多个机房，同一个机房也可能有多个机房，需要按最小颗粒度做区分。
其他维度
其他维度通常带有很强的业务特性或时效性，让这个监控项最有效、最便捷地帮助到SRE、研发是第一优先的原则。
● 业务特性：例如业务身份、业务类型来细分某个流量指标。
● 时效性：例如接口版本，通常用在系统切流阶段。
监控项布局
● 最核心的指标放首屏
● 从前至后
○ 用户动线、产品链路时序从前到后。比如buy2大盘里确认订单 -> 提交订单，逆向交易大盘里路由 -> 详情 -> 渲染 -> 提交 -> 同意，等等。方便查看是从哪个环节开始出现问题的。
● 从上至下
○ 技术链路，因果关系从上至下。流量 -> 成功率/RT -> 限流 -> 错误码。这体现了排查问题的典型思路，比如成功量跌了，是总流量就跌了还是成功率跌了，成功率跌了是因为自身负载高了（RT飙升），还是限流或是某类错误？
● 从粗至精
○ 按维度做细分，先看指标的总量，再看某个维度每个分类的量。最典型的就是按单元*机房来查看，排查问题时一个典型的思路就是看总量跌的时候，是所有单元*机房一起跌，还是个别机房在跌。其他维度也可以起到一样的作用。
