打开浏览器按F12，看网控切到Network面板，站实刷新页面，时监看着那一行行请求滚出来——这就是看网控最原始的网站实时监控。不用任何工具，站实不用装软件，时监你就能看到每次加载背后发生了什么：哪些资源慢了，看网控哪个接口报500了，站实哪个第三方脚本拖了后腿。时监很多人以为监控需要一套复杂的看网控系统，其实从你按下F12那一刻起，站实监控就已经开始了。时监

但手动看显然不现实。看网控你不可能24小时盯着屏幕。站实真正实用的时监做法是让机器替你盯着，出事了再叫你。我自己的博客用的是Uptime Kuma，跑在一台1核1G的小机器上，每60秒发一次HTTP请求，状态码不是200就发通知到手机。配置过程大概五分钟，比装个WordPress还快。它监控的不只是“网站活着没”，还能检查特定关键词是否出现在页面里——比如你电商站的“加入购物车”按钮，如果某次返回的HTML里少了这几个字，说明页面结构被改坏了，哪怕状态码是200，照样报警。

光知道“挂了”不够，还得知道“哪里挂了”。这就轮到APM工具上场。以前用New Relic，功能全但贵得离谱。后来换到Grafana加上Prometheus，自己搭一套，成本骤降。具体做法是在服务器上跑一个node_exporter，把CPU、内存、磁盘IO暴露出来；应用层用middleware埋点，记录每个请求的耗时和状态。Grafana面板一拉，哪条曲线突然翘起来，鼠标悬上去就能看到具体是哪个接口、哪个SQL拖慢的。有次我发现凌晨三点数据库连接数飙升，查下来是备份脚本没关连接池，这种问题靠人眼根本发现不了。

前端监控是另一个维度。用户说“网站卡”，你问他具体哪里卡，他答不上来。这时候需要RUM（真实用户监控）。在页面里嵌一小段JS，收集每个用户的加载时间、白屏时间、JS报错。我见过一个案例：某网站首页在Chrome里秒开，但在某国产浏览器里要8秒。RUM数据一拉，发现是某个polyfill在那个浏览器里反复执行了上千次。没有真实用户数据，这种问题你测一辈子都测不出来。

日志监控也绕不开。ELK那套（Elasticsearch、Logstash、Kibana）太重，小团队用Loki加Grafana足够。Nginx的access log和error log直接丢给Promtail，Grafana里按状态码、URL、响应时间做聚合。有次线上502暴增，我在Grafana里搜了一下，发现所有出问题的请求都指向同一个后端IP，而那台机器的健康检查端口恰好被防火墙拦了。从报警到定位，不到两分钟。

监控的终点不是 dashboard，是通知。但通知太频繁等于没通知。我吃过亏：一开始把所有warning都发到手机，结果一晚上被吵醒七次，第二天直接关掉了通知。后来改成分级——P0电话叫醒，P1发钉钉，P2只写进日报。P0的定义很窄：首页不可访问超过30秒，或者支付接口成功率跌破95%。其他一律不配叫醒我。这个阈值是拍脑袋定的，但比没有强。监控系统再先进，最后做判断的还是人。

还有一点：监控自己也会挂。你的监控脚本跑在服务器上，服务器宕机了，监控也跟着没了，你反而收不到报警。所以关键监控得放在外部。我用的是UptimeRobot的免费版，从美国、欧洲、亚洲三个节点同时探测，只要两个节点都报故障才发通知。虽然免费版只有5分钟间隔，但对个人项目够用了。商业项目建议上Better Stack或者Pingdom，贵是贵点，但探测频率能到30秒，还有状态页功能。

说到底，网站实时监控不是买一个工具就完事。它是一套组合：浏览器开发者工具做临时排查，Uptime Kuma做可用性报警，Prometheus加Grafana做性能趋势，RUM做真实用户体验，Loki做日志聚合。每层解决不同问题，缺一层就多一个盲区。别想着一步到位，先从最简单的开始——哪怕只是写个cron脚本每五分钟curl一次首页，也比什么都不做强。