نظارت بر سلامت می‌تواند اطلاعاتی در زمان واقعی در مورد وضعیت ظروف و ریزسرویس‌های شما فراهم کند. نظارت بر سلامت برای جنبه‌های مختلف میکروسرویس‌های عملیاتی حیاتی است و به‌ویژه زمانی مهم است که ارکستراتورها به‌روزرسانی‌های جزئی برنامه را در مراحل انجام دهند، همانطور که توضیح خواهیم داد.
برنامه‌های کاربردی مبتنی بر میکروسرویس‌ها اغلب از ضربان قلب یا بررسی‌های سلامتی استفاده می‌کنند تا مانیتورهای عملکرد، زمان‌بندی‌کننده‌ها و سازمان‌دهندگان خود را قادر به پیگیری تعداد زیادی از خدمات کنند. اگر سرویس‌ها نتوانند نوعی سیگنال «من زنده‌ام» را ارسال کنند، چه بر اساس تقاضا یا بر اساس برنامه، برنامه شما ممکن است در هنگام استقرار به‌روزرسانی‌ها با خطراتی مواجه شود، یا ممکن است خیلی دیر خرابی‌ها را تشخیص دهد و نتواند خرابی‌های آبشاری را متوقف کند. می تواند منجر به قطعی های عمده شود.
در مدل معمولی، سرویس‌ها گزارش‌هایی درباره وضعیت خود ارسال می‌کنند و این اطلاعات برای ارائه یک دید کلی از وضعیت سلامت برنامه شما جمع‌آوری می‌شوند. اگر از یک ارکستراتور استفاده می کنید، می توانید اطلاعات سلامتی را در اختیار گروه ارکستراتور خود قرار دهید تا خوشه بتواند مطابق با آن عمل کند. اگر روی گزارش‌دهی سلامت با کیفیت بالا که برای برنامه شما سفارشی شده است سرمایه‌گذاری می‌کنید، می‌توانید مشکلات برنامه در حال اجرا خود را خیلی راحت‌تر شناسایی و برطرف کنید.
بررسی های سلامت را در خدمات ASP.NET Core اجرا کنید
هنگام توسعه یک میکروسرویس یا برنامه وب ASP.NET Core، می توانید از ویژگی داخلی بررسی سلامتی که در ASP .NET Core 2.2 (Microsoft.Extensions.Diagnostics.HealthChecks) منتشر شده است استفاده کنید. مانند بسیاری از ویژگی‌های ASP.NET Core، بررسی‌های سلامت با مجموعه‌ای از خدمات و میان‌افزار همراه است.
استفاده از سرویس‌های بررسی سلامت و میان‌افزار آسان است و قابلیت‌هایی را ارائه می‌کند که به شما امکان می‌دهد اگر منبع خارجی مورد نیاز برای برنامه شما (مانند پایگاه داده SQL Server یا API راه دور) به درستی کار می‌کند، اعتبارسنجی کنید. هنگامی که از این ویژگی استفاده می کنید، همانطور که بعدا توضیح خواهیم داد، همچنین می توانید تصمیم بگیرید که سالم بودن منبع چیست.
برای استفاده موثر از این ویژگی، ابتدا باید سرویس ها را در میکروسرویس های خود پیکربندی کنید. دوم، شما به یک برنامه کاربردی front-end نیاز دارید که گزارش های سلامتی را درخواست کند. این برنامه جلویی می‌تواند یک برنامه گزارش‌دهی سفارشی باشد، یا می‌تواند خود یک ارکستراتور باشد که می‌تواند مطابق با وضعیت سلامت واکنش نشان دهد.
از ویژگی HealthChecks در ریزسرویس های ASP.NET خود استفاده کنید
در این بخش، نحوه پیاده سازی ویژگی HealthChecks را در یک نمونه برنامه ASP.NET Core 6.0 Web API در هنگام استفاده از بسته Microsoft.Extensions.Diagnostics.HealthChecks یاد خواهید گرفت. پیاده سازی این ویژگی در میکروسرویس های بزرگ مانند eShopOnContainers در بخش بعدی توضیح داده شده است.
برای شروع، باید مشخص کنید که چه چیزی یک وضعیت سالم برای هر میکروسرویس است. در برنامه نمونه، ما تعریف می کنیم که میکروسرویس در صورتی سالم است که API آن از طریق HTTP قابل دسترسی باشد و پایگاه داده SQL Server مربوط به آن نیز موجود باشد.
در NET 6، با API های داخلی، می توانید سرویس ها را پیکربندی کنید، یک بررسی سلامت برای میکروسرویس و پایگاه داده SQL Server وابسته به آن اضافه کنید:
// Startup.cs from .NET 6 Web API sample
//
public void ConfigureServices(IServiceCollection services)
{
//...
// Registers required services for health checks
services.AddHealthChecks()
// Add a health check for a SQL Server database
.AddCheck(
"OrderingDB-check",
new SqlConnectionHealthCheck(Configuration["ConnectionString"]),
HealthStatus.Unhealthy,
new string[] { "orderingdb" });
}
در کد قبلی، متد services.AddHealthChecks() یک چک HTTP اولیه را پیکربندی می‌کند که کد وضعیت 200 را با "سالم" برمی‌گرداند. علاوه بر این، متد افزونه AddCheck() یک SqlConnectionHealthCheck سفارشی را پیکربندی می کند که سلامت پایگاه داده SQL مربوطه را بررسی می کند.
متد AddCheck() یک بررسی سلامت جدید با یک نام مشخص و اجرای نوع IHealthCheck اضافه می کند. با استفاده از روش AddCheck می‌توانید چندین بررسی سلامت اضافه کنید، بنابراین یک میکروسرویس تا زمانی که همه چک‌هایش سالم نباشند، وضعیت «سالم» را ارائه نمی‌کنند.
SqlConnectionHealthCheck یک کلاس سفارشی است که IHealthCheck را پیاده سازی می کند، که یک رشته اتصال را به عنوان پارامتر سازنده می گیرد و یک کوئری ساده برای بررسی موفقیت آمیز بودن اتصال به پایگاه داده SQL اجرا می کند. اگر کوئری با موفقیت اجرا شود، HealthCheckResult.Healthy را برمی‌گرداند و وضعیت FailureStatus را با استثنای واقعی زمانی که شکست می‌خورد، برمی‌گرداند.
// Sample SQL Connection Health Check
public class SqlConnectionHealthCheck : IHealthCheck
{
private const string DefaultTestQuery = "Select 1";
public string ConnectionString { get; }
public string TestQuery { get; }
public SqlConnectionHealthCheck(string connectionString)
: this(connectionString, testQuery: DefaultTestQuery)
{
}
public SqlConnectionHealthCheck(string connectionString, string testQuery)
{
ConnectionString = connectionString ?? throw new ArgumentNullException(nameof(connectionString));
TestQuery = testQuery;
}
public async Task<HealthCheckResult> CheckHealthAsync(HealthCheckContext context, CancellationToken cancellationToken = default(CancellationToken))
{
using (var connection = new SqlConnection(ConnectionString))
{
try
{
await connection.OpenAsync(cancellationToken);
if (TestQuery != null)
{
var command = connection.CreateCommand();
command.CommandText = TestQuery;
await command.ExecuteNonQueryAsync(cancellationToken);
}
}
catch (DbException ex)
{
return new HealthCheckResult(status: context.Registration.FailureStatus, exception: ex);
}
}
return HealthCheckResult.Healthy();
}
}
توجه داشته باشید که در کد قبلی Select 1 کوئری است که برای بررسی سلامت پایگاه داده استفاده می شود. برای نظارت بر در دسترس بودن میکروسرویس‌های شما، ارکسترهایی مانند Kubernetes به طور دوره‌ای با ارسال درخواست‌هایی برای آزمایش میکروسرویس‌ها، بررسی‌های سلامتی را انجام می‌دهند. این مهم است که جستجوهای پایگاه داده خود را کارآمد نگه دارید تا این عملیات سریع باشد و منجر به استفاده بیشتر از منابع نشود.
در نهایت، یک میان افزار اضافه کنید که به مسیر url /hc پاسخ می دهد:
// Startup.cs from .NET 6 Web Api sample
//
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
//…
app.UseEndpoints(endpoints =>
{
//...
endpoints.MapHealthChecks("/hc");
//...
});
//…
}
هنگامی که نقطه پایانی <yourmicroservice>/hc فراخوانی می شود، تمام بررسی های سلامتی که در متد AddHealthChecks() در کلاس Startup پیکربندی شده اند را اجرا می کند و نتیجه را نشان می دهد.
اجرای HealthChecks در eShopOnContainers
میکروسرویس ها در eShopOnContainers برای انجام وظایف خود به چندین سرویس متکی هستند. به عنوان مثال، ریزسرویس Catalog.API از eShopOnContainers به بسیاری از خدمات مانند Azure Blob Storage، SQL Server و RabbitMQ بستگی دارد. بنابراین، چندین بررسی سلامت با استفاده از روش AddCheck() اضافه شده است. برای هر سرویس وابسته، یک پیاده سازی سفارشی IHealthCheck که وضعیت سلامت مربوطه آن را تعریف می کند باید اضافه شود.
پروژه منبع باز AspNetCore.Diagnostics.HealthChecks این مشکل را با ارائه پیاده سازی های بررسی سلامت سفارشی برای هر یک از این سرویس های سازمانی که بر روی .NET 6 ساخته شده اند، حل می کند. به پروژه اضافه شد. eShopOnContainers به طور گسترده از آنها در تمام ریزسرویس های خود استفاده می کند.
در کد زیر، اجرای بررسی سلامت برای هر سرویس وابسته اضافه شده و سپس میان افزار پیکربندی شده است:
// Startup.cs from Catalog.api microservice
//
public static IServiceCollection AddCustomHealthCheck(this IServiceCollection services, IConfiguration configuration)
{
var accountName = configuration.GetValue<string>("AzureStorageAccountName");
var accountKey = configuration.GetValue<string>("AzureStorageAccountKey");
var hcBuilder = services.AddHealthChecks();
hcBuilder
.AddSqlServer(
configuration["ConnectionString"],
name: "CatalogDB-check",
tags: new string[] { "catalogdb" });
if (!string.IsNullOrEmpty(accountName) && !string.IsNullOrEmpty(accountKey))
{
hcBuilder
.AddAzureBlobStorage(
$"DefaultEndpointsProtocol=https;AccountName={accountName};AccountKey={accountKey};EndpointSuffix=core.windows.net",
name: "catalog-storage-check",
tags: new string[] { "catalogstorage" });
}
if (configuration.GetValue<bool>("AzureServiceBusEnabled"))
{
hcBuilder
.AddAzureServiceBusTopic(
configuration["EventBusConnection"],
topicName: "eshop_event_bus",
name: "catalog-servicebus-check",
tags: new string[] { "servicebus" });
}
else
{
hcBuilder
.AddRabbitMQ(
$"amqp://{configuration["EventBusConnection"]}",
name: "catalog-rabbitmqbus-check",
tags: new string[] { "rabbitmqbus" });
}
return services;
}
در نهایت، میان افزار HealthCheck را برای گوش دادن به نقطه پایانی “/hc” اضافه کنید:
// HealthCheck middleware
app.UseHealthChecks("/hc", new HealthCheckOptions()
{
Predicate = _ => true,
ResponseWriter = UIResponseWriter.WriteHealthCheckUIResponse
});
از میکروسرویس های خود پرس و جو کنید تا وضعیت سلامتی آنها را گزارش کنید
هنگامی که بررسی های سلامت را همانطور که در این مقاله توضیح داده شده پیکربندی کرده اید و میکروسرویس را در Docker اجرا می کنید، می توانید مستقیماً از یک مرورگر سالم بودن آن را بررسی کنید. همانطور که در شکل 8-8 نشان داده شده است، باید پورت کانتینر را در میزبان Docker منتشر کنید، بنابراین می توانید از طریق IP میزبان خارجی داکر یا از طریق host.docker.internal به کانتینر دسترسی داشته باشید.
ریزسرویس Catalog.API (که روی پورت 5101 اجرا می‌شود) سالم است و وضعیت HTTP 200 و اطلاعات وضعیت را در JSON برمی‌گرداند. این سرویس همچنین سلامت وابستگی پایگاه داده SQL Server و RabbitMQ خود را بررسی کرد، بنابراین بررسی سلامت خود را سالم گزارش کرد.
از سگ های نگهبان استفاده کنید
Watchdog یک سرویس جداگانه است که می‌تواند سلامتی را تماشا کند و سرویس‌ها را بارگذاری کند، و سلامت میکروسرویس‌ها را با پرس و جو در کتابخانه HealthChecks که قبلاً معرفی شد، گزارش کند. این می تواند به جلوگیری از خطاهایی که بر اساس نمای یک سرویس شناسایی نمی شوند کمک کند. Watchdogs همچنین مکان خوبی برای میزبانی کد است که می تواند اقدامات اصلاحی را برای شرایط شناخته شده بدون تعامل کاربر انجام دهد.
نمونه eShopOnContainers حاوی یک صفحه وب است که نمونه گزارش های بررسی سلامت را نمایش می دهد، این ساده ترین نگهبانی است که می توانید داشته باشید زیرا فقط وضعیت میکروسرویس ها و برنامه های کاربردی وب را در eShopOnContainers نشان می دهد. معمولاً یک نگهبان زمانی که وضعیت های ناسالم را تشخیص می دهد اقداماتی را انجام می دهد.
خوشبختانه، AspNetCore.Diagnostics.HealthChecks همچنین بسته NuGet AspNetCore.HealthChecks.UI را ارائه می دهد که می تواند برای نمایش نتایج بررسی سلامت از URI های پیکربندی شده استفاده شود.
به طور خلاصه، این سرویس ناظر، نقطه پایانی "/hc" هر میکروسرویس را پرس و جو می کند. این همه بررسی های بهداشتی تعریف شده در آن را انجام می دهد و بسته به همه آن بررسی ها وضعیت سلامت کلی را برمی گرداند. HealthChecksUI با چند ورودی پیکربندی و دو خط کد که باید به Startup.cs سرویس Watchdog اضافه شود، آسان است.
نمونه فایل پیکربندی برای رابط کاربری بررسی سلامت:
// Configuration
{
"HealthChecksUI": {
"HealthChecks": [
{
"Name": "Ordering HTTP Check",
"Uri": "http://host.docker.internal:5102/hc"
},
{
"Name": "Ordering HTTP Background Check",
"Uri": "http://host.docker.internal:5111/hc"
},
//...
]}
}
فایل Startup.cs که HealthChecksUI را اضافه می کند:
// Startup.cs from WebStatus(Watch Dog) service
//
public void ConfigureServices(IServiceCollection services)
{
//…
// Registers required services for health checks
services.AddHealthChecksUI();
}
//…
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
//…
app.UseHealthChecksUI(config => config.UIPath = "/hc-ui");
//…
}
بررسی های بهداشتی هنگام استفاده از ارکستر
برای نظارت بر در دسترس بودن میکروسرویس‌های خود، ارکسترهایی مانند Kubernetes و Service Fabric به طور دوره‌ای با ارسال درخواست‌هایی برای آزمایش میکروسرویس‌ها، بررسی‌های سلامتی را انجام می‌دهند. هنگامی که یک ارکستر تشخیص می دهد که یک سرویس/کانتینر ناسالم است، درخواست مسیریابی به آن نمونه را متوقف می کند. همچنین معمولاً یک نمونه جدید از آن ظرف ایجاد می کند.
به عنوان مثال، اکثر ارکسترها می‌توانند از بررسی‌های سلامتی برای مدیریت استقرار بدون توقف استفاده کنند. تنها زمانی که وضعیت سرویس/کانتینر به سالم تغییر کند، ارکستراتور شروع به مسیریابی ترافیک به نمونه‌های سرویس/کانتینر می‌کند.
نظارت بر سلامت به ویژه زمانی مهم است که یک ارکستر برنامه ارتقاء برنامه را انجام دهد. برخی از ارکستراتورها (مانند Azure Service Fabric) خدمات را در مراحل به روز می کنند - برای مثال، ممکن است یک پنجم سطح کلاستر را برای هر ارتقاء برنامه به روز کنند. مجموعه ای از گره هایی که همزمان ارتقا می یابند به عنوان دامنه ارتقاء نامیده می شوند. پس از ارتقاء هر دامنه ارتقاء و در دسترس بودن آن برای کاربران، آن دامنه ارتقاء دهنده باید قبل از اینکه استقرار به دامنه ارتقاء بعدی منتقل شود، بررسی های سلامت را انجام دهد.
یکی دیگر از جنبه های سلامت خدمات، گزارش معیارها از خدمات است. این یک قابلیت پیشرفته از مدل سلامتی برخی ارکسترها مانند Service Fabric است. معیارها هنگام استفاده از یک ارکستر مهم هستند زیرا برای متعادل کردن استفاده از منابع استفاده می شوند. معیارها همچنین می توانند نشانگر سلامت سیستم باشند. برای مثال، ممکن است برنامه‌ای داشته باشید که ریزسرویس‌های زیادی دارد و هر نمونه یک معیار درخواست در ثانیه (RPS) را گزارش می‌کند. اگر یک سرویس از منابع بیشتری (حافظه، پردازنده و غیره) نسبت به سرویس دیگر استفاده می‌کند، ارکستراتور می‌تواند نمونه‌های سرویس را در خوشه جابجا کند تا سعی کند استفاده از منابع را حفظ کند.
توجه داشته باشید که Azure Service Fabric مدل مانیتورینگ سلامت خود را ارائه می‌کند که از بررسی‌های ساده سلامت پیشرفته‌تر است.
نظارت پیشرفته: تجسم، تجزیه و تحلیل و هشدارها
بخش پایانی نظارت، تجسم جریان رویداد، گزارش عملکرد سرویس و هشدار در هنگام شناسایی مشکل است. برای این جنبه از نظارت می توانید از راه حل های مختلفی استفاده کنید.
می‌توانید از برنامه‌های سفارشی ساده استفاده کنید که وضعیت خدمات شما را نشان می‌دهند، مانند صفحه سفارشی که هنگام توضیح AspNetCore.Diagnostics.HealthChecks نشان داده شده است. یا می توانید از ابزارهای پیشرفته تری مانند Azure Monitor برای افزایش هشدارها بر اساس جریان رویدادها استفاده کنید.
در نهایت، اگر تمام جریان‌های رویداد را ذخیره می‌کنید، می‌توانید از Microsoft Power BI یا راه‌حل‌های دیگری مانند Kibana یا Splunk برای تجسم داده‌ها استفاده کنید.