开放平台
取消
开发者平台
中文
EN
取消
  • 平台指南

    • # 排查指引

    平台整理了一些在对接微信服务端时，常见问题的排查手段。

    # 1、DNS 失败

    该错误为微信服务器在推送消息给开发者时，解析 DNS 失败。如遇到此报警，请开发者确认：

    1）填写的 URL，域名是否有误

    2）域名是否发生变化，如过期，更新等

    如果不是以上 2 个问题，请联系微信公众平台。问题解决方案：

    1）Ping 测试你们 MP 上配置的 URL 里的域名，确认是否能够得到正确的 IP。如不能得到或者错误，请到你们的域名托管商管理系统上检查配置。

    2）如 1 能够得到正确的 IP，又有 DNS 失败的报警；请使用 DNS 服务器 182.254.116.116 来再测试验证。Linux：dig @182.254.116.116 域名；Windows 修改网络配置里的 DNS 服务器地址，然后再 ping 域名。如果得到的 IP 不正确或者得不到，请联系微信团队。

    # 2、DNS 超时

    目前不会有此错误。

    # 3、连接超时

    该错误是微信服务器和开发者服务器 3S 内未连接成功。报警消息会提供出首次发生连接失败的时间和连接的 IP。如遇此报警，请开发者确认：

    1）该 IP 是否有误

    2）该 IP 机器是否过载，连接过多

    3）如果是第三方提供服务器托管，托管商是否有故障

    4）网络运营商是否有故障

    5）是否设置了防火墙等网络策略，可为微信服务器的 IP 增设白名单。详细参看获取微信服务器 IP 地址

    6）是否网络不通，可通过网络检测排查

    问题解决方案如下：

    1）查看是否网络环境问题。使用获取微信推送服务器 IP 接口，获取微信回调服务器的 IP，在你的服务上 ping 测试，检查你们服务器到微信回调用服务器的网络质量情况。如有网络问题，请联系你们的服务器提供商解决。

    2）查看接入层服务器连接数，负载，nginx 的配置，允许的连接个数。查看 nginx 错误日志是否有 Connection reset by peer 或 Connection timed out 错误日志，如有说明 nginx 连接数超负载。

    3）建议搭建测试工具，对系统进行心跳检查，对系统负载，连接数，处理数，处理耗时进行实时监控报警。

    对于 nginx 配置，这里提供官方文档和一篇简单配置介绍链接，希望有帮助：http://nginx.org/en/docs/ ，重点关注连接数配置，日志配置等。nginx 的一些重要配置参考例子如下：

    worker_processes  16;          //CPU核数
error_log  logs/error.log  info;   //错误日志log
worker_rlimit_nofile 102400;     //打开最大句柄数
events {
   worker_connections  102400;   //允许最大连接数
}
//请求日志记录，关键字段：request_time-请求总时间，upstream_response_time后端处理时间
log_format  main  '$remote_addr  - $remote_user [$time_local] "$request" '
                 '$status $body_bytes_sent "$http_referer" '
                  '"$http_user_agent" "$http_x_forwarded_for" "$host"  "$cookie_ssl_edition" '
                 '"$upstream_addr"   "$upstream_status"  "$request_time"  '
                 '"$upstream_response_time" ';
