Skills
skills/skills.netease.im/qs-techsupport

qs-techsupport

SKILL.md

QS Techsupport

Use this skill only for authorized internal QS investigations on qs.netease.im.

Relationship to yunxin-troubleshooting-assistant

  • qs-techsupport is the QS execution layer: it queries live QS data, service-side logs, message history, account mappings, push/device state, SDK log tasks, and RTC2 records.
  • yunxin-troubleshooting-assistant is the diagnosis / routing layer: it decides what to check, how to interpret protocol clues, which chain the problem belongs to, and what evidence should be fetched next.
  • When the user asks “去 QS 查一下 / 拉一下 / 搜一下 / 给我短链 / 帮我捞数据”, use this skill directly.
  • When the user asks “这是什么问题 / 协议号是什么意思 / 下一步查什么 / 更像客户端还是服务端 / 这条日志怎么解释”, prefer yunxin-troubleshooting-assistant first, then use this skill to execute the chosen QS queries.
  • This skill may mention example sid/cid filters for log retrieval, but it is not the canonical protocol-semantics reference for V10/V2.
  • For V10/V2 protocol meaning, mapping, and troubleshooting interpretation, hand off to yunxin-troubleshooting-assistant, especially its protocol references under references/evidence/protocols/.

Start here

  • Prefer the unified entrypoint: python3 scripts/qs_cli.py --email <corp-email> <subcommand> ...
  • Pass --email for normal use. That is the only auth input most users need; the wrapper builds the equivalent request context internally.
  • Fall back to individual scripts only when the wrapper does not expose the option you need.
  • Add --insecure in internal certificate environments.
  • Save large JSON outputs to a workspace path outside the skill directory.
  • Temporary JSON / response dump files may be deleted after use to avoid long-term accumulation in the workspace.
  • For log-search, default to im_app_log_online when querying general service-side logs; use nim_debug_log with tag-based conditions when specifically investigating push logs.
  • For SMS request/delivery investigations, do not use im_app_log_online / nim_debug_log by default; use the dedicated sms-log capability (fixed index: nim_sms_log).
  • For every log-search result, proactively return a QS review link so the user can independently verify.
  • When sharing QS log review links with colleagues or customers, prefer the absolute-time review long URL (query.review.longUrl, with quickTime=custom&startTime=...&endTime=...) as the primary link. Do not send only the default short-link, because it may reopen as a relative-time view and drift as time passes.
  • If a short-link is still useful for convenience, include it only as a secondary link after the absolute-time long URL, and clearly treat the long URL as the source of truth for the time window.
  • For sdk-log-task, default to returning download URLs and lightweight metadata only. Do not download SDK log archives unless the user explicitly asks for that.
  • For repeated SDK log pulls on the same account, record the latest dispatch time in workspace state and reuse it when listing uploaded files. Prefer classifying results into current-dispatch logs vs historical logs, and explicitly warn when only historical logs are found so older uploads are not mistaken for the current pull.
  • Treat IM SDK log pull and RTC SDK log pull as asynchronous operations. If the log is not available on the first check, do not stop at “还没拉到”; proactively ask whether the user wants a scheduled follow-up task / timed re-check, so the case can continue automatically later.

Choose the module

  • appid / appkey mapping, app metadata → app-info → references/app-info.md
  • accid / uid / account lookup → user-info → references/user-info.md
  • message history → history-msg → references/history-msg.md
  • group metadata / team state → chat-group → references/chat-group.md
  • chatroom metadata → chat-room → references/chat-room.md
  • device list / push token inspection → push-token → references/push-token.md
  • SDK log task dispatch / uploaded SDK log files（客户端 SDK/IM 日志拉取） → sdk-log-task → references/sdk-log.md
  • RTC 音视频 SDK 日志拉取（按 cid+uid 自动查设备并逐设备下发） → rtc-sdk-log-fetch → references/rtc-sdk-log.md
  • SMS service-side request / delivery records（短信服务端请求与回执） → sms-log → references/sms-log.md
  • ELK / Doris / Kibana / 服务端日志检索（服务端日志检索） → log-search → references/log-search.md
  • RTC2 channel / member / SDK event / API event analysis → rtc2-call-analysis → references/rtc2-call-analysis.md
  • RTC 服务端下发音频配置参数（服务端下发优先级高于客户端主动设置） → 先看 references/rtc2-call-analysis.md 中的“distributedParameter”小节，当前优先走原始 HTTP 请求 / curl 方式

For a compact selector, read references/modules.md.

Routing rules: client logs vs service-side logs

Choose the module by where the logs live, not just by the word “日志”.

  • If the user asks for “IM日志 / SDK日志 / 客户端日志 / 拉日志 / 上传日志 / 日志包”, treat it as a client SDK log pull request and use sdk-log-task.

    • Typical examples:
      • “帮我拉 accid xxx 的 IM 日志”
      • “查这个账号客户端日志”
      • “让用户上传 SDK 日志”
      • “拉一下 appkey + accid 的日志包”
    • Do not route these to log-search by default.

  • If the user asks for “服务端日志 / ELK / Doris / Kibana / sid / cid / 请求日志 / 链路日志”, treat it as a service-side log search request and use log-search.

    • This also includes cases where ELK is only being used as a reverse lookup step to recover missing app context from a globally unique uid / tid / chatroomid.
    • Typical examples:
      • “查 ELK 里这个 uid 的收发消息日志”
      • “帮我搜 kibana 上 sid=13 cid=2 的日志”
      • “查 Doris 里这个 appid 的服务端报错”

  • If the user only says “查日志” and the source is ambiguous, ask one short clarifying question: client SDK/IM logs, or service-side ELK/Doris/Kibana logs?

