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

Bạn đang xem tài liệu về Apigee Edge.
Truy cập vào tài liệu Apigee X.
thông tin

Dấu hiệu

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

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

Thông báo lỗi

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

HTTP/1.1 502 Bad Gateway

Ngoài ra, bạn có thể 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 thông báo 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.

<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ể dẫn đến vấn đề này

Sau đây là một số nguyên nhân có thể dẫn đến lỗi 502 Cổng vào bị lỗi cho các API đi qua Apigee Edge:

Nguyên nhân Nội dung mô tả Hướng dẫn khắc phục sự cố áp dụng cho
Không có MP nào trong nhóm Lỗi này xảy ra nếu tất cả MP trong nhóm đều không hoạt động, tức là chúng đang ngừng hoạt động hoặc bận và do đó không phản hồi. Người dùng Edge Private Cloud
Cấu hình SSL không chính xác giữa các Bộ định tuyến và MP Lỗi này xảy ra nếu thiếu chứng chỉ gốc do CA của máy khách ký trong truststore của Bộ định tuyến của Edge. Người dùng Edge Private Cloud
Lỗi từ máy chủ phụ trợ Lỗi này sẽ xảy ra nếu máy chủ phụ trợ gặp lỗi và gửi phản hồi này. Người dùng Edge Public và Private Cloud

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

Lỗi này sẽ xảy ra nếu Router phát hiện thấy tất cả Message Processor trong một khu vực/trung tâm dữ liệu nhất định đều không hoạt động (ví dụ: nếu tất cả đều ngừng hoạt động).

Apigee Edge được định cấu hình theo cách mà lưu lượng truy cập API đến (yêu cầu) ở 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) ở cùng khu vực/trung tâm dữ liệu đó. Trong một số trường hợp, các thành phần Apigee Edge có thể được thiết lập chỉ trong một khu vực/trung tâm dữ liệu và trong một số trường hợp, chúng có thể được thiết lập ở 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ừ 2 Bộ định tuyến và Bộ xử lý thông báo trở lên đượ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 mà các yêu cầu API đang gặp lỗi 502 Cổng vào bị lỗi, 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 lỗi 502 hoặc bằng cách kiểm tra nhật ký truy cập NGINX trong thư mục /opt/apigee/var/log/edge-router/nginx/ trên từng 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ả Trình xử lý tin nhắn đều ngừng hoạt động

  1. Kiểm tra xem Bộ xử lý tin nhắn 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ả Trình xử lý tin nhắn đều ngừng hoạt động, hãy khởi động lại chúng.

Độ phân giải

Khởi động lại tất cả Trình xử lý tin nhắn bằng lệnh sau:

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

Trường hợp 2: Tất cả Trình xử lý thông báo đề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ả 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 vì tất cả đều đang bận xử lý các yêu cầu đang diễn ra.

  1. Kiểm tra xem Bộ xử lý tin nhắn 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ả Trình xử lý thông báo đều đang hoạt động, hãy kiểm tra xem(các) Trình xử lý thông báo có đang sử dụng CPU ở mức cao hay không, sau đó tạo 3 kết xuất luồng sau mỗi 30 giây bằng lệnh sau:
    <JAVA_HOME>/bin/jstack -l <pid> > <filename>
  3. Nếu(các) Trình xử lý thông báo đang có mức sử dụng bộ nhớ cao, hãy tạo một 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 Trình xử lý thông báo bằng lệnh bên dưới. Thao tác này sẽ giảm mức sử dụng 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ó còn tồn tại hay không.
  6. Liên hệ với Nhóm hỗ trợ Apigee và cung cấp các kết xuất luồng, kết xuất heap và nhật ký Trình xử lý thông báo (/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 các 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ư minh hoạ dưới đây:
        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. 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. Điều này cho thấy quá trình bắt tay SSL không thành công giữa Bộ định tuyến và Trình xử lý thông báo.
  4. Nếu bạn chú ý kỹ thông báo lỗi ở bước 1 và 2, thì cổng được dùng để giao tiếp với Trình xử lý thông báo là 8998. Đây là cổng không bảo mật nhưng giao thức là SSL (https). Thông thường, số cổng bảo mật được dùng là 8443. Vì cổng không bảo mật được dùng cho hoạt động giao tiếp bảo mật nên điều này 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à Trình xử lý thông báo. 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. Số 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ị xoá 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 rằng port# của Trình xử lý thông báo sẽ vẫn là 8998 trong các tệp cấu hình.

Độ phân giải

  1. Đảm bảo rằng bạn đã làm theo đúng tất cả các bước được cung cấp trong phần Định cấu hình TLS giữa Bộ định tuyến và Trình xử lý thông báo.
  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 xảy ra mỗi lần, thì 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à chuyển qua các giai đoạn khác nhau trong dấu vết. Nếu bạn nhận thấy mình nhận được thông báo "502 Bad Gateway" từ chính máy chủ phụ trợ, thì vấn đề có thể là do máy chủ phụ trợ gặp phải một số lỗi.
    Dấu vết cho thấy lỗi 502 Cổng không hợp lệ đến từ máy chủ phụ trợ
  2. Nếu vấn đề xảy ra không liên tục và bạn không thể ghi lại dấu vết, hãy
    1. Nếu là người dùng Đám mây công cộng, 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 thấy Mã lỗi là messaging.adaptors.http.flow.ErrorResponseCode và Nguồn lỗi là target, thì lỗi này là 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ý truy cập NGINX
      /opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log.
      Bạn sẽ thấy mục cho 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 thấy Mã lỗi là messaging.adaptors.http.flow.ErrorResponseCode và Nguồn lỗi là target, thì lỗi này là 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ợ để khắc phục vấn đề này ở 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ý Message Processor
    (/opt/apigee/var/log/edge-message-processor/logs/system.log).