مانیتورینگ و لاگ‌گیری حرفه‌ای

۰۱مانیتورینگ و لاگ‌گیری: سه ستون مشاهده‌پذیری

مانیتورینگ به شما می‌گوید «مشکلی هست»؛ لاگ و ردیابی می‌گویند «چرا». این سه نوع داده هرکدام به پرسش دیگری جواب می‌دهند و جایگزین هم نیستند:

حتی برای یک اپلیکیشن تک‌سرور هم لاگ و چند متریک پایه ارزش دارد. ردیابی توزیع‌شده وقتی لازم می‌شود که با چند سرویس سروکار دارید؛ برای آن موقع معماری میکروسرویس‌ها را ببینید.

۰۲لاگ ساختاریافته که واقعاً به کار بیاید

لاگ متنی آزاد مثل «User logged in» برای چشم انسان خوب است اما جست‌وجو و تجمیع آن دردناک است. لاگ JSON با فیلدهای ثابت را می‌شود فیلتر کرد، شمرد و روی نمودار آورد:

{"time":"2026-10-27T03:12:08Z","level":"error","msg":"payment failed",
 "service":"checkout","request_id":"a1f9-77c2","user_id":7,
 "order_id":42,"duration_ms":2310,"error":"upstream timeout"}

ارزش شناسه‌ی درخواست

یک شناسه‌ی یکتا برای هر درخواست بسازید (یا از هدر ورودی بخوانید)، در همه‌ی لاگ‌ها بگذارید و به سرویس‌های پایین‌دست بفرستید. آن‌وقت یک جست‌وجو کل مسیر درخواست را نشان می‌دهد. نمونه‌ی ساده در Node.js با Express:

import { randomUUID } from "node:crypto";

app.use((req, res, next) => {
  req.id = req.headers["x-request-id"] || randomUUID();
  res.setHeader("x-request-id", req.id);
  const start = Date.now();
  res.on("finish", () => {
    console.log(JSON.stringify({
      time: new Date().toISOString(), level: "info", msg: "request",
      request_id: req.id, method: req.method, path: req.path,
      status: res.statusCode, duration_ms: Date.now() - start,
    }));
  });
  next();
});

در لاراول هم کانال‌های لاگ از پیش‌ساخته‌ای مثل stack و daily دارید و می‌توانید با Log::withContext(['request_id' => ...]) شناسه را به همه‌ی لاگ‌های همان درخواست اضافه کنید؛ جزئیات در مستندات لاراول آمده است.

۰۳سطح لاگ، حجم و حریم خصوصی

• error: چیزی شکست خورده و کسی باید نگاه کند. اگر هر روز صدها بار ظاهر شود، دیگر کسی آن را نمی‌خواند.
• warn: اتفاق غیرعادی که سیستم از آن عبور کرد، مثل retry موفق.
• info: رویدادهای کسب‌وکاری مهم و خلاصه‌ی هر درخواست.
• debug: جزئیات برای توسعه؛ در تولید به‌صورت پیش‌فرض خاموش یا نمونه‌برداری‌شده.

حجم لاگ هم هزینه دارد. لاگ‌های پرتکرار و کم‌ارزش (مثل health check هر ده ثانیه) را حذف یا نمونه‌برداری کنید و لاگ را به stdout بنویسید تا Docker یا پلتفرم آن را جمع کند؛ در دیپلوی با Docker این الگو توضیح داده شده است.

۰۴متریک‌هایی که ارزش اندازه‌گیری دارند

فهرست متریک‌های ممکن بی‌پایان است؛ با چهار «سیگنال طلایی» شروع کنید که برای هر سرویس درگاه‌محور صدق می‌کنند:

1. ترافیک: تعداد درخواست در ثانیه، به تفکیک مسیر.
2. خطا: نسبت پاسخ‌های ۵xx (و پاسخ‌های نادرست منطقی) به کل.
3. تأخیر: صدک‌های ۵۰، ۹۵ و ۹۹، نه میانگین؛ میانگین کندی تعداد کمی از کاربران را پنهان می‌کند.
4. اشباع: پر بودن CPU، حافظه، دیسک، اتصال‌های دیتابیس و طول صف‌ها.

به همین فهرست، متریک‌های کسب‌وکاری را اضافه کنید: سفارش‌های ثبت‌شده در ساعت یا ورودهای ناموفق. افت ناگهانی سفارش‌ها گاهی قبل از هر نمودار فنی مشکل را نشان می‌دهد. نرخ برخورد کش (cache hit ratio) هم برای کسی که از Redis استفاده می‌کند یکی از بهترین شاخص‌های سلامت است.

۰۵هشدار بدون نویز

هشداری که هر شب بیدارتان کند و نیازی به اقدام نداشته باشد، به‌زودی نادیده گرفته می‌شود. قاعده‌ی ساده: برای «علامت» هشدار بدهید، نه برای «علت». کاربر از بالا بودن CPU خبر ندارد؛ از خطا و کندی خبر دارد. نمونه‌ای با قالب قوانین Prometheus:

groups:
  - name: api
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
            / sum(rate(http_requests_total[5m])) > 0.05
        for: 10m
        labels:
          severity: page
        annotations:
          summary: "More than 5% of requests failed for 10 minutes"

• for: 10m جلوی هشدار برای جهش‌های لحظه‌ای را می‌گیرد.
• هر هشدار باید یک اقدام روشن داشته باشد؛ لینک یک runbook کوتاه را در توضیح بگذارید.
• هشدارهای فوری (بیدار کردن آدم) را از هشدارهای اطلاع‌رسانی (پیام در چت) جدا کنید.

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

۰۶چک‌لیست راه‌اندازی

• همه‌ی لاگ‌ها JSON هستند و شناسه‌ی درخواست و نام سرویس دارند.
• یک endpoint سلامت (مثلاً /health) وجود دارد که وابستگی‌های حیاتی را واقعاً بررسی می‌کند.
• چهار سیگنال طلایی روی یک داشبورد دیده می‌شوند.
• حداکثر چند هشدار فوری وجود دارد و هرکدام یک runbook دارد.
• اطلاعات حساس پاک‌سازی می‌شوند و مدت نگهداری لاگ مشخص است.
• یک‌بار فرایند را تمرین کنید: خطا را عمداً ایجاد کنید و ببینید هشدار می‌رسد و لاگ‌ها برای یافتن علت کافی‌اند.

اگر کند بودن بخشی از سایت را می‌بینید، پیش از هرچیز سراغ بهینه‌سازی سرعت بارگذاری صفحه بروید و داده‌ی واقعی کاربران را کنار متریک‌های سرور بگذارید. برای راه‌اندازی مانیتورینگ روی پروژه‌ی شما هم می‌توانید از تیم ما کمک بگیرید.