随着系统运营时有遇到告警漏报 。 漏报常见场景:

• 监控检测逻辑不完善 ， 没有发现上报数据异常 。 这个主要通过持续优化监控逻辑来不断完善 。
• 业务服务漏报数据 ， 在生产环境中漏报原因各异 。
• 业务配置问题 ， 一般业务服务无法完全判断配置内容正确性 。
• 灰产对系统非法侵蚀 ， 如工作室对游戏道具的刷取 。

针对上述情况 ， 选取业务系统关键指标监测 。 如: 服务流量变化 ， 系统输出（在游戏营销常见道具实时发放变化） 。 也可采用主动探测业务或心跳机制避免漏报 ， 但具体实现可能比较重 。 构造现网正式请求有可能随着时间该请求会失效 ， 有一定维护成本 ， 特别在微服务场景监测服务多 。 若业务提供专门接口供探测 ， 涉及业务改造 ， 同时探测结果不一定准确 。 (在对监控系统自身监控 ， 由于相对闭环以及作为最基础监控 ， 则采用主动探测结合心跳机制) 。 这些关键指标检测逐步演化成跟安全有交集的业务监控 。
当告警达到精准有效（即召回率和精确率达到比较理想平衡） ， 就需在告警触发时 ， 给出根因分析 ， 以及建议处理方法 。 这需将各种告警信息以及系统变更信息 (业务发布 ， 扩缩容等) 进行联动 ， 分析出告警原因以及建议处理方案 。
当监控系统比较稳定 ， 与业务系统形成平衡 。 监控需根据现网运营 ， 对业务设计和运营给出合理建议和反馈 。
上述是监控系统演进大致脉络 。 具体系统实现过程并不严格按照上述线性发展 。 如上文提到的 ， 除了监控方法发展 ， 监控系统自身生技术架构也需要不断升级 。 随着技术发展 ， 技术选型相应变化 。 如实时计算框架不断升级 ， 监控引擎开发语言从 C/C++ 演化到 Go 等 。
如上所述监控从早期基于阈值配置的单层监控逐渐演化成适用于微服务环境的立体多维监控体系的分层架构 。
文章插图
监控体系从下往上依次 (智能贯穿这五层 ， 每一层呈不一样体现):

1. 资源监控层
2. 系统监控层
3. 逻辑监控层
4. 业务监控层
5. 综合监控层

第一层：资源监控层 ， 主要对业务消耗资源进行监控 ， 如 CPU/ 内存 / 网络 / 硬盘 / 网卡饱和度等 。 该层重点需知道资源相关故障影响范围和可能恢复时间 ， 并及时通过告警信息总线将相关异常通知其它监控层 ， 方便业务定位异常原因以及主动采取措施 ， 如隔离相关故障 。 早期这一层监控相对简单 ， 明确 。 随着云时代和微服务设计方式广泛应用 ， 资源自身演化成服务 ， 监控遇到挑战也越来越多 。
第二层：系统监控层 ， 主要使用业务系统上报数据 (如错误码 ， 耗时等) 触发告警 。 该层监控设计者需要熟悉业务系统设计原理 ， 服务架构 Topo ， 技术选型原因以及可能需要重点监控模块 。 系统故障根因往往需从这层相关数据解释 ， 验证 ， 因而通常采用白盒监控方法 。 该层监控类似业务系统的影子系统 ， 是整个监控体系实现架构和逻辑最重一层 。 该层与业务开发人员交互最多 ， 大多数告警治理发生在这一层 。 具体实现可根据系统服务不同功能采用不同监控方法 。 如网关类型服务就需将网关上下游服务衔接起来 。 该层智能主要体现告警收敛和故障定因 。
下面介绍一种分层检测方案 ， 异常检测按以下分类：

1. 一级敏感类 ， 只要出现即告警 ， 比较常见权限 ， 动态语言解析错误等
2. 二级敏感类 ， 异常产生以分钟为单位聚合告警
3. 小量升级类 ， 异常随着时间积累到一定量触发告警
4. 陡变检测类 ， 上报数据发生异常突变触发告警 。
5. 震荡升级 ， 服务质量不稳定触发告警
6. 自愈恢复检测 ， 对查询类延迟告警 ， 以判断是否恢复
   • 上一页
   • 1
   • 2
   • 3
   • 4
   • 下一页
   
   

   
   

   • 无边界办公——WebDAV文件共享服务构建
   • C语言开发环境
   • 第2天 | 12天搞定Python，运行环境(详细步骤)
   • Chiplet如何开拓半导体技术的未来
   • 苹果服务业务也赚钱：第四季度仍将保持两位数增速
   • 如何编写JAVA小白第一个程序
   • Nginx服务器屏蔽与禁止屏蔽网络爬虫的方法
   • 阿里云数智服务创新挑战赛落幕 南京大学夺冠
   • 如何进行不确定度估算：模型为何不确定以及如何估计不确定性水平
   • 学大数据是否有前途 如何系统掌握大数据技术