Common workflow

  1. If the input is appid, resolve appkey with app-info when the target module needs it.
  2. If the input is accid but the target module needs uid, resolve it with user-info.
  3. Run the target module with normalized identifiers.
  4. When results are large, write the raw JSON to a file and return a concise summary plus the file path.
  5. For log-search, include the absolute-time review long URL in the final reply first, and only append a short-link as optional convenience if needed. For sms-log, include the review link returned by the tool.

Auth and handling rules

  • For normal use through qs_cli.py, most modules only need a company email plus internal network access.
  • If you bypass the wrapper and call low-level scripts or raw HTTP endpoints directly, provide the equivalent userinfo context yourself.
  • Some RTC2 endpoints also require QS_COOKIE; check references/rtc2-call-analysis.md before calling them.
  • 对于 RTC 服务端下发参数查询接口 POST /qs_inner/v2/api/nrtc/server/distributedParameter，当前已确认需要 userinfo + QS_COOKIE，入参核心为 beginTime、endTime、uid、cid。
  • Never store live cookies, userinfo payloads, or other credentials in the skill files.
  • Do not keep ad-hoc captures, response dumps, cache files, or editor swap files inside the skill directory.

Entrypoints

  • Unified wrapper: scripts/qs_cli.py
  • Low-level scripts:
    • scripts/query_app_info.py
    • scripts/query_user_info.py
    • scripts/query_history_msg.py
    • scripts/query_chat_group.py
    • scripts/query_chat_room.py
    • scripts/query_push_token.py
    • scripts/dispatch_sdk_log_task.py
    • scripts/list_sdk_log_files.py
    • scripts/fetch_rtc_sdk_logs.py
    • scripts/query_log_search.py
    • scripts/query_sms_service_log.py
    • scripts/query_rtc2_call.py

Examples

python3 scripts/qs_cli.py --email xxx@corp.netease.com app-info --appid 30541651 --insecure
python3 scripts/qs_cli.py --email xxx@corp.netease.com user-info --appid 25242404 --by accid --id online_11732525 --insecure
python3 scripts/qs_cli.py --email xxx@corp.netease.com history-msg --appid 25242404 --type p2p --from-time '2026-03-16 00:00:00' --to-time '2026-03-16 23:59:59' --my-uid 207395769659 --to-accid online_11732525 --limit 20 --insecure
python3 scripts/qs_cli.py --email xxx@corp.netease.com log-search --begin-time 1773246426986 --end-time 1773329234986 --index im_app_log_online --term sid=-22 --term cid=2 --term appid=15676383 --term uid=29237556195 --size 1000 --insecure
# 查短信服务端请求/回执（固定用 nim_sms_log）
python3 scripts/qs_cli.py --email xxx@corp.netease.com sms-log --mobile 15875425437 --begin-time '2026-03-18 00:00:00' --end-time '2026-03-18 23:59:59' --insecure
# 读取 log-search 原始输出文件中的复核短链（query.review.shortUrl）
python3 - <<'PY'
import json
p='${LOG_RESULT_JSON_PATH}'
print(json.load(open(p, 'r', encoding='utf-8'))['query']['review']['shortUrl'])
PY
python3 scripts/qs_cli.py --email xxx@corp.netease.com sdk-dispatch --appkey d1e9b3e0485794b1d0b473d249e15873 --accid 177150256295430 --insecure
python3 scripts/qs_cli.py --email xxx@corp.netease.com sdk-files --appkey d1e9b3e0485794b1d0b473d249e15873 --accid 177150256295430 --insecure
# RTC 音视频 SDK 日志拉取：先查设备，再按设备逐个下发 fetchLogfile
python3 scripts/qs_cli.py --email xxx@corp.netease.com rtc-sdk-log-fetch --appid 15793948 --cid 1349858385874898 --uid 10052904 --insecure
python3 scripts/query_rtc2_call.py --insecure sdk-events --cid 1349854796763083 --uid 10271127 --begin-time 1773729600000 --end-time 1773736800000 --is-g2

ispatch --appkey d1e9b3e0485794b1d0b473d249e15873 --accid 177150256295430 --insecure python3 scripts/qs_cli.py --email xxx@corp.netease.com sdk-files --appkey d1e9b3e0485794b1d0b473d249e15873 --accid 177150256295430 --insecure

RTC 音视频 SDK 日志拉取：先查设备，再按设备逐个下发 fetchLogfile

python3 scripts/qs_cli.py --email xxx@corp.netease.com rtc-sdk-log-fetch --appid 15793948 --cid 1349858385874898 --uid 10052904 --insecure python3 scripts/query_rtc2_call.py --insecure sdk-events --cid 1349854796763083 --uid 10271127 --begin-time 1773729600000 --end-time 1773736800000 --is-g2

Installs
6
Source
skills.netease.…24af0db3
First Seen
Apr 16, 2026