指标===》规则（预警、告警）==》告警中心（/多通道/信息精简/聚合/限流/分级/）

路由：通过 app 等信息，找到对应的收件人（cmdb 支撑）

管理闭环：忽略、关闭、升级、转事件、转需求、自愈联动

RCA: 根因分析

复盘+SOP

度量+成本+大盘

报警系统

指标采集==》指标存储==》规则报警

这部分足够庞大，完全可以是一个独立的系统。

抵达用户

报警信息===》（渠道）====》抵达到用户

报警的接收

说明

好的接口设计，不要有任何的歧义。

用户送的尽可能的少。

保证安全性、拓展性。方便问题的排查等等。

安全性

所有的系统，必须有对应的申请记录。方能调用，不然后续会非常乱。

系统的申请

appKey
appSecret

这个一般可以和审批系统结合，或者初期管理员人工添加。

频率不高，但是比较重要。

鉴权

提供对应的 client 包，初期可以实现 java 等。

启动启动时，做一次统一的鉴权。

针对我们的需求，我们设计一些核心的表。

满足我们的需求。

申请系统表

说明

记录申请的系统表，以及对应的接口能力。

语句

drop table if exists alarm_system_info;
CREATE TABLE alarm_system_info (
    id bigint(20) PRIMARY KEY auto_increment comment '主键',
    system_id varchar(64) NOT NULL comment '系统标识',
    system_name varchar(64) NOT NULL comment '系统名称',
    config_status varchar(512) NULL comment '配置状态',
    config_remark varchar(512) NULL comment '配置备注',
    create_time datetime comment '创建时间',
    update_time datetime comment '更新时间',
    create_by VARCHAR(64) comment '创建人',
    update_by VARCHAR(64) comment '更新人',
    UNIQUE KEY (config_name)
) COMMENT '报警系统信息';

alarm-admin===>控台

alarm-executor===>核心实现====》goutong-center（依赖渠道中心）

==> cmdb 等基础数据信息

说明

做一下简单的核心实现。

申请系统表

说明

记录申请的系统表，以及对应的接口能力。

实现

接口可以选择是否控制，一般也可以不控制这么细致。

报警信息

核心表

事件表

收件人

初期可以简单些，直接根据用户传入的为准。

一般而言，我们希望监控可以指标，比如交易的成功率。

成功率 = (成功数 / 交易总数) * 100%

大家好，我是老马。

本文为大家介绍一些简单有效的配置指标。

chat

介绍软件监控中简单的配置，比如异常数，同比，环比

一、核心指标定义

1. 异常数（Anomaly Count）

   • 定义：单位时间内超出预设阈值（如固定值、标准差、箱线图Whisker线）的数据点数量。
   • 用途：快速定位系统异常波动（如API错误率激增、CPU使用率突增）。

2. 同比（Year-over-Year, YoY）

   • 定义：当前时间段与去年同期同一时间段的数值对比。
   • 公式：(当前值 - 去年同期值) / 去年同期值 × 100%
   • 用途：消除季节性影响（如电商大促期间流量对比）。

3. 环比（Month-over-Month/Week-over-Week, MoM/WoW）

   • 定义：当前时间段与上一个连续周期（如上周、上月）的数值对比。
   • 公式：(当前值 - 上周期值) / 上周期值 × 100%
   • 用途：检测短期趋势变化（如用户活跃度周环比下跌）。