序文
最近、同社のプロジェクトでセキュリティ脆弱性の調査が行われ、一連のサービスの fastjson、tomcat、log4j バージョンがアップグレードされ、その日は 50 以上のサービスが開始されました。ライブネットワークログを確認したところ、適応サービスに異常な情報があることがわかりました。エラー情報は次のとおりです。
Caused by: feign.FeignException: status 400 reading TestServiceClient#calculateDuration(String); content:
<!doctype html><html lang="en"><head><title>HTTP Status 400 – Bad Request</title><style type="text/css">body {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b {color:white;background-color:#525D76;} h1 {font-size:22px;} h2 {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a {color:black;} .line {height:1px;background-color:#525D76;border:none;}</style></head><body><h1>HTTP Status 400 – Bad Request</h1></body></html>
at feign.FeignException.errorStatus(FeignException.java:62)
at feign.codec.ErrorDecoder$Default.decode(ErrorDecoder.java:91)HTTP プロトコルに精通している人は、400 応答ステータスがクライアント要求が不正であり、サーバーが要求を解析できないことを意味することを知っているはずです。当時の捜査過程を見てみましょう。
トラブルシューティングのプロセス
アダプテーションサービスの例外ログについては前述の通り、クライアントリクエストの問題であることが判明しましたが、今回のアダプテーションサービスの開始内容は特定のビジネスニーズに関わるものではないため、稼働中のネットワーク上でクライアントアダプテーションサービスを緊急ロールバックするよう運用保守に通知しましたが、アダプテーションサービスの全ノードをロールバックした後も、古いバージョンのアダプテーションサービスが依然としてエラーを報告していることが判明しました。これは、問題が上位レベルの適応サービスによって引き起こされたものではないことを示しているため、注文ビジネスの確認を開始します。問題は、traceIdを元にkibana上のリンクを確認すると、アダプテーションサービスのエラーメッセージのみが確認でき、次のオーダーサービスのリクエスト情報が確認できないことです。そのとき、ライブ ネットワーク上のユーザーからのフィードバックが増えたため、注文サービスをロールバックするしか方法がなくなり、注文サービスのロールバックが完了すると、ライブ ネットワーク上のエラー ログが消えてしまいました。
その後、ライブネットワーク版を統合環境にデプロイし、ローカルIDEAでリモートデバッグし、録音ペンに注文を入れた結果、音声すらアップロードできなくなりましたが、後日、統合環境音声アップロードサービスのバージョンが翌日開始予定のバージョンであることを確認し、いくつかのバグ修正も行われたため、統合環境音声アップロードサービス版をライブネットワークにロールバックしました。ネットワークの現在のバージョンを再現するつもりです。サービスログの中で、いくつかの手がかりを見つけました。
Error parsing HTTP request header
Note: further occurrences of HTTP request parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: The HTTP header line [x-device-info:{"content":""0x00.","createTime":1562298084000,"deviceId":"12132123213213","deviceType":"ashkdahdksahkd","key":"232hahkdkadhksadhkad"}] does not conform to RFC 7230. The request has been rejected.
at org.apache.coyote.http11.Http11InputBuffer.skipLine(Http11InputBuffer.java:1074)
at org.apache.coyote.http11.Http11InputBuffer.parseHeader(Http11InputBuffer.java:977)
at org.apache.coyote.http11.Http11InputBuffer.parseHeaders(Http11InputBuffer.java:606)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:514)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:63)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:932)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1695)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52)
at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)オーダーサービスの最後でオーダーサービスのTomcatサービスによってアダプテーションサービスへのリクエストが拒否されたため、リクエストがオーダーサービスに全く届かなかったことが判明し、kibana上のtraceIdを元にリンクログを問い合わせたところオーダーサービスへのリクエスト情報がなかったと説明。上記の例外情報を見て、Tomcat のソース コードをたどって、Tomcat がリクエストを拒否する原因となった問題を確認しました。エラー箇所は以下の通りです
ここを参照して、rejectThisHeader が true に設定されるときを見てみましょう
このコメントに注意してください。 // 不正なコンテンツ長ヘッダーは常に拒否される必要があり、不正なコンテンツ長リクエスト ヘッダーは拒否されます。これを見て、リクエストの content-length が不正な箇所を確認しようとしましたが、リクエストヘッダーに content-length 属性がないことが判明しました。このリクエストはポストリクエストですが、ボディデータがありません。リクエストボディデータがない場合、Content-Length 属性はリクエストヘッダーに含まれません。Content-Length 属性は主にリクエストボディのデータの長さを示すために使用され、リクエストボディのデータがない場合はこの属性は省略されます。したがって、失敗の最終的な原因が見つかります。では、なぜ以前は問題がなかったのでしょうか? サービスの提出記録を読んだところ、同僚が jackson をアップグレードしただけでなく、tomcat のバージョンもアップグレードしたことがわかりました。
要約する
この件を通じてまとめると以下のとおりです
- 稼働中のネットワーク上で問題が発生しても慌てず、問題の本質を冷静に考え、業務ログだけをチェックするのではなく、業務ログを確認しても何もわかりません。ゲートウェイのログだけでなく、tomcatやNginxのaccess.logも非常に役に立ちます。これらのログをもとに、リクエストがどこで中断されているかを確認してください。
- 今回開始された一連のサービスは、一部のセキュリティ脆弱性の修復を目的としたものであり、ビジネス要件ではないため、テストの機能検証漏れが本番ネットワークの障害につながった可能性があり、依然として注意が必要である。