تعادل بار در سرورهای باطن

شما در حال مشاهده اسناد Apigee Edge هستید.
به مستندات Apigee X بروید . اطلاعات

Apigee Edge در دسترس بودن API شما را با ارائه پشتیبانی داخلی برای تعادل بار و failover در چندین نمونه سرور باطن افزایش می‌دهد.

پیکربندی های TargetServer URL های نقطه پایانی مشخص را از پیکربندی های TargetEndpoint جدا می کند. هر TargetServer با نام در TargetEndpoint HTTPConnection ارجاع داده می شود. به جای تعریف یک URL مشخص در پیکربندی، می توانید یک یا چند سرور با نام TargetServer را همانطور که در بخش TargetEndpoint توضیح داده شده است، پیکربندی کنید.

تعریف TargetServer شامل یک نام، یک میزبان و یک پورت، با یک عنصر اضافی برای نشان دادن فعال یا غیرفعال بودن TargetServer است.

ویدیوها

برای کسب اطلاعات بیشتر در مورد مسیریابی API و تعادل بار با استفاده از سرورهای هدف، ویدیوهای زیر را تماشا کنید

نمونه پیکربندی TargetServer

کد زیر یک سرور هدف را تعریف می کند:

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

عناصر پیکربندی TargetServer

جدول زیر عناصر مورد استفاده برای ایجاد و پیکربندی TargetServer را توضیح می دهد:

مدیریت سرورهای هدف با استفاده از رابط کاربری

مدیریت سرورهای هدف، همانطور که در زیر توضیح داده شده است..

مدیریت سرورهای هدف با استفاده از API

می‌توانید از Edge API برای ایجاد، حذف، به‌روزرسانی، دریافت و فهرست کردن سرورهای هدف استفاده کنید. برای اطلاعات بیشتر، TargetServers را ببینید.

از فراخوانی API زیر برای ایجاد یک سرور هدف استفاده کنید:

$ 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

نمونه پاسخ:

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

پس از ایجاد اولین TargetServer، سپس از فراخوانی API زیر برای ایجاد TargetServer دوم استفاده کنید. با تعریف دو TargetServer، دو URL ارائه می کنید که TargetEndpoint می تواند برای متعادل کردن بار استفاده کند:

$ 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

نمونه پاسخ:

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

از فراخوانی API زیر برای بازیابی لیستی از TargetServers در یک محیط استفاده کنید:

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

نمونه پاسخ:

[ "target2", "target1" ]

در حال حاضر دو TargetServer برای استفاده توسط پراکسی های API در محیط آزمایشی موجود است. برای بارگیری ترافیک موجود در این TargetServers، اتصال HTTP را در نقطه پایانی هدف پروکسی API برای استفاده از TargetServers پیکربندی می‌کنید.

همانطور که در مبحث Limits مستند شده است، محدودیت 500 TargetServer در هر محیط وجود دارد.

پیکربندی TargetEndpoint برای بارگذاری تعادل در سرورهای Target نام‌گذاری شده

اکنون که دو TargetServer در دسترس دارید، می توانید تنظیمات اتصال TargetEndpoint HTTP را برای ارجاع به آن دو TargetServer با نام تغییر دهید:

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

پیکربندی بالا ابتدایی ترین پیکربندی متعادل کننده بار ممکن است. متعادل کننده بار از سه الگوریتم متعادل کننده بار، Round Robin، Weighted و Least Connection پشتیبانی می کند. Round Robin الگوریتم پیش فرض است. از آنجایی که هیچ الگوریتمی در پیکربندی بالا مشخص نشده است، درخواست‌های خروجی از پروکسی API به سرورهای پشتیبان، یک به یک، بین target1 و target 2 جایگزین می‌شوند.

عنصر <Path> مسیر پایه URI TargetEndpoint را برای همه سرورهای هدف تشکیل می دهد. فقط زمانی استفاده می شود که <LoadBalancer> استفاده شود. در غیر این صورت نادیده گرفته می شود. در مثال بالا، درخواستی که به "target1" می رسد http://target1/test و به همین ترتیب برای سایر سرورهای هدف خواهد بود.

تنظیم گزینه های متعادل کننده بار

می‌توانید با استفاده از گزینه‌های متعادل‌سازی بار و شکست در سطح بار متعادل‌کننده و TargetServer، دسترسی را تنظیم کنید. این بخش این گزینه ها را توضیح می دهد.

الگوریتم

الگوریتم مورد استفاده توسط <LoadBalancer> را تنظیم می کند. الگوریتم‌های موجود RoundRobin ، Weighted و LeastConnections هستند که هر کدام در زیر مستند شده‌اند.

گرد رابین

الگوریتم پیش‌فرض، دور روبین، یک درخواست را به هر TargetServer به ترتیبی که سرورها در اتصال HTTP نقطه پایانی هدف فهرست شده‌اند، ارسال می‌کند. به عنوان مثال:

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

وزن دار

الگوریتم متعادل کننده بار وزنی شما را قادر می سازد تا بارهای ترافیکی متناسب را برای TargetServers خود پیکربندی کنید. LoadBalancer وزنی درخواست را به TargetServer شما به نسبت مستقیم با وزن هر TargetServer توزیع می کند. بنابراین، الگوریتم وزنی از شما می خواهد که برای هر TargetServer یک ویژگی weight تنظیم کنید. به عنوان مثال:

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

در این مثال، به ازای هر درخواستی که به target1 مسیریابی می‌شود، دو درخواست به target2 هدایت می‌شوند.

کمترین اتصال

LoadBalancers پیکربندی شده‌اند تا از کمترین الگوریتم اتصال، درخواست‌های خروجی را به TargetServer با کمترین اتصالات HTTP باز هدایت کنند. به عنوان مثال:

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

حداکثر شکست

حداکثر تعداد درخواست های ناموفق از پروکسی API به TargetServer که منجر به هدایت درخواست به TargetServer دیگر می شود.

شکست پاسخ به این معنی است که Apigee هیچ پاسخی از سرور مورد نظر دریافت نمی کند. هنگامی که این اتفاق می افتد، شمارنده شکست یک افزایش می یابد.

با این حال، زمانی که Apigee پاسخی را از یک هدف دریافت می‌کند، حتی اگر پاسخ یک خطای HTTP باشد (مانند 500 )، این پاسخ به عنوان یک پاسخ از طرف سرور هدف به حساب می‌آید و شمارنده خرابی بازنشانی می‌شود. برای اطمینان از اینکه پاسخ‌های بد HTTP (مانند 500 ) همچنین شمارشگر خرابی را افزایش می‌دهد تا سرور ناسالم را در اسرع وقت از چرخش تعادل بار خارج کند، می‌توانید عنصر <ServerUnhealthyResponse> را با عناصر <ResponseCode> به متعادل کننده بار خود اضافه کنید. پیکربندی Edge همچنین پاسخ‌هایی با آن کدها را به‌عنوان شکست حساب می‌کند.

در مثال زیر، target1 پس از پنج درخواست ناموفق، از جمله برخی از پاسخ‌های 5XX از سرور هدف، از چرخش حذف می‌شود.

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

پیش فرض MaxFailures 0 است. این بدان معنی است که Edge همیشه سعی می کند برای هر درخواست به هدف متصل شود و هرگز سرور مورد نظر را از چرخش حذف نمی کند.

بهتر است از MaxFailures > 0 با HealthMonitor استفاده کنید. اگر MaxFailures > 0 را پیکربندی کنید، TargetServer از چرخش حذف می شود که هدف به تعداد دفعاتی که شما نشان می دهید شکست بخورد. هنگامی که یک HealthMonitor در جای خود قرار دارد، Apigee به طور خودکار TargetServer را پس از راه اندازی و اجرا مجدد هدف، مطابق پیکربندی آن HealthMonitor در چرخش قرار می دهد. برای اطلاعات بیشتر به نظارت بر سلامت مراجعه کنید.

از طرف دیگر، اگر MaxFailures > 0 را پیکربندی کنید، و HealthMonitor را پیکربندی نکنید، Apigee پس از تشخیص خرابی Apigee، TargetServer را مجدداً به چرخش وارد نمی‌کند. در این مورد، باید قبل از اینکه Apigee TargetServer را به چرخش بازگرداند، پراکسی API را مجدداً مستقر کنید. به استقرار یک پروکسی API مراجعه کنید.

دوباره امتحان کنید

اگر تلاش مجدد فعال باشد، هر زمان که یک خطای پاسخ (خطای I/O یا زمان پایان HTTP) رخ دهد یا پاسخ دریافتی با مقدار تنظیم شده توسط <ServerUnhealthyResponse> مطابقت داشته باشد، درخواست مجدداً امتحان می شود. برای اطلاعات بیشتر در مورد تنظیم <ServerUnhealthyResponse> به حداکثر خرابی در بالا مراجعه کنید.

به طور پیش فرض <RetryEnabled> روی true تنظیم شده است. برای غیرفعال کردن تلاش مجدد، روی false تنظیم کنید. به عنوان مثال:

<RetryEnabled>false</RetryEnabled>

IsFallback

یک (و تنها یک) TargetServer را می توان به عنوان سرور بازگشتی تنظیم کرد. تا زمانی که همه TargetServer های دیگر توسط متعادل کننده بار در دسترس نیستند، TargetServer بازگشتی در روال های متعادل کننده بار گنجانده نمی شود. هنگامی که متعادل کننده بار تشخیص می دهد که همه TargetServer ها در دسترس نیستند، تمام ترافیک به سرور بازگشتی هدایت می شود. به عنوان مثال:

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

پیکربندی بالا منجر به متعادل کردن بار دور بین اهداف 1 و 2 می شود تا زمانی که هر دو هدف 1 و 2 در دسترس نباشند. وقتی اهداف 1 و 2 در دسترس نباشند، تمام ترافیک به سمت هدف 3 هدایت می شود.

مسیر

Path یک قطعه URI را تعریف می کند که به تمام درخواست های صادر شده توسط TargetServer به سرور backend اضافه می شود.

این عنصر یک مسیر رشته تحت اللفظی یا یک الگوی پیام را می پذیرد. یک قالب پیام به شما امکان می دهد در زمان اجرا جایگزین رشته متغیر را انجام دهید. به عنوان مثال، در تعریف نقطه پایانی هدف زیر، مقدار {mypath} برای مسیر استفاده می‌شود:

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

پیکربندی یک سرور هدف برای TLS/SSL

اگر از TargetServer برای تعریف سرویس Backend استفاده می کنید، و سرویس Backend برای استفاده از پروتکل HTTPS به اتصال نیاز دارد، باید TLS/SSL را در تعریف TargetServer فعال کنید. این امر ضروری است زیرا تگ <Host> به شما اجازه نمی دهد پروتکل اتصال را مشخص کنید. در زیر تعریف TargetServer برای TLS/SSL یک طرفه نشان داده شده است که Edge درخواست‌های HTTPS را به سرویس باطن ارائه می‌کند:

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

اگر سرویس Backend به TLS/SSL دو طرفه یا متقابل نیاز دارد، TargetServer را با استفاده از همان تنظیمات پیکربندی TLS/SSL مانند 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 >

برای اطلاعات در مورد ویژگی‌های <SSLInfo> ، مانند <Ciphers> و <ClientAuthEnabled> ، به اطلاعات مربوط به تنظیم این ویژگی‌ها برای یک میزبان مجازی در پیکربندی دسترسی TLS به یک API برای Private Cloud مراجعه کنید.

برای دستورالعمل‌های کامل در مورد پیکربندی TLS/SSL خروجی، به پیکربندی TLS از Edge به باطن (Cloud و Private Cloud) مراجعه کنید.

طرح واره TargetServer

طرح TargetServer و سایر موجودات را در GitHub ببینید.

نظارت بر سلامت

نظارت بر سلامت شما را قادر می‌سازد تا با نظرسنجی فعال آدرس‌های اینترنتی سرویس پشتیبان تعریف‌شده در پیکربندی‌های TargetServer، پیکربندی‌های تعادل بار را بهبود ببخشید. با فعال بودن نظارت بر سلامت، زمانی که HealthMonitor تشخیص دهد که TargetServer فعال است، یک TargetServer ناموفق به طور خودکار در چرخش قرار می گیرد.

نظارت بر سلامت با <MaxFailures> کار می کند. بدون فعال بودن نظارت بر سلامت، <MaxFailures> تعداد درخواست های ناموفق از پروکسی API به TargetServer را مشخص می کند که منجر به هدایت درخواست به TargetServer دیگر می شود. سپس TargetServer ناموفق از چرخش خارج می شود تا زمانی که پراکسی را مجدداً مستقر کنید.

با فعال بودن نظارت بر سلامت، TargetServer ناموفق به طور خودکار به چرخش بازگردانده می شود و نیازی به استقرار مجدد پروکسی نیست.

HealthMonitor به عنوان یک کلاینت ساده عمل می کند که یک سرویس پشتیبان را از طریق TCP یا HTTP فراخوانی می کند:

• یک کلاینت TCP به سادگی تضمین می کند که یک سوکت می تواند باز شود.
• شما سرویس گیرنده HTTP را برای ارسال یک درخواست معتبر HTTP به سرویس پشتیبان پیکربندی می کنید. می توانید عملیات HTTP GET، PUT، POST یا DELETE را تعریف کنید. پاسخ تماس مانیتور HTTP باید با تنظیمات پیکربندی شده در بلوک <SuccessResponse> مطابقت داشته باشد.

موفقیت ها و شکست ها

هنگامی که نظارت بر سلامت را فعال می کنید، Edge شروع به ارسال چک های سلامت به سرور مورد نظر شما می کند. بررسی سلامت درخواستی است که به سرور مورد نظر ارسال می شود و مشخص می کند که آیا سرور مورد نظر سالم است یا خیر.

بررسی سلامت می تواند یکی از دو نتیجه ممکن را داشته باشد:

• موفقیت: سرور مورد نظر زمانی سالم در نظر گرفته می شود که یک بررسی سلامت موفقیت آمیز انجام شود. این معمولاً نتیجه یک یا چند مورد از موارد زیر است:
  • سرور هدف یک اتصال جدید به پورت مشخص شده را می پذیرد، به درخواستی در آن پورت پاسخ می دهد و سپس پورت را در بازه زمانی مشخص شده می بندد. پاسخ سرور مورد نظر حاوی "اتصال: بستن" است
  • سرور هدف به درخواست بررسی سلامت با 200 (OK) یا کد وضعیت HTTP دیگری که شما تشخیص می دهید قابل قبول است پاسخ می دهد.
  • سرور هدف با متن پیامی که با متن مورد انتظار مطابقت دارد به درخواست بررسی سلامت پاسخ می دهد.

  وقتی Edge تشخیص می‌دهد که سرور سالم است، Edge به ارسال درخواست‌ها به آن ادامه می‌دهد یا از سر می‌گیرد.

• خرابی: سرور مورد نظر بسته به نوع بررسی می‌تواند به روش‌های مختلف در بررسی سلامت شکست بخورد. هنگامی که سرور هدف می تواند یک شکست ثبت شود:
  • اتصال از Edge به پورت بررسی سلامت را رد می کند.
  • در یک بازه زمانی مشخص به درخواست چک سلامت پاسخ نمی دهد.
  • کد وضعیت غیرمنتظره HTTP را برمی گرداند.
  • با متن پیامی که با متن مورد انتظار پیام مطابقت ندارد پاسخ می دهد.

  هنگامی که یک سرور هدف در بررسی سلامت ناموفق باشد، Edge تعداد خرابی سرور را افزایش می دهد. اگر تعداد خرابی‌های آن سرور از آستانه از پیش تعریف‌شده ( <MaxFailures> ) فراتر رفت یا از آن فراتر رفت، Edge ارسال درخواست‌ها به آن سرور را متوقف می‌کند.

فعال کردن مانیتور سلامت

برای ایجاد HealthMonitor، عنصر <HealthMonitor> را به پیکربندی HTTPConnection TargetEndpoint برای یک پروکسی اضافه می‌کنید. شما نمی توانید این کار را در UI انجام دهید. در عوض، یک پیکربندی پروکسی ایجاد می‌کنید و آن را به عنوان یک فایل ZIP در Edge آپلود می‌کنید. یک پیکربندی پروکسی یک توصیف ساختار یافته از تمام جنبه های یک پراکسی API است. پیکربندی های پروکسی شامل فایل های XML در یک ساختار دایرکتوری از پیش تعریف شده است. برای اطلاعات بیشتر، به مرجع پیکربندی پروکسی API مراجعه کنید.

یک HealthMonitor ساده یک IntervalInSec ترکیب شده با یک TCPMonitor یا یک HTTPMonitor را تعریف می کند. عنصر <MaxFailures> حداکثر تعداد درخواست های ناموفق را از پروکسی API به TargetServer مشخص می کند که منجر به هدایت درخواست به TargetServer دیگر می شود. به طور پیش فرض <MaxFailures> 0 است، به این معنی که Edge هیچ اقدام اصلاحی انجام نمی دهد. هنگام پیکربندی یک مانیتور سلامت، مطمئن شوید که <MaxFailures> را در تگ <HTTPTargetConnection> تگ <TargetEndpoint> روی یک مقدار غیر صفر تنظیم کرده اید.

TCPMonitor

پیکربندی زیر یک HealthMonitor را تعریف می‌کند که با باز کردن یک اتصال در پورت 80 هر پنج ثانیه از هر TargetServer نظرسنجی می‌کند. (پورت اختیاری است. اگر مشخص نشده باشد، درگاه TCPMonitor پورت TargetServer است.)

• اگر اتصال قطع شود یا بیش از 10 ثانیه طول بکشد تا وصل شود، تعداد خرابی ها برای آن TargetServer 1 افزایش می یابد.
• اگر اتصال موفقیت آمیز باشد، تعداد خرابی ها برای TargetServer به 0 بازنشانی می شود.

همانطور که در زیر نشان داده شده است، می توانید یک HealthMonitor را به عنوان عنصر فرزند عنصر HTTPTargetConnetion در TargetEndpoint اضافه کنید:

<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 با عناصر پیکربندی TCPMonitor

جدول زیر عناصر پیکربندی TCPMonitor را توضیح می دهد:

مانیتور HTTP

یک نمونه HealthMonitor که از HTTPMonitor استفاده می کند، هر پنج ثانیه یک بار درخواست GET را به سرویس Backend ارسال می کند. نمونه زیر یک عنوان مجوز اولیه HTTP را به پیام درخواست اضافه می کند. پیکربندی Response تنظیماتی را تعریف می‌کند که با پاسخ واقعی سرویس پشتیبان مقایسه می‌شوند. در مثال زیر، پاسخ مورد انتظار یک کد پاسخ HTTP 200 و یک هدر HTTP سفارشی ImOK است که مقدار آن YourOK است. اگر پاسخ مطابقت نداشته باشد، آنگاه با پیکربندی متعادل کننده بار، درخواست به عنوان یک شکست تلقی می شود.

HTTPMonitor از خدمات پشتیبان پیکربندی شده برای استفاده از پروتکل های HTTP و HTTPS یک طرفه پشتیبانی می کند. با این حال، موارد زیر را پشتیبانی نمی کند:

• HTTPS دو طرفه (که TLS/SSL دو طرفه نیز نامیده می شود)
• گواهی های خود امضا شده

توجه داشته باشید که تمام تنظیمات Request و Response در یک مانیتور HTTP مختص سرویس backend است که باید فراخوانی شود.

    <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 با عناصر پیکربندی HTTPMonitor

جدول زیر عناصر پیکربندی HTTPMonitor را توضیح می دهد: