ตัวแทนของลูกค้าของเราซึ่งมี Application Stack อยู่ใน Microsoft Cloud (Azure) ได้แก้ไขปัญหา: เมื่อเร็วๆ นี้ คำขอบางรายการจากไคลเอ็นต์บางรายจากยุโรปเริ่มลงท้ายด้วยข้อผิดพลาด 400 (
หนึ่งในแอปพลิเคชันคือ API ซึ่งในที่สุดการรับส่งข้อมูลทั้งหมดจะมาถึง การรับส่งข้อมูลนี้ถูกฟังโดยเซิร์ฟเวอร์ HTTP
ข้อผิดพลาดใน Ingress มีลักษณะดังนี้:
{
"number_fields":{
"status":400,
"request_time":0.001,
"bytes_sent":465,
"upstream_response_time":0,
"upstream_retries":0,
"bytes_received":2328
},
"stream":"stdout",
"string_fields":{
"ingress":"app",
"protocol":"HTTP/1.1",
"request_id":"f9ab8540407208a119463975afda90bc",
"path":"/api/sign-in",
"nginx_upstream_status":"400",
"service":"app",
"namespace":"production",
"location":"/front",
"scheme":"https",
"method":"POST",
"nginx_upstream_response_time":"0.000",
"nginx_upstream_bytes_received":"120",
"vhost":"api.app.example.com",
"host":"api.app.example.com",
"user":"",
"address":"83.41.81.250",
"nginx_upstream_addr":"10.240.0.110:80",
"referrer":"https://api.app.example.com/auth/login?long_encrypted_header",
"service_port":"http",
"user_agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36",
"time":"2019-03-06T18:29:16+00:00",
"content_kind":"cache-headers-not-present",
"request_query":""
},
"timestamp":"2019-03-06 18:29:16",
"labels":{
"app":"nginx",
"pod-template-generation":"6",
"controller-revision-hash":"1682636041"
},
"namespace":"kube-nginx-ingress",
"nsec":6726612,
"source":"kubernetes",
"host":"k8s-node-55555-0",
"pod_name":"nginx-v2hcb",
"container_name":"nginx",
"boolean_fields":{}
}
ในเวลาเดียวกัน Kestrel ให้:
HTTP/1.1 400 Bad Request
Connection: close
Date: Wed, 06 Mar 2019 12:34:20 GMT
Server: Kestrel
Content-Length: 0
แม้จะมีการใช้คำฟุ่มเฟือยสูงสุด แต่ข้อผิดพลาดของชวาก็มีอยู่อย่างมาก ข้อมูลที่เป็นประโยชน์เพียงเล็กน้อย:
{
"number_fields":{"ThreadId":76},
"stream":"stdout",
"string_fields":{
"EventId":"{"Id"=>17, "Name"=>"ConnectionBadRequest"}",
"SourceContext":"Microsoft.AspNetCore.Server.Kestrel",
"ConnectionId":"0HLL2VJSST5KV",
"@mt":"Connection id "{ConnectionId}" bad request data: "{message}"",
"@t":"2019-03-07T13:06:48.1449083Z",
"@x":"Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException: Malformed request: invalid headers.n at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1Connection.TryParseRequest(ReadResult result, Boolean& endConnection)n at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.<ProcessRequestsAsync>d__185`1.MoveNext()",
"message":"Malformed request: invalid headers."
},
"timestamp":"2019-03-07 13:06:48",
"labels":{
"pod-template-hash":"2368795483",
"service":"app"
},
"namespace":"production",
"nsec":145341848,
"source":"kubernetes",
"host":"k8s-node-55555-1",
"pod_name":"app-67bdcf98d7-mhktx",
"container_name":"app",
"boolean_fields":{}
}
ดูเหมือนว่ามีเพียง tcpdump เท่านั้นที่จะช่วยแก้ปัญหานี้ได้... แต่ฉันจะทำซ้ำเกี่ยวกับห่วงโซ่การรับส่งข้อมูล:
การสอบสวน
แน่นอนว่าควรฟังเสียงจราจรจะดีกว่า บนโหนดเฉพาะนั้นโดยที่ Kubernetes ได้ปรับใช้พ็อด: ปริมาณของดัมพ์จะมากจนสามารถค้นหาบางสิ่งได้อย่างรวดเร็วเป็นอย่างน้อย และแท้จริงเมื่อตรวจดูก็พบว่ามีกรอบดังต่อไปนี้
GET /back/user HTTP/1.1
Host: api.app.example.com
X-Request-ID: 27ceb14972da8c21a8f92904b3eff1e5
X-Real-IP: 83.41.81.250
X-Forwarded-For: 83.41.81.250
X-Forwarded-Host: api.app.example.com
X-Forwarded-Port: 443
X-Forwarded-Proto: https
X-Original-URI: /front/back/user
X-Scheme: https
X-Original-Forwarded-For: 83.41.81.250
X-Nginx-Geo-Client-Country: Spain
X-Nginx-Geo-Client-City: M.laga
Accept-Encoding: gzip
CF-IPCountry: ES
CF-RAY: 4b345cfd1c4ac691-MAD
CF-Visitor: {"scheme":"https"}
pragma: no-cache
cache-control: no-cache
accept: application/json, text/plain, */*
origin: https://app.example.com
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.119 Safari/537.36
referer: https://app.example.com/auth/login
accept-language: en-US,en;q=0.9,en-GB;q=0.8,pl;q=0.7
cookie: many_encrypted_cookies; .AspNetCore.Identity.Application=something_encrypted;
CF-Connecting-IP: 83.41.81.250
True-Client-IP: 83.41.81.250
CDN-Loop: cloudflare
HTTP/1.1 400 Bad Request
Connection: close
Date: Wed, 06 Mar 2019 12:34:20 GMT
Server: Kestrel
Content-Length: 0
เมื่อตรวจสอบกองขยะอย่างใกล้ชิดก็สังเกตเห็นคำว่า M.laga
. เดาได้ง่ายว่าไม่มีเมือง M.laga ในสเปน (แต่ก็มี
ingress.kubernetes.io/configuration-snippet: |
proxy_set_header X-Nginx-Geo-Client-Country $geoip_country_name;
proxy_set_header X-Nginx-Geo-Client-City $geoip_city;
หลังจากปิดการใช้งานการส่งต่อส่วนหัวเหล่านี้ ทุกอย่างก็เรียบร้อยดี! (ในไม่ช้าก็เห็นได้ชัดว่าตัวแอปพลิเคชันไม่ต้องการส่วนหัวเหล่านี้อีกต่อไป)
ตอนนี้เรามาดูปัญหากัน ให้เป็นปกติมากกว่านี้. สามารถทำซ้ำได้อย่างง่ายดายภายในแอปพลิเคชันโดยการร้องขอ telnet ไปที่ localhost:80
:
GET /back/user HTTP/1.1
Host: api.app.example.com
cache-control: no-cache
accept: application/json, text/plain, */*
origin: https://app.example.com
Cookie: test=Desiree
... กลับมา 401 Unauthorized
, อย่างที่คาดไว้. จะเกิดอะไรขึ้นถ้าเราทำ:
GET /back/user HTTP/1.1
Host: api.app.example.com
cache-control: no-cache
accept: application/json, text/plain, */*
origin: https://app.example.com
Cookie: test=Désirée
?
จะกลับมา 400 Bad request
— ในบันทึกแอปพลิเคชัน เราจะได้รับข้อผิดพลาดที่เราคุ้นเคยอยู่แล้ว:
{
"@t":"2019-03-31T12:59:54.3746446Z",
"@mt":"Connection id "{ConnectionId}" bad request data: "{message}"",
"@x":"Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException: Malformed request: invalid headers.n at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1Connection.TryParseRequest(ReadResult result, Boolean& endConnection)n at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.<ProcessRequestsAsync>d__185`1.MoveNext()",
"ConnectionId":"0HLLLR1J974L9",
"message":"Malformed request: invalid headers.",
"EventId":{
"Id":17,
"Name":"ConnectionBadRequest"
},
"SourceContext":"Microsoft.AspNetCore.Server.Kestrel",
"ThreadId":71
}
ผลของการ
โดยเฉพาะชวา
ปัจจัยเพิ่มเติมในกรณีของเราคือขณะนี้ลูกค้าไม่ได้วางแผนที่จะเปลี่ยนแปลงการใช้งาน Kestrel ในแอปพลิเคชัน อย่างไรก็ตาม ปัญหาใน AspNetCore นั้นเอง (
โดยสรุป: หมายเหตุไม่เกี่ยวกับปัญหาเฉพาะของ Kestrel หรือ UTF-8 อีกต่อไป (ในปี 2019?!) แต่เกี่ยวกับข้อเท็จจริงที่ว่า มีสติและศึกษาอย่างสม่ำเสมอ ทุกขั้นตอนที่คุณทำในขณะที่ค้นหาปัญหาไม่ช้าก็เร็วจะเกิดผล ขอให้โชคดี!
PS
อ่านเพิ่มเติมในบล็อกของเรา:
- «
6 ข้อบกพร่องของระบบความบันเทิงในการทำงานของ Kubernetes [และวิธีแก้ปัญหา] "; - «
เคล็ดลับและลูกเล่น Kubernetes: หน้าข้อผิดพลาดที่กำหนดเองใน NGINX Ingress "; - «
ภาพรวมและการเปรียบเทียบตัวควบคุม Ingress สำหรับ Kubernetes "; - «
การตรวจสอบการส่ง Ping ระหว่างโหนด Kubernetes - สูตรของเรา "; - «
3 กรณีผิดปกติเกี่ยวกับระบบย่อยเครือข่าย Linux '
ที่มา: will.com