502 Cổng kết nối bị lỗi

Bạn đang xem tài liệu về Apigee Edge.
Chuyển đến tài liệu về Apigee X. thông tin

Triệu chứng

Ứng dụng sẽ nhận được mã trạng thái HTTP 502 kèm theo thông báo "Bad Gateway" (Cổng vào lỗi) dưới dạng phản hồi cho lệnh gọi API.

Mã trạng thái HTTP 502 có nghĩa là máy khách không nhận được phản hồi hợp lệ từ các máy chủ phụ trợ thực sự đáp ứng yêu cầu.

Thông báo lỗi

Ứng dụng khách nhận được mã phản hồi sau đây:

HTTP/1.1 502 Bad Gateway

Ngoài ra, bạn có thể nhận thấy các thông báo lỗi sau:

<html>
<head>
<title>Error</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>An error occurred.</h1>
<p>Sorry, the page you are looking for is currently unavailable.<br/>
Please try again later.</p>
</body>
</html>

Nếu lỗi xuất phát từ máy chủ phụ trợ, thì bạn có thể thấy như sau. Thông báo lỗi từ phần phụ trợ hoàn toàn phụ thuộc vào cách triển khai phần phụ trợ. 

<html>
<head><title>502 Bad Gateway</title></head>
<body bgcolor="white">
<center><h1>502 Bad Gateway</h1></center>
</body>
</html>

Nguyên nhân có thể xảy ra

Sau đây là một số nguyên nhân có thể dẫn đến lỗi 502 Bad Gateway đối với các API chạy qua Apigee Edge:

Nguyên nhân Mô tả Hướng dẫn khắc phục sự cố có thể áp dụng cho
Không có MP trong nhóm Lỗi này xuất hiện nếu tất cả các MP trong nhóm không hoạt động, tức là các MP này đang hoạt động hoặc đang bận nên không phản hồi. Người dùng Đám mây riêng tư Edge
Cấu hình SSL không chính xác giữa Bộ định tuyến và MP Lỗi này xảy ra nếu ứng dụng thiếu chứng chỉ gốc có chữ ký của CA trong kho lưu trữ tin cậy của Bộ định tuyến của Edge. Người dùng Đám mây riêng tư Edge
Lỗi từ máy chủ phụ trợ Lỗi này sẽ được quan sát thấy nếu máy chủ phụ trợ gặp sự cố và gửi phản hồi này. Người dùng Đám mây công khai và riêng tư của Edge

Nguyên nhân: Không có MP trong nhóm

Lỗi này sẽ xảy ra nếu Bộ định tuyến thấy rằng tất cả Bộ xử lý thư trong một khu vực/trung tâm dữ liệu nhất định đều không hoạt động (ví dụ: tất cả đều ngừng hoạt động).

Apigee được định cấu hình sao cho lưu lượng truy cập API gửi đến (yêu cầu) trong một khu vực/trung tâm dữ liệu nhất định luôn được định tuyến từ Bộ định tuyến đến Bộ xử lý thông báo (MP) trong cùng một khu vực/trung tâm dữ liệu. Trong một số trường hợp, bạn chỉ cần thiết lập các thành phần Apigee Edge tại một khu vực/trung tâm dữ liệu và cũng có thể thiết lập các thành phần này ở nhiều khu vực/trung tâm dữ liệu. Trong mỗi khu vực/trung tâm dữ liệu sẽ có ít nhất 2 Bộ định tuyến và Bộ xử lý thư được định cấu hình.

Chẩn đoán

  1. Xác định (các) khu vực/trung tâm dữ liệu nơi yêu cầu API không thực hiện được kèm theo lỗi 502 Bad Gateway (Cổng vào không hợp lệ) nếu có nhiều khu vực/trung tâm dữ liệu. Bạn có thể tìm thấy thông tin này bằng cách xác định khu vực mà người dùng đang gặp phải lỗi 502 hoặc kiểm tra nhật ký Truy cập NGINX trong thư mục /opt/apigee/var/log/edge-router/nginx/ trên mỗi Bộ định tuyến thuộc các khu vực khác nhau.
  2. Bạn sẽ thấy lỗi sau trong nhật ký lỗi NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log)
    2019/06/24 15:26:00 [error] 4796#4796: *56357443 no live upstreams while connecting to upstream, client: <Router_IP_address>, server: <HostAlias>, request: "PUT <BasePath> HTTP/1.1", upstream: "http://<ListOfMP-IP_R-MP-Port>/<BasePath>", host: "<HostAlias>"

Trường hợp 1: Tất cả các bộ xử lý tin nhắn đều ngừng hoạt động

  1. Kiểm tra xem Bộ xử lý thư trong khu vực/trung tâm dữ liệu cụ thể có đang hoạt động hay không.
  2. Nếu tất cả các Bộ xử lý thư đều ngừng hoạt động, hãy khởi động lại các bộ xử lý đó.

Độ phân giải

Khởi động lại tất cả Bộ xử lý thư bằng lệnh sau:

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Trường hợp 2: Tất cả Bộ xử lý tin nhắn đều đang bận xử lý các yêu cầu đang diễn ra

Lỗi này sẽ xảy ra nếu Bộ định tuyến nhận thấy rằng tất cả các Bộ xử lý thông báo trong một khu vực/trung tâm dữ liệu nhất định đều không hoạt động do tất cả đều đang xử lý các yêu cầu đang diễn ra.

  1. Kiểm tra xem Bộ xử lý thư trong khu vực/trung tâm dữ liệu cụ thể có đang hoạt động hay không.
  2. Nếu tất cả Bộ xử lý thông báo đều đã được thiết lập và hoạt động, hãy kiểm tra xem(các) Bộ xử lý thông báo có đang bị mức sử dụng CPU cao hay không, sau đó cứ mỗi 30 giây lại tạo 3 tệp kết xuất luồng bằng lệnh sau:
    <JAVA_HOME>/bin/jstack -l <pid> > <filename>
  3. Nếu(các) Bộ xử lý thư gặp phải vấn đề mức sử dụng bộ nhớ cao, hãy tạo tệp báo lỗi bằng lệnh sau:
    sudo -u apigee /bin/jmap -dump:live,format=b,file=
  4. Khởi động lại Bộ xử lý thư bằng lệnh dưới đây. Thao tác này sẽ làm giảm CPU và Bộ nhớ:
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  5. Theo dõi các lệnh gọi API để xác nhận xem vấn đề còn tồn tại hay không.
  6. Liên hệ với Nhóm hỗ trợ API và cung cấp tệp kết xuất luồng, tệp báo lỗi và nhật ký Trình xử lý thư (/opt/apigee/var/log/edge-message-processor/logs/system.log) để giúp điều tra nguyên nhân dẫn đến mức sử dụng CPU/bộ nhớ cao.

Nguyên nhân: Cấu hình SSL không chính xác giữa Bộ định tuyến và MP

