MONITORING · 监控体系

看得见,才管得住
网站监控与告警体系

网站宕机、接口变慢、磁盘将满……问题第一时间知道,才能第一时间解决。本讲从监控指标、日志、告警到可观测性,讲透一套完整的监控体系,让团队"先于用户发现问题"。

指标Prometheus + Grafana
日志集中采集与检索
链路全链路追踪
告警第一时间通知
PAIN POINTS

没有监控,问题全靠用户发现

📵

网站挂了,用户投诉才知道

凌晨宕机,第二天上班才看到用户刷屏,损失已经发生且无法挽回。

🌫️

磁盘爆满,服务器直接卡死

没有预警,磁盘日志把空间吃满,网站突然打不开,重启也没用。

🐢

接口变慢,不知道卡在哪

只知道"慢",但不知道是前端、后端还是数据库,排查全靠猜。

PILLARS

可观测性三大支柱

📊

指标 Metrics

CPU、内存、QPS、延迟等量化指标,Prometheus 采集 + Grafana 可视化。

📜

日志 Logs

集中采集与全文检索(ELK/Loki),排错定位的"第一现场"。

🔗

链路 Traces

跨服务请求全链路追踪(SkyWalking/Jaeger),定位慢在哪个环节。

METRIC CHART

监控指标速查表

分层监控,每层看什么、用什么,一目了然。

层级核心指标常用工具
基础设施CPU / 内存 / 磁盘 / 网络node_exporter + Grafana
应用服务QPS / 延迟 / 错误率 / 饱和度Prometheus + 应用埋点
数据库连接数 / 慢查询 / 主从延迟mysqld_exporter + 性能洞察
业务订单 / 转化 / 活跃 / 营收埋点 + 看板
用户端LCP / CLS / INP / 崩溃率RUM 真实用户监控
可用性拨测 / 证书到期 / 首页状态全球拨测 + 告警
ALERTING

告警策略设计要点

01

告警分级

P1 严重(宕机)/ P2 警告(延迟高)/ P3 提示(容量趋势),不同级别不同响应。

02

避免告警轰炸

同类告警合并、抑制与静默,防止"狼来了"让团队麻木。

03

多渠道触达

IM/短信/电话分级通知,关键故障必须有电话兜底。

04

值班与复盘

On-call 轮值 + 事后复盘,把每次故障变成体系改进。

USE CASES

监控用在哪

🌐

网站可用性

全球拨测 + 服务器指标监控,宕机分钟级告警。

📈

业务指标

下单量、转化率、接口成功率,异常波动即时发现。

🖥️

基础设施

服务器、数据库、容器集群的资源与健康监控。

🧩

微服务链路

跨服务调用追踪与依赖分析,分布式排错不再抓瞎。

网站出问题总靠用户提醒

我们提供监控体系搭建与告警服务,让问题在影响用户之前被发现。

FAQ

监控体系高频问答

基础设施(CPU/内存/磁盘/网络)+ 应用(QPS/延迟/错误率)+ 业务(订单/转化)+ 可用性(拨测)。按"用户视角 + 系统视角"分层监控。
开源组合:Prometheus + Grafana 指标、Loki/ELK 日志、SkyWalking/Jaeger 链路;云厂商(云监控)开箱即用。小站可从云监控起步。
合并同类、设置合理阈值与持续时间(抖动抑制)、按服务分组静默、定期评审收敛。目标是"每个告警都值得处理"。
用 RUM(真实用户监控)采集 LCP/CLS/INP 等 Web Vitals,配合错误上报(window.onerror)与埋点,反映真实用户体验。
小规模用开源方案自建成本可控;日志量大时存储是主要成本,可分级存储(热/冷)+ 采样。相对宕机损失,监控投入回报极高。
做"混沌演练":故意制造故障(停服务/满磁盘),看是否按时告警、能否快速定位。每次故障复盘检查监控盲区并补齐。
轻量选 Loki + Promtail(与 Prometheus 同源),传统选 ELK(Elasticsearch + Logstash + Kibana);关键点:结构化输出、按服务/级别索引、保留期策略。
先用历史数据定基线(P95/P99),再设定阈值 + 持续时长(如 CPU 90% 持续 5 分钟),避免瞬时抖动误报;上线后按告警命中率持续调优。

先于用户发现故障,才是专业

编程新知提供监控告警与 7×24 运维服务,让网站故障分钟级响应。