APM چیست و چه چیزی را واقعاً نشان می‌دهد

تیم آرادتیم مهندسی

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

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

تراکنش، و چرا این واحدِ درست است

سنجه‌های معمولی سرور — مصرف پردازنده، حافظه، تعداد درخواست — واحدشان ماشین است. APM واحدش تراکنش است: یک درخواست HTTP، یک کار پس‌زمینه، یک فراخوان API.

تفاوت در عمل این است. سرور می‌گوید پردازنده ۴۰٪ است. APM می‌گوید:

POST /api/orders          ۲٫۴ ثانیه
  ├─ احراز هویت             ۱۲ms
  ├─ اعتبارسنجی سبد          ۳۱ms
  ├─ پرس‌وجوی موجودی      ۱٬۸۴۰ms   ← اینجا
  ├─ ثبت سفارش              ۹۴ms
  └─ فراخوان درگاه پرداخت   ۳۸۰ms

پردازندهٔ ۴۰ درصدی هیچ‌وقت این را به شما نمی‌گفت. سرور بیکار نشسته بود و منتظر پایگاه داده بود — و «سرور سالم است» فنی‌اش درست بود و عملاً بی‌ربط.

میانگین دروغ می‌گوید، بگذارید مشخص بگوییم چطور

فرض کنید ۱۰۰ درخواست دارید. ۹۵ تایشان ۱۰۰ میلی‌ثانیه طول می‌کشند و ۵ تایشان ۶ ثانیه. میانگین می‌شود ۳۹۵ میلی‌ثانیه — عددی که نه وضعیت آن ۹۵ نفر را توصیف می‌کند و نه وضعیت آن ۵ نفر را. هیچ کاربری «میانگین» را تجربه نمی‌کند.

به همین دلیل APM را با صدک می‌خوانند:

  • صدک ۵۰ (میانه): تجربهٔ کاربر معمولی
  • صدک ۹۵: جایی که شکایت‌ها از آن شروع می‌شود
  • صدک ۹۹: جایی که تیکت‌های عصبانی از آن می‌آید

اگر روزی صد هزار درخواست دارید، صدک ۹۹ یعنی هزار درخواست در روز. این «حالت استثنایی» نیست؛ این هزار نفر آدم است.

و یک نکتهٔ کوچک که زیاد اشتباه می‌شود: صدک‌ها را نمی‌شود میانگین گرفت. میانگینِ صدک ۹۵ِ ده سرور، صدک ۹۵ِ کل سامانه نیست. ابزار درست این را خودش حساب می‌کند؛ اگر شما دستی جمع می‌زنید، احتمالاً عدد اشتباهی دارید.

چه چیزی را پیدا می‌کند

الگوهایی که APM معمولاً در چند روز اول لو می‌دهد و تیم‌ها تا آن لحظه نمی‌دانستند:

مسئلهٔ N+1 — صفحه‌ای که به‌جای یک پرس‌وجو، ۲۰۰ تا می‌زند چون هر ردیف جداگانه واکشی می‌شود. تقریباً همیشه وجود دارد و تقریباً همیشه ارزان‌ترین چیزی است که می‌شود درست کرد. تفصیلش در کارایی پایگاه داده.

سرویس بیرونی کندی که کسی زمان‌سنجش نکرده: درگاه پرداخت، سرویس پیامک، سامانهٔ مؤدیان. وقتی آن کند می‌شود، برنامهٔ شما کند می‌شود و لاگ شما هیچ نمی‌گوید.

مسیرهایی که اصلاً فکر نمی‌کردید پرترافیک باشند — معمولاً یک نقطهٔ پایانی که اپلیکیشن موبایل هر ۳۰ ثانیه صدا می‌زند.

کارهای پس‌زمینه‌ای که از زمان‌بندی‌شان عقب افتاده‌اند؛ موضوعی که در کارهای پس‌زمینه و زمان‌بندی جدا نوشته‌ایم.

و چه چیزی را نشان نمی‌دهد

اینجا جایی است که انتظارها معمولاً غلط بسته می‌شود.

APM سمت سرور شماست. تجربهٔ کاربر را نمی‌بیند. اگر سرور در ۹۰ میلی‌ثانیه جواب بدهد و مرورگر پنج ثانیه طول بکشد تا صفحه را قابل استفاده کند، APM شما سبزِ سبز است. آن نیمهٔ دیگر کار RUM است.

APM «چرا» را هم نمی‌گوید، فقط «کجا» را. می‌گوید این پرس‌وجو ۱٫۸ ثانیه طول کشید؛ اینکه چون ایندکس ندارد یا چون قفل نشسته یا چون داده ده‌برابر شده، کار شماست.

و اگر معماری‌تان چند سرویس دارد، APMِ تک‌سرویس شما را گمراه می‌کند: هر سرویس می‌گوید «من سریع بودم» و مجموع کند است. آنجا به ردیابی توزیع‌شده نیاز دارید که اساساً همان ایدهٔ APM است، ولی از مرز سرویس‌ها رد می‌شود.

استاندارد، و چرا دیگر لازم نیست قفل شوید

تا چند سال پیش انتخاب APM یک تصمیم برگشت‌ناپذیر بود: عامل اختصاصی هر فروشنده در کد شما می‌نشست و مهاجرت یعنی ابزارگذاری دوباره.

حالا OpenTelemetry همان داده را به شکل استاندارد تولید می‌کند. ردیابی در بیشتر زبان‌ها پایدار است — یعنی این بخش، بخشی نیست که روی آن ریسک می‌کنید. یک‌بار ابزارگذاری، و مقصد قابل تعویض.

برای ما این تصمیمِ محکمی است، نه ترجیح سلیقه‌ای: سرویسی که امروز در دسترس است ممکن است فردا نباشد، و در آن روز چیزی که اهمیت دارد این است که عوض کردن مقصد یک تغییر پیکربندی باشد نه یک پروژهٔ سه‌ماهه.

گزینه‌ها

روی مقصد، دو مسیر عملی دارید. اگر می‌خواهید روی زیرساخت خودتان بماند، Prometheus سنجه‌ها را نگه می‌دارد و از نسخه‌های اخیر OTLP را هم مستقیم می‌پذیرد — با یک نکته که وقت زیادی از آدم‌ها گرفته: این گیرنده به‌صورت پیش‌فرض خاموش است و باید با --web.enable-otlp-receiver روشنش کنید.

اگر تمرکزتان روی خطاست نه کارایی، Sentry خودمیزبان ردیابی کارایی هم دارد. مجوزش FSL است — یعنی رایگان استفاده می‌کنید و بعد از دو سال هر نسخه Apache 2.0 می‌شود، ولی حق ندارید آن را به‌عنوان سرویس بفروشید.

مقایسهٔ کاملشان در پشته‌های سنجه و لاگ، کنار هم است.

از کجا شروع کنید

پنج مسیر پرترافیک‌تان را ابزارگذاری کنید، نه همه را. یک هفته صبر کنید. بعد صدک ۹۵ را مرتب کنید و به سه ردیف اول نگاه کنید.

تقریباً همیشه یکی از آن سه، چیزی است که تیم می‌گفت «آن که مشکلی ندارد». این لحظه — لحظه‌ای که حدس جای خودش را به داده می‌دهد — تمام ارزش APM است.

پروژه یا ایده‌ای دارید؟

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

مشاوره رایگان

پروژه‌تان را با هم بررسی کنیم

جلسهٔ اول رایگان است و معمولاً همان یک جلسه روشن می‌کند پروژه چقدر کار دارد.

چطور با شما تماس بگیریم؟

برای هماهنگی سریع‌تر — اگر تماس تلفنی را ترجیح نمی‌دهید، همان شماره را در پیام‌رسان پیام می‌دهیم.

راه دوم برای رساندن پاسخ — اگر تلفن در دسترس نبود، ایمیل می‌زنیم.

در حال ارسال…

درخواست شما ثبت شد.

همکاران ما پیام شما را می‌بینند و با شما تماس می‌گیرند.