access_log  logs/access.log  main;

    # 4、请求超时

    微信服务器向开发者服务器推送消息或事件，开发者 5 秒内没有返回。请求超时时，报警消息会提供第一次出现请求超时的时间，开发者 IP 和消息类型。请开发者确认：

    1）该 IP 是否有误

    2）该 IP 是否接收到报警消息给出的该消息类型的请求

    3）该请求是否处理时间过长

    解决方案：

    每个模块都需要有完整的日志，能够查出每个请求在每个模块的耗时信息，配合微信报警提供信息，能够很容易的定位到是哪个服务器出问题。常见的原因是：

    1）机器负载太高，耗时增加

    2）机器处理异常，消息丢失

    3）机器异常，对于机器处理异常，建议尽快修复 bug，对于机器异常，请尽快屏蔽有问题的机器。这里对机器负载太高，简单提供可行的解决方案。

    方案一：优化性能，扩容。 检查负载情况（CPU、内存、IO、网络，详见附录），根据具体性能瓶颈的不同，采取不同的优化方式。

    方案二：异步处理。 如果微信服务器推送的消息来不及实时处理，可将消息先存储，先返回 success 给微信服务器，后台可后续再处理消息，如果需要回复用户消息，可通过调用客服消息接口 API 再回复用户消息。

    # 5、回应失败

    开发者没有按照文档的回复消息格式进行回复消息，或者发生网络错误，会报警回应失败，报警消息会提供第一次出现请求回应失败的时间，开发者的 IP，消息类型以及回应的消息内容，请开发者确认：

    1）该 IP 是否有误

    2）该 IP 是否发生网络错误

    3）该业务处理逻辑是否没有按照文档规范回复消息，或是进入了异常逻辑

    # 5.1 MarkFail（自动屏蔽）

    微信后台会实时统计开发者的失败次数。在推送消息给开发者发生大量失败时，微信服务器会自动屏蔽开发者，1 分钟内不再推送任何消息，并会发送报警到微信群。此报警是级别最高的报警，开发者在收到此报警时请尽快处理后台故障，恢复服务。事实上，开发者在收到此报警前，必然会收到连接超时，请求超时或回应失败等报警，需要开发者即时去解决这些故障，避免被微信服务器屏蔽，严重影响业务服务！

    # 5.2 推送 component_verify_ticket 超时

    只有业务第三方平台开发者会收到，其他业务开发者无需关注。由于业务第三方平台承载了更多的业务，所以业务第三方平台的服务质量需要更严格要求和报警，所以把这 4 个特殊的事件单独报警。component_verify_ticket 的问题定位可查看 component_verify_ticket 常见排错指南。

    # 5.3 推送 component_verify_ticket 失败

    只有业务第三方平台开发者会收到，其他业务开发者无需关注。component_verify_ticket 的问题定位可查看 component_verify_ticket 常见排错指南。

    # 5.4 推送组件消息超时

    只有业务第三方平台开发者会收到，其他业务开发者无需关注。详情可查看第三方平台全网发布检测说明。

    # 5.5 推送组件消息失败

    只有业务第三方平台开发者会收到，其他业务开发者无需关注。详情可查看第三方平台全网发布检测说明。

    # 6、常用工具

    下面对查看服务器性能负载的常用工具做简单介绍，详细的工具使用请另行查阅。

    # 6.1 查看 CPU 的性能负载

    • uptime：用于观察服务器整体负载，系统负载指运行队列（1 分钟、5 分钟、15 分钟前）的平均长度，正常情况需要小于 CPU 个数。
    • vmstat：vmstat 是 Virtual Memory Statistics（虚拟内存统计）的缩写，可对操作系统的虚拟内存、进程、CPU 活动进行监控。他是对系统的整体情况进行统计，通常使用 vmstat 5 5（表示每隔 5 秒生成一次数据，生成五次）命令测试。将得到一个数据汇总他能够反映真正的系统情况。
    • top：top 命令是最流行 Unix/Linux 的性能工具之一。系统管理员可用运行 top 命令监视进程和 Linux 整体性能。

    # 6.2 查看内存的性能负载

    • free：Linux 下的 free 命令，可以用于查看当前系统内存的使用情况，它显示系统中剩余及已用的物理内存和交换内存，以及共享内存和被核心使用的缓冲区。

    # 6.3 查看网络的性能负载

    • netstat：Netstat 是控制台命令，是一个监控 TCP/IP 网络的非常有用的工具，它可以显示路由表、实际的网络连接以及每一个网络接口设备的状态信息。Netstat 用于显示与 IP、TCP、UDP 和 ICMP 协议相关的统计数据，一般用于检验本机各端口的网络连接情况。
    • sar：sar（System Activity Reporter 系统活动情况报告）是目前 Linux 上最为全面的系统性能分析工具之一，可以从多方面对系统的活动进行报告，包括：文件的读写情况、系统调用的使用情况、磁盘 I/O、CPU 效率、内存使用状况、进程活动及 IPC 有关的活动等。

    # 6.4 查看磁盘的性能负载

    • iostat：Linux 下的 iostat 命令，可用于报告中央处理器（CPU）统计信息和整个系统、适配器、tty 设备、磁盘和 CD-ROM 的输入/输出统计信息。

    # 7、nginx 配置和排查指引

    当出现直接超时、处理返回慢时的报警时，nginx 侧的故障排查参考方法有如下：

    检查请求日志情况，tail -f logs/access.log，看 upstream_status 字段：

    • 200：表示正常
    • 502/503/504：表示处理慢，或者后端 down 机；再看 upstream_response_time 返回的时间是否真的较慢，有没有上百毫秒，或更高的，有则说明是后端服务有问题
    • 404：表示请求的路径不存在或不对，文件不在了。需要检查你配置在公众平台上的 URL 路径是否正确；服务器上的文件、程序是否存在
    • 403：表示无权限访问。检查一下 nginx.conf 是否有特殊的访问配置
    • 499：则是客户端的问题，请联系微信团队。此错误少见

    检查错误日志情况，tail -f logs/error_log，查看是否有 connect() failed、Connection refused、Connection reset by peer 等 error 错误日志，有则说明有可能 nginx 出现的连接数超负载等情况。

    查看系统的网络连接数情况确认是否有较大的链接数：

    netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

    CLOSED        //无连接是活动的或正在进行
LISTEN        //服务器在等待进入呼叫
SYN_RECV      //一个连接请求已经到达，等待确认
SYN_SENT      //应用已经开始，打开一个连接
ESTABLISHED   //正常数据传输状态/当前并发连接数
FIN_WAIT1     //应用说它已经完成
FIN_WAIT2     //另一边已同意释放
ITMED_WAIT    //等待所有分组死掉
CLOSING       //两边同时尝试关闭
TIME_WAIT     //另一边已初始化一个释放
LAST_ACK      //等待所有分组死掉

    查看系统的句柄配置情况，ulimit -n，确认是否过小（小于请求数）。

    worker_rlimit_nofile、worker_connections 配置项，是否过小（小于请求数）。