Logging و Observability

#Logs و metrics و traces: كل إشارة بتجاوب على إيه؟Logs, metrics and traces: different questions

«الدفع بطيء» مش تشخيص. محتاج تعرف حجم التأثير، وأنهي مرحلة اتأخرت، وتفاصيل الفشل. Observability هي قدرتك تستنتج حالة النظام الداخلية من إشاراته، مش مجرد تثبيت dashboard.

اربط الإشارات بـ service و environment و version و trace ID. مش كل trace هيتسجل مع sampling، وغياب error log مش دليل نجاح. Telemetry نفسها محتاجة limits و redaction ومراقبة export failures.

#Structured logging و LoggerMessage و SerilogStructured logging, LoggerMessage and Serilog

لو جمّعت log كـ string، البحث عن الطلبات اللي مبلغها أكبر من حد معين هيبقى parsing. Message template بتحفظ أسماء properties وقيمها لو الـ provider بيحافظ على structure. بلاش أسماء properties متغيرة لكل request.

logger.LogInformation($"Order {orderId} paid {amount}");

logger.LogInformation("Order {OrderId} paid {Amount}", orderId, amount);

using Microsoft.Extensions.Logging;

public static partial class OrderLog
{
    [LoggerMessage(EventId = 1001, Level = LogLevel.Information,
        Message = "Order {OrderId} paid {Amount}")]
    public static partial void Paid(
        ILogger logger, Guid orderId, decimal amount);     // (1)
}
// At the call site: OrderLog.Paid(logger, orderId, amount);

// Packages: Serilog.AspNetCore and Serilog.Sinks.Console
using Serilog;

builder.Host.UseSerilog((context, configuration) => configuration
    .MinimumLevel.Information()
    .Enrich.FromLogContext()
    .WriteTo.Console());                                  // (2)

ماتسجلش tokens أو passwords أو card data أو request body كاملة افتراضياً. ماتعملش log لنفس exception في كل طبقة؛ سجل عند boundary اللي بتتعامل مع نتيجتها.

#Log levels و scopes و correlationLog levels, scopes and correlation

W3C traceparent بيحمل version و trace ID و parent span ID و flags. كل span ليها ID مستقل، لكن spans الرحلة تشترك في trace ID. Correlation ID business ممكن يستمر عبر retries أو أيام، ومش لازم يساوي trace ID.

using System.Diagnostics;

using var scope = logger.BeginScope(new Dictionary<string, object?>
{
    ["OrderId"] = orderId,
    ["TraceId"] = Activity.Current?.TraceId.ToString() // (1)
});
logger.LogWarning("Payment confirmation is delayed"); // (2)

ASP.NET Core و HttpClient بيدعموا trace propagation، لكن broker messages محتاجة injection و extraction عبر instrumentation أو framework. متثقش في inbound correlation header كدليل هوية؛ حدّد الطول والـ format، وماتحطش أسرار في baggage.

#OpenTelemetry: instrumentation و OTLPOpenTelemetry instrumentation and OTLP

اربط كود التطبيق بـ standard instrumentation بدل backend معين. في .NET، ActivitySource بتنتج spans، و Meter بتنتج measurements. OpenTelemetry SDK تختار المصادر وتعمل processing و sampling و export. OTLP بروتوكول نقل، مش database ولا dashboard.

// Packages: OpenTelemetry.Extensions.Hosting, OpenTelemetry.Exporter.OpenTelemetryProtocol,
// OpenTelemetry.Instrumentation.AspNetCore, OpenTelemetry.Instrumentation.Http,
// OpenTelemetry.Instrumentation.Runtime
using OpenTelemetry;
using OpenTelemetry.Logs;
using OpenTelemetry.Metrics;
using OpenTelemetry.Resources;
using OpenTelemetry.Trace;

builder.Services.AddOpenTelemetry()
    .ConfigureResource(resource => resource.AddService("orders-api")) // (1)
    .WithTracing(tracing => tracing
        .AddAspNetCoreInstrumentation()
        .AddHttpClientInstrumentation()
        .AddSource("Shop.Checkout")
        .AddOtlpExporter())                                         // (2)
    .WithMetrics(metrics => metrics
        .AddAspNetCoreInstrumentation()
        .AddRuntimeInstrumentation()
        .AddMeter("Shop.Orders")
        .AddOtlpExporter());                                        // (3)
builder.Logging.AddOpenTelemetry(logging => logging.AddOtlpExporter()); // (4)

ظبط OTLP endpoint و protocol و TLS و authentication حسب collector؛ config شائعة هي OTEL_EXPORTER_OTLP_ENDPOINT. Collector يقدر يعمل batching و redaction و routing. حط queue limits وراقب dropped telemetry. Export مش ضمان تخزين، وماتعملش exporters مكررة لنفس signal من غير قصد.

#Custom spans و metrics من غير cardinality explosionCustom spans and bounded-cardinality metrics

HTTP span بتقول request خدت قد إيه، لكن مش بتشرح انتظار حجز المخزون. أضف span لخطوة business مهمة، و metric مجمعة لمدتها. ماتحطش order ID أو email كـ metric label: كل قيمة جديدة بتعمل time series وتكلفة.

using System.Diagnostics;
using System.Diagnostics.Metrics;

public static class OrderTelemetry
{
    public static readonly ActivitySource Source = new("Shop.Checkout");
    public static readonly Meter Meter = new("Shop.Orders");
    public static readonly Counter<long> Completed =
        Meter.CreateCounter<long>("orders.completed");           // (1)
    public static readonly Histogram<double> Duration =
        Meter.CreateHistogram<double>("orders.duration", "s"); // (2)
}

// Inside an async service method; ReserveAsync is an application operation.
using var activity = OrderTelemetry.Source.StartActivity("reserve-stock");
long started = Stopwatch.GetTimestamp();
try
{
    await ReserveAsync(ct);
    OrderTelemetry.Completed.Add(1);
}
catch (Exception ex)
{
    activity?.SetStatus(ActivityStatusCode.Error, ex.GetType().Name); // (3)
    throw;
}
finally
{
    OrderTelemetry.Duration.Record(
        Stopwatch.GetElapsedTime(started).TotalSeconds);          // (4)
}

خلي ActivitySource و Meter طويلة العمر، مش واحدة لكل request. Tags زي operation و outcome محدودة القيم مناسبة للـ metrics؛ IDs للتفاصيل في logs أو traces بعد privacy review. Sampling أول الرحلة أرخص، و tail sampling في collector يقدر يختار traces البطيئة أو الفاشلة مقابل buffering وتكلفة.

#RED و USE و histograms و percentilesRED, USE, histograms and percentiles

RED للخدمات: Rate و Errors و Duration. USE للموارد: Utilization و Saturation و Errors. CPU utilization عالية تختلف عن saturation: tasks منتظرة CPU أو connection pool queue ممكن تكشف bottleneck حتى قبل فشل الطلبات.

p95 معناها حوالي 95% من الملاحظات في النافذة أقل من أو تساوي القيمة. مش «95% من المستخدمين» بالضرورة. Average بتخبي tail latency، وماتجمعش p95 بتاعة كل instance بمتوسط؛ اجمع توزيعات compatible وبعدين احسب percentile.

Requests: 95 at 100 ms, 5 at 2000 ms                       // (1)
Mean: (95 * 100 + 5 * 2000) / 100 = 195 ms
Tail: five requests still take two seconds
SLO threshold: count requests <= 300 ms / eligible requests // (2)

#SLI و SLO و error budgets و alertsSLIs, SLOs, error budgets and alerts

SLI قياس تجربة الخدمة، زي نسبة checkout ناجحة من الطلبات المؤهلة. SLO هدف للقياس خلال نافذة، و SLA التزام تعاقدي ممكن يكون له تبعات. عرف النجاح والاستثناءات ومصدر القياس؛ 200 HTTP ممكن تخفي payment فشلت business-wise.

SLO: 99.9% successful eligible requests over 30 days
Budget fraction: 1 - 0.999 = 0.001                         // (1)
At 1,000,000 eligible requests: 1,000 failures allowed
Observed error ratio: 1% => burn rate = 0.01 / 0.001 = 10  // (2)

اعمل paging لأعراض قابلة للتصرف: فشل مستخدمين، و latency، و oldest message age، و burn rate سريع ومستمر. استخدم windows قصيرة وطويلة لتأكيد الفشل وتخفيف الضوضاء. Alert فيها owner و runbook و dashboard و action؛ CPU عالية وحدها غالباً signal للتحقيق أو capacity planning، مش page تلقائية.

Error budget توجه القرار: لو الاستهلاك عالي، قدم reliability work وتقليل مخاطرة deploys باتفاق الفريق، مش قاعدة عمياء لوقف كل تطوير.

#Liveness و readiness و startupLiveness, readiness and startup checks

Liveness بتسأل هل process محتاجة restart، و readiness هل ينفع تستقبل traffic دلوقتي، و startup بتدي وقت للتهيئة قبل تطبيق probes العادية حسب orchestrator. Restart مش هيصلح database خارجية وقعت؛ حط اعتمادها في readiness لو أساسي للخدمة.

using Microsoft.AspNetCore.Diagnostics.HealthChecks;
using Microsoft.Extensions.Diagnostics.HealthChecks;

builder.Services.AddHealthChecks()
    .AddCheck("self", () => HealthCheckResult.Healthy(), tags: ["live"])
    .AddCheck<DatabaseReadiness>("database", tags: ["ready"]); // (1)

// After builder.Build():
app.MapHealthChecks("/health/live", new HealthCheckOptions
{
    Predicate = registration => registration.Tags.Contains("live") // (2)
});
app.MapHealthChecks("/health/ready", new HealthCheckOptions
{
    Predicate = registration => registration.Tags.Contains("ready")
});

// Application check; IOrderStore is an injected database adapter.
public sealed class DatabaseReadiness(IOrderStore store) : IHealthCheck
{
    public async Task<HealthCheckResult> CheckHealthAsync(
        HealthCheckContext context, CancellationToken ct = default)
    {
        return await store.CanConnectAsync(ct)
            ? HealthCheckResult.Healthy()
            : HealthCheckResult.Unhealthy("Database unavailable"); // (3)
    }
}

ماتربطش readiness بكل dependency optional؛ ممكن تعمل إخراج جماعي لكل instances بدل degraded service مفيدة. حدد timeouts و probe frequency و failure thresholds عشان health checks ماتعملش حمل مؤذي.

#Production debugging وأدوات .NETProduction debugging and .NET diagnostics

ابدأ بالتأثير، مش اختيار أداة. لو users بتفشل دلوقتي، mitigation آمنة أهم من إكمال التحقيق قبل أي تصرف.

1. حدد مين متأثر، ونسبة الفشل، والتوقيت، والخدمات الحرجة؛ اختار rollback أو feature flag أو عزل dependency حسب الأدلة.
2. من metrics حدد endpoint و region و version، وقارن deploy أو traffic change.
3. افتح trace متأثرة وحدد critical path؛ راجع logs بنفس trace ID من غير أسرار.
4. اختبر hypothesis واحدة بأدلة مناسبة: CPU profile، أو thread stacks، أو heap retention.
5. أعد الإنتاج، واعمل regression test، وانشر fix تدريجياً وراقب نفس SLI.
6. وثّق timeline و contributing factors و actions بمالك وتاريخ؛ post-mortem من غير لوم.

# Tools must be installed; replace 1234 with the target process ID.
dotnet-counters monitor --process-id 1234 --counters System.Runtime
dotnet-trace collect --process-id 1234 --duration 00:00:30
dotnet-dump collect --process-id 1234 --output process.dmp
dotnet-dump analyze process.dmp

حدد collection window و disk budget و impact قبل dump؛ الملف ممكن يحتوي tokens وبيانات شخصية. ارتفاع heap مش دائماً leak؛ افحص retention و GC roots عبر الزمن. Thread count عالي وحده مش سبب كفاية لزيادة ThreadPool minimum.