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 khách sẽ nhận được mã trạng thái HTTP 502 kèm theo thông báo "Bad Gateway" làm 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 sẽ nhận được mã phản hồi sau đây:

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ợ, 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ể xảy ra

Dưới đâ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 đ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 trong nhóm Lỗi này sẽ xảy ra nếu tất cả MP trong nhóm không hoạt động, tức là chúng đang ngừng hoạt động hoặc đang bận nên 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 Bộ định tuyến và MP Lỗi này sẽ xảy ra nếu chứng chỉ gốc đã ký của CA của ứng dụng bị thiếu trong kho tin cậy 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ẽ xuất hiện nếu máy chủ phụ trợ gặp sự cố 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 trong nhóm

Lỗi này sẽ xảy ra nếu Bộ định tuyến nhận thấy 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 không có sẵn (ví dụ: nếu tất cả đều không hoạt động).

Apigee Edge được định cấu hình sao cho lưu lượng truy cập API đến (các 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ý tin nhắn (MP) trong cùng một khu vực/trung tâm dữ liệu. Trong một số trường hợp, các thành phần Apigee có thể chỉ được thiết lập ở một khu vực/trung tâm dữ liệu. Trong một số trường hợp, các thành phần này 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ó hai hoặc nhiều 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 mà các yêu cầu API không thực hiện được do lỗi 502 Bad Gateway, nếu có nhiều khu vực/trung tâm dữ liệu. Bạn có thể tìm điều này bằng cách xác định khu vực mà người dùng đang quan sát 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 mỗi Bộ định tuyến thuộc những 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ả Bộ xử lý tin nhắn ngừng hoạt động

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

Độ phân giải

Khởi động lại tất cả Trình 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ý thư đ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 tất cả Bộ xử lý thư trong một khu vực/trung tâm dữ liệu nhất định không khả dụng vì chúng đều đang bận xử lý các yêu cầu đang diễn ra.

  1. Kiểm tra xem Bộ xử lý thông báo trong khu vực/trung tâm dữ liệu cụ thể có được thiết lập và đang chạy 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ư này có đang gặp tình trạng sử dụng CPU cao hay không, sau đó tạo 3 tệp kết xuất luồng (thread dump) 30 giây một lần bằng lệnh sau:
    <JAVA_HOME>/bin/jstack -l <pid> > <filename>
  3. Nếu(các) Trình xử lý thư đang gặp tình trạng 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 Trình xử lý thư bằng lệnh bên dưới. 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. Giám sát 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 Bộ phận 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ô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 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. Hình ảnh này cho thấy không thể bắt tay SSL giữa Bộ định tuyến và Trình xử lý thư.
  4. Nếu bạn chú ý cẩn thận thông báo lỗi ở bước #1 và #2, thì cổng # được sử 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). Số cổng bảo mật thường được dùng là 8443. Do cổng không bảo mật được dùng để giao tiếp an toàn nên sẽ gây ra lỗi giao tiếp 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ư. 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 rằng cổng# của Bộ xử lý thư 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 thực hiện đú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ư.
  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, 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 rằng mình nhận được “502 Bad Gateway” (Cổng vào lỗi 502) từ chính máy chủ phụ trợ, thì vấn đề có thể là do có thể đã xảy ra lỗi trên máy chủ phụ trợ.
    Dấu vết cho thấy Cổng vào lỗi 502 đến từ máy chủ phụ trợ
  2. Nếu sự cố không 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 Cloud Public, bạn có thể sử dụng tính năng Giám sát API và xem 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 đó là do máy chủ phụ trợ.
    2. Nếu là người dùng Cloud 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 nhập của 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 đó là do máy chủ phụ trợ.

Độ 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ư
    (/opt/apigee/var/log/edge-message-processor/logs/system.log).