2025.11–2026实习相关整理5
企业监控告警平台
1. 背景
随着企业业务的发展，服务实例数不断增长的同时监控数据的类型和数量也呈现爆发式增长的趋势。为了更好地管理这些监控指标数据，我们引入了一个统一监控平台，旨在统一管理各类监控数据指标，包括指标配置、告警订阅、告警通知、数据查看、拓展接入、开放接口等。
通过这个平台，帮助业务更及时、精确地定位和解决问题，提高服务的可用性和稳定性。标准化告警配置与告警口径，降低理解成本，提升效率。
2. 监控平台
2.1 数据指标
监控平台接入的监控数据分类：
graph TD
A[监控数据] --> B[业务指标]
A --> C[拓展指标]
A --> D[系统指标]
B --> B1[IDKey]
B --> B2[调用关系]
B --> B3[业务模块/框架埋点上报]
C --> C1[域名证书监控]
C --> C2[基础agent监控]
C --> C3[Prometheus数据接入]
C1 --> C1a[自建prober探测上报]
C2 --> C2a[SDK上报]
D --> D1[单机属性]
D --> D2[PaaS/CVM云平台指标]
D --> D3[网络ping状态]
D1 --> D1a[CPU]
D1 --> D1b[磁盘]
D1 --> D1c[进程]
D2 --> D2a[DB满查询]
D2 --> D2b[连接数]
D2 --> D2c[负载]
style A fill:#e1f5ff
style B fill:#fff4e1
style C fill:#fff4e1
style D fill:#fff4e12.2 数据应用与自动化
监控数据被广泛应用到各个业务系统：
graph LR
A[监控数据] --> B[告警用途]
A --> C[业务系统应用]
C --> C1[变更]
C --> C2[扩/缩容]
C --> C3[容灾演练]
C --> C4[智能定位]
C --> C5[可用率不达标跟进]
C --> C6[计数指标]
C --> C7[预算自动预测]
D[monitordatabroker<br/>数据服务] --> E[OpenAPI<br/>监控数据查询]
E --> F[各业务系统]
style A fill:#e1f5ff
style D fill:#ffe1e1
style E fill:#e1ffe1自动化措施
- 监控项OpenAPI - 通过接口申请监控上报
- 告警配置OpenAPI - 通过接口新增告警配置、调整参数
- 监控配置模板 - 直接应用模板配置的阈值、算法等参数
应用案例
案例一：智能语音识别 ——将连续语言快速识别为文字，给应用配上”耳朵”
flowchart LR
A[应用接入] --> B[监控项OpenAPI<br/>申请指标]
B --> C[应用调用<br/>监控指标上报]
C --> D[月底计费]
D --> E[监控数据Databroker<br/>查询指标数据]
E --> F[完成计费]
style B fill:#e1f5ff
style E fill:#e1f5ff案例二：可用率系统 ——功能指标可用率计算、不达标跟进
flowchart LR
A[功能指标接入] --> B[上报IDKEY]
A --> C[上报调用关系]
A --> D[上报多维数据]
B --> E[监控数据Databroker<br/>查询并计算]
C --> E
D --> E
E --> F[数据落库]
F --> G{指标达标?}
G -->|否| H[自动生成工单]
H --> I[机器人跟进]
G -->|是| J[监控完成]
style E fill:#e1f5ff
style H fill:#ffe1e1
style I fill:#ffe1e1
classDef keyData fill:#e1ffe1,stroke:#333,stroke-width:2px;
class K keyData;当前可用率系统已有 4600+ 功能指标接入，覆盖了基础服务、模式识别、开放平台、内容平台、运营系统、安全等产品。
2.3 系统架构
监控平台系统架构整体分为6个板块：
graph TB
subgraph "监控平台系统架构"
direction TB
subgraph A["UI层 - 用户交互"]
A1[站点服务]
A2[监控数据Broker]
A3[告警配置服务]
end
subgraph B["DataCollector层 - 数据采集"]
B1[globalagent<br/>业务层埋点上报]
B2[系统层单机属性指标]
end
subgraph C["DataProcessor层 - 数据处理"]
C1[map-reduce处理]
C2[入库TSDB]
end
subgraph D["TSDataStorage层 - 时序数据存储"]
D1[TSDB数据库]
end
subgraph E["ExtData层 - 拓展数据"]
E1[ping状态]
E2[prometheus]
E3[agent状态]
E4[云平台CVM/PaaS]
end
subgraph F["DetectAnomaly层 - 异常检测"]
F1[加载告警配置]
F2[处理监控数据]
F3[异常检测]
F4[告警通知]
end
end
B -->|推送| C
B -->|单机属性| F
C --> D
F --> A1
E --> F
style A fill:#fff4e1
style B fill:#e1f5ff
style C fill:#e1ffe1
style D fill:#f5e1ff
style E fill:#ffe1e1
style F fill:#e1ffff2.4 平台功能
常用功能入口：
- 监控门户 —— 可管理告警模板、管理告警配置、管理告警单据、管理订阅等
- 多维监控 —— 支持新增上报多维度的数据，查询数据、配置告警等
- 数据查看 —— 支持配置各个数据源数据面板
- IDKey管理 —— 新增IDKey上报，管理IDKey元数据信息
3. 优化与拓展
接下来列举监控平台在”全”、“快”、“准”、“稳”等方面做的优化与拓展。
3.1 基础agent监控数据 🌟
企业现网环境的层次结构：
graph TB
subgraph "企业现网环境"
A[业务层]
B[基础环境层]
subgraph B1["各种全局Agent"]
B1a[单机基础数据采集上报]
B1b[模块认证]
B1c[监控数据上报]
B1d[变更/jobs任务执行]
B1e[定时任务执行]
end
A --> B
B --> B1
end
style A fill:#e1f5ff
style B fill:#fff4e1
style B1 fill:#e1ffe1各Agent关键作用：
- 模块认证 挂了 → 影响模块认证 → 服务调用认证拒绝
- 定时任务执行 挂了 → 影响定时任务 → 全局保活CK任务失败
- 单机基础数据采集上报 挂了 → 影响基础数据采集 → 数据缺失无法及时发现问题
解决方案：监控平台设计开发了 agentstat监控
- agent心跳上报SDK
- 数据存储
- 数据汇聚查询
3.2 证书监控 🔄
旧版监控路径
flowchart TD
subgraph A["旧版证书监控"]
direction TB
A1[DB登记的证书文件及路径] --> A2[扫描]
A3[包管理] --> A4[获取证书文件信息]
A5[拨测域名] --> A6[获取cert信息]
A2 --> A7[有效期检测]
A4 --> A7
A6 --> A8[解析检测有效期]
style A fill:#ffe1e1
style A7 fill:#ffb3b3
style A8 fill:#ffb3b3
end问题：
- 包管理形态不再能支持证书监控（上云进程加快）
- 拨测域名解析cert信息存在漏网之鱼
- 发生证书过期故障：
- 证书文件已更新但无重新加载
- 邮箱域名证书无登记漏监控
新版监控路径
flowchart TD
subgraph B["新版证书监控 - 优化后"]
direction TB
B1[域名关联模块实例] --> B2[全量拨测]
B2 --> B3[证书监控有效覆盖]
B4[支持私有协议] --> B5[内部业务证书监控]
B6[自动接入业务域名] --> B7[避免增量缺少监控]
B8[工单机器人跟进] --> B9[自动化跟进流程]
B3 --> B10[告警触达]
B5 --> B10
B7 --> B10
B9 --> B10
style B fill:#e1ffe1
style B10 fill:#b3ffb3
end优化亮点：
- ✅ 增加域名关联模块实例的全量拨测
- ✅ 支持私有协议，满足内部业务证书监控需求
- ✅ 自动接入业务域名，避免增量缺少监控
- ✅ 工单机器人跟进，自动化跟进流程
成果：自上线以后，接入证书监控后相关的故障不再发生。
3.3 异常检测链路重构 ⚡
旧架构问题
graph TD
A[旧架构问题] --> B[MQ异步组件]
A --> C[链路重试/感知缺失]
A --> D[链路隔离级别差]
A --> E[自监控不完善]
B --> B1[时延不可控]
B --> B2[可用性不可控]
B --> B3[曾发生故障导致服务停摆]
style A fill:#ffe1e1
style B fill:#ffb3b3
style C fill:#ffb3b3
style D fill:#ffb3b3
style E fill:#ffb3b3重构方案
flowchart TB
subgraph A["重构方案 - 同步架构"]
direction TB
A1[同步化重构<br/>去除外部组件依赖]
A2[任务状态持久化存储<br/>全链路反馈机制]
A3[全链路条带化拆分<br/>各业务/任务相互隔离]
A4[自监控完善<br/>多集群交叉互备<br/>定期兜底巡检]
A1 --> A5[提升故障发现能力]
A2 --> A6[提升故障响应能力]
A3 --> A7[提升故障定位能力]
A4 --> A8[提升故障恢复能力]
style A fill:#e1ffe1
style A5 fill:#b3ffb3
style A6 fill:#b3ffb3
style A7 fill:#b3ffb3
style A8 fill:#b3ffb3
end优化成果
graph LR
subgraph A["优化效果"]
A1[异常检测链路重构] --> A2[稳定性提升]
A2 --> A3[batch/cache设计]
A3 --> A4[告警配置DB负载峰值<br/>降低80%]
A3 --> A5[IDKey TSDB存储压力<br/>降低40%]
end
style A fill:#e1ffe1
style A4 fill:#b3ffb3
style A5 fill:#b3ffb33.4 推拉组合监控 🎯
单机属性监控指标
mindmap
root((单机属性监控))
CPU/GPU/内存
CPU使用率
GPU使用率
内存使用率
系统状态
重启
OOM
Core
网络
发送流量
接收流量
TCP连接数
磁盘
掉盘
只读
磁盘使用率拉模式 vs 推模式
graph TB
subgraph A["拉模式 - 用于IDKey/调用关系"]
direction TB
A1[异常检测层] --> A2[查询TSDB]
A2 --> A3[获取监控数据]
A3 --> A4[多条数据曲线对比]
A4 --> A5[窗口异常检测]
style A fill:#e1f5ff
end
subgraph B["推模式 - 用于单机属性"]
direction TB
B1[数据入库处理层] --> B2[推送数据到异常检测层]
B2 --> B3[流监控]
B3 --> B4[实时检测]
style B fill:#e1ffe1
end
subgraph C["推模式优势"]
C1[降低TSDB查询压力]
C2[降低告警延迟]
C3[提升告警速率]
C4[99%+指标使用阈值算法]
style C fill:#b3ffb3
end
B --> C问题与解决
| 问题 | 原因 | 解决方案 | 效果 |
|---|---|---|---|
| 数据查询失败 | 单机属性数据属于明细数据，展开维度高达3kw | 推模式 - 流监控 | 日均检测异常告警项1.2w左右 |
| TSDB高负载 | 拉模式对TSDB查询压力过大 | 数据入库层直接推送到异常检测层 | 全链路可用率99.99%+ |
flowchart LR
A[单机属性监控挑战] --> B[明细数据<br/>ip*ip各属性]
B --> C[维度展开高达6kw]
C --> D[拉模式TSDB查询压力极大]
D --> E[TSDB高负载失败]
F[推模式解决方案] --> G[数据入库处理层]
G --> H[推送到异常检测层]
H --> I[流监控实时检测]
E --> F
I --> J[日均检测2w异常告警]
I --> K[全链路可用率99.99%+]
style A fill:#ffe1e1
style F fill:#e1ffe1
style J fill:#b3ffb3
style K fill:#b3ffb33.5 数据入库检测 ✅
问题：误告导致”狼来了效应”
flowchart TD
A[数据入库问题] --> B[链路故障]
A --> C[变更引入bug]
A --> D[其他入库异常]
B --> E[误告]
C --> E
D --> E
E --> F[狼来了效应]
F --> G[影响业务]
F --> H[告警可信度降低]
style A fill:#ffe1e1
style E fill:#ffb3b3
style F fill:#ff9999解决方案
flowchart LR
A[解决方案] --> B[新增数据入库状态上报]
A --> C[数据入库状态存储]
A --> D[异常检测任务下发层检查]
B --> E[数据入库状态上报]
C --> E
D --> F{入库状态正常?}
F -->|否| G[拦截有问题的监控项]
F -->|是| H[正常告警检测]
G --> I[避免误告]
H --> I
I --> J[提升告警准确性]
style A fill:#e1ffe1
style G fill:#b3ffb3
style J fill:#b3ffb34. 结语
本文从监控平台的数据源、数据应用与自动化、系统架构、平台功能做全景解读，列举了监控平台在”全”、“快”、“稳”、“准”方面做的一部分优化拓展并展示了落地的成果。
优化成果总结
| 维度 | 优化内容 | 核心成果 |
|---|---|---|
| 全 | 基础agent监控 | 接入15w+实例，覆盖各类agent |
| 全 | 证书监控 | 域名关联模块全量拨测，杜绝过期故障 |
| 稳 | 异常检测链路重构 | 可用率99.99%+，DB负载降低80% |
| 快 | 推拉组合监控 | 日均检测1.2w异常，告警延迟降低 |
| 准 | 数据入库检测 | 避免误告，提升准确性 |
未来规划
后续监控平台将继续完善：
- ✨ 数据的全面性
- ⚡ 告警的低时延
- 🧠 定位的智能化
- 🤖 流程的自动化
- 🎛️ 配置的灵活性
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 Lowo's blog！
微信
支付宝
评论