アラームのトラブルシューティング ガイド

概要説明

---

WeChat パブリック プラットフォームは、WeChat サーバーによる開発者へのメッセージのプッシュ試行の失敗回数が所定のしきい値に達すると、アラーム メッセージを外部に公開しました。指定された WeChat アラーム グループ (設定方法: パブリック プラットフォーム -> 開発 - 運用保守センター -> インターフェイス アラーム) に送信されると、開発者はアラームに積極的に注意を払い、障害を直ちに解決し、サービス品質を向上することが求められます。 WeChat公式アカウント。

アラーム情報 (openid とタイムスタンプが提供される) の最後にある例に基づいて問題をより適切にトラブルシューティングするには、開発者は、アクセス層やロジック層などの各レベルの重要な情報を含む詳細なログを迅速な解決に役立てる必要があります。問題の特定。

現在 2 種類のアラームがあります:

1. すべての開発者が注意する必要がある一般的なアラーム。

2. 公式アカウントのサードパーティ プラットフォームのアラーム。WeChat オープン プラットフォーム (open.weixin.qq.com) でパブリック アカウントのサードパーティ プラットフォームになることを申請する開発者のみが、このアラームに注意する必要があります。

以下は、特定のアラームとトラブルシューティングのガイドラインの例です。

アラーム内容の説明

アラーム内容の説明:

a)appid：公众号appid
b)昵称: 公众号昵称
c)时间：所有报警，都会提供首次发生异常的时间。（如首次发生超时的时间，首次发生回应失败的时间）
d)内容：错误的具体描述
e)次数：发生失败的次数
f)错误样例：错误样例里注明了一些帮助查找问题的信息。如：首次超时开发者的IP和推送消息类型。如果是回应失败，错误样例还会注明首次回应失败时开发者的回包。

通常の状況では、アラームによって提供される IP、時間、およびメッセージ タイプを通じて、サードパーティの問題の原因を迅速に特定できます。

アラームの例 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 分間に 7,289 回発生しました。この 5 分間に初めて接続タイムアウトが発生したのは 2015-02-04 20: 13:09、開発者の IP は 180.150.190.135 で、イベント タイプはユーザーによってプッシュされたメッセージです。

さまざまなアラームのトラブルシューティング方法

1. DNS エラー

このエラーは、開発者にメッセージをプッシュするときに WeChat サーバーが DNS を解決できなかったことを意味します。このアラームが発生した場合は、開発者に確認してください:

a）填写的url,域名是否有误；
b) 域名是否发生变化，如过期，更新等。

上記 2 つの問題ではない場合は、WeChat パブリック プラットフォームにお問い合わせください。

2.DNSタイムアウト

現時点ではそのようなエラーは発生しません。

3. 接続タイムアウト

このエラーは、WeChat サーバーと開発者サーバーが 3S 内で正常に接続できなかったことを意味します。アラーム メッセージには、最初の接続障害が発生した時刻と接続の IP アドレスが表示されます。このアラームが発生した場合は、開発者に確認してください:

a)该IP是否有误。
b)该IP机器是否过载，连接过多。
c)如果是第三方提供服务器托管，托管商是否有故障。
d)网络运营商是否有故障。

4. リクエスト タイムアウト

WeChat サーバーがメッセージまたはイベントを開発者サーバーにプッシュしましたが、開発者は 5 秒以内に戻りませんでした。リクエストがタイムアウトすると、アラーム メッセージにはリクエストのタイムアウトが初めて発生した時刻、開発者 IP、およびメッセージ タイプが表示されます。開発者はご確認ください:

a）该IP是否有误
b）该IP是否接收到报警消息给出的该消息类型的请求
c）该请求是否处理时间过长

5. 応答失敗

開発者が Wiki の応答メッセージ形式に従ってメッセージに応答しない場合、またはネットワークエラーが発生した場合、アラーム応答失敗が報告されます。最初のリクエスト応答失敗を提供します。開発者の IP、メッセージ タイプ、応答メッセージの内容を開発者に確認してください:

a）该IP是否有误
b）该IP是否发生网络错误
c）该业务处理逻辑是否没有按照wiki规范回复消息，或是进入了异常逻辑。

6. MarkFail (自動ブロック)

WeChat の背景は開発者の失敗の数をカウントします。リアルタイムで。開発者へのメッセージのプッシュで多数の失敗が発生した場合、WeChat サーバーは自動的に開発者をブロックし、1 分以内にメッセージのプッシュを停止し、WeChat グループにアラームを送信します。このアラームは最高レベルのアラームです。開発者がこのアラームを受け取った場合は、できるだけ早くバックグラウンド障害に対処し、サービスを復元してください。実際、このアラームを受信する前に、開発者は必然的に接続タイムアウト、リクエスト タイムアウト、応答失敗などのアラームを受信し、WeChat サーバーによってブロックされ、パブリック アカウント サービスに深刻な影響を与えることを避けるために、これらの障害をすぐに解決する必要があります。

7.component_verify_ticket のプッシュがタイムアウトしました & 8.component_verify_ticket のプッシュが失敗しました & 9.コンポーネント メッセージのプッシュがタイムアウトしました & 10.コンポーネント メッセージのプッシュに失敗しました

上記の 4 つのアラームを受け取るのは、パブリック アカウントを持つサードパーティ プラットフォーム開発者のみです。他のパブリック アカウントは、開発者は注意する必要はありません。パブリック アカウント用のサードパーティ プラットフォームにはより多くのパブリック アカウントが含まれるため、パブリック アカウント用のサードパーティ プラットフォームのサービス品質にはより厳しい要件と警告が必要となるため、これら 4 つの特別なイベントは個別にレポートされます。具体的な問題点の発見方法は4、5と同様ですので、ここでは詳しく説明しません。サードパーティのパブリック アカウント プラットフォームの特定のアプリケーションと開発実装については、WeChat オープン プラットフォーム (open.weixin.qq.com) を参照してください。

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 のストレージと使用法の問題を解決するにはどうすればよいですか?

access_token がサービス中断を引き起こすというサードパーティからの報告がよくあります。パブリック プラットフォームで問題をトラブルシューティングすると、ほとんどのサードパーティが access_token を必死に更新し、その結果、access_token がインターフェイスの頻度制限を超えて無効になることがわかります。 ここでは、より単純な access_token のストレージと使用方法のソリューションを示します。

1）中控服务器定时（建议1小时）调用微信api，刷新access_token,将新的access_token 存入mysql（或其他存储），
2）其他工作服务器每次调用微信api时从mysql(或其他存储)获取access_token，并可在内存缓存一段时间（建议1分钟）。

パブリック プラットフォームは、access_token が更新された後も 5 分以内は古い access_token が引き続き使用できることを保証し、access_token の更新時にサードパーティが WeChat API の呼び出しに失敗しないようにします。

付録

付録 1: WeChat プッシュ メッセージ イベント リストと応答形式

詳細については、WeChat プッシュ メッセージとイベントの説明を参照してください

付録 2: サーバーのパフォーマンス負荷の表示よく使用されるツール

以下は、サーバーのパフォーマンス負荷を確認するための一般的なツールの簡単な紹介です。詳細なツールの使用方法については、別途参照してください。

1. CPU のパフォーマンス負荷を確認します

a)uptime

は、サーバーの全体的な負荷を観察するために使用されます (1 分、5 分、15 分)。通常の状況では、CPU の数よりも少ない必要があります。

b)vmstat

vmstat は Virtual Meomory Statistics の略称で、オペレーティング システムの仮想メモリ、プロセス、CPU アクティビティを監視できます。システム全体の状況に関する統計を実行します。通常、vmstat 5 5 (データが 5 秒ごとに 5 回生成される) コマンドを使用してテストされます。実際のシステム状態を反映したデータ概要が取得されます。

c)top top コマンドは、最も人気のある Unix/Linux パフォーマンス ツールの 1 つです。システム管理者は、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 上で最も包括的なシステム パフォーマンス分析ツールの 1 つであり、ファイルの読み取りと書き込み、システム コールの使用状況など、さまざまな側面からシステム アクティビティをレポートできます。ディスク I/O、CPU 効率、メモリ使用量、プロセス アクティビティ、IPC 関連アクティビティなど。この記事では、主に CentOS 6.3 x64 システムを例として sar コマンドを紹介します。

4. ディスクのパフォーマンス負荷を確認します

a)iostat

Linux で iostat コマンドを使用すると、システム全体、アダプター、TY デバイス、ディスクの中央処理装置 (CPU) 統計と入出力をレポートできます。 CD-ROM の統計。

付録 3: nginx の設定とトラブルシューティングガイド

nginx の問題のトラブルシューティング方法

ダイレクトタイムアウトまたは処理復帰が遅いというアラームがある場合、nigix 側でのトラブルシューティングの参照方法は次のとおりです。リクエストのログ ステータスを確認し、tail -f logs/access.log で、upstream_status フィールドを確認します。

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

2. エラー ログ (tail -f logs/error_log) を確認して、connect() の失敗、接続の拒否、ピアによる接続のリセットなどのエラー ログがあるかどうかを確認します。 nginx の接続数が過負荷になっているなどの状態を示している可能性があります。

りー