500 Lỗi máy chủ nội bộ

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

Hãy xem các video sau để tìm hiểu thêm về cách giải quyết Lỗi máy chủ nội bộ 500.

Video Mô tả
Giới thiệu Giới thiệu về 500 Lỗi máy chủ nội bộ và các nguyên nhân có thể gây ra lỗi này. Ngoài ra, video này còn minh hoạ lỗi 500 Lỗi máy chủ nội bộ theo thời gian thực, cùng với các bước khắc phục và giải quyết lỗi.
Xử lý lỗi Chú thích dịch vụ và Trích xuất biến Minh hoạ 2 lỗi 500 Lỗi máy chủ nội bộ do các chính sách Lời gọi dịch vụ và Trích xuất biến gây ra, đồng thời cho biết cách khắc phục và giải quyết những lỗi này.
Xử lý lỗi chính sách JavaScript Cho biết Lỗi máy chủ nội bộ 500 do chính sách JavaScript gây ra và các bước khắc phục cũng như giải quyết lỗi này.
Xử lý các lỗi từ máy chủ phụ trợ Cho thấy ví dụ về Lỗi máy chủ nội bộ 500 do lỗi ở máy chủ phụ trợ và cho thấy các bước để giải quyết lỗi.

Dấu hiệu

Ứng dụng khách nhận được mã trạng thái HTTP là 500 kèm theo thông báo "Lỗi máy chủ nội bộ" dưới dạng phản hồi cho các lệnh gọi API. Lỗi 500 Internal Server (Lỗi máy chủ nội bộ) có thể xảy ra do lỗi trong quá trình thực thi bất kỳ chính sách nào trong Edge hoặc do lỗi trên máy chủ đích/phụ trợ.

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

Bạn có thể nhận được thông báo lỗi sau:

HTTP/1.1 500 Internal Server Error

Trong một số trường hợp, bạn có thể thấy một thông báo lỗi khác có nhiều thông tin chi tiết hơn. Dưới đây là thông báo lỗi mẫu:

{
   "fault":{
      "detail":{
         "errorcode":"steps.servicecallout.ExecutionFailed"
      },
      "faultstring":"Execution of ServiceCallout callWCSAuthServiceCallout failed. Reason: ResponseCode 400 is treated as error"
   }
}

Nguyên nhân có thể dẫn đến vấn đề này

Lỗi 500 Internal Server Error có thể xảy ra do một số nguyên nhân. Trong Edge, các nguyên nhân có thể được phân loại thành 2 danh mục chính dựa trên vị trí xảy ra lỗi:

Nguyên nhân Chi tiết Các bước khắc phục sự cố chi tiết được cung cấp cho
Lỗi thực thi trong Chính sách Edge Chính sách trong proxy API có thể không thành công vì một số lý do. Người dùng Edge Private Cloud và Public Cloud
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

Lỗi thực thi trong Chính sách Edge

Chính sách trong proxy API có thể không thành công vì một số lý do. Phần này giải thích cách khắc phục vấn đề nếu Lỗi máy chủ nội bộ 500 xảy ra trong quá trình thực thi một chính sách.

Chẩn đoán

Các bước chẩn đoán dành cho người dùng đám mây riêng và đám mây công cộng

Nếu bạn có phiên giao diện người dùng theo dõi cho lỗi này, hãy làm như sau:

  1. Xác minh rằng lỗi đó là do việc thực thi một chính sách. Hãy xem phần Xác định nguồn gốc của vấn đề để biết thông tin chi tiết.
  2. Nếu lỗi xảy ra trong quá trình thực thi chính sách, hãy tiếp tục. Nếu lỗi do máy chủ phụ trợ gây ra, hãy chuyển đến phần Lỗi trong máy chủ phụ trợ.
  3. Chọn yêu cầu API không thành công do Lỗi máy chủ nội bộ 500 trong dấu vết.
  4. Kiểm tra yêu cầu và chọn chính sách cụ thể không thành công hoặc luồng có tên "Lỗi" ngay sau chính sách không thành công trong dấu vết.
  5. Xem thêm thông tin chi tiết về lỗi bằng cách kiểm tra trường "error" trong mục Thuộc tính hoặc Nội dung lỗi.
  6. Dựa vào thông tin chi tiết mà bạn đã thu thập được về lỗi, hãy cố gắng xác định nguyên nhân gây ra lỗi.

Các bước chẩn đoán chỉ dành cho người dùng Đám mây riêng

Nếu bạn không có phiên theo dõi giao diện người dùng, hãy làm như sau:

  1. Xác minh rằng lỗi xảy ra trong quá trình thực thi một chính sách. Hãy xem phần Xác định nguồn gốc của vấn đề để biết thông tin chi tiết.
  2. Nếu lỗi là do quá trình thực thi chính sách, hãy tiếp tục. Nếu lỗi xảy ra trong quá trình thực thi chính sách, hãy tiếp tục. Nếu lỗi do máy chủ phụ trợ gây ra, hãy chuyển đến phần Lỗi trong máy chủ phụ trợ.
  3. Sử dụng nhật ký truy cập NGINX như được giải thích trong phần Xác định nguồn gốc của vấn đề để xác định chính sách không thành công trong proxy API và cả mã nhận dạng thông báo yêu cầu duy nhất
  4. Kiểm tra nhật ký Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log) và tìm mã nhận dạng thông báo yêu cầu duy nhất trong nhật ký đó.
  5. Nếu bạn tìm thấy mã nhận dạng thông báo yêu cầu duy nhất, hãy xem bạn có thể nhận thêm thông tin về nguyên nhân gây ra lỗi hay không.

Độ phân giải

Nếu bạn đã xác định được nguyên nhân gây ra vấn đề về chính sách, hãy thử khắc phục vấn đề bằng cách sửa đổi chính sách và triển khai lại proxy.

Các ví dụ sau đây minh hoạ cách xác định nguyên nhân và giải pháp cho nhiều loại vấn đề.

Nếu bạn cần được hỗ trợ thêm trong việc khắc phục Lỗi máy chủ nội bộ 500 hoặc bạn nghi ngờ đây là vấn đề trong Edge, hãy liên hệ với Nhóm hỗ trợ Apigee.

Ví dụ 1: Lỗi trong chính sách Chú thích dịch vụ do lỗi ở máy chủ phụ trợ

Nếu lệnh gọi đến máy chủ phụ trợ không thành công trong chính sách Lệnh gọi dịch vụ với bất kỳ lỗi nào như 4XX hoặc 5XX, thì lệnh gọi đó sẽ được coi là 500 Lỗi máy chủ nội bộ.

  1. Sau đây là ví dụ về trường hợp dịch vụ phụ trợ gặp lỗi 404 trong chính sách Chú thích dịch vụ. Thông báo lỗi sau đây sẽ được gửi đến người dùng cuối: 
    {
"fault":
     { "detail":
           { "errorcode":"steps.servicecallout.ExecutionFailed"
           },"faultstring":"Execution of ServiceCallout service_callout_v3_store_by_lat_lon
 failed. Reason: ResponseCode 404 is treated as error"
          }
     }
}
  2. Phiên giao diện người dùng theo dõi sau đây cho thấy mã trạng thái 500 do lỗi trong chính sách Lời gọi dịch vụ:

  3. Trong ví dụ này, thuộc tính "error" liệt kê lý do khiến chính sách Chú thích dịch vụ không thành công là "ResponseCode 404 is treated as error" (ResponseCode 404 được coi là lỗi). Lỗi này có thể xảy ra nếu tài nguyên được truy cập thông qua URL máy chủ phụ trợ trong chính sách Lời gọi dịch vụ không có sẵn.
  4. Kiểm tra tính sẵn có của tài nguyên trên máy chủ phụ trợ. Có thể tệp đó tạm thời/vĩnh viễn không có sẵn hoặc đã được chuyển đến một vị trí khác.

Ví dụ 1: Giải pháp

  1. Kiểm tra tính sẵn có của tài nguyên trên máy chủ phụ trợ. Có thể tệp đó tạm thời/vĩnh viễn không có sẵn hoặc đã được chuyển đến một vị trí khác.
  2. Chỉnh sửa URL máy chủ phụ trợ trong chính sách Chú thích dịch vụ để trỏ đến một tài nguyên hợp lệ và hiện có.
  3. Nếu tài nguyên chỉ tạm thời không có sẵn, hãy thử đưa ra yêu cầu API khi tài nguyên có sẵn.

Ví dụ 2: Lỗi trong chính sách trích xuất biến

Bây giờ, hãy xem một ví dụ khác, trong đó Lỗi máy chủ nội bộ 500 xảy ra do lỗi trong chính sách Trích xuất biến và xem cách khắc phục và giải quyết vấn đề này.

  1. Dấu vết sau đây trong phiên giao diện người dùng cho thấy mã trạng thái 500 do lỗi trong chính sách Trích xuất biến:

  2. Chọn chính sách Extract Variables (Trích xuất biến) không thành công, di chuyển xuống và xem phần "Error Content" (Nội dung lỗi) để biết thêm thông tin chi tiết:

  3. Nội dung lỗi cho biết biến "serviceCallout.oamCookieValidationResponse" không có trong chính sách Trích xuất biến. Như tên của biến cho biết, biến này sẽ giữ phản hồi của chính sách Lời gọi dịch vụ trước đó.
  4. Chọn chính sách Chú thích dịch vụ trong dấu vết và bạn có thể thấy rằng biến "serviceCallout.oamCookieValidationResponse" chưa được đặt. Điều này cho biết lệnh gọi đến dịch vụ phụ trợ không thành công, dẫn đến một biến phản hồi trống.
  5. Mặc dù chính sách Chú thích dịch vụ không thành công, nhưng việc thực thi các chính sách sau chính sách Chú thích dịch vụ vẫn tiếp tục vì cờ "continueOnError" trong chính sách Chú thích dịch vụ được đặt thành true, như minh hoạ dưới đây:

    <ServiceCallout async="false" continueOnError="true" enabled="true" name="Callout.OamCookieValidation">
  <DisplayName>Callout.OamCookieValidation</DisplayName>
  <Properties />
  <Request clearPayload="true" variable="serviceCallout.oamCookieValidationRequest">
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  </Request>
  <Response>serviceCallout.oamCookieValidationResponse</Response>
  <HTTPTargetConnection>
    <Properties />
    <URL>http://{Url}</URL>
  </HTTPTargetConnection>
</ServiceCallout>
  6. Lưu ý mã nhận dạng thông báo duy nhất "X-Apigee.Message-ID" cho yêu cầu API cụ thể này từ dấu vết, như sau:
    1. Chọn giai đoạn "Dữ liệu phân tích được ghi lại" trong yêu cầu.
    2. Di chuyển xuống và ghi lại giá trị của X-Apigee.Message-ID.

  7. Xem nhật ký Message Processor (/opt/apigee/var/log/edge-message-processor/system.log) và tìm kiếm mã nhận dạng thư riêng biệt được ghi lại ở bước 6. Thông báo lỗi sau đây được ghi nhận cho yêu cầu API cụ thể: 
    2017-05-05 07:48:18,653 org:myorg env:prod api:myapi rev:834 messageid:rrt-04984fed9e5ad3551-c-wo-32168-77563  NIOThread@5 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@149081 useCount=1 bytesRead=0 bytesWritten=0 age=3002ms lastIO=3002ms .onConnectTimeout connectAddress=mybackend.domain.com/XX.XX.XX.XX:443 resolvedAddress=mybackend.domain.com/XX.XX.XX.XX

    Lỗi nêu trên cho biết chính sách Lời gọi dịch vụ không thành công do lỗi hết thời gian chờ kết nối khi kết nối với máy chủ phụ trợ.

  8. Để xác định nguyên nhân gây ra lỗi hết thời gian chờ kết nối, hãy thực thi lệnh telnet đối với máy chủ phụ trợ từ(các) Trình xử lý thông báo. Lệnh telnet cho biết lỗi "Connection timed out" (Hết thời gian chờ kết nối) như minh hoạ dưới đây: 
    telnet mybackend.domain.com 443
Trying XX.XX.XX.XX...
telnet: connect to address XX.XX.XX.XX: Connection timed out

    Thông thường, lỗi này xảy ra trong các trường hợp sau:

    • Khi máy chủ phụ trợ không được định cấu hình để cho phép lưu lượng truy cập từ Edge Message Processors.
    • Nếu máy chủ phụ trợ không theo dõi trên cổng cụ thể.

    Trong ví dụ minh hoạ ở trên, mặc dù chính sách Trích xuất biến không thành công, nhưng nguyên nhân thực tế là Edge không thể kết nối với máy chủ phụ trợ trong chính sách Lệnh gọi dịch vụ. Nguyên nhân gây ra lỗi này là do máy chủ phụ trợ chưa được định cấu hình để cho phép lưu lượng truy cập từ Trình xử lý thông báo Edge.

    Chính sách Extract Variables (Trích xuất biến) của riêng bạn sẽ hoạt động theo cách khác và có thể không thành công vì một lý do khác. Bạn có thể khắc phục sự cố một cách thích hợp tuỳ thuộc vào nguyên nhân khiến chính sách Trích xuất biến của bạn không thành công bằng cách kiểm tra thông báo trong thuộc tính error.

Giải pháp cho ví dụ 2

  1. Khắc phục nguyên nhân gây ra lỗi hoặc sự cố trong chính sách Trích xuất biến một cách thích hợp.
  2. Trong ví dụ minh hoạ ở trên, giải pháp là điều chỉnh cấu hình mạng để cho phép lưu lượng truy cập từ Edge Message Processors đến máy chủ phụ trợ của bạn. Việc này được thực hiện bằng cách đưa địa chỉ IP của Trình xử lý thông báo vào danh sách cho phép trên máy chủ phụ trợ cụ thể. Ví dụ: trên Linux, bạn có thể dùng iptables để cho phép lưu lượng truy cập từ địa chỉ IP của Trình xử lý thông báo trên máy chủ phụ trợ.

Ví dụ 3: Lỗi trong chính sách JavaCallout

Bây giờ, hãy xem thêm một ví dụ nữa, trong đó Lỗi máy chủ nội bộ 500 xảy ra do lỗi trong chính sách Lệnh gọi Java và xem cách khắc phục và giải quyết vấn đề này.

  1. Dấu vết giao diện người dùng sau đây cho thấy mã trạng thái 500 do lỗi trong Chính sách lệnh gọi Java:

  2. Chọn Luồng có tên "Error" (Lỗi), sau đó chọn Chính sách lệnh gọi Java không thành công để xem thông tin chi tiết về lỗi như minh hoạ trong hình bên dưới:

  3. Trong ví dụ này, thuộc tính "error" trong phần Properties (Thuộc tính) cho thấy lỗi là do mật khẩu đã hết hạn được dùng khi kết nối với Cơ sở dữ liệu Oracle trong chính sách JavaCallout. Lệnh gọi Java của riêng bạn sẽ hoạt động theo cách khác và sẽ điền một thông báo khác vào thuộc tính error.
  4. Kiểm tra mã chính sách JavaCallout và xác nhận cấu hình chính xác cần được sử dụng.

Giải pháp cho ví dụ 3

Sửa mã hoặc cấu hình lệnh gọi Java một cách thích hợp để tránh ngoại lệ thời gian chạy. Trong ví dụ về lỗi chú thích Java minh hoạ ở trên, bạn cần sử dụng đúng mật khẩu để kết nối với cơ sở dữ liệu Oracle nhằm giải quyết vấn đề.

Lỗi trong máy chủ phụ trợ

Lỗi 500 Internal Server Error cũng có thể bắt nguồn từ máy chủ phụ trợ. Phần này giải thích cách khắc phục vấn đề nếu lỗi bắt nguồn từ máy chủ phụ trợ.

Chẩn đoán

Các bước chẩn đoán dành cho tất cả người dùng

Nguyên nhân gây ra các lỗi phụ trợ khác có thể rất đa dạng. 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 minh rằng lỗi này là do máy chủ phụ trợ gây ra. Hãy xem phần Xác định nguồn gốc của vấn đề để biết thông tin chi tiết.
  2. Nếu lỗi do máy chủ phụ trợ gây ra, hãy tiếp tục. Nếu lỗi xảy ra trong quá trình thực thi chính sách, hãy chuyển đến phần Lỗi thực thi trong chính sách Edge.
  3. Hãy làm theo các bước bên dưới, tuỳ thuộc vào việc bạn có quyền truy cập vào một phiên theo dõi cho API không thành công hay không, hoặc nếu phần phụ trợ là một máy chủ Node.js:

Nếu bạn không có phiên Theo dõi cho lệnh gọi API không thành công:

  1. Nếu dấu vết giao diện người dùng không có sẵn cho yêu cầu không thành công, hãy kiểm tra nhật ký máy chủ phụ trợ để biết thông tin chi tiết về 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 về lỗi và nguyên nhân.

Nếu bạn có một phiên theo dõi cho lệnh gọi API không thành công:

Nếu bạn có một phiên theo dõi, thì các bước sau đây sẽ giúp bạn chẩn đoán vấn đề.

  1. Trong công cụ Theo dõi, hãy chọn yêu cầu API không thực hiện được do Lỗi máy chủ nội bộ 500.
  2. Chọn giai đoạn "Phản hồi nhận được 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:

  3. Kiểm tra phần "Nội dung phản hồi" để biết thông tin chi tiết về lỗi.

  4. Trong ví dụ này, Nội dung phản hồi là một SOAP Envelope, cho thấy chuỗi lỗi là thông báo "Không được phép". Nguyên nhân có khả năng nhất gây ra vấn đề này là do người dùng không chuyển thông tin đăng nhập thích hợp (tên người dùng/mật khẩu, mã truy cập, v.v.) đến máy chủ phụ trợ. Bạn có thể khắc phục vấn đề này bằng cách truyền thông tin đăng nhập chính xác đến máy chủ phụ trợ.

Nếu phần phụ trợ là một máy chủ Node.js:

  1. Nếu phần phụ trợ là Máy chủ phụ trợ Node.js, hãy kiểm tra nhật ký Node.js cho Proxy API cụ thể trong giao diện người dùng Edge (cả người dùng Đám mây công khai và Đám mây riêng tư đều có thể kiểm tra nhật ký Node.js). Nếu là người dùng Edge Private Cloud, bạn cũng có thể kiểm tra nhật ký Trình xử lý thông báo (/opt/apigee/var/log/edge-message-processor/logs/system.log) để biết thêm thông tin chi tiết về lỗi.

    Lựa chọn Nhật ký NodeJS trong giao diện người dùng Edge – Thẻ Tổng quan về API Proxy

Độ phân giải

  1. Sau khi xác định được nguyên nhân gây ra lỗi, hãy khắc phục vấn đề trong máy chủ phụ trợ của bạn.
  2. Nếu đó là máy chủ phụ trợ Node.js:
    1. Kiểm tra xem lỗi có phát sinh từ mã tuỳ chỉnh của bạn hay không và khắc phục vấn đề (nếu có thể).
    2. Nếu lỗi không xuất phát từ mã tuỳ chỉnh của bạn hoặc nếu bạn cần được trợ giúp, hãy liên hệ với Nhóm hỗ trợ Apigee.

Nếu bạn cần được hỗ trợ thêm trong việc khắc phục Lỗi máy chủ nội bộ 500 hoặc bạn nghi ngờ đây là vấn đề trong Edge, hãy liên hệ với Nhóm hỗ trợ Apigee.

Xác định nguồn gốc của vấn đề

Hãy sử dụng một trong các quy trình sau để xác định xem Lỗi máy chủ nội bộ 500 có được gửi trong quá trình thực thi một chính sách trong proxy API hay do máy chủ phụ trợ gửi hay không.

Sử dụng tính năng Theo dõi trong giao diện người dùng

Lưu ý: Cả người dùng Đám mây công cộng và Đám mây riêng tư đều có thể thực hiện các bước trong phần này.

  1. Nếu vấn đề vẫn đang diễn ra, hãy bật dấu vết trong giao diện người dùng cho API bị ảnh hưởng.
  2. Sau khi bạn ghi lại dấu vết, hãy chọn yêu cầu API cho thấy mã phản hồi là 500.
  3. Chuyển qua tất cả các giai đoạn của yêu cầu API không thành công và kiểm tra xem giai đoạn nào trả về Lỗi máy chủ nội bộ 500:
    1. Nếu lỗi xảy ra trong quá trình thực thi một chính sách, hãy chuyển đến phần Lỗi thực thi trong chính sách biên.
    2. Nếu máy chủ phụ trợ đã phản hồi bằng 500 Lỗi máy chủ nội bộ, hãy chuyển sang phần Lỗi trong máy chủ phụ trợ.

Sử dụng tính năng Giám sát API

Lưu ý: Chỉ người dùng Đám mây công khai mới có thể thực hiện các bước trong phần này.

Giám sát API cho phép bạn nhanh chóng cô lập các khu vực có vấn đề để chẩn đoán lỗi, hiệu suất và độ trễ cũng như nguồn của chúng, chẳng hạn như ứng dụng của nhà phát triển, proxy API, mục tiêu phụ trợ hoặc nền tảng API.

Xem xét một tình huống mẫu minh hoạ cách khắc phục các vấn đề 5xx với API bằng tính năng Giám sát API. Ví dụ: bạn có thể muốn thiết lập một cảnh báo để nhận thông báo khi số lượng mã trạng thái 500 hoặc lỗi steps.servicecallout.ExecutionFailed vượt quá một ngưỡng cụ thể.

Sử dụng nhật ký truy cập NGINX

Lưu ý: Các bước trong phần này chỉ dành cho người dùng Edge Private Cloud.

Bạn cũng có thể tham khảo nhật ký truy cập NGINX để xác định xem mã trạng thái 500 có được gửi trong quá trình thực thi chính sách trong proxy API hay do máy chủ phụ trợ hay không. Điều này đặc biệt hữu ích nếu vấn đề đã xảy ra trong quá khứ hoặc 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 trong giao diện người dùng. Hãy làm theo các bước sau để xác định thông tin này từ nhật ký truy cập NGINX:

  1. Kiểm tra nhật ký truy cập NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log ).
  2. Tìm xem có Lỗi 500 nào cho proxy API cụ thể trong khoảng thời gian cụ thể hay không.
  3. Nếu có lỗi 500, hãy kiểm tra xem lỗi đó là lỗi chính sách hay lỗi máy chủ đích, như minh hoạ bên dưới:

    Mẫu mục nhập cho thấy Lỗi vi phạm chính sách

    Mẫu mục nhập cho thấy Lỗi máy chủ đích

  4. Sau khi bạn xác định được đó là lỗi chính sách hay lỗi máy chủ đích:
    1. Chuyển đến phần Lỗi thực thi trong chính sách biên nếu đó là lỗi chính sách.
    2. Chuyển đến phần Lỗi ở máy chủ phụ trợ nếu đó là lỗi máy chủ đích.