알람 문제 해결 가이드
요약 설명
WeChat 공개 플랫폼은 개발자에게 메시지를 푸시하려는 WeChat 서버의 실패한 시도 횟수가 미리 정해진 임계값에 도달하면 경보 메시지가 외부 세계에 공개됩니다. 지정된 WeChat 알람 그룹(설정 방법: 공개 플랫폼->개발-운영 및 유지 관리 센터->인터페이스 알람)에 전송되면 개발자는 알람에 적극적으로 주의하고 결함을 즉시 해결하며 서비스 품질을 향상시켜야 합니다. 위챗 공식 계정.
알람 정보(openid 및 타임스탬프 제공) 끝에 있는 예시를 기반으로 문제를 더 잘 해결하려면 개발자는 액세스 레이어, 로직 레이어 등 각 수준의 주요 정보가 포함된 자세한 로그를 도움말에 추가해야 합니다. 문제를 찾아보세요.
현재 두 가지 유형의 알람이 있습니다:
1. 모든 개발자가 주의해야 하는 일반 알람입니다.
2. 공식 계정 타사 플랫폼 알람. WeChat 오픈 플랫폼(open.weixin.qq.com)에서 공개 계정 타사 플랫폼을 신청하는 개발자만 이 알람에 주의해야 합니다.
다음은 특정 경보 및 문제 해결 지침의 예입니다.
알람 내용 설명
알람 내용 설명:
a)appid:公众号appid b)昵称: 公众号昵称 c)时间:所有报警,都会提供首次发生异常的时间。(如首次发生超时的时间,首次发生回应失败的时间) d)内容:错误的具体描述 e)次数:发生失败的次数 f)错误样例:错误样例里注明了一些帮助查找问题的信息。如:首次超时开发者的IP和推送消息类型。如果是回应失败,错误样例还会注明首次回应失败时开发者的回包。
일반적인 상황에서는 알람에서 제공하는 IP, 시간, 메시지 유형을 통해 제3자 문제의 원인을 빠르게 찾을 수 있습니다.
알람 예시 1: 시간 초과 알람
Appid: wxxxxxx 昵称: WxNickName 时间: 2014-12-01 20:12:00 内容: 微信服务器向公众号推送消息或事件后,开发者5秒内没有返回 次数: 5分钟 1272次 错误样例: [IP=203.205.140.29][Event=UnSubscribe]
이 알람의 의미: WeChat 서버가 팔로우 취소 이벤트를 개발자에게 푸시했을 때 개발자가 5초 이내에 결과를 반환하지 않았습니다. 2014-12-01 20:12:00부터 2014-12-01 20:17:00까지 5분 동안 1272번 일어났습니다. 5분 이내에 발생한 첫 번째 타임아웃은 2014-12-01 20:12:00, 개발자 IP는 203.205.140.29, 이벤트 유형은 언팔로우 이벤트였습니다.
알람 예 2: 응답 실패
Appid: wxxxx 昵称: WxNickName 时间: 2014-12-01 20:12:00 内容: 微信服务器向公众号推送消息或事件后,得到的回应不合法 次数: 5分钟 1320次 错误样例: [Event=Click] [ip=58.248.9.218][response_length=10][response_content=Error 500:]
이 알람의 의미: WeChat 서버가 사용자 정의 메뉴 클릭 이벤트를 개발자에게 푸시할 때 개발자의 반환 결과가 불법입니다. 2014-12-01 20:12:00부터 2014-12-01 20:17:00까지 5분 동안 1320번이나 일어났습니다. 이 5분 동안 처음 응답이 실패한 시간은 2014-12-01 20:12:00, 개발자 IP는 58.248.9.218, 이벤트 유형은 클릭 메뉴 이벤트, 반환된 콘텐츠의 길이는 다음과 같습니다. 제3자가 10바이트이면 내용은 "오류 500:"입니다.
알람 예 3: 연결 시간 초과
Appid: wxxxx 昵称: WxNickName 时间: 2015-02-04 20:13:09 内容: 微信服务器连接公众号开发者服务器时发生超时,超时时间为5秒 次数: 5分钟 7289次 错误样例: [IP=180.150.190.135][Msg=Text]
이 알람의 의미: WeChat 서버가 팬의 문자 메시지를 개발자에게 푸시할 때 개발자가 입력한 서버 주소에 연결할 수 없습니다. 2015-02-04 20:13:09부터 2015-02-04 20:18:00까지 5분 동안 7289번 발생했습니다. 이 5분 동안 처음으로 연결 시간 초과가 발생한 것은 2015-02-04 20입니다. 13:09, 개발자 IP는 180.150.190.135이고, 이벤트 유형은 사용자가 푸시한 메시지입니다.
다양한 알람에 대한 문제 해결 방법
1.DNS 실패
이 오류는 WeChat에서 발생합니다. 서버가 개발자에게 메시지를 푸시하면 DNS 확인에 실패합니다. 이 알람이 발생하면 개발자에게 확인하세요.
a)填写的url,域名是否有误; b) 域名是否发生变化,如过期,更新等。
위의 두 가지 문제가 아닌 경우 WeChat 공개 플랫폼에 문의하세요.
2.Dns timeout
현재 이 오류는 발생하지 않습니다.
3. 연결 시간 초과
이 오류는 WeChat 서버와 개발자 서버가 3S 내에서 성공적으로 연결되지 않았기 때문에 발생합니다. 경보 메시지는 첫 번째 연결 실패가 발생한 시간과 연결의 IP 주소를 제공합니다. 이 알람이 발생하면 개발자는 다음을 확인하세요.
a)该IP是否有误。 b)该IP机器是否过载,连接过多。 c)如果是第三方提供服务器托管,托管商是否有故障。 d)网络运营商是否有故障。
4. 요청 시간 초과
WeChat 서버가 개발자 서버에 메시지나 이벤트를 푸시했지만 개발자가 해당 시간 내에 반환하지 않았습니다. 5초. 요청 시간이 초과되면 처음으로 요청 시간 초과가 발생한 시간, 개발자 IP 및 메시지 유형을 알람 메시지에 제공합니다. 개발자 확인 부탁드립니다:
a)该IP是否有误 b)该IP是否接收到报警消息给出的该消息类型的请求 c)该请求是否处理时间过长
5. 응답 실패
위키의 응답 메시지 형식에 따라 개발자가 메시지에 응답하지 않거나 네트워크 오류가 발생합니다. 응답 실패가 보고됩니다. 알람 메시지는 요청 응답이 처음 실패한 시간, 개발자의 IP, 메시지 유형 및 응답 메시지 내용을 제공합니다.
a)该IP是否有误 b)该IP是否发生网络错误 c)该业务处理逻辑是否没有按照wiki规范回复消息,或是进入了异常逻辑。
6.MarkFail(자동 차단)#🎜 🎜#
WeChat 백엔드는 개발자의 실패 횟수를 실시간으로 계산합니다. 개발자에게 메시지를 푸시하는 데 많은 실패가 발생하면 WeChat 서버는 자동으로 개발자를 차단하고 1분 이내에 모든 메시지 푸시를 중지하며 WeChat 그룹에 알람을 보냅니다. 이 알람은 가장 높은 수준의 알람입니다. 개발자가 이 알람을 수신하면 가능한 한 빨리 백그라운드 오류를 처리하고 서비스를 복원하십시오. 실제로 이 알람을 받기 전에 개발자는 필연적으로 연결 시간 초과, 요청 시간 초과 또는 응답 실패와 같은 알람을 받게 됩니다. 개발자는 WeChat 서버에 의해 차단되어 공개 계정 서비스에 심각한 영향을 미치지 않도록 이러한 오류를 즉시 해결해야 합니다! 7. 푸시 구성 요소_verify_ticket 시간 초과 & 8. 푸시 구성 요소_verify_ticket 실패 & 9. 푸시 구성 요소 메시지 시간 초과 & 10. 푸시 구성 요소 메시지 실패 위 4개 경보에는 타사만 있습니다. 공개 계정 플랫폼 개발자는 이를 받게 되며, 다른 공개 계정 개발자는 주의를 기울일 필요가 없습니다. 공개 계정 제3자 플랫폼은 더 많은 공개 계정을 보유하므로 공개 계정 제3자 플랫폼의 서비스 품질에는 더 엄격한 요구 사항과 경보가 필요하므로 이 네 가지 특별 이벤트는 별도로 보고됩니다. 구체적인 문제 발견 방법은 4, 5와 동일하므로 여기서는 자세히 다루지 않겠습니다. 공개 계정 제3자 플랫폼의 구체적인 적용 및 개발 구현에 대해서는 WeChat 개방형 플랫폼(open.weixin.qq.com)#🎜🎜을 방문하세요. #FAQ# 🎜🎜#1. DNS 실패 문제를 해결하는 방법은 무엇입니까? 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. 연결 시간 초과 문제를 해결하는 방법은 무엇입니까? 1.查看是否网络环境问题。 (1)使用公众平台接口,获取到微信回调服务器的IP,https://api.weixin.qq.com/cgi-bin/getcallbackip?access_token=ACCESS_TOKEN, (2)在你们的服务上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;3. 요청 시간 초과 문제를 해결하는 방법은 무엇입니까? 각 모듈에는 각 모듈의 각 요청에 대해 시간이 많이 걸리는 정보를 알아낼 수 있는 완전한 로그가 있어야 하며, WeChat 알람과 협력하여 정보를 제공해야 합니다. 이를 통해 어떤 서버에 해당 요청이 있는지 쉽게 찾을 수 있습니다. 문제. . 일반적인 이유는 다음과 같습니다:
1)机器负载太高,耗时增加 2)机器处理异常,消息丢失 3)机器异常,对于机器处理异常,建议尽快修复bug,对于机器异常,请尽快屏蔽有问题的机器。这里对机器负载太高,简单提供可行的解决方案。方案一:优化性能,扩容。检查负载情况(cpu,内存,io,网络,详见附录),根据具体性能瓶颈的不同,采取不同的优化方式。方案二:异步处理。如果微信服务器推送的消息来不及实时处理,可将消息先存储,先返回success给微信服务器,后台可后续再处理消息,如果需要回复用户消息,可通过调用客服消息接口API再回复用户消息。4. access_token 저장 및 사용 문제를 해결하는 방법은 무엇입니까?
제3자는 종종 access_token이 서비스 중단을 야기한다고 보고합니다. 공용 플랫폼에서 문제를 해결할 때 대부분의 제3자가 access_token을 미친 듯이 새로 고쳐서 인터페이스 빈도 제한을 넘어 access_token이 무효화되는 것을 발견합니다. 다음은 더 간단한 access_token 저장 및 사용 솔루션입니다.
1)中控服务器定时(建议1小时)调用微信api,刷新access_token,将新的access_token 存入mysql(或其他存储), 2)其他工作服务器每次调用微信api时从mysql(或其他存储)获取access_token,并可在内存缓存一段时间(建议1分钟)。
공개 플랫폼은 access_token을 새로 고친 후에도 제3자가 access_token을 업데이트할 때 WeChat API를 호출하는 데 실패하지 않도록 5분 이내에 이전 access_token을 계속 사용할 수 있도록 보장합니다. ### ## ## ## ## #####부록#### ## ## ## ## ####부록 1 : Wechat Push 메시지 이벤트 목록 및 응답 형식
자세한 내용은 WeChat 푸시 메시지 및 이벤트 설명을 참조하세요.
#🎜🎜 #부록 2: 서버 성능 부하 확인을 위한 일반 도구다음은 서버 성능 부하 확인을 위한 일반 도구에 대한 간략한 소개입니다. 자세한 도구 사용법은 별도로 확인하시기 바랍니다. 1. CPU의 성능 부하를 확인합니다.
a)uptime
은 서버의 전체 부하를 관찰하는 데 사용됩니다. 실행 중인 대기열(1분, 5분, 15분 전)을 참조하므로 평균 길이는 일반적인 상황에서 CPU 수보다 작아야 합니다. b)vmstatvmstat은 Virtual Meomory Statistics(가상 메모리 통계)의 약어로, 운영체제의 가상 메모리, 프로세스, CPU 활동을 모니터링할 수 있습니다. 시스템의 전반적인 상황에 대한 통계를 수행하며 일반적으로 vmstat 5 5(데이터가 5초마다 5번 생성됨을 의미) 명령을 사용하여 테스트됩니다. 실제 시스템 조건을 반영하는 데이터 요약이 제공됩니다.
c)top top 명령은 가장 널리 사용되는 Unix/Linux 성능 도구 중 하나입니다. 시스템 관리자는 top 명령을 실행하여 프로세스와 전반적인 Linux 성능을 모니터링할 수 있습니다.
2. 메모리 성능 부하 확인
a)free
Linux에서 free 명령을 사용하면 현재 시스템 메모리 사용량을 확인할 수 있습니다. 에는 시스템에 남아 있거나 사용된 물리적 메모리와 스왑 메모리는 물론 코어에서 사용하는 공유 메모리와 버퍼도 표시됩니다.
3. 네트워크의 성능 부하를 확인합니다.
b)netstat
Netstat은 TCP/모니터링에 매우 유용한 콘솔 명령입니다. IP 네트워크 각 네트워크 인터페이스 장치에 대한 라우팅 테이블, 실제 네트워크 연결 및 상태 정보를 표시하는 도구입니다. Netstat는 IP, TCP, UDP 및 ICMP 프로토콜과 관련된 통계 데이터를 표시하는 데 사용됩니다. 일반적으로 기기의 각 포트의 네트워크 연결을 확인하는 데 사용됩니다.
c)sar
sar(System Activity Reporter 시스템 활동 보고서)는 현재 Linux에서 가장 포괄적인 시스템 성능 분석 도구 중 하나입니다. 시스템을 여러 측면에서 분석할 수 있습니다. 파일 읽기 및 쓰기, 시스템 호출 사용량, 디스크 I/O, CPU 효율성, 메모리 사용량, 프로세스 활동 및 IPC 관련 활동을 포함한 활동이 보고됩니다. 이 기사에서는 주로 CentOS 6.3 x64 시스템을 예로 들어 sar 명령을 소개합니다.
4. 디스크의 성능 부하 확인
a)iostat
Linux의 iostat 명령은 중앙 처리 장치(CPU) 통계 및 전체 시스템, 어댑터, tty 장치, 디스크 및 입출력의 입출력을 보고하는 데 사용할 수 있습니다. CD-ROM 통계.
부록 3: nginx 구성 및 문제 해결 가이드
nginx 문제의 문제 해결 방법
직접 시간 초과 또는 느린 처리 반환 알람이 발생하는 경우 nigix 측의 문제 해결 참조 방법은 다음과 같습니다. 요청 로그 상태를 확인하고 tail -flogs/access.log를 확인하고 upstream_status 필드를 살펴보세요.
200:表示正常; 502/503/504:表示处理慢,或者后端down机;再看upstream_response_time返回的时间是否真的较慢,有没有上百毫秒,或更高的,有则说明是后端服务有问题。 404:表示请求的路径不存在或不对,文件不在了。需要检查你配置在公众平台上的url路径是否正确; 服务器上的文件、程序是否存在。 403:表示无权限访问。 检查一下nginx.conf 是否有特殊的访问配置。 499: 则是客户端的问题,请联系微信团队。 此错误少见。
2 오류 로그 tail -f 로그/error_log를 확인하여 connect() 실패, 연결 거부, 피어에 의한 연결 재설정 등과 같은 오류 오류 로그가 있는지 확인하세요. nginx에 과부하된 연결 등이 있을 수 있습니다. 조건.
(1)查看系统的网络连接数情况确认是否有较大的链接数 # 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 //等待所有分组死掉 (2)查看系统的句柄配置情况,ulimit -n ,确认是否过小(小于请求数) (3)worker_rlimit_nofile、worker_connections配置项,是否过小(小于请求数)