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 cải thiện khả năng sử dụng API của bạn bằng cách cung cấp tính năng hỗ trợ tích hợp sẵn cho việc tải cân bằng và chuyển đổi dự phòng trên nhiều thực thể máy chủ phụ trợ.

Cấu hình TargetServer tách URL điểm cuối cụ thể khỏi 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 URL hoặc các Máy chủ Mục tiêu có tên như được mô tả trong phần TargetEndpoint (Điểm cuối mục tiêu).

Đị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 cho biết TargetServer được 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 cách sử dụng đích máy chủ

Cấu hình máy chủ đích mẫu

Đoạn mã sau đây định nghĩa một máy chủ mục tiêu:

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

Phần tử cấu hình máy chủ đích

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ý các máy chủ đích bằng giao diện người dùng

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

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

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

Sử dụng lệnh gọi API sau đây để tạo một 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 đây để tạo TargetServer thứ hai. Bằng cách xác định 2 TargetServers, bạn cung cấp 2 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 để truy xuất danh sách Máy chủ mục tiêu 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 TargetServers để sử dụng bằng proxy API được triển khai trong thử nghiệm môi trường. Để cân bằng tải lưu lượng truy cập trên các TargetServer này, bạn hãy định cấu hình HTTP kết nối trong điểm cuối mục tiêu của proxy API để sử dụng TargetServers.

Có giới hạn 500 Máy chủ mục tiêu cho mỗi môi trường, vì được nêu trong chủ đề Giới hạn.

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

Giờ đây khi có hai TargetServers, bạn có thể sửa đổi TargetEndpoint HTTP cài đặt kết nối để tham chiếu đến 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ể. Tải trọng trình cân bằng hỗ trợ 3 thuật toán cân bằng tải, Round Robin, Weight và Least Connection (Kết nối ít nhất). Round Robin là thuật toán mặc định. Do không có thuật toán nào được chỉ định trong cấu hình ở trên, các yêu cầu đi từ proxy API đến máy chủ phụ trợ sẽ thay thế lần lượt từng yêu cầ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. Chỉ dùng khi <LoadBalancer> được dùng. Nếu không, sẽ bị bỏ qua. Trong ví dụ trên, yêu cầu đạt tới "target1" sẽ là http://target1/test và tương tự đối với các máy chủ mục tiêu khác.

Đặt tuỳ chọn trình cân bằng tải

Bạn có thể điều chỉnh tình trạng hoạt độ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 khi tải cân bằng và TargetServer. Phần này mô tả các lựa chọn này.

Thuật toán

Thiết lập thuật toán mà <LoadBalancer> sử dụng. Các là RoundRobin, Weighted và LeastConnections, mỗi yếu tố được ghi lại dưới đây.

Thi đấu vòng tròn

Thuật toán mặc định, quay vòng, chuyển tiếp yêu cầu đến từng TargetServer theo thứ tự trong mà máy chủ được liệt kê trong kết nối HTTP đ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 tỷ lệ cho Máy chủ mục tiêu của bạn. Trình cân bằng tải trọng số phân phối yêu cầu đến TargetServers của bạn một cách trực tiếp tỷ lệ 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 phải đặ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, hai yêu cầu sẽ được định tuyến đến target2 cho mỗi một yêu cầu được định tuyến đến target1.

Ít kết nối nhất

Trình cân bằng tải được định cấu hình để sử dụng thuật toán kết nối ít nhất sẽ định tuyến các yêu cầu đi đến Máy chủ mục tiêu 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ỗ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 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. Thời gian khi điều này xảy ra, bộ đếm lỗi sẽ tăng thêm 1.

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à một phản hồi từ máy chủ đích và bộ đếm lỗi được đặt lại. Để giúp đảm bảo rằng phản hồi HTTP không hợp lệ (chẳng hạn như 500) cũng tăng bộ đếm lỗi để lấy một máy chủ không hoạt động tốt ra xoay 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ó <ResponseCode> các phần tử con vào cấu hình trình cân bằng tải. Edge cũng sẽ tính số lượt phản hồi khi người dùng nhấp vào mã là lỗi.

Trong ví dụ sau, target1 sẽ bị xoá khỏi chế độ xoay sau 5 yêu cầu không thực hiện được, bao gồm một số 5XX phản hồi 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áy chủ đích 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 khi thiết lập tính năng theo dõi sức khoẻ. 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 đáp ứng được số lần bạn chỉ ra. Khi một HealthMonitor đã được thiết lập, Apigee sẽ tự động đặt TargetServer quay lại xoay vòng sau khi mục tiêu được thiết lập và chạy lại, theo của HealthMonitor đó. Xem bài viết Theo dõi sức khoẻ để biết thêm thông tin.

Hoặc nếu bạn định cấu hình MaxFailures > 0 và bạn không định cấu hình HealthMonitor, Apigee sẽ không đưa lại TargetServer vào quy trình xoay vòng tự động sau khi Apigee phát hiện lỗi. Trong trường hợp này, bạn phải triển khai lại proxy API trước khi Apigee đặt TargetServer trở lại xoay. Xem Triển khai proxy API.

Thử lại

Nếu bạn bật tính năng thử lại, thì hệ thống sẽ thử lại yêu cầu bất cứ khi nào có phản hồi không thành công (lỗi I/O hoặc hết thời gian chờ HTTP) xảy ra hoặc phản hồi đã nhận khớp với giá trị do <ServerUnhealthyResponse> đặt. Xem phần Lỗi tối đa ở trên để biết thêm thông tin về chế độ cài đặ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

Một (và chỉ một) Máy chủ đích có thể được đặt làm "dự phòng" máy chủ. Máy chủ mục tiêu dự phòng không được đưa vào thói quen cân bằng tải cho đến khi tất cả TargetServers khác được xác định là không khả dụng bởi trình cân bằng tải. Khi trình cân bằng tải xác định rằng tất cả TargetServers không khả dụ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 dẫn đến cân bằng tải theo thứ tự vòng tròn giữa các mục tiêu 1 và 2 cho đến cả mục tiêu 1 và 2 đều không có sẵn. Khi không có mục tiêu 1 và 2, tất cả lưu lượng truy cập sẽ được định tuyến để nhắm 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 một đường dẫn chuỗi dạng cố định hoặc mẫu thông báo. Tin nhắn mẫu 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ủ đích cho TLS/SSL

Nếu bạn đang sử dụng TargetServer để xác định dịch vụ phụ trợ và dịch vụ phụ trợ cần có 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 của TargetServer dành cho một chiều TLS/SSL khi Edge gửi 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 tương hỗ, thì bạn sẽ định cấu hình TargetServer bằng cách sử dụng cùng các 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 đặt các thuộc tính đó cho Máy chủ lưu trữ ảo tại bài viết Định cấu hình quyền truy cập TLS vào API dành cho Cloud riêng tư.

Để biết hướng dẫn đầy đủ về cách định cấu hình TLS/SSL đi, hãy xem Đị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ò URL dịch vụ phụ trợ được xác định trong cấu hình TargetServer. Khi bật tính năng theo dõi sức khoẻ, một TargetServer không thành công sẽ tự động được xoay trở lại khi HealthMonitor xác định máy chủ Target đ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 theo dõi sức khoẻ, <MaxFailures> chỉ định số lượng yêu cầu không thực hiện được từ proxy API cho Máy chủ mục tiêu dẫn đến việc yêu cầu được chuyển hướng đến một TargetServer khác. Sau đó, TargetServer ngừng xoay cho đến khi bạn triển khai lại proxy.

Khi bật tính năng theo dõi tình trạng, một TargetServer gặp sự cố sẽ tự động được xoay vòng trở lại và không có proxy triển khai lại là cần thiết.

HealthMonitor đóng vai trò là một ứng dụng đơn giản gọi ra dịch vụ phụ trợ qua TCP hoặc HTTP:

• Ứng dụng TCP chỉ đơn giản là đảm bảo rằng có thể mở cổng.
• 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 theo dõi 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 theo dõi tình trạng sức khoẻ, Edge sẽ bắt đầu gửi thông tin kiểm tra tình trạng đến mục tiêu của bạn máy chủ. Kiểm tra tình trạng là một yêu cầu được gửi đến máy chủ đích nhằm xác định xem máy chủ mục tiêu có hoạt động tốt hay không.

Kết quả 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ủ mục tiêu được xem là hoạt động tốt khi có trạng thái hoạt động thành công kiểm tra. Đây thường là kết quả của một hoặc nhiều điều sau đây:
  • 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 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 có 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 HTTP khác mà bạn xác định là được chấp nhận.
  • 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 dự kiến.

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

• Không thành công: Máy chủ đích có thể không vượt qua được quy trình kiểm tra tình trạng theo nhiều cách, tuỳ theo loại séc. 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 với 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 nhất định.
  • 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ư mong muố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ỗi của máy chủ đó. Nếu số lượng lỗi mà máy chủ đó đáp ứng hoặc vượt quá ngưỡng xác định trước (<MaxFailures>), Edge sẽ ngừng gửi yêu cầu đến máy chủ đó.

Bật tính năng Giám sát sức khoẻ

Để tạo một HealthMonitor, bạn hãy thêm phần tử <HealthMonitor> vào 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 tệp đó dưới dạng tệp ZIP lên Edge. Cấu hình proxy là nội dung mô tả có cấu trúc về tất cả các khía cạnh của 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 API Proxy Tài liệu tham khảo về cấu hình.

Một HealthMonitor đơn giản xác định một IntervalInSec kết hợp với một TCPMonitor hoặc một HTTPMonitor. Phần tử <MaxFailures> chỉ định giá trị tối đa số yêu cầu không thành công từ proxy API đến TargetServer dẫn đến 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 thiết bị theo dõi tình trạng sức khoẻ, 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ò ý kiến của từng TargetServer bằng cách mở một trên cổng 80 cứ 5 giây một lần. (Cổng là không bắt buộc. Nếu không được chỉ định, cổng TCPMonitor 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 lỗi sẽ được tính tăng thêm 1 cho TargetServer đó.
• Nếu kết nối thành công, thì số lỗi cho TargetServer được đặt lại thành 0.

Bạn có thể thêm HealthMonitor làm phần tử con của HTTPTargetConnetion của TargetEndpoint như thể hiện 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>
. . .

Giám sát sức khoẻ 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 một HTTPMonitor sẽ gửi một yêu cầu GET đến phần phụ trợ 5 giây một lần. Mẫu dưới đây thêm tiêu đề Uỷ quyền cơ bản HTTP vào tin nhắn 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 chế độ thực tế phản hồi từ dịch vụ phụ trợ. Trong ví dụ bên dưới, phản hồi dự kiến là một HTTP mã phản hồi 200 và tiêu đề HTTP tùy 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 HTTP và HTTPS một chiều giao thức. Tuy nhiên, API này không hỗ trợ các tính năng sau:

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

Lưu ý rằng tất cả cài đặt Yêu cầu và phản hồi trong màn hình HTTP sẽ dành riêng cho dịch vụ phụ trợ này 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>
    

Giám sát sức khoẻ 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: