tencent cloud

云直播

文档云直播运维指南CLS 协助直播问题排查

CLS 协助直播问题排查

PDF
聚焦模式
字号
最后更新时间： 2026-03-16 11:32:50

准备工作

请先参考 文档，将日志投递到腾讯云日志服务（CLS）。

目的

通过腾讯云日志服务（CLS）实时采集并分析 CSS 播放访问日志，帮助您快速缩小直播问题的排查范围，定位客户端、网络、CDN、源站及推流端编码配置等链路中的根因，从而提升故障排查效率与运维效率。

推荐看板

使用方法

运行前，请先替换以下参数：
{start_time}、{end_time}：通常通过 CLS 时间选择器设置；仅在确有需要时再补充显式时间戳过滤条件。
{host} ：域名
{streamname}
{client_ip}
{interval}（例如 1 minute / 5 minute，请与您的 CLS SQL 语法保持一致。）

播放—概览/错误

HttpCode 趋势（200 vs 4xx vs 5xx）

目标：确认错误是否出现突增，并区分4xx与5xx。
输出：时间分桶 + 200/4xx/5xx 数量。
type:"lvb"
and host:"{host}"
and streamname:"{streamname}"
| select
    histogram(cast(__TIMESTAMP__ as timestamp), interval 1 minute) as analytic_time,
    sum(case when http_code = 200 then 1 else 0 end) as http_code200,
    sum(case when http_code >= 400 and http_code < 500 then 1 else 0 end) as http_code4XX,
    sum(case when http_code >= 500 then 1 else 0 end) as http_code5XX
  group by analytic_time
  order by analytic_time
  limit 1000


按域名统计错误数（req_4xx/req_5xx）

目标：找出异常域名。
输出：host + 总请求数 + 4xx/5xx 数量。
type:"lvb"
| SELECT
    host,
    COUNT(*) AS req_total,
    COUNT_IF(http_code >= 400 AND http_code < 500) AS req_4xx,
    COUNT_IF(http_code >= 500 AND http_code < 600) AS req_5xx
  GROUP BY host
  ORDER BY req_5xx DESC, req_4xx DESC
  LIMIT 200


播放—时延/丢包

平均处理耗时

目标：识别处理时延是否出现突增。
输出：时间分桶 + process_time 平均值/最大值（秒）。
type:"lvb" and host:"{host}" and http_code=200 and streamname:"{streamname}" 
| select histogram( cast(__TIMESTAMP__ as timestamp),interval 1 minute) as analytic_time, 
avg(process_time)/1000.0 as process_time_sec 
group by analytic_time 
order by analytic_time 
limit 1000


RTT 趋势

目标：识别网络时延是否出现突增。
输出：时间分桶 + 平均 rtt
说明：
请根据您的字段单位保留或调整单位换算逻辑（部分环境中的 rtt 字段本身已是 ms）。
type:"lvb" and host:"{host}" and http_code=200 and streamname:"{streamname}" 
| select histogram( cast(__TIMESTAMP__ as timestamp),interval 1 minute) as analytic_time,
 avg( if(rtt='-', NULL, cast(rtt as double)) )/1000.0 as avg_rtt_ms 
 group by analytic_time 
 order by analytic_time 
 limit 1000

丢包率趋势

目标：识别丢包是否出现突增。
输出：时间分桶 + 平均 lost_rate
type:"lvb"
| SELECT
    histogram(CAST(__TIMESTAMP__ AS timestamp), interval 1 minute) AS time,
    host,
    AVG(IF(lost_rate = '-', NULL, CAST(lost_rate AS double))) AS avg_lost_rate
GROUP BY time, host
ORDER BY time
LIMIT 1000

播放—对比/异常点

按域名统计请求数

目标：对比各域名的流量情况。
输出：host + request_count
type:"lvb"
| select
    histogram(CAST(__TIMESTAMP__ AS timestamp), interval 1 minute) AS time,
    host,
    count(*) as req_count
group by time, host
order by time
limit 1000


按协议-域名统计请求数

目标：识别某个域名下是否存在协议维度异常。
输出：时间分桶 + host + protocol + request_count
HLS 并发用户可参考 文档。
说明：
如果您的字段名不是 url，请替换为实际字段名（例如 request_url、uri、path）。
type:"lvb"
| select
    histogram(CAST(__TIMESTAMP__ AS timestamp), interval 1 minute) AS time,
    host,
    case
        when url like '%.flv%' then 'flv'            
        when url like '%rtmp%' then 'rtmp'
        else 'other'
    end as protocol,
    count(*) as req_count
group by time, host, protocol
order by time
limit 1000


按域名统计处理耗时

目标：对比各域名的处理时延。
输出：时间分桶 + host + avg/max process_time
*
| SELECT
    histogram(CAST(__TIMESTAMP__ AS timestamp), interval {interval}) AS time,
    host,
    AVG(process_time) AS avg_process_time,
    MAX(process_time) AS max_process_time
  GROUP BY time, host
  ORDER BY time
  LIMIT 1000


按域名统计错误率

目标：查看各域名错误情况。
输出：时间分桶 + host + 成功/错误 + 平均 rtt/loss
type:"lvb"
| SELECT
    histogram(cast(__TIMESTAMP__ AS timestamp), interval 1 minute) AS time,
    host,
    SUM(IF(http_code >= 400 AND http_code < 600, 1, 0)) AS err_count,
    SUM(IF(http_code >= 400 AND http_code < 600, 1, 0)) * 1.0 / COUNT(*) AS err_rate
GROUP BY time, host
ORDER BY time
LIMIT 1000


播放—单用户

单用户质量（成功率/时延/丢包/错误）

目标：评估单个用户的播放质量。
输出：时间分桶 + 成功率 + 平均 rtt/loss + 4xx/5xx 数量
type:"lvb"
AND host:"{host}"
AND streamname:"{streamname}"
AND client_ip:"{client_ip}"
| SELECT
    histogram(CAST(__TIMESTAMP__ AS timestamp), interval {interval}) AS time,
    client_ip,
    COUNT(*) AS req_count,
    ROUND(COUNT_IF(http_code = 200) * 100.0 / COUNT(*), 2) AS success_rate_pct,
    COUNT_IF(http_code >= 400 AND http_code < 500) AS err_4xx,
    COUNT_IF(http_code >= 500 AND http_code < 600) AS err_5xx,
    AVG(IF(rtt = '-', NULL, CAST(rtt AS DOUBLE))) / 1000.0 AS avg_rtt_ms,
    AVG(IF(lost_rate = '-', NULL, CAST(lost_rate AS DOUBLE))) AS avg_lost_rate
  GROUP BY time, client_ip
  ORDER BY time
  LIMIT 1000

推流—质量

说明：
以下码率公式默认 {interval} = 1m（60 秒）。
如果将 {interval} 改为 5m，请将除数从 60 调整为 300。

按流统计推流码率

目标：识别推流码率下降/不稳定问题。
输出：时间分桶 + bitrate_kbps
*
| SELECT
    histogram(CAST(__TIMESTAMP__ AS timestamp), interval 1 minute) AS time,
    CONCAT(host, ' | ', streamname) AS host_stream,
    ROUND(SUM(size) * 8 / 60.0 / 1000, 2) AS bitrate_kbps
  GROUP BY time, host_stream
  ORDER BY time
  LIMIT 1000

平均带宽（mbps）

目标：识别上行带宽下降/不稳定问题。
输出：时间分桶 + avg_bandwidth_mbps
*
| SELECT
    histogram(CAST(__TIMESTAMP__ AS timestamp), interval 1 minute) AS time,
    host,
    ROUND(SUM(size) * 8 / 60.0 / 1000 / 1000, 3) AS avg_bandwidth_mbps
  GROUP BY time, host
  ORDER BY time
  LIMIT 1000

HTTP 状态码趋势（2xx vs 4xx vs 5xx）

为什么 4xx 响应会突增？

如果403占比最高：建议重点检查以下内容

1. 播放鉴权或签名 URL 不匹配。
403 通常表示播放 URL 无效、已过期，或与当前播放鉴权策略不匹配。
检查 txSecret / txTime。
检查过期时间和服务器时钟。
检查该域名的播放鉴权配置。
如使用拼接直播，请检查 URL 签名规则和 URL 格式。
推流与播放（包含 txSecret / txTime 用法）：参考 文档说明。
拼接直播 URL 规则（URL 签名规则/示例）：参考 文档说明。
播放鉴权配置：参考 文档说明。
2. 高级内容保护（如已开启）。
如果已启用额外保护能力（例如远程 Token 校验），请确认相关能力未拦截正常请求。
视频内容保护：参考 文档说明。
3. Referer 或 IP 访问控制（如已开启）。
这类配置在启用或变更后，较容易引发 403 突增。
Referer 配置：参考 文档说明。
IP 白名单 / 黑名单配置：参考 文档说明。
4. 地域访问控制（如已开启）。
如果开启了播放地域管理，请确认异常用户所在地域是否在允许范围内。地域策略可能导致特定地区用户返回 403。
按地域访问控制配置：参考 文档说明。

如果 404 占比最高：建议重点检查以下内容（CSS）

1. 确认播放 URL 是否正确（domain / app / stream / suffix）。
很多 404 本质上是播放 URL 配置错误导致，例如域名错误、AppName/StreamName 错误，或后缀错误（如 .flv / .m3u8）。
播放 URL 格式 / 示例：参考 文档说明。
2. 确认流是否确实在 CSS 上处于直播中（推流状态）。
如果流没有推上来，或推流已经停止，即使播放 URL 正确，也会返回 404。
可在控制台（流管理 > 直播流）中查看，或调用 DescribeLiveStreamState 确认该流当前状态是否为 active / inactive / disabled：参考 文档说明。
3. 检查流是否曾中断或结束
推流中断或停止后，播放侧可能立即或延迟一段时间后出现 404。
断流记录（控制台）：参考 文档说明。
流事件 API（推流/断流事件）：参考 文档说明。
4. 针对 HLS：确认 404 发生在 .m3u8 还是 .ts 分片上。
这一点非常关键，因为两类问题的根因通常不同：
.m3u8 返回 404，大概率说明流不存在、未在直播中，或路径错误。
.ts 返回 404，通常表示客户端请求了当前播放位置下不存在的分片（常见原因包括播放列表陈旧、代理缓存问题，或 seek 到可用分片窗口之外）。
HLS 会将流切分为5秒–10秒的小分片，并通过 M3U8 播放列表进行管理：参考 文档说明。
如有回看/回放需求，请使用时移功能（CSS 会保存 TS 分片，并支持通过 M3U8 参数指定播放时间，时间范围最长可达 6 小时）。参考 文档说明。
5. 如果已开启源站模式（origin-pull mode）
如果播放域名配置了回源，404 也可能表示源站侧对应流/资源不存在。
源站配置：参考 文档说明。

为什么 5xx 响应会突增？

1. 先确认是否开启了源站模式（origin-pull mode）。在开启回源的情况下，播放 5xx 突增多数与上游/源站异常有关。
源站配置：参考 文档说明。
2. 确认是哪个 5xx 状态码占比最高（500 / 502 / 503 / 504）。
不同的 5xx 状态码通常对应不同的上游故障模式。
数据类型（合法的播放错误码）：参考 文档说明。
3. 结合时延和影响范围分析 5xx（blast radius）。
可按 host / streamname / url 拆分 5xx，并检查是否与更高的处理耗时相关（例如上游变慢通常会先表现为 process_time 升高，再出现 504/5xx）。
实时日志分析（CSS-CLS 播放日志）：参考 文档说明。
4. 如果 503/504 与流量突增时间一致，请确认容量与资源准备情况。
遇到大流量场景建议提前评估和协调，否则容易一直在处理表象问题。
使用限制 / 流量突增保障说明：参考 文档说明。

时延（大多数为 HTTP 200）

为什么大多数请求都返回 HTTP 200，但播放时延仍然很高？

如果协议选择是主要原因，很可能当前使用的是 HLS（M3U8）协议，该协议天然具有较高的延迟（通常约为10秒-30秒）。
如需低时延播放，建议切换为 LL-HLS / WebRTC（需结合平台支持情况）。
如必须使用 HLS，可适当调整分片设置（但可能增加卡顿风险）：参考 文档说明。

我们已经在使用 HTTP-FLV/RTMP，但时延仍然很高，还需要调整什么？

高时延排查参考 文档说明。

丢包（大多数为 HTTP 200）

为什么大多数请求都返回 HTTP 200，但播放仍然会卡顿/冻结？

1. 如果 lost_rate 是主要异常指标，很可能是观众侧丢包或下行网络不稳定（lost_rate 仅在 type=leb 时有效）。
2. 在 CLS 播放日志中筛选 type=leb，观察 lost_rate 和 rtt 的趋势。
3. 按 prov / isp / server_region 拆分，确认丢包是否集中在特定地域/运营商。
如果问题集中在特定地域/运营商：建议将受影响用户切换至 LEB（WebRTC），以获得更好的弱网抗性。参考 文档说明。
如果需要在带宽波动场景下获得更平滑的播放体验：可开启自适应码率（仅支持 HLS/WebRTC）。参考 文档说明。
如果所有观众都出现卡顿（而非集中在某个地域）：更应按上游问题处理，例如上游 FPS 过低、上行拥塞等；建议降低码率/分辨率，或优先稳定上行网络。参考 文档说明。

对比/异常点

只有一个地域异常，其他地域都正常，应该重点检查什么？

如果某个地域明显异常（错误/时延/卡顿）而其他地域正常，常见原因包括：
播放域名加速地域与实际访问地域不匹配。
开启了地域允许/封禁策略（播放地域管理）。
协议问题仅在该地域生效（协议被屏蔽 / 回退行为异常）。
1. 加速地域不匹配（域名级配置）。
检查播放域名的“加速区域”配置。
如果异常用户所在地域不在加速覆盖范围内，播放可能失败，或表现异常。
地域配置：参考 文档说明。
服务地域：参考 文档说明。
2. 地域允许/封禁（“仅某一地域异常”最常见的配置原因）。
检查是否开启了“按地域访问控制”（播放地域管理）。
确认异常地域未被封禁，且已被纳入允许范围。
按地域访问控制配置：参考 文档说明。
3. 协议维度影响。
如果异常仅与某个协议相关（例如仅 HLS 或仅 FLV 异常），请重点验证该协议的开启状态及播放器行为：
该域名是否屏蔽了此协议。
播放器在该地域/设备上是否自动回退到了其他协议。
按协议屏蔽播放：参考 文档说明。

单用户

只有一个用户反馈卡顿/高时延/报错，但整体看板正常，如何验证并隔离问题？

1. 先确认是否为单点问题：
对比同一时间窗内的全局指标（请求/错误/时延），参考 文档说明。
2. 在 CLS 实时日志分析中，按 client_ip 和精确时间范围筛选，重点查看 http_code。
如使用 LEB，还应同时查看 rtt 和 lost_rate（仅 LEB 有效字段；type=leb）。
3. 判断逻辑
rtt / lost_rate 高，但大多数请求为 200，更可能是客户端网络质量问题（Wi-Fi / ISP / 路由）。
持续出现 4xx/5xx，仍按主 RCA 逻辑排查，但范围收敛到该用户（增加 client_ip 过滤条件）。

推流

推流码率下降/断流/上游表现不稳定，如何判断是上行网络问题还是推流端编码配置问题？

1. 如果推流不稳定是主要现象，常见原因是上行拥塞/丢包，或推流设备/推流软件编码参数不合理、资源负载过高，导致码率/FPS 波动。
2. 检查项：确认故障时间窗附近该流状态是否为 active / inactive / forbidden。参考 文档说明。
3. 按流拉取推流侧指标并观察趋势：视频码率/视频 FPS/音频码率/编码格式/客户端 IP。参考 文档说明，字段参考 文档说明。
4. 如果怀疑是上行网络问题（码率下降 + 重连 / 不稳定）：建议降低推流码率并优先稳定上行网络；上行带宽不足容易导致拥塞。参考 文档说明。
5. 如果怀疑是推流端编码配置问题（带宽看起来稳定，但码率 / FPS 不稳定）：建议调整推流设备 / 推流软件的编码参数，并控制在合理码率范围内（腾讯建议 < 4 Mbps，以避免推流卡顿）。参考 文档说明。
6. 如果上行链路存在高丢包或长距离传输场景：建议切换推流协议为 SRT 或 RTMP over SRT，以提升抗丢包能力。
RTMP over SRT 说明与配置参考：文档说明。
SRT 抗弱网示例：文档说明。
上一篇: 播放失败问题排查下一篇: 直播延迟问题排查

帮助和支持

本页内容是否解决了您的问题？

填写满意度调查问卷，共创更好文档体验。

文档反馈