一、业务为什么要做播放器性能监控
上线网页 M3U8 点播直播业务，产品需要了解真实用户体验：用户起播快不快？播放会不会卡顿？卡顿发生比例高不高？
很多小项目没有任何播放器埋点监控，用户反馈视频卡顿，开发手上没有任何客观指标，只知道用户一句 "播放很卡"，无法区分是用户网络差，还是我们服务端 M3U8 分片、CDN 存在问题。
很多新手不知道要采集哪些指标，要么什么都不采集，要么采集一大堆原始日志，不知道哪些指标是有业务价值。监控不是把所有 hls.js 事件全部上报，而是提取业务可读懂的指标：起播耗时、卡顿次数、致命错误率、码率切换情况。
同时，监控告警不能看到任何警告就告警，hls.js 很多非 fatal 警告属于网络抖动，内部会自动重试，不能当成故障。监控发现指标异常之后，需要拿到对应的 M3U8 流做复现验证。排查线上播放性能问题的时候，我会使用 m3u8live.cn网页调试工具，模拟对应 M3U8 流的播放表现，用来对照线上监控数据。
二、网页播放器业务重点监控指标通俗解释
1. 起播耗时
从用户点击播放，到第一帧画面渲染出来的耗时。可以反映用户点开视频要等多久才能看到画面。起播耗时越高，用户体验越差。
2. 卡顿相关指标
- 卡顿总次数：一次完整播放过程中，缓冲区耗尽发生 stalled 卡顿的次数；
- 卡顿总时长：累计卡顿等待的秒数；
注意：弱网下少量短暂卡顿属于正常现象，重点监控卡顿占比很高的异常用户。
3. 错误类指标
- 致命错误 fatal=true 的错误，需要统计错误类型占比：清单加载失败、分片加载失败、解密失败、解码失败。致命错误代表播放器无法继续播放。
- fatal=false 的警告：网络抖动，内部自动重试，不要触发告警，只做日志留存。
4. 码率切换指标
统计自适应码率向上升级、向下降级的次数，可以侧面反映用户网络波动情况。
5. 附加环境信息
上报浏览器版本、设备类型、网络类型，出问题方便回溯用户环境。
三、新手做监控容易踩的坑
坑 1：把所有控制台报错全部当做故障告警
把 fatal=false 的普通警告也触发业务告警，告警泛滥，大量误报。只有 fatal 等于 true 才是真正致命播放故障。
坑 2：只统计错误数量，不统计播放总样本
只看到一天 100 次播放报错，不知道总播放量是 100 次还是 10 万次。要看错误占比，而不是单纯绝对值。
坑 3：只埋点上报，没有复现验证链路
监控大盘看到指标劣化，但是没有留存对应的 M3U8 流地址，无法线下复现，只能干看指标，定位不了根因。
坑 4：不区分点播和直播，一套指标直接套用
直播业务天然会有更多网络抖动事件，点播和直播的告警阈值要分开设置。
四、监控简单落地思路
- 重点采集：起播耗时、卡顿次数、卡顿总时长、fatal 致命错误类型、码率切换事件；非致命警告只记录日志，不告警。
- 计算占比：错误数 / 总播放样本数，用百分比来衡量体验好坏，不要只看绝对值。
- 指标异常的时候，同步留存对应的 M3U8 流地址、用户浏览器信息，方便线下复现。
- 点播、直播分开设置告警阈值，直播业务允许更高的抖动容忍。
- 拿到异常 M3U8，放到网页调试工具做基准复现，区分是 M3U8 资源问题还是前端业务逻辑问题。
五、总结
网页 M3U8 播放器性能监控，核心是拿到起播、卡顿、致命错误等客观指标，而不是一堆看不懂的原始日志。一定要区分致命错误和普通警告，重点看错误占比而不是单纯的错误数量。监控发现指标劣化之后，拿到对应的 M3U8 流，借助网页调试工具线下复现，区分故障归属服务端资源还是前端业务，形成监控‑复现‑修复闭环，持续改善真实用户播放体验。