Chẩn đoán

  1. Kiểm tra nhật ký truy cập NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log). Bạn sẽ thấy phản hồi 502 như sau:
        2019-07-23T12:13:42+03:00	sc-10-254-226-23	10.X.X.X:53634	10.X.X.X:8998	0.000	-	-	502	502	189	344	GET <path> curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2	<host alias>	mp-10-254-226-23-23706-8552529-1	10.129.107.101	-	-	-1	-	-	dc-2	gateway-2	green	-	gateway-2	dc-2	op	pilot	http	-
  2. Hãy kiểm tra nhật ký lỗi NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log). Bạn sẽ thấy các lỗi như sau:
    	2019/07/30 17:02:24 [error] 7691#7691: *11753633 peer closed connection in SSL handshake while SSL handshaking to upstream, client: X.X.X.X, server: <HostAlias>, request: "GET /no-target HTTP/1.1", upstream: "https://X.X.X.X:8998/no-target", host: "<HostAlias>"
  3. Thông báo này cho thấy sự kiện bắt tay SSL giữa Bộ định tuyến và Bộ xử lý thư không thành công.
  4. Nếu bạn chú ý kỹ trong thông báo lỗi ở bước 1 và 2 thì cổng # được dùng để giao tiếp với Bộ xử lý thông báo là 8998. Đây là một cổng không an toàn nhưng giao thức là SSL (https). Thông thường, cổng bảo mật # được sử dụng là 8443. Vì cổng không an toàn được sử dụng cho giao tiếp an toàn, cổng này sẽ gây ra lỗi bắt tay SSL.
  5. Thông thường, điều này có thể xảy ra nếu bạn bỏ lỡ bất kỳ bước nào hoặc đặt bất kỳ giá trị không chính xác nào trong khi định cấu hình SSL giữa Bộ định tuyến và Bộ xử lý thông báo. Hãy tham khảo các bước được nêu tại đây.
    Ví dụ: lỗi này có thể xảy ra nếu
    1. Cổng # được chỉ định là 8998 thay vì 8443 trong /opt/apigee/customer/application/message-processor.properties as shown below
              conf/message-processor-communication.properties+local.http.port=8998
    2. Các tệp cấu hình Bộ định tuyến trong thư mục /opt/nginx/conf.d/* không bị xóa và Bộ định tuyến chưa được khởi động lại trong khi thực hiện cấu hình SSL. Trong trường hợp này, bạn có thể nhận thấy cổng# của Bộ xử lý thư vẫn là 8998 trong tệp cấu hình.

Độ phân giải

  1. Đảm bảo tất cả các bước đã nêu trong bài viết Định cấu hình TLS giữa Bộ định tuyến và Trình xử lý thư đều được tuân thủ đúng cách.
  2. Nếu vấn đề vẫn tiếp diễn, hãy chuyển đến phần Thu thập thông tin chẩn đoán.

Nguyên nhân: Lỗi từ máy chủ phụ trợ

Chẩn đoán

  1. Nếu lỗi luôn xảy ra, bạn có thể ghi lại dấu vết giao diện người dùng cho các yêu cầu không thành công. Chọn một yêu cầu không thành công và di chuyển qua nhiều giai đoạn trong quá trình theo dõi. Nếu bạn nhận thấy mình nhận được “502 Bad Gateway” từ chính máy chủ phụ trợ, thì vấn đề này có thể là do một số lỗi có thể đã xảy ra trên máy chủ phụ trợ.
    Dấu vết cho thấy lỗi 502 Cổng vào không hợp lệ đến từ máy chủ phụ trợ
  2. Nếu vấn đề xuất hiện liên tục và bạn không thể ghi lại dấu vết,
    1. Nếu là người dùng Public Cloud, bạn có thể sử dụng tính năng Giám sát API và kiểm tra thông tin chi tiết về lỗi 502.
      1. Nếu bạn quan sát thấy Mã lỗi là messaging.adaptors.http.flow.ErrorResponseCode và Nguồn lỗi là target, thì lỗi do máy chủ phụ trợ gây ra.
    2. Nếu là người dùng Đám mây riêng tư, bạn có thể phân tích nhật ký Quyền truy cập NGINX
      /opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log.
      Bạn sẽ thấy mục nhập yêu cầu không thành công như sau:
      2017-02-24T14:42:12+00:00	rt-01	192.8.155.2:18118	192.168.84.166:8998	10.225	-	-	502	502	440	0	GET /adv-eadlg-test/documents?type=doctype HTTP/1.1	rt-02efawae234-1234	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36	myorg-dev.apigee.net	 rt-02efawae234-1234	6	-	false	target	messaging.adaptors.http.flow.ErrorResponseCode	null/null	-	/organizations/myorg/environments/dev/apiproxies/api123
      1. Nếu bạn quan sát thấy Mã lỗi là messaging.adaptors.http.flow.ErrorResponseCode và Nguồn lỗi là target, thì lỗi do máy chủ phụ trợ gây ra.

Độ phân giải

  1. Hãy làm việc với nhóm máy chủ phụ trợ của bạn để khắc phục sự cố này trong phần phụ trợ.

Thu thập thông tin chẩn đoán

  1. Nhật ký truy cập NGINX
    (/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log)
    và Nhật ký lỗi
    (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log).
  2. Nhật ký Trình xử lý thông báo
    (/opt/apigee/var/log/edge-message-processor/logs/system.log).