پایش، لاگ و ردیابی: دیدن آنچه در تولید میگذرد
مشتری زنگ میزند که «سایت کند است». باز میکنید، سریع است. چه میگویید؟
بدون داده، جواب حدس است. و حدسزدن در تولید، همان چیزی است که یک مشکل نیمساعته را به یک بحث دوروزه تبدیل میکند.
سه لایه، و اینکه هر کدام به چه سؤالی جواب میدهند
سنجهها میگویند چیزی اشتباه است. تعداد درخواست، زمان پاسخ، نرخ خطا، مصرف منابع. عدد در طول زمان، ارزان برای ذخیره، و مناسب برای هشدار.
لاگها میگویند چه اتفاقی افتاد. رویدادهای منفرد با جزئیات. گرانتر و مفصلتر.
ردیابی میگوید کجا. یک درخواست از پنج سرویس رد میشود و ردیابی نشان میدهد در کدام مرحله وقت رفته.
اگر یک سامانهٔ یکپارچه دارید، دو تای اول کافی است. ردیابی وقتی ضروری میشود که چند سرویس دارید و «کدامشان کند بود؟» جواب بدیهی ندارد.
لاگهایی که به درد میخورند
بیشتر سامانههایی که دیدهایم لاگ دارند و لاگشان بیفایده است. چند چیز که این را عوض میکند:
ساختاریافته بنویسید، نه جملهٔ آزاد. «سفارش ۱۲۳ برای مشتری ۴۵ ثبت شد» را نمیشود جستجو کرد؛ همان رویداد با فیلدهای مشخص را میشود فیلتر کرد، شمرد و نمودار کرد.
شناسهٔ درخواست بگذارید. یک شناسهٔ یکتا که از ابتدای درخواست تولید میشود و در همهٔ لاگهای مربوط به آن تکرار میشود. بدون آن، لاگهای ده کاربر همزمان در هم میروند و قابل تفکیک نیستند. ارزانترین کاری است که میشود کرد و بیشترین اثر را دارد.
سطحها را جدی بگیرید. اگر همهچیز ERROR باشد، هیچچیز ERROR نیست. خطا یعنی چیزی که کسی باید دربارهٔ آن کاری بکند.
دادهٔ حساس را ننویسید. رمز، توکن، شمارهٔ کارت، اطلاعات شخصی. لاگ معمولاً دسترسی بازتری از پایگاه داده دارد و مدت نگهداریاش هم روشن نیست. این را در محرمانگی داده هم دربارهٔ سامانههای هوش مصنوعی گفتهایم و اینجا عمومیتر است.
سنجههایی که واقعاً نگاه میشوند
مجموعهٔ کوچکی که برای بیشتر سامانهها کافی است:
نرخ درخواست، نرخ خطا، و زمان پاسخ در صدکهای بالا — نه میانگین. میانگین خوب میتواند پنج درصد کاربر با تجربهٔ افتضاح را پنهان کند.
منابع: پردازنده، حافظه، دیسک، و اتصالهای باز پایگاه داده.
و چند سنجهٔ کسبوکاری: تعداد سفارش در دقیقه، نرخ پرداخت موفق. اینها اغلب زودتر از سنجههای فنی به شما میگویند چیزی خراب شده — افت ناگهانی سفارش، سریعتر از هر هشدار فنی دیده میشود.
هشدار: کمتر، ولی واقعی
مسئلهٔ رایجتر از نداشتن هشدار، داشتن هشدار زیاد است. تیمی که روزی پنجاه هشدار میگیرد، هیچکدام را نمیخواند — و آن یکی که مهم بود هم گم میشود.
دو قاعده:
هشدار فقط برای چیزی که کسی باید همان لحظه کاری بکند. بقیه گزارشاند، نه هشدار.
هشدار روی نشانه، نه روی علت. «نرخ خطا بالا رفت» به درد میخورد؛ «مصرف حافظه از هفتاد درصد گذشت» معمولاً نه، چون شاید کاملاً عادی باشد.
و برای هر هشدار، یک راهنمای کوتاه: وقتی این آمد، اول چه چیزی را نگاه کنیم؟
عددی که بیشتر از خود خرابی اهمیت دارد
چقدر طول کشید تا فهمیدیم.
سامانهای که ده دقیقه پایین بود و در دقیقهٔ اول هشدار داد، وضعیت سالمتری دارد از سامانهای که دو ساعت پایین بود و مشتری خبر داد.
اگر یک عدد را میخواهید دنبال کنید، این باشد. مستقیم میگوید پایش شما کار میکند یا نه.
نگهداری و هزینه
لاگ حجم میگیرد و نگهداشتن همهچیز برای همیشه گران است. سیاست متعارف: لاگ خام برای مدت کوتاه، سنجههای خلاصه برای مدت طولانی.
و مراقب باشید ابزار پایش خودش به یک پروژه تبدیل نشود. برای سازمانی با یکی دو سامانه، نصب یک پشتهٔ کامل رصد معمولاً بیش از نیاز است — و ابزاری که کسی نگهش نمیدارد، خودش به بدهی تبدیل میشود.
اگر امروز چیزی ندارید
به ترتیب، اینها را اضافه کنید:
لاگ ساختاریافته با شناسهٔ درخواست. تقریباً رایگان و بیشترین اثر.
نرخ خطا و زمان پاسخ، با هشدار روی جهش ناگهانی.
یک صفحه که نشان دهد سامانه بالاست و اجزای اصلی جواب میدهند.
و بعد، اگر چند سرویس دارید، ردیابی.
بیشتر تیمها از انتها شروع میکنند — ابزار گران میخرند و لاگشان همچنان جملهٔ آزاد بدون شناسه است. آن ترتیب هزینه دارد و مسئله را حل نمیکند.