تراز کردن بار در سرورهای زیرینه

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

‫Apigee Edge با ارائه پشتیبانی داخلی برای تراز کردن بار و انتقال خرابی در چندین نمونه سرور زیرینه، دردسترس بودن API شما را بهبود می‌بخشد.

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

تعریف «سرور هدف» از نام، میزبان، و درگاه تشکیل شده است و عنصر دیگری نیز دارد که نشان می‌دهد «سرور هدف» فعال است یا غیرفعال.

ویدیوها

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

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

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

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

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

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

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

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

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

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

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

$ 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، دو نشانی وب ارائه می‌کنید که 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 استفاده کند.

طبق آنچه در موضوع محدودیت‌ها مستند شده است، در هر محیط حداکثر ۵۰۰ «کارساز هدف» مجاز است.

پیکربندی TargetEndpoint برای تراز کردن بار در سراسر TargetServers نام‌گذاری‌شده

اکنون که دو 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 پشتیبانی می‌کند. «نوبت گردشی» الگوریتم پیش‌فرض است. ازآنجایی‌که در پیکربندی بالا هیچ الگوریتمی مشخص نشده است، درخواست‌های خروجی از پراکسی API به سرورهای زیرینه به‌صورت یک‌به‌یک بین هدف ۱ و هدف ۲ متناوب خواهد بود.

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

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

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

الگوریتم

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

دوره‌ای

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

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

وزن‌دهی‌شده

الگوریتم تراز بار وزنی به شما امکان می‌دهد بارهای ترافیکی متناسبی را برای «سرورهای هدف» خود پیکربندی کنید. «توزیع‌کننده بار» وزنی درخواست را به «سرورهای هدف» شما در تناسب مستقیم با وزن هر «سرور هدف» توزیع می‌کند. بنابراین، الگوریتم وزن‌دار از شما می‌خواهد برای هر «سرور هدف» یک مشخصه 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>

در این مثال، برای هر یک درخواست که به هدف۱ هدایت می‌شود، دو درخواست به هدف۲ هدایت می‌شود.

کمترین ارتباط

«توزیع‌کننده‌های بار» که برای استفاده از الگوریتم کمترین اتصال پیکربندی شده‌اند، درخواست‌های خروجی را به «سرور هدف» با کمترین اتصال 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‏ ۰ است. این یعنی Edge همیشه تلاش می‌کند برای هر درخواست به هدف متصل شود و هرگز سرور هدف را از چرخش برنمی‌دارد.

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

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

امتحان مجدد

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

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

<RetryEnabled>false</RetryEnabled>

IsFallback

یک (و فقط یک) 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>

پیکربندی بالا منجر به تراز بار چرخشی بین هدف‌های ۱ و ۲ می‌شود تا زمانی که هر دو هدف ۱ و ۲ دردسترس نباشند. وقتی هدف‌های ۱ و ۲ دردسترس نباشند، همه ترافیک به هدف ۳ هدایت می‌شود.

مسیر

«مسیر» قطعه‌ای از نشانی وب را تعریف می‌کند که به همه درخواست‌های صادرشده توسط TargetServer به سرور پشتیبان اضافه می‌شود.

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

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

درحال پیکربندی سرور هدف برای امنیت لایه انتقال/پوسته ایمن

اگر از TargetServer برای تعریف سرویس زیرینه استفاده می‌کنید و سرویس زیرینه نیاز دارد اتصال از پروتکل 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>

اگر سرویس زیرینه به 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>، به اطلاعات مربوط به تنظیم این ویژگی‌ها برای «میزبان مجازی» در پیکربندی دسترسی «امنیت لایه انتقال» به API برای «ابر خصوصی» مراجعه کنید.

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

طرح‌واره TargetServer

طرحواره TargetServer و دیگر نهادها را در GitHub ببینید.

پایش سلامت

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

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

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

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

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

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

وقتی پایش سلامت را فعال می‌کنید، Edge شروع به ارسال بررسی‌های سلامت به سرور مقصد شما می‌کند. بررسی سلامت درخواستی است که به سرور هدف ارسال می‌شود و مشخص می‌کند که سرور هدف سالم است یا نه.

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

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

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

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

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

فعال کردن HealthMonitor

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

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

TCPMonitor

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

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

می‌توانید 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 را شرح می‌دهد:

HTTPMonitor

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

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

• ‫HTTPS دوطرفه (که به آن TLS/SSL دوطرفه نیز گفته می‌شود)
• گواهینامه‌های خودامضا.

توجه داشته باشید که همه تنظیمات «درخواست» و «پاسخ» در پایشگر HTTP مختص سرویس کارساز پشتیبانی است که باید فراخوانی شود.

    <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 را شرح می‌دهد: