متریک و هشدار (Metrics و Alert)

مشکل: اول مشتری خبردار می‌شود، بعد ما

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

لاگ و Trace داشتیم. پس مشکل کجا بود؟

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

پس دو چیز لازم داریم: عددهای خلاصه درباره حال سیستم، و هشداری که خودش ما را خبر کند.

متریک چیست؟

متریک یک عدد است که در طول زمان اندازه می‌گیریم. مثلاً تعداد سفارش در دقیقه، درصد خطای پرداخت یا زمان پاسخ API. هر متریک می‌تواند چند برچسب (Label) هم داشته باشد، مثل روش پرداخت یا کد وضعیت HTTP.

هزینه متریک ثابت می‌ماند، چون برنامه هر درخواست را جدا ذخیره نمی‌کند. فقط یک شمارنده را یکی زیاد می‌کند. برای همین متریک بهترین پایه برای داشبورد و هشدار است.

سه نوع اصلی متریک

1. شمارنده (Counter). فقط بالا می‌رود. مثل تعداد کل سفارش‌ها. خود عدد مهم نیست. سرعت تغییرش مهم است، مثلاً سفارش در ثانیه.
2. گیج (Gauge). یک مقدار لحظه‌ای که بالا و پایین می‌رود. مثل تعداد پیام‌های داخل صف یا حافظه مصرفی.
3. هیستوگرام (Histogram). مقدارها را در چند سطل (Bucket) می‌شمارد. مثلاً چند درخواست زیر ۱۰۰ میلی‌ثانیه، چند تا زیر ۵۰۰ میلی‌ثانیه و همین‌طور تا آخر. با هیستوگرام می‌شود صدک‌ها را حساب کرد.

میانگین دروغ می‌گوید

فرض کن از صد درخواست پرداخت، ۹۵ تا سریع هستند و ۵ تا چند ثانیه طول می‌کشند. میانگین زمان پاسخ خوب به نظر می‌رسد. ولی پنج مشتری از هر صد نفر، چند ثانیه منتظر مانده‌اند.

صدک ۹۹ (p99) یعنی ۹۹ درصد درخواست‌ها از این عدد سریع‌تر بودند. برای زمان پاسخ معمولاً صدک ۵۰، ۹۵ و ۹۹ را نگاه می‌کنیم. در سیستم پرترافیک، یک درصد یعنی هزاران مشتری در روز.

کد: متریک در .NET

خود ASP.NET Core و HttpClient از .NET 8 به بعد متریک‌های آماده دارند. مثلاً متریک http.server.request.duration یک هیستوگرام از زمان پاسخ همه درخواست‌ها است. فقط باید آن‌ها را جمع کنیم و بیرون بدهیم.

برای عددهای کسب‌وکار، متریک خودمان را با کلاس Meter می‌سازیم. رابط IMeterFactory آن را از DI می‌دهد:

public sealed class ShopMetrics
{
    public const string MeterName = "Shop.Orders";

    private readonly Counter<long> _ordersPlaced;
    private readonly Histogram<double> _paymentDuration;

    public ShopMetrics(IMeterFactory meterFactory)
    {
        var meter = meterFactory.Create(MeterName);
        _ordersPlaced = meter.CreateCounter<long>("shop.orders.placed");
        _paymentDuration = meter.CreateHistogram<double>("shop.payment.duration", unit: "s");
    }

    public void OrderPlaced(string paymentMethod) =>
        _ordersPlaced.Add(1, new KeyValuePair<string, object?>("payment.method", paymentMethod));

    public void PaymentFinished(TimeSpan elapsed) =>
        _paymentDuration.Record(elapsed.TotalSeconds);
}

حالا با OpenTelemetry همه متریک‌ها را در آدرس metrics برای Prometheus باز می‌کنیم:

builder.Services.AddSingleton<ShopMetrics>();

builder.Services.AddOpenTelemetry()
    .ConfigureResource(r => r.AddService("orders-api"))
    .WithMetrics(metrics => metrics
        .AddAspNetCoreInstrumentation()
        .AddHttpClientInstrumentation()
        .AddMeter(ShopMetrics.MeterName)
        .AddPrometheusExporter());

var app = builder.Build();
app.MapPrometheusScrapingEndpoint();   // exposes /metrics

جریان داده: Prometheus و Grafana

1. برنامه عددهای فعلی را در آدرس metrics نشان می‌دهد.
2. ابزار Prometheus در فاصله‌های ثابت این آدرس را از همه نسخه‌ها می‌خواند (Scrape) و عددها را با زمانشان ذخیره می‌کند.
3. ابزار Grafana با زبان PromQL از Prometheus سؤال می‌پرسد و نمودار می‌کشد.
4. ابزار Prometheus قانون‌های هشدار را مدام بررسی می‌کند. اگر قانونی برقرار شد، آن را به Alertmanager می‌دهد. Alertmanager هشدارهای مشابه را گروه می‌کند و به آدم درست می‌فرستد.

دو سؤال رایج با PromQL. اسم متریک‌ها در Prometheus کمی عوض می‌شود: نقطه به خط زیر تبدیل می‌شود و واحد به آخر اسم اضافه می‌شود.

# Requests per second that ended with a 5xx status, over the last 5 minutes
sum(rate(http_server_request_duration_seconds_count{http_response_status_code=~"5.."}[5m]))

# p99 response time of the checkout endpoint
histogram_quantile(0.99,
  sum by (le) (rate(http_server_request_duration_seconds_bucket{http_route="/checkout"}[5m])))

چه چیزی را اندازه بگیریم؟

برای هر سرویس، سه عدد اصلی را بگیر. به این روش RED می‌گویند:

1. تعداد درخواست (Rate). چند درخواست در ثانیه می‌آید؟
2. خطا (Errors). چند درصد آن‌ها خطا می‌دهند؟
3. زمان (Duration). صدک‌های زمان پاسخ چقدر است؟

برای منابع، مثل CPU، حافظه، صف و Connection Pool، میزان پر بودن (Saturation) هم مهم است. مثلاً اگر Connection Pool دیتابیس همیشه پر است، به زودی درخواست‌ها منتظر می‌مانند.

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

هشدار خوب

هشدار یعنی بیدار کردن یک آدم. پس هر هشدار باید ارزش آن را داشته باشد:

1. روی درد کاربر، نه روی علت. «درصد خطای پرداخت بالا است» درد کاربر است. «CPU هشتاد درصد است» شاید هیچ دردی نداشته باشد.
2. کمی صبر کن. یک جهش چند ثانیه‌ای ارزش بیدار کردن کسی را ندارد. در Prometheus با بخش for می‌گوییم شرط باید مدتی پشت سر هم برقرار بماند.
3. قابل اقدام باشد. کسی که هشدار را می‌گیرد، باید بداند چه کند. یک لینک به راهنمای رفع مشکل (Runbook) کنار هشدار بگذار.
4. سطح داشته باشد. فقط مشکل فوری باید آدم را بیدار کند. بقیه می‌توانند یک تیکت یا پیام در چت تیم باشند.

ببین بخش for در عمل چه می‌کند:

همان قانون در Prometheus این شکل را دارد:

groups:
  - name: payments
    rules:
      - alert: PaymentErrorRateHigh
        expr: |
          sum(rate(http_server_request_duration_seconds_count{http_route="/pay", http_response_status_code=~"5.."}[5m]))
            /
          sum(rate(http_server_request_duration_seconds_count{http_route="/pay"}[5m]))
            > 0.05
        for: 5m
        labels:
          severity: page
        annotations:
          summary: "More than 5% of payments fail"
          runbook_url: "https://wiki.example.com/runbooks/payment-errors"

اشتباه‌های رایج