Cân bằng tải trên các 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

Apigee Edge giúp tăng khả năng cung cấp API của bạn bằng cách hỗ trợ tích hợp tính năng cân bằng tải và chuyển đổi dự phòng trên nhiều phiên bản máy chủ phụ trợ.

Cấu hình TargetServer tách các URL điểm cuối cụ thể khỏi cấu hình TargetEndpoint. Mỗi TargetServer được tham chiếu theo tên trong một TargetEndpoint HTTPConnection. Thay vì xác định một URL cụ thể trong cấu hình, bạn có thể định cấu hình một hoặc nhiều TargetServer có tên như mô tả trong phần TargetEndpoint.

Định nghĩa TargetServer bao gồm tên, máy chủ lưu trữ và cổng, cùng với một phần tử bổ sung để cho biết TargetServer có được bật hay tắt.

Video

Hãy xem các video sau đây để tìm hiểu thêm về việc định tuyến API và cân bằng tải bằng cách sử dụng các máy chủ đích

Ví dụ về cấu hình TargetServer

Đoạn mã sau đây xác định một máy chủ đích:

<TargetServer  name="target1">
  <Host>1.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >

Các phần tử cấu hình TargetServer

Bảng sau đây mô tả các phần tử dùng để tạo và định cấu hình TargetServer:

Quản lý máy chủ đích bằng giao diện người dùng

Quản lý các máy chủ đích, như mô tả dưới đây.

Quản lý các máy chủ đích bằng API

Bạn có thể sử dụng Edge API để tạo, xoá, cập nhật, nhận và liệt kê các máy chủ đích. Để biết thêm thông tin, hãy xem phần TargetServers.

Sử dụng lệnh gọi API sau đây để tạo một máy chủ đích:

$ curl -H "Content-Type:text/xml" -X POST -d \
'<TargetServer name="target1">
   <Host>1.mybackendservice.com</Host>
   <Port>80</Port>
   <IsEnabled>true</IsEnabled>
 </TargetServer>' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Phản hồi mẫu:

{
  "host" : "1.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target1",
  "port" : 80
}

Sau khi tạo TargetServer đầu tiên, hãy dùng lệnh gọi API sau đây để tạo TargetServer thứ hai. Bằng cách xác định hai TargetServer, bạn cung cấp hai URL mà TargetEndpoint có thể dùng để cân bằng tải:

$ curl -H "Content-type:text/xml" -X POST -d \
'<TargetServer  name="target2">
  <Host>2.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Phản hồi mẫu:

{
  "host" : "2.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target2",
  "port" : 80
}

Sử dụng lệnh gọi API sau đây để truy xuất danh sách TargetServer trong một môi trường:

$ curl -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Phản hồi mẫu:

[ "target2", "target1" ]

Hiện có 2 TargetServer mà các proxy API được triển khai trong môi trường kiểm thử có thể sử dụng. Để cân bằng tải lưu lượng truy cập trên các TargetServer này, bạn sẽ định cấu hình kết nối HTTP trong điểm cuối đích của một proxy API để sử dụng TargetServer.

Mỗi môi trường có tối đa 500 TargetServer, như được ghi lại trong chủ đề Giới hạn.

Định cấu hình TargetEndpoint để cân bằng tải trên các TargetServer được đặt tên

Giờ đây, khi có 2 TargetServer, bạn có thể sửa đổi chế độ cài đặt kết nối HTTP TargetEndpoint để tham chiếu đến 2 TargetServer đó theo tên:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Server name="target1" />
      <Server name="target2" />
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Cấu hình ở trên là cấu hình cân bằng tải cơ bản nhất có thể. Trình cân bằng tải hỗ trợ 3 thuật toán cân bằng tải: Round Robin, Weighted và Least Connection. Round Robin là thuật toán mặc định. Vì không có thuật toán nào được chỉ định trong cấu hình ở trên, nên các yêu cầu đi ra từ proxy API đến các máy chủ phụ trợ sẽ thay phiên nhau, lần lượt giữa target1 và target 2.

Phần tử <Path> tạo thành basepath của URI TargetEndpoint cho tất cả các máy chủ đích. Tham số này chỉ được dùng khi <LoadBalancer> được dùng. Nếu không, yêu cầu này sẽ bị bỏ qua. Trong ví dụ trên, một yêu cầu đến "target1" sẽ là http://target1/test và tương tự đối với các máy chủ đích khác.

Thiết lập các lựa chọn về trình cân bằng tải

Bạn có thể điều chỉnh tính sẵn sàng bằng cách sử dụng các lựa chọn cân bằng tải và chuyển đổi dự phòng ở cấp độ trình cân bằng tải và TargetServer. Phần này mô tả các lựa chọn này.

Thuật toán

Đặt thuật toán mà <LoadBalancer> sử dụng. Các thuật toán có sẵn là RoundRobin, Weighted và LeastConnections, mỗi thuật toán được ghi lại bên dưới.

Vòng tròn

Thuật toán mặc định (luân phiên) sẽ chuyển tiếp yêu cầu đến từng TargetServer theo thứ tự mà các máy chủ được liệt kê trong kết nối HTTP của điểm cuối đích. Ví dụ:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Trọng số

Thuật toán cân bằng tải có trọng số cho phép bạn định cấu hình tải lưu lượng truy cập theo tỷ lệ cho TargetServers. LoadBalancer có trọng số sẽ phân phối yêu cầu đến TargetServers theo tỷ lệ thuận với trọng số của mỗi TargetServer. Do đó, thuật toán có trọng số yêu cầu bạn đặt một thuộc tính weight cho mỗi TargetServer. Ví dụ:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Algorithm>Weighted</Algorithm>
      <Server name="target1">
        <Weight>1</Weight>
      </Server>
      <Server name="target2">
        <Weight>2</Weight>
      </Server>
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Trong ví dụ này, cứ một yêu cầu được định tuyến đến target1 thì sẽ có hai yêu cầu được định tuyến đến target2.

Ít kết nối nhất

LoadBalancer được định cấu hình để sử dụng thuật toán ít kết nối nhất sẽ định tuyến các yêu cầu gửi đi đến TargetServer có ít kết nối HTTP đang mở nhất. Ví dụ:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>LeastConnections</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
  </HTTPTargetConnection>
  <Path>/test</Path>
</TargetEndpoint>

Số lần thất bại tối đa

Số lượng tối đa yêu cầu không thành công từ proxy API đến TargetServer dẫn đến việc yêu cầu được chuyển hướng đến một TargetServer khác.

Lỗi phản hồi có nghĩa là Apigee không nhận được phản hồi nào từ máy chủ đích. Khi điều này xảy ra, bộ đếm lỗi sẽ tăng thêm một.

Tuy nhiên, khi Apigee nhận được phản hồi từ một đích đến, ngay cả khi phản hồi đó là lỗi HTTP (chẳng hạn như 500), thì đó được coi là phản hồi từ máy chủ đích và bộ đếm lỗi sẽ được đặt lại. Để đảm bảo rằng các phản hồi HTTP không hợp lệ (chẳng hạn như 500) cũng làm tăng bộ đếm lỗi để loại bỏ máy chủ không hoạt động khỏi vòng cân bằng tải càng sớm càng tốt, bạn có thể thêm phần tử <ServerUnhealthyResponse> có các phần tử con <ResponseCode> vào cấu hình trình cân bằng tải. Edge cũng sẽ coi những phản hồi có mã đó là phản hồi không thành công.

Trong ví dụ sau, target1 sẽ bị loại bỏ khỏi danh sách luân phiên sau 5 yêu cầu không thành công, bao gồm cả một số phản hồi 5XX từ máy chủ đích.

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
        <ServerUnhealthyResponse>
            <ResponseCode>500</ResponseCode>
            <ResponseCode>502</ResponseCode>
            <ResponseCode>503</ResponseCode>
        </ServerUnhealthyResponse>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Giá trị mặc định của MaxFailures là 0. Điều này có nghĩa là Edge luôn cố gắng kết nối với mục tiêu cho từng yêu cầu và không bao giờ xoá máy chủ mục tiêu khỏi quá trình luân phiên.

Tốt nhất là bạn nên sử dụng MaxFailures > 0 với HealthMonitor. Nếu bạn định cấu hình MaxFailures > 0, TargetServer sẽ bị xoá khỏi vòng xoay khi mục tiêu không đạt được số lần mà bạn chỉ định. Khi HealthMonitor được đặt đúng vị trí, Apigee sẽ tự động đưa TargetServer trở lại vòng luân phiên sau khi đích đến hoạt động trở lại, theo cấu hình của HealthMonitor đó. Hãy xem phần Theo dõi tình trạng để biết thêm thông tin.

Ngoài ra, nếu bạn định cấu hình MaxFailures > 0 và không định cấu hình một màn hình tình trạng, thì Apigee sẽ tự động loại bỏ máy chủ đích khỏi vòng luân phiên khi phát hiện thấy lỗi đầu tiên. Apigee sẽ kiểm tra trạng thái của máy chủ đích sau mỗi 5 phút và đưa máy chủ đó trở lại vòng xoay khi máy chủ phản hồi bình thường.

Thử lại

Nếu bạn bật tính năng thử lại, yêu cầu sẽ được thử lại bất cứ khi nào xảy ra lỗi phản hồi (lỗi I/O hoặc hết thời gian chờ HTTP) hoặc phản hồi nhận được khớp với giá trị do <ServerUnhealthyResponse> đặt. Hãy xem phần Số lần thất bại tối đa ở trên để biết thêm thông tin về cách thiết lập <ServerUnhealthyResponse>.

Theo mặc định, <RetryEnabled> được đặt thành true. Đặt thành false để tắt tính năng thử lại. Ví dụ:

<RetryEnabled>false</RetryEnabled>

IsFallback

Bạn có thể đặt một (và chỉ một) TargetServer làm máy chủ "dự phòng". TargetServer dự phòng không được đưa vào các quy trình cân bằng tải cho đến khi trình cân bằng tải xác định tất cả TargetServer khác là không có sẵn. Khi bộ cân bằng tải xác định rằng tất cả TargetServer đều không hoạt động, mọi lưu lượng truy cập sẽ được định tuyến đến máy chủ dự phòng. Ví dụ:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <Server name="target3">
          <IsFallback>true</IsFallback>
        </Server>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Cấu hình ở trên sẽ dẫn đến việc cân bằng tải luân phiên giữa các mục tiêu 1 và 2 cho đến khi cả mục tiêu 1 và 2 đều không hoạt động. Khi mục tiêu 1 và 2 không hoạt động, tất cả lưu lượng truy cập sẽ được định tuyến đến mục tiêu 3.

Đường dẫn

Đường dẫn xác định một đoạn URI sẽ được thêm vào tất cả các yêu cầu do TargetServer đưa ra cho máy chủ phụ trợ.

Phần tử này chấp nhận một đường dẫn chuỗi theo nghĩa đen hoặc một mẫu thông báo. Mẫu thông báo cho phép bạn thực hiện thay thế chuỗi biến trong thời gian chạy. Ví dụ: trong định nghĩa điểm cuối mục tiêu sau đây, giá trị của {mypath} được dùng cho đường dẫn:

<HTTPTargetConnection>
    <SSLInfo>
      <Enabled>true</Enabled>
    </SSLInfo>
    <LoadBalancer>
      <Server name="testserver"/>
    </LoadBalancer>
    <Path>{mypath}</Path>
</HTTPTargetConnection>

Định cấu hình máy chủ đích cho TLS/SSL

Nếu đang sử dụng TargetServer để xác định dịch vụ phụ trợ và dịch vụ phụ trợ yêu cầu kết nối sử dụng giao thức HTTPS, thì bạn phải bật TLS/SSL trong định nghĩa TargetServer. Điều này là cần thiết vì thẻ <Host> không cho phép bạn chỉ định giao thức kết nối. Dưới đây là định nghĩa TargetServer cho TLS/SSL một chiều, trong đó Edge đưa ra các yêu cầu HTTPS cho dịch vụ phụ trợ:

<TargetServer name="target1">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo> 
</TargetServer>

Nếu dịch vụ phụ trợ yêu cầu TLS/SSL hai chiều hoặc tương hỗ, thì bạn sẽ định cấu hình TargetServer bằng cách sử dụng cùng chế độ cài đặt cấu hình TLS/SSL như TargetEndpoints:

<TargetServer  name="TargetServer 1">
    <IsEnabled>true</IsEnabled>
    <Host>www.example.com</Host>
    <Port>443</Port>
    <SSLInfo>
        <Ciphers/>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <Enabled>true</Enabled>
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
        <KeyAlias>keystore-alias</KeyAlias>
        <KeyStore>keystore-name</KeyStore>
        <Protocols/>
        <TrustStore>truststore-name</TrustStore>
    </SSLInfo>
</TargetServer >

Để biết thông tin về các thuộc tính <SSLInfo>, chẳng hạn như <Ciphers> và <ClientAuthEnabled>, hãy xem thông tin về cách thiết lập các thuộc tính đó cho Máy chủ ảo tại Định cấu hình quyền truy cập TLS vào một API cho Đám mây riêng.

Để xem hướng dẫn đầy đủ về cách định cấu hình TLS/SSL đi, hãy xem phần Định cấu hình TLS từ Edge đến phần phụ trợ (Cloud và Đám mây riêng).

Giản đồ TargetServer

Xem giản đồ cho TargetServer và các thực thể khác trên GitHub.

Theo dõi sức khoẻ

Tính năng giám sát tình trạng hoạt động cho phép bạn cải thiện cấu hình cân bằng tải bằng cách chủ động thăm dò các URL dịch vụ phụ trợ được xác định trong cấu hình TargetServer. Khi bật tính năng giám sát tình trạng sức khoẻ, TargetServer không hoạt động sẽ tự động được đưa trở lại vòng quay khi HealthMonitor xác định rằng TargetServer đang hoạt động.

Tính năng theo dõi sức khoẻ hoạt động với <MaxFailures>. Nếu không bật tính năng giám sát tình trạng, <MaxFailures> sẽ chỉ định số lượng yêu cầu không thành công từ proxy API đến TargetServer dẫn đến việc yêu cầu được chuyển hướng đến một TargetServer khác. Sau đó, TargetServer không hoạt động sẽ bị loại bỏ khỏi vòng luân phiên cho đến khi bạn triển khai lại proxy.

Khi bật tính năng giám sát tình trạng sức khoẻ, TargetServer bị lỗi sẽ tự động được đưa trở lại vòng xoay và không cần triển khai lại proxy.

HealthMonitor hoạt động như một ứng dụng đơn giản gọi một dịch vụ phụ trợ qua TCP hoặc HTTP:

• Máy khách TCP chỉ cần đảm bảo rằng có thể mở một ổ cắm.
• Bạn định cấu hình ứng dụng HTTP để gửi một yêu cầu HTTP hợp lệ đến dịch vụ phụ trợ. Bạn có thể xác định các thao tác HTTP GET, PUT, POST hoặc DELETE. Phản hồi của lệnh gọi giám sát HTTP phải khớp với các chế độ cài đặt đã định cấu hình trong khối <SuccessResponse>.

Thành công và thất bại

Khi bạn bật tính năng giám sát tình trạng, Edge sẽ bắt đầu gửi các lệnh kiểm tra tình trạng đến máy chủ đích của bạn. Kiểm tra tình trạng là một yêu cầu được gửi đến máy chủ đích để xác định xem máy chủ đích có hoạt động bình thường hay không.

Một quy trình kiểm tra tình trạng có thể có một trong hai kết quả sau:

• Thành công: Máy chủ đích được coi là hoạt động bình thường khi quá trình kiểm tra tình trạng hoạt động diễn ra thành công. Điều này thường là do một hoặc nhiều nguyên nhân sau:
  • Máy chủ đích chấp nhận một kết nối mới đến cổng được chỉ định, phản hồi một yêu cầu trên cổng đó, rồi đóng cổng trong khung thời gian được chỉ định. Phản hồi từ máy chủ đích chứa "Connection: close"
  • Máy chủ đích phản hồi yêu cầu kiểm tra tình trạng bằng mã trạng thái HTTP 200 (OK) hoặc mã trạng thái HTTP khác mà bạn cho là chấp nhận được.
  • Máy chủ đích phản hồi yêu cầu kiểm tra tình trạng bằng một nội dung thông báo khớp với nội dung thông báo dự kiến.

  Khi xác định rằng một máy chủ đang hoạt động bình thường, Edge sẽ tiếp tục hoặc tiếp tục gửi yêu cầu đến máy chủ đó.

• Lỗi: Máy chủ đích có thể không vượt qua quy trình kiểm tra tình trạng theo nhiều cách, tuỳ thuộc vào loại kiểm tra. Bạn có thể ghi lại lỗi khi máy chủ đích:
  • Từ chối kết nối từ Edge đến cổng kiểm tra tình trạng.
  • Không phản hồi yêu cầu kiểm tra tình trạng trong một khoảng thời gian cụ thể.
  • Trả về mã trạng thái HTTP không mong muốn.
  • Trả lời bằng nội dung thư không khớp với nội dung thư dự kiến.

  Khi một máy chủ đích không vượt qua được quy trình kiểm tra tình trạng, Edge sẽ tăng số lần thất bại của máy chủ đó. Nếu số lần thất bại của máy chủ đó đạt đến hoặc vượt quá một ngưỡng được xác định trước (<MaxFailures>), Edge sẽ ngừng gửi yêu cầu đến máy chủ đó.

Bật HealthMonitor

Để tạo một HealthMonitor, bạn hãy thêm phần tử <HealthMonitor> vào cấu hình HTTPConnection của TargetEndpoint cho một proxy. Bạn không thể thực hiện việc này trong giao diện người dùng. Thay vào đó, bạn tạo một cấu hình proxy và tải cấu hình đó lên Edge dưới dạng tệp ZIP. Cấu hình proxy là nội dung mô tả có cấu trúc về mọi khía cạnh của một proxy API. Cấu hình proxy bao gồm các tệp XML trong một cấu trúc thư mục được xác định trước. Để biết thêm thông tin, hãy xem phần Tài liệu tham khảo về cấu hình API Proxy.

HealthMonitor đơn giản xác định IntervalInSec kết hợp với TCPMonitor hoặc HTTPMonitor. Phần tử <MaxFailures> chỉ định số lượng tối đa các yêu cầu không thành công từ proxy API đến TargetServer, dẫn đến việc yêu cầu được chuyển hướng đến một TargetServer khác. Theo mặc định, <MaxFailures> là 0, tức là Edge không thực hiện biện pháp khắc phục nào. Khi định cấu hình một màn hình tình trạng, hãy đảm bảo rằng bạn đặt <MaxFailures> trong thẻ <HTTPTargetConnection> của thẻ <TargetEndpoint> thành một giá trị khác 0.

TCPMonitor

Cấu hình dưới đây xác định một HealthMonitor sẽ thăm dò từng TargetServer bằng cách mở một kết nối trên cổng 80 sau mỗi 5 giây. (Cổng là không bắt buộc. Nếu không được chỉ định, cổng TCPMonitor sẽ là cổng TargetServer.)

• Nếu kết nối không thành công hoặc mất hơn 10 giây để kết nối, thì số lần thất bại sẽ tăng thêm 1 cho TargetServer đó.
• Nếu kết nối thành công, số lần thất bại cho TargetServer sẽ được đặt lại thành 0.

Bạn có thể thêm HealthMonitor làm phần tử con của phần tử HTTPTargetConnetion trong TargetEndpoint, như minh hoạ dưới đây:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
      <Path>/test</Path>
      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <TCPMonitor>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <Port>80</Port>
        </TCPMonitor>
      </HealthMonitor>
  </HTTPTargetConnection>
. . .

HealthMonitor với các phần tử cấu hình TCPMonitor

Bảng sau đây mô tả các phần tử cấu hình TCPMonitor:

HTTPMonitor

HealthMonitor mẫu sử dụng HTTPMonitor sẽ gửi yêu cầu GET đến dịch vụ phụ trợ cứ 5 giây một lần. Mẫu bên dưới sẽ thêm tiêu đề Uỷ quyền cơ bản HTTP vào thông báo yêu cầu. Cấu hình Phản hồi xác định các chế độ cài đặt sẽ được so sánh với phản hồi thực tế từ dịch vụ phụ trợ. Trong ví dụ bên dưới, phản hồi dự kiến là mã phản hồi HTTP 200 và tiêu đề HTTP tuỳ chỉnh ImOK có giá trị là YourOK. Nếu phản hồi không khớp, thì yêu cầu sẽ được coi là không thành công theo cấu hình trình cân bằng tải.

HTTPMonitor hỗ trợ các dịch vụ phụ trợ được định cấu hình để sử dụng giao thức HTTP và HTTPS một chiều. Tuy nhiên, tính năng này không hỗ trợ những nội dung sau:

• HTTPS hai chiều (còn gọi là TLS/SSL hai chiều)
• Chứng chỉ tự ký.

Xin lưu ý rằng tất cả chế độ cài đặt Yêu cầu và Phản hồi trong một màn hình HTTP sẽ dành riêng cho dịch vụ phụ trợ phải được gọi.

    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <IsSSL>true</IsSSL>
          <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
          <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
          <Port>80</Port>
          <Verb>GET</Verb>
          <Path>/healthcheck</Path>
          <Header name="Authorization">Basic 12e98yfw87etf</Header>
          <IncludeHealthCheckIdHeader>true</IncludeHealthCheckIdHeader>
        </Request>
        <SuccessResponse>
          <ResponseCode>200</ResponseCode>
          <Header name="ImOK">YourOK</Header>
        </SuccessResponse>
      </HTTPMonitor>
    </HealthMonitor>
    

HealthMonitor có các phần tử cấu hình HTTPMonitor

Bảng sau đây mô tả các phần tử cấu hình HTTPMonitor: