Lỗi máy chủ nội bộ 500 - Máy chủ phụ trợ

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

Video

Video Mô tả
500 Lỗi máy chủ nội bộ – do phần phụ trợ gây ra Minh hoạ một 500 Internal Server Error theo thời gian thực do máy chủ phụ trợ gây ra, cùng với các bước khắc phục sự cố và giải quyết lỗi.

Dấu hiệu

Ứng dụng khách nhận được mã trạng thái HTTP 500 kèm theo thông báo Internal Server Error làm phản hồi cho các lệnh gọi API.

Mã trạng thái HTTP 500 là một phản hồi lỗi chung. Điều này có nghĩa là máy chủ đã gặp phải một điều kiện không mong muốn khiến máy chủ không thực hiện được yêu cầu. Lỗi này thường do máy chủ trả về khi không có mã lỗi nào khác phù hợp.

Thông báo lỗi

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

HTTP/1.1 500 Internal Server Error

Ngoài ra, bạn có thể thấy một thông báo lỗi tương tự như thông báo dưới đây:

Mẫu số 1

Phản hồi mẫu của máy chủ phụ trợ số 1

{"errorMessage":"Sorry either your e-mail or password didn't match.",
"errorParameters":"{}",
"errorCode":"500",
"errorKey":"INVALID_EMAILPASSWORD"}

Mẫu số 2

Phản hồi mẫu của máy chủ phụ trợ số 2

<Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
   <Body>
      <Error>
         <code>500</code>
         <message xml:lang="en-US">Not Authorised(e4138fa0-ec57).</message>
      </Error>
   </Body>
</Envelope>

Các nguyên nhân có thể

Máy chủ phụ trợ có thể trả về 500 Internal Server Error do một số nguyên nhân. Sổ tay này giải thích cách khắc phục sự cố bằng các bước phổ biến và giải quyết lỗi này bất kể nguyên nhân gây ra lỗi.

Sau đây là những nguyên nhân có thể gây ra vấn đề này:

Nguyên nhân Mô tả Hướng dẫn khắc phục sự cố áp dụng cho
Lỗi trong máy chủ phụ trợ Máy chủ phụ trợ có thể gặp lỗi vì lý do nào đó. Người dùng Edge Private Cloud và Public Cloud

Các bước chẩn đoán thường gặp

Hãy sử dụng một trong các công cụ/kỹ thuật sau để chẩn đoán lỗi này:

Giám sát API

Quy trình 1: Sử dụng tính năng Giám sát API

Cách chẩn đoán lỗi bằng tính năng Giám sát API:

  1. Đăng nhập vào giao diện người dùng Apigee Edge với tư cách là người dùng có vai trò phù hợp.

  2. Chuyển sang tổ chức mà bạn muốn điều tra vấn đề.

  3. Chuyển đến trang Phân tích > Giám sát API > Điều tra.
  4. Chọn khung thời gian cụ thể mà bạn nhận thấy lỗi.

  5. Vẽ Mã lỗi theo Thời gian.

  6. Chọn một ô có mã lỗi messaging.adaptors.http.flow.ErrorResponseCode như minh hoạ bên dưới:

    ( xem hình ảnh lớn hơn)

  7. Thông tin về mã lỗi messaging.adaptors.http.flow.ErrorResponseCode sẽ xuất hiện như hình dưới đây:

    ( xem hình ảnh lớn hơn)

  8. Nhấp vào Xem nhật ký rồi mở rộng hàng của yêu cầu không thực hiện được.

    ( xem hình ảnh lớn hơn)

  9. Trong cửa sổ Nhật ký, hãy lưu ý những thông tin sau:
    • Mã thông báo yêu cầu
    • Mã trạng thái: 500
    • Nguồn lỗi: target
    • Mã lỗi: messaging.adaptors.http.flow.ErrorResponseCode

Trace

Quy trình 2: Sử dụng công cụ Trace

Cách chẩn đoán lỗi bằng công cụ Trace (Theo dõi):

  1. Bật phiên theo dõi và một trong hai
    • Chờ lỗi 500 Internal Server Error với mã lỗi messaging.adaptors.http.flow.ErrorResponseCode xảy ra, hoặc
    • Nếu bạn có thể tái hiện vấn đề, hãy thực hiện lệnh gọi API để tái hiện vấn đề 500 Internal Server Error

  2. Đảm bảo bạn đã bật chế độ Show all FlowInfos (Hiện tất cả FlowInfo):

  3. Chọn một trong các yêu cầu không thực hiện được và kiểm tra dấu vết.
  4. Điều hướng qua các giai đoạn khác nhau của dấu vết và xác định vị trí xảy ra lỗi.

  5. Bạn thường sẽ thấy lỗi này trong một luồng sau giai đoạn Phản hồi nhận được từ máy chủ đích như minh hoạ dưới đây:

    ( xem hình ảnh lớn hơn)

  6. Chuyển đến Giai đoạn AX (Dữ liệu Analytics được ghi lại) trong dấu vết rồi nhấp vào giai đoạn đó.

  7. Di chuyển xuống phần Phase Details Response Headers (Tiêu đề phản hồi chi tiết theo giai đoạn) và xác định các giá trị của X-Apigee-fault-code và X-Apigee-fault-source, cũng như X-Apigee-Message-ID như minh hoạ dưới đây:

    ( xem hình ảnh lớn hơn)

  8. Lưu ý các giá trị của X-Apigee-fault-code, X-Apigee-fault-source và X-Apigee-Message-ID:
    9. Tiêu đề phản hồi Giá trị
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
    X-Apigee-fault-source target
    X-Apigee-Message-ID MESSAGE_ID

NGINX

Quy trình 3: Sử dụng nhật ký truy cập NGINX

Cách chẩn đoán lỗi bằng nhật ký truy cập NGINX:

  1. Nếu là người dùng Đám mây riêng, bạn có thể sử dụng nhật ký truy cập NGINX để xác định thông tin chính về 500 Internal Server Error HTTP.

  2. Kiểm tra nhật ký truy cập NGINX:

    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

  3. Tìm xem có lỗi 500 nào với mã lỗi messaging.adaptors.http.flow.ErrorResponseCode trong một khoảng thời gian cụ thể hay không (nếu vấn đề xảy ra trong quá khứ) hoặc có yêu cầu nào vẫn không thành công với 500 hay không.

  4. Nếu bạn tìm thấy bất kỳ lỗi 500 nào có X-Apigee-fault-code khớp với giá trị của messaging.adaptors.http.flow.ErrorResponseCode, thì hãy xác định giá trị của X-Apigee-fault-source.

    Ví dụ về lỗi 500 trong nhật ký truy cập của NGINX:

    ( xem hình ảnh lớn hơn)

    Mục nhập mẫu ở trên trong nhật ký truy cập NGINX có các giá trị sau cho X-Apigee-fault-code và X-Apigee-fault-source:

    Tiêu đề Giá trị
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
    X-Apigee-fault-source target

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

Chẩn đoán

500 Internal Server Error do máy chủ phụ trợ phản hồi có thể là do một số lý do. Bạn sẽ cần chẩn đoán từng trường hợp một cách độc lập.

  1. Xác định Mã lỗi, Nguồn lỗi cho lỗi quan sát được bằng cách sử dụng API Monitoring, công cụ Theo dõi hoặc nhật ký truy cập NGINX như được giải thích trong Các bước chẩn đoán thường gặp.
  2. Nếu Nguồn lỗi là target và Mã lỗi là messaging.adaptors.http.flow.ErrorResponseCode, thì điều đó cho biết lỗi do máy chủ phụ trợ trả về.
  3. Bạn có thể thực hiện một trong các bước sau để chẩn đoán nguyên nhân gây ra vấn đề:

    Trace

    Sử dụng Trace:

    Nếu bạn có một phiên theo dõi cho lỗi này, hãy thực hiện các bước sau:

    1. Trong phần Trace (Dấu vết), hãy chọn yêu cầu API không thực hiện được với 500 Internal Server Error.

    2. Chọn giai đoạn Response received from target server (Đã nhận được phản hồi từ máy chủ đích) trong yêu cầu API không thành công như minh hoạ trong hình bên dưới:

      ( xem hình ảnh lớn hơn)

    3. Di chuyển xuống phần Phase Details (Thông tin chi tiết về giai đoạn) rồi kiểm tra Response Content (Nội dung phản hồi). Phần này chứa phản hồi từ máy chủ phụ trợ.

      Nội dung phản hồi mẫu:

      <Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
   <Body>
      <Error>
         <code>500</code>
         <message xml:lang="en-US">Not Authorised(e4138fa0-ec57).</message>
      </Error>
   </Body>
</Envelope>

      Trong phản hồi ở trên, xin lưu ý rằng thông báo lỗi từ máy chủ phụ trợ là Not Authorised (Không được phép). Điều này cho biết người dùng có thể đã truyền thông tin đăng nhập không hợp lệ và đó là lý do họ gặp phải lỗi này.

    Gọi máy chủ phụ trợ

    Thực hiện cuộc gọi trực tiếp đến máy chủ phụ trợ:

    Bạn có thể thực hiện cuộc gọi trực tiếp đến máy chủ phụ trợ và:

    • Xác thực xem bạn có nhận được cùng một phản hồi 500 Internal Server Error như khi yêu cầu được thực hiện thông qua Apigee Edge hay không
    • Kiểm tra thông báo lỗi (phản hồi) nhận được từ máy chủ phụ trợ

    Thực hiện các bước sau để thực hiện lệnh gọi trực tiếp đến máy chủ phụ trợ:

    1. Đảm bảo rằng bạn có tất cả các tiêu đề, tham số truy vấn bắt buộc và mọi thông tin đăng nhập cần được truyền đến máy chủ phụ trợ trong yêu cầu.
    2. Nếu dịch vụ phụ trợ có thể truy cập công khai, thì bạn có thể sử dụng lệnh curl, Postman hoặc bất kỳ REST Client nào khác và gọi trực tiếp API máy chủ phụ trợ.

    3. Nếu chỉ có thể truy cập vào máy chủ phụ trợ từ Trình xử lý tin nhắn, thì bạn có thể sử dụng lệnh curl, Postman hoặc bất kỳ Ứng dụng REST nào khác và gọi API máy chủ phụ trợ trực tiếp từ Trình xử lý tin nhắn.

    4. Xác thực xem dịch vụ phụ trợ có thực sự trả về 500 Internal Server Error hay không, đồng thời kiểm tra thông báo lỗi (phản hồi) do máy chủ phụ trợ trả về và xác định nguyên nhân gây ra lỗi này.

    Nhật ký máy chủ phụ trợ

    Sử dụng nhật ký máy chủ phụ trợ

    1. Xem xét nhật ký máy chủ phụ trợ và cố gắng tìm hiểu thêm chi tiết về lỗi cũng như nguyên nhân gây ra lỗi.
    2. Nếu có thể, hãy bật chế độ gỡ lỗi trên máy chủ phụ trợ để biết thêm thông tin chi tiết về lỗi và nguyên nhân.

  4. Kiểm tra xem bạn có đang sử dụng chuỗi proxy trong điểm cuối mục tiêu cụ thể của Proxy API không thành công hay không; tức là nếu máy chủ mục tiêu/điểm cuối mục tiêu đang gọi một proxy khác trong Apigee Edge. Cách xác định:

    1. Nếu bạn có dấu vết cho yêu cầu không thành công, hãy chuyển đến giai đoạn Yêu cầu được gửi đến máy chủ đích rồi nhấp vào Hiện Curl.

    2. Cửa sổ Curl for Request Sent to Target Server (Curl cho yêu cầu được gửi đến máy chủ đích) sẽ mở ra. Từ đó, bạn có thể xác định bí danh máy chủ đích.
    3. Xem xét điểm cuối mục tiêu của API Proxy và kiểm tra xem URL máy chủ phụ trợ hoặc tên máy chủ trong máy chủ mục tiêu có trỏ đến một Proxy khác hay máy chủ phụ trợ của riêng bạn hay không.
    4. Nếu bí danh máy chủ đích đang trỏ đến một bí danh máy chủ ảo, thì đó là chuỗi proxy. Trong trường hợp này, bạn cần lặp lại tất cả các bước trên cho proxy được liên kết cho đến khi xác định được nguyên nhân thực sự gây ra 500 Internal Server Error. Trong những trường hợp này, 500 Internal Server Error cũng có thể xảy ra ở các proxy được liên kết khác ở các giai đoạn khác. Bạn có thể chẩn đoán và giải quyết vấn đề này bằng cách làm theo hướng dẫn trong sổ tay này hoặc trong sổ tay về Lỗi 500 Máy chủ nội bộ.
    5. Nếu bí danh máy chủ đích trỏ đến máy chủ phụ trợ của bạn, hãy chuyển đến phần Giải pháp.

Độ phân giải

Nếu xác định được lỗi 500 đến từ máy chủ phụ trợ, hãy làm việc với nhóm máy chủ phụ trợ để khắc phục vấn đề một cách thích hợp.

Trong ví dụ được thảo luận ở trên, bạn có thể phải yêu cầu người dùng truyền thông tin xác thực hợp lệ để khắc phục vấn đề này.

Những điểm chính cần lưu ý

  1. Bạn chỉ có thể xem thông báo lỗi thực tế do máy chủ phụ trợ trả về cho 500 Internal Server Error nếu đã ghi lại phiên theo dõi cho các yêu cầu không thành công.
  2. Phản hồi của máy chủ phụ trợ sẽ không được ghi vào nhật ký trong API Monitoring, NGINX Access Logs hoặc nhật ký Message Processor vì lý do bảo mật.
  3. Bạn có thể xem nhật ký máy chủ phụ trợ hoặc bật chế độ gỡ lỗi trên phụ trợ để biết thêm thông tin chi tiết về 500 Internal Server Error và/hoặc xem thông báo lỗi do máy chủ phụ trợ trả về.

Phải thu thập thông tin chẩn đoán

Nếu vấn đề vẫn tiếp diễn ngay cả sau khi bạn làm theo hướng dẫn ở trên, hãy thu thập thông tin chẩn đoán sau đây rồi liên hệ với Nhóm hỗ trợ Apigee Edge.

Nếu bạn là người dùng Đám mây công cộng, hãy cung cấp những thông tin sau:

  • Tên tổ chức
  • Tên môi trường
  • Tên API Proxy
  • Hoàn tất lệnh curl để tái tạo lỗi 500
  • Tệp theo dõi chứa các yêu cầu có 500 Internal Server Error
  • Nếu lỗi 500 hiện không xảy ra, hãy cung cấp khoảng thời gian kèm theo thông tin về múi giờ khi lỗi 500 xảy ra trong quá khứ.

Nếu bạn là người dùng Đám mây riêng, hãy cung cấp những thông tin sau:

  • Thông báo lỗi hoàn chỉnh được ghi nhận cho các yêu cầu không thành công
  • Tên tổ chức, tên môi trường và tên proxy API mà bạn đang quan sát thấy lỗi 500
  • Gói proxy API
  • Tệp theo dõi chứa các yêu cầu có 500 Internal Server Error
  • Nhật ký truy cập NGINX /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    Vị trí: ORG, ENV và PORT# được thay thế bằng các giá trị thực tế.

  • Nhật ký hệ thống của Trình xử lý thông báo /opt/apigee/var/log/edge-message-processor/logs/system.log
  • Khoảng thời gian có thông tin về múi giờ khi xảy ra lỗi 500.