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.
Chuyển đến tài liệu về Apigee X. thông tin

Apigee Edge tăng khả năng sẵn sàng của API bằng cách cung cấp tính năng hỗ trợ tích hợp cho việc cân bằng tải và 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 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 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, với một phần tử bổ sung để cho biết TargetServer đang bật hay tắt.

Video

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

Cấu hình TargetServer mẫu

Mã sau đây xác định một máy chủ mục tiêu:

<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ủ mục tiêu bằng giao diện người dùng

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

Quản lý máy chủ mục tiêu bằng API

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

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

$ 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 bạn tạo TargetServer đầu tiên, hãy sử dụng lệnh gọi API sau để 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ể sử 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

Câu trả lời mẫu:

[ "target2", "target1" ]

Hiện có hai TargetServer để các proxy API triển khai trong môi trường thử nghiệm 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 định cấu hình kết nối HTTP trong điểm cuối mục tiêu của proxy API để sử dụng TargetServer.

Mỗi môi trường có giới hạn là 500 TargetServer, như được nêu 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ó hai TargetServer, bạn có thể sửa đổi chế độ cài đặt kết nối HTTP TargetEndpoint để tham chiếu hai 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ợ ba thuật toán cân bằng tải, Round Robin (Kéo theo vòng tròn), Weighted (Được cân bằng) và Least Connection (Ít kết nối nhất). 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 từ proxy API đến máy chủ phụ trợ sẽ thay thế nhau, một yêu cầu cho mỗi mục tiêu giữa mục tiêu 1 và mục tiêu 2.

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

Thiết lập các tuỳ chọn của trình cân bằng tải

Bạn có thể điều chỉnh khả năng sử dụng bằng cách sử dụng các tuỳ chọn cân bằng tải và dự phòng tại trình cân bằng tải và cấp TargetServer. Phần này mô tả các tuỳ chọn này.

Thuật toán

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

Thi đấu vòng tròn

Thuật toán mặc định, vòng tròn, 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 điểm cuối mục tiêu. 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 theo 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 TargetServer. LoadBalancer có trọng số phân phối yêu cầu đến các TargetServer theo tỷ lệ trực tiếp với trọng số của từng TargetServer. Do đó, thuật toán trọng số yêu cầu bạn đặ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, 2 yêu cầu sẽ được định tuyến đến mục tiêu 2 cho mỗi yêu cầu được định tuyến đến mục tiêu 1.

Ít kết nối nhất

LoadBalancer được định cấu hình để sử dụng thuật toán kết nối ít nhất, định tuyến các yêu cầu gửi đi đến TargetServer có ít kết nối HTTP 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 yêu cầu không thành công tối đa 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ủ mục tiêu. 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 mục tiêu, ngay cả khi phản hồi đó là lỗi HTTP (chẳng hạn như 500), thì phản hồi đó vẫn được tính là phản hồi từ máy chủ mục tiêu 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 để đưa một máy chủ không ổn định ra khỏi chế độ luân phiên 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ẽ tính các phản hồi có những mã đó là lỗi.

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

<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>

Mặc định, 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 mỗi yêu cầu và không bao giờ xoá máy chủ mục tiêu khỏi chế độ xoay vòng.

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 chế độ xoay khi mục tiêu không đạt được số lần bạn chỉ định. Khi một HealthMonitor được triển khai, Apigee sẽ tự động đưa TargetServer trở lại chế độ xoay vòng sau khi mục tiêu khởi động và chạy 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 trình giám sát trạng thái, Apigee sẽ tự động loại bỏ máy chủ mục tiêu khỏi chế độ xoay vòng khi phát hiện lỗi đầu tiên. Apigee sẽ kiểm tra tình trạng của máy chủ mục tiêu 5 phút một lần và trả về máy chủ đó vào chế độ xoay vòng 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, hệ thống sẽ thử lại một yêu cầu 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. Xem phần Số lỗi tối đa ở trên để biết thêm về cách đặt <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 chỉ 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 bộ cân bằng tải xác định rằng tất cả các TargetServer khác đều không hoạt động. Khi bộ cân bằng tải xác định rằng tất cả TargetServer đều không hoạt động, tất cả 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 theo vòng tròn giữa 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 chuyển đến mục tiêu 3.

Đường dẫn

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

Phần tử này chấp nhận đường dẫn chuỗi cố định hoặc mẫu thông báo. Mẫu thông báo cho phép bạn thực hiện việc 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ủ mục tiêu 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 về TargetServer cho TLS/SSL một chiều, trong đó Edge đưa ra các yêu cầu HTTPS đến 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 hai bên, thì bạn hãy định cấu hình TargetServer bằng cách sử dụng các chế độ cài đặt cấu hình TLS/SSL giống 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 trong phần Định cấu hình quyền truy cập TLS vào API cho đám mây riêng.

Để biết 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ợ (Đám mây và Đám mây riêng tư).

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 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ò ý kiến về 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, TargetServer không thành công sẽ tự động được đưa trở lại vòng luân phiên 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 bạn 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 thành công sẽ bị loại khỏi chế độ xoay vòng 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, TargetServer không thành công sẽ tự động được đưa trở lại vòng luân phiên 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:

• Ứng dụng khách TCP chỉ đảm bảo rằng bạn có thể mở một ổ cắm.
• Bạn định cấu hình ứng dụng HTTP để gửi 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 trình theo dõi HTTP phải khớp với chế độ cài đặt đã định cấu hình trong khối <SuccessResponse>.

Thành công và không thành công

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

Kết quả kiểm tra tình trạng có thể là một trong hai:

• Thành công: Máy chủ mục tiêu được coi là khỏe mạnh khi quá trình kiểm tra tình trạng diễn ra thành công. Điều này thường là do một hoặc nhiều lý do sau:
  • Máy chủ mục tiêu chấp nhận một kết nối mới với cổng được chỉ định, phản hồi một yêu cầu trên cổng đó, sau đó đóng cổng trong khung thời gian được chỉ định. Phản hồi từ máy chủ mục tiêu chứa "Kết nối: đóng"
  • Máy chủ mục tiêu phản hồi yêu cầu kiểm tra tình trạng bằng mã trạng thái 200 (OK) hoặc mã trạng thái HTTP khác mà bạn xác định là chấp nhận được.
  • Máy chủ mục tiêu phản hồi yêu cầu kiểm tra tình trạng bằng 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 được 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ủ đó.

• Không thành công: Máy chủ mục tiêu có thể không thành công trong quá trình kiểm tra tình trạng theo nhiều cách, tuỳ thuộc vào loại kiểm tra. Lỗi có thể được ghi lại khi máy chủ mục tiêu:
  • 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ủ mục tiêu không vượt qua được quy trình kiểm tra tình trạng, Edge sẽ tăng số lần lỗi của máy chủ đó. Nếu số lượng lỗi của máy chủ đó đạt hoặc vượt quá 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 HealthMonitor, bạn 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 dưới dạng tệp ZIP vào Edge. Cấu hình proxy là nội dung mô tả có cấu trúc về tất cả khía cạnh của một proxy API. Cấu hình proxy bao gồm các tệp XML trong cấu trúc thư mục được xác định trước. Để biết thêm thông tin, hãy xem Tài liệu tham khảo về cấu hình Proxy API.

Một 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ủ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, nghĩa là Edge không thực hiện hành động khắc phục. Khi định cấu hình trình theo dõi tình trạng, hãy đảm bảo 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 bên dưới xác định một HealthMonitor thăm dò ý kiến từng TargetServer bằng cách mở một kết nối trên cổng 80 mỗi 5 giây. (Cổng là không bắt buộc. Nếu bạn không chỉ định, cổng TCPMonitor sẽ là cổng TargetServer.)

• Nếu không kết nối được hoặc mất hơn 10 giây để kết nối, thì số lần không kết nối sẽ tăng thêm 1 cho TargetServer đó.
• Nếu kết nối thành công, thì số lần không thành công 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 của 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

Một HealthMonitor mẫu sử dụng HTTPMonitor sẽ gửi một yêu cầu GET đến dịch vụ phụ trợ mỗi 5 giây. Mẫu bên dưới 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ụ dưới đây, 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 bộ 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à giao thức HTTPS một chiều. Tuy nhiên, tính năng này không hỗ trợ những tính năng 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ả các chế độ cài đặt Yêu cầu và Phản hồi trong trình theo dõi 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 với 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: