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 giúp bạn tăng cường khả năng cung cấp API bằng cách cung cấp tính năng hỗ trợ tích hợp sẵn cho việc cân bằng tải 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 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 HTTPConnection TargetEndpoint. 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 TargetServers 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 bật hay tắt.

Video

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

Video	Nội dung mô tả
Cân bằng tải bằng máy chủ mục tiêu	API cân bằng tải trên các máy chủ mục tiêu.
Định tuyến API dựa trên môi trường bằng cách sử dụng máy chủ mục tiêu	Định tuyến API đến một máy chủ đích khác dựa trên môi trường.
Định tuyến API và cân bằng tải bằng máy chủ mục tiêu (Edge cổ điển)	Định tuyến API đến một máy chủ mục tiêu khác dựa trên môi trường và cân bằng tải API của bạn trên các máy chủ mục tiêu trong giao diện người dùng Classic Edge.

Cấu hình TargetServer mẫu

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 >

Phần tử cấu hình máy chủ mục tiêu

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

Tên	Nội dung mô tả	Mặc định	Bắt buộc?
name	Tên của cấu hình TargetServer, phải là duy nhất trong môi trường. Tên TargetServer chỉ có thể chứa các ký tự chữ-số.	Không áp dụng	Có
Host	URL máy chủ lưu trữ của dịch vụ phụ trợ (không có giao thức).	Không áp dụng	Có
Port	Cổng mà dịch vụ phụ trợ đang nghe	Không áp dụng	Có
IsEnabled	Một giá trị boolean cho biết cấu hình TargetServer được bật hay tắt. Điều này cho phép bạn gỡ bỏ TargetServers ra khỏi chế độ xoay vòng mà không cần sửa đổi cấu hình proxy API. Có một trường hợp sử dụng phổ biến là viết một ứng dụng hoặc tập lệnh giúp tự động bật hoặc tắt TargetServers dựa trên yêu cầu về dung lượng dự kiến, lịch bảo trì, v.v.	true	Có

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ủ đích, như được mô tả bên dưới.

Quản lý các 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, nhận và liệt kê máy chủ đích. Để biết thêm thông tin, hãy xem bài viết TargetServers.

Hãy sử dụng lệnh gọi API sau để tạo 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

Câu trả lờ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. Khi xác định hai Máy chủ mục tiêu, bạn cung cấp hai URL mà một 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

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

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

Hãy 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ó 2 Máy chủ mục tiêu cho các proxy API được triển khai trong môi trường thử nghiệm. Để tải lưu lượng truy cập cân bằng trên các TargetServers 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 TargetServers.

Mỗi môi trường chỉ được có tối đa 500 Máy chủ mục tiêu, như đã nêu trong chủ đề Giới hạn.

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

Hiện tại, khi đã có 2 TargetServers, 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 là Round Robin, Có trọng số và Í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 gửi đi từ proxy API tới các máy chủ phụ trợ sẽ thay thế luân phiên (một lần cho một) từ mục tiêu 1 đến 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. Hàm này chỉ được dùng khi dùng <LoadBalancer>. Nếu không, thuộc tính này sẽ bị bỏ qua. Trong ví dụ trên, yêu cầu chuyển đến "target1" sẽ là http://target1/test và đố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 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à chuyển đổi dự phòng ở cấp trình cân bằng tải và cấp TargetServer. Mục này mô tả các tùy chọn này.

Thuật toán

Đặt thuật toán mà <LoadBalancer> sử dụng. Hiện có các thuật toán RoundRobin, Weighted và LeastConnections. Mỗi thuật toán trong số này được nêu rõ dưới đây.

Thi đấu vòng tròn

Thuật toán mặc định (vòng tròn) sẽ chuyển tiếp một yêu cầu đến từng máy chủ mục tiêu 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 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>

Theo 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 lưu lượng truy cập theo tỷ lệ cho các Máy chủ mục tiêu của mình. Trình cân bằng tải có trọng số phân phối yêu cầu đến TargetServers của bạn theo tỷ lệ trực tiếp với mỗi trọng số của 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 chuyển đến target2 đối với mỗi yêu cầu được chuyển đến target1.

Ít kết nối nhất

Bộ cân bằng tải dữ liệu đượ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 gửi đi đến Máy chủ mục tiêu 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ỗi tối đa

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.

Nếu phản hồi không thành công, 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 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 đó sẽ được tính là một 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 hoạt động tốt ra khỏi chế độ xoay vòng cân bằng tải sớm nhất có thể, 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ó các 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 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 mỗi yêu cầu và không bao giờ xoá máy chủ mục tiêu khỏi việc xoay.

Tốt nhất là bạn nên sử dụng MaxFailures > 0 cùng với HealthMonitor. Nếu bạn định cấu hình MaxFailures > 0, thì TargetServer bị xoá khỏi chế độ xoay vòng khi mục tiêu không vượt qua được số lần bạn chỉ định. Khi có một HealthMonitor, Apigee sẽ tự động đặt TargetServer xoay vòng trở lại sau khi mục tiêu được thiết lập và chạy lại, theo cấu hình của HealthMonitor đó. Hãy xem phần Theo dõi sức khoẻ để 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 HealthMonitor, thì Apigee sẽ không tự động thêm TargetServer vào chế độ xoay vòng sau khi Apigee phát hiện thấy 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 vào chế độ xoay vòng. Xem phần Triển khai proxy API.

Thử lại

Nếu tính năng thử lại được bật, yêu cầu sẽ được thử lại bất cứ khi nào phản hồi lỗi (lỗi I/O hoặc hết thời gian chờ HTTP) xảy ra 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 thông tin 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 có thể đặt một (và chỉ một) TargetServer làm máy chủ "fallback". 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 được tất cả TargetServer khác không hoạt động. Khi trình cân bằng tải xác định rằng tất cả TargetServers đều không hoạt động, mọi lưu lượng truy cập sẽ được chuyể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 việc cân bằng tải vòng tròn giữa các mục tiêu 1 và 2 cho đến khi cả mục tiêu 1 và 2 không có sẵn. Khi không có mục tiêu 1 và 2, mọi 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 Máy chủ mục tiêu đưa ra đến máy chủ phụ trợ.

Phần tử này chấp nhận một đường dẫn chuỗi cố định 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 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ị {mypath} được sử 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 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 phần đị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 đế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ỗ, TLS/SSL, bạn có thể định cấu hình TargetServer bằng cách sử dụng cùng một chế độ cài đặt cấu hình TLS/SSL làm 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ột Máy chủ ảo trong bài viết Định cấu hình quyền truy cập TLS vào một API cho Đám mây riêng tư.

Để biết hướng dẫn đầy đủ về cách định cấu hình TLS/SSL đi, hãy xem bài viết Đị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ác 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 tính năng theo dõi tình trạng đang bật, một TargetServer gặp lỗi sẽ tự động được đưa trở lại chế độ xoay vòng khi HealthMonitor xác định rằng TargetServer đang hoạt động.

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

Khi tính năng theo dõi tình trạng đang bật, một TargetServer không thành công sẽ tự động được đặt trở lại chế độ xoay vòng và bạn không cần phải 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 TCP chỉ đơn giản là đảm bảo rằng có thể mở một cổng.
• Bạn định cấu hình máy khách 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 giám sát 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à thất bại

Khi bạn bật tính năng theo dõi tình trạng, Edge sẽ bắt đầu gửi lượt 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 tới máy chủ đích nhằm xác định xem máy chủ đích có đang hoạt động tốt hay không.

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

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

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

• Không đạt: Máy chủ mục tiêu 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 bước kiểm tra. Lỗi có thể được ghi 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 nhất định.
  • Trả về mã trạng thái HTTP không mong muốn.
  • Phản hồ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ượng lỗi của máy chủ đó. Nếu số lỗi của máy chủ đó đạt đến hoặc vượt quá ngưỡng định sẵn (<MaxFailures>), thì 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 sẽ tạo một cấu hình proxy rồi tải 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ề mọi 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 bài viết Tài liệu tham khảo về cấu hình proxy API.

HealthMonitor đơn giản xác định một 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 đó sẽ đượ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 sửa đổi nào. Khi định cấu hình trình theo dõi 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 bên dưới xác định một HealthMonitor thăm dò từng TargetServer bằng cách mở kết nối trên cổng 80 mỗi 5 giây. (Không bắt buộc phải chuyển cổng. Nếu không chỉ định thì cổng TCPMonitor 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ỗi sẽ tăng thêm 1 cho TargetServer đó.
• Nếu kết nối thành công, số lượng lỗi của 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:

Tên	Nội dung mô tả	Mặc định	Bắt buộc?
IsEnabled	Một giá trị boolean bật hoặc tắt HealthMonitor.	false	Không
IntervalInSec	Khoảng thời gian (tính bằng giây) giữa mỗi lần thăm dò yêu cầu TCP.	0	Có
ConnectTimeoutInSec	Thời gian kết nối với cổng TCP phải được thiết lập để được coi là thành công. Việc không kết nối trong khoảng thời gian đã chỉ định sẽ bị tính là lỗi, làm tăng số lỗi của trình cân bằng tải cho TargetServer.	0	Có
Port	Không bắt buộc. Cổng mà kết nối TCP sẽ được thiết lập. Nếu không chỉ định thì cổng TCPMonitor là cổng TargetServer.	0	Không

HTTPMonitor

Một HealthMonitor mẫu sử dụng HTTPMonitor sẽ gửi một yêu cầu GET tới dịch vụ phụ trợ một lần mỗi 5 giây. 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ế của dịch vụ phụ trợ. Trong ví dụ bên dưới, phản hồi dự kiến là một mã phản hồi HTTP 200 và một 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 cấu hình trình cân bằng tải coi là lỗi.

HTTPMonitor hỗ trợ các dịch vụ phụ trợ được định cấu hình để sử dụng các giao thức HTTP và HTTPS một chiều. Tuy nhiên, tính năng 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ý.

Xin lưu ý rằng tất cả chế độ cài đặt Yêu cầu và phản hồi trong trình giám sát 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:

Tên	Nội dung mô tả	Mặc định	Bắt buộc?
IsEnabled	Một giá trị boolean bật hoặc tắt HealthMonitor.	false	Không
IntervalInSec	Khoảng thời gian (tính bằng giây) giữa mỗi yêu cầu thăm dò ý kiến.	0	Có
Request	Các tuỳ chọn cấu hình cho thông báo yêu cầu gửi đi do HealthMonitor gửi đến Máy chủ mục tiêu trong chế độ xoay vòng. Đường dẫn không hỗ trợ các biến.	Không áp dụng	Có
IsSSL	Chỉ định xem có sử dụng HTTPS (HTTP bảo mật) để giám sát kết nối hay không. Các giá trị tiềm năng: true: HTTPs được sử dụng. false: HTTP được sử dụng. Không xác định: Sử dụng cấu hình máy chủ mục tiêu.	false	Không
ConnectTimeoutInSec	Thời gian, tính bằng giây, trong đó quá trình bắt tay kết nối TCP với dịch vụ HTTP phải hoàn tất để được coi là thành công. Việc không kết nối trong khoảng thời gian đã chỉ định sẽ bị coi là lỗi, làm tăng số lượng lỗi của Load Balancer cho TargetServer.	0	Không
SocketReadTimeoutInSec	Thời gian, tính bằng giây, trong đó dữ liệu phải được đọc từ dịch vụ HTTP để được coi là thành công. Việc không đọc trong khoảng thời gian đã chỉ định sẽ bị coi là lỗi, làm tăng số lỗi của Load Balancer cho TargetServer.	0	Không
Port	Cổng mà trên đó kết nối HTTP tới dịch vụ phụ trợ sẽ được thiết lập.	Không áp dụng	Không
Verb	Động từ HTTP được sử dụng cho mỗi yêu cầu HTTP thăm dò tới dịch vụ phụ trợ .	Không áp dụng	Không
Path	Đường dẫn được thêm vào URL được xác định trong TargetServer. Sử dụng phần tử đường dẫn để định cấu hình "điểm cuối thăm dò ý kiến" trên dịch vụ HTTP của bạn.	Không áp dụng	Không
IncludeHealthCheckIdHeader	Cho phép bạn theo dõi các yêu cầu kiểm tra tình trạng trên các hệ thống cấp trên. IncludeHealthCheckIdHeader nhận giá trị Boolean và mặc định là false. Nếu bạn đặt thành true, thì sẽ có một Header tên là X-Apigee-Healthcheck-Id được chèn vào yêu cầu kiểm tra tình trạng. Giá trị của tiêu đề được gán động và có dạng ORG/ENV/SERVER_UUID/N, trong đó ORG là tên tổ chức, ENV là tên môi trường, SERVER_UUID là mã nhận dạng duy nhất xác định MP và N là số mili giây đã trôi qua kể từ ngày 1 tháng 1 năm 1970. Ví dụ về tiêu đề kết quả của yêu cầu: X-Apigee-Healthcheck-Id: orgname/envname/E8C4D2EE-3A69-428A-8616-030ABDE864E0/1586802968123	false	Không
Payload	Nội dung HTTP được tạo cho mỗi yêu cầu HTTP thăm dò. Lưu ý rằng phần tử này không bắt buộc đối với các yêu cầu GET.	Không áp dụng	Không
SuccessResponse	Các lựa chọn so khớp cho thông báo phản hồi HTTP gửi đến do dịch vụ phụ trợ đã thăm dò ý kiến tạo ra. Các phản hồi không khớp sẽ tăng số lượng lỗi thêm 1.	Không áp dụng	Không
ResponseCode	Mã phản hồi HTTP dự kiến sẽ nhận được từ TargetServer đã được thăm dò ý kiến. Nếu mã khác với mã được chỉ định, thì sẽ gây ra lỗi và số lượng sẽ tăng lên đối với dịch vụ phụ trợ đã thăm dò ý kiến. Bạn có thể xác định nhiều phần tử ResponseCode.	Không áp dụng	Không
Headers	Danh sách một hoặc nhiều tiêu đề và giá trị HTTP dự kiến sẽ nhận được từ dịch vụ phụ trợ đã được thăm dò ý kiến. Mọi tiêu đề hoặc giá trị HTTP trên phản hồi khác với các tiêu đề hoặc giá trị đã chỉ định sẽ dẫn đến lỗi và số lượng TargetServer được thăm dò sẽ tăng lên 1. Bạn có thể xác định nhiều phần tử Tiêu đề.	Không áp dụng	Không