پایش اپلیکیشن: از کجا میفهمید چه خبر است
سؤالی که پشت تلفن ساعت یازده شب پرسیده میشود همیشه یک شکل دارد: «سامانه کار نمیکند.» و جواب دادن به آن، بدون داده، یعنی حدس زدن.
اما «سامانه» یک چیز نیست. یک درخواست از انگشت کاربر تا پایگاه داده و برگشت، از چهار قلمرو مختلف عبور میکند که هر کدام صاحب، ابزار و زبان خودش را دارد. و تجربهٔ ما این است که بیشتر تیمها فقط یکی از این چهار را میبینند — معمولاً سرور — و بعد تعجب میکنند که چرا نمودارها سبزند و کاربر شاکی است.
این مقاله نقشه است، نه دستورالعمل. هر ایستگاهش مقالهٔ خودش را دارد.
چهار جایی که مشکل ظاهر میشود
اول یک تفکیک ساده، چون بدون آن بقیهٔ بحث قاطی میشود:
سرور. کد شما روی ماشین خودتان. اینجا لاگ، سنجه و ردیابی دارید و کنترل کامل. سه لایهٔ این قلمرو را در پایش و لاگ در محیط تولید نوشتهایم و اینجا تکرارش نمیکنیم.
مرورگر. کدی که روی دستگاه کسی اجرا میشود که شما هیچ کنترلی رویش ندارید — با اینترنت او، روی گوشی چهار سال پیشِ او. سرور میتواند در ۸۰ میلیثانیه جواب بدهد و صفحه شش ثانیه طول بکشد تا قابل استفاده شود.
اپلیکیشن موبایل. مثل مرورگر، با دو تفاوت مهم: نسخهای که کاربر دارد ممکن است سه ماه قدیمی باشد و شما نمیتوانید مجبورش کنید بهروز کند، و وقتی خراب میشود اپلیکیشن بسته میشود و هیچکس گزارش نمیدهد.
دستگاه. پایانه، سنسور، کیوسک، خودروی مجهز. جایی که اتصال قطع و وصل میشود و باتری تمام میکند.
قلمروها را که جدا کردید، بقیهاش مشخص میشود: هر کدام سؤال متفاوتی میپرسد.
هر سیگنال به چه سؤالی جواب میدهد
این جدول را اگر فقط همین را از این مقاله بردارید، کافی است:
| سؤال | سیگنالی که جواب میدهد |
|---|---|
| اصلاً بالاست؟ | پایش در دسترسبودن |
| کند است؟ کجایش؟ | APM |
| کاربر واقعی چه چیزی دید؟ | RUM |
| این درخواست از کجاها رد شد؟ | ردیابی توزیعشده |
| چرا افتاد؟ | گزارش خرابی |
| چرا نمیافتد ولی کار هم نمیکند؟ | ANR و فریز |
| این نسخه بهتر شد یا بدتر؟ | سلامت انتشار |
| دستگاههای میدانی چه حالی دارند؟ | پایش ناوگان IoT |
دقت کنید که هیچکدام جای دیگری را نمیگیرد. APM به شما نمیگوید کاربرِ روی اینترنت همراهِ ضعیف چه دید، و RUM به شما نمیگوید کدام پرسوجوی پایگاه داده کند است. تیمهایی که یک ابزار میخرند و انتظار دارند همهچیز را ببیند، معمولاً شش ماه بعد ابزار دوم را هم میخرند.
اشتباهی که تقریباً همه میکنند
سنجه را با تجربه اشتباه میگیرند.
میانگین زمان پاسخ سرور ۱۲۰ میلیثانیه است. عالی. حالا این را کنارش بگذارید: ۵٪ از کاربران شما روی اتصالی هستند که فقط برقراری ارتباط اولیهاش ۸۰۰ میلیثانیه طول میکشد، و صفحهای که برایشان میفرستید ۲.۳ مگابایت جاوااسکریپت دارد.
میانگین، بدترین تجربهها را پنهان میکند. همیشه. به همین دلیل است که در هر مقالهای از این مجموعه اصرار میکنیم به صدک ۹۵ و ۹۹ نگاه کنید نه به میانگین — چون آن ۱٪، در یک سامانه با روزی صد هزار درخواست، هزار نفر آدم است.
استانداردها: چرا اینبار واقعاً مهم است
سالها هر ابزار پایش، قالب داده و کتابخانهٔ خودش را داشت. یعنی انتخاب ابزار، انتخاب یکبارهٔ غیرقابلبرگشت بود: کد شما به آن ابزار گره میخورد.
OpenTelemetry این را عوض کرد. یکبار ابزارگذاری میکنید، و پشتِ صحنه هر مقصدی را که خواستید میگذارید. برای ما در ایران این فقط یک راحتی مهندسی نیست — با توجه به اینکه دسترسی به سرویسهای خارجی میتواند فردا قطع شود، تنها معماری عاقلانه همان است که مقصدش قابل تعویض باشد.
برای وب هم یک استاندارد واقعی وجود دارد: Core Web Vitals، که سه عدد مشخص را تعریف میکند و گوگل هم با همانها سایت شما را میسنجد. تفصیلش در مقالهٔ RUM.
گزینهها: خودمیزبان، رایگان، پولی
سه دسته وجود دارد و انتخاب بینشان در ایران شکل متفاوتی دارد:
خودمیزبان و متنباز. Prometheus برای سنجه، و Sentry برای خطا و خرابی. هزینهٔ مستقیمش صفر است ولی هزینهٔ واقعیاش سرور و آدم است — Sentry خودمیزبان برای راهاندازی حداقل ۴ هسته و ۱۶ گیگابایت رم بهعلاوهٔ ۱۶ گیگابایت swap میخواهد. این عدد را قبل از تصمیم ببینید، نه بعدش.
رایگانِ میزبانیشده. برای اپلیکیشن موبایل، AppMetrica حساب رایگان دارد و — برخلاف بیشتر رقبایش — از ایران قابل استفاده است. خرابی و ANR را روی اندروید و iOS جمع میکند و فایلهای نگاشت را هم سمت سرور رمزگشایی میکند.
پولی. بیشتر نامهای معروف این دسته از ایران نه قابل ثبتناماند و نه قابل پرداخت. صادقانهاش این است: توصیهشان به شما وقت تلف کردن است، هرچند ابزارهای خوبی باشند.
تصمیم بین دستهٔ اول و دوم را در پایش خودمیزبان در برابر ابری کامل باز کردهایم، چون این تصمیم برای ما شکل دیگری دارد تا برای یک تیم در برلین.
اگر امروز هیچ چیز ندارید
ترتیب پیشنهادی ما، بر اساس اینکه هر قدم چقدر درد کم میکند بهازای زحمتی که دارد:
۱. یک پایش در دسترسبودن ساده از بیرون. ده دقیقه کار دارد و اولین چیزی است که جلوی «دو ساعت بود سایت پایین بود و نفهمیدیم» را میگیرد.
۲. گزارش خرابی روی اپلیکیشن و روی سرور. چون خطاهایی که کاربر گزارش نمیدهد، بیشتر از خطاهایی هستند که گزارش میدهد.
۳. سنجههای پایه و هشدار روی چند تای معدود.
۴. بعد از اینها، و فقط بعد از اینها، سراغ ردیابی و RUM بروید.
ترتیب عمدی است. تیمی که از قدم چهار شروع میکند، شش ماه بعد داشبورد زیبایی دارد که کسی نگاهش نمیکند و هنوز نمیداند دیشب سرویس چند دقیقه پایین بوده.
یک هشدار دربارهٔ هزینه
پایش، داده تولید میکند و داده هزینه دارد. تیمهایی دیدهایم که صورتحساب ذخیرهٔ لاگشان از صورتحساب سرورِ خود برنامه بیشتر شده. این اتفاق تدریجی میافتد و کسی متوجهش نمیشود تا روزی که مالی سؤال میکند.
راهش پیچیده نیست: سطحبندی نگهداری، و اینکه از اول تصمیم بگیرید چه چیزی را نگه نمیدارید. در مدیریت متمرکز لاگ عددها و روشهایش هست.
پایش، پروژهای نیست که تمام شود. سامانهای که امروز کاملاً رصد میشود، شش ماه دیگر سه سرویس جدید دارد که هیچکدام ابزارگذاری نشدهاند. این کار، بخشی از نگهداری است و اگر صاحب مشخصی نداشته باشد، همیشه اولین چیزی است که از فهرست کارها میافتد بیرون.