Loading documentation…
مانیتورینگ، لاگ و Analytics برنامه
لاگ runtime، رویدادها، مصرف CPU و حافظه و آمار درخواستهای HTTP برنامه ابران را بررسی و عیبیابی کنید.
آخرین بازبینی:
این صفحه مفید بود؟
بازخورد شما به بهترشدن مستندات کمک میکند.
لاگ runtime، رویدادها، مصرف CPU و حافظه و آمار درخواستهای HTTP برنامه ابران را بررسی و عیبیابی کنید.
آخرین بازبینی:
Loading documentation…
این صفحه مفید بود؟
بازخورد شما به بهترشدن مستندات کمک میکند.
برای تشخیص وضعیت یک App ابتدا باید signal درست را انتخاب کنید. خروجی deployment درباره build و release است؛ در مقابل، لاگها، eventها، metricها و Analytics رفتار برنامه در حال اجرا را از زاویههای متفاوت نشان میدهند.
| سؤال | بخش مناسب |
|---|---|
| build یا release چرا شکست خورد؟ | جزئیات و خروجی Deployment |
| process چه پیام یا خطایی نوشته است؟ | Logs |
| start، stop یا تغییر وضعیت چه زمانی رخ داده است؟ | Events |
| CPU، حافظه، شبکه یا restartها چه وضعی دارند؟ | Metrics |
| چند request رسیده و latency یا error rate چقدر است؟ | Analytics |
این signalها مکمل یکدیگرند. برای نمونه، افزایش error rate در Analytics را با زمان همان بازه در Logs و مصرف حافظه در Metrics مقایسه کنید.
ابتدا پروژه و App هدف را تأیید کنید:
abrun project current
abrun app inspect <app>سپس بدون تغییر state، eventها و لاگهای اخیر را بخوانید:
abrun app events <app> --tail 20
abrun app logs <app> --tail 100اگر مشکل هنگام build یا rollout رخ داده است، بهجای runtime log از مراحل و لاگهای استقرار شروع کنید.
برای گرفتن تعداد محدودی از خطهای اخیر:
abrun app logs <app> --tail 200بازه زمانی را با یک مقدار نسبی یا timestamp پشتیبانیشده محدود کنید:
abrun app logs <app> --since 30m --tail 200برای جستوجوی server-side از regular expression استفاده کنید:
abrun app logs <app> --since 1h --filter 'error|timeout|panic'هنگام بازتولید یک خطا، stream را باز نگه دارید:
abrun app logs <app> --followاگر container قبلی crash کرده است، لاگ instance قبلی میتواند علت را نگه داشته باشد:
abrun app logs <app> --previous --tail 200پیش از ذخیره یا فرستادن لاگ، token، cookie، password، connection URL و داده شخصی را حذف کنید. secret را در command جستوجو یا ticket پشتیبانی تکرار نکنید.
در Console نیز از صفحه App وارد Logs شوید. فیلتر سطح پیام در Console برای مرور خروجی نمایشدادهشده مفید است؛ برای automation و بازههای دقیق از CLI استفاده کنید.
eventها تغییرات عملیاتی resource را نشان میدهند و جای لاگ process را نمیگیرند. آخرین eventها را بخوانید:
abrun app events <app> --tail 20برای محدودکردن زمان یا دنبالکردن eventهای تازه:
abrun app events <app> --since 5h
abrun app events <app> --watchtimestamp، نوع event و پیام آن را با deploy یا تغییر تنظیمات همان زمان مقایسه کنید. اگر event به یک deployment اشاره میکند، جزئیات همان deployment را باز کنید؛ اجرای فوری deploy جدید ممکن است evidence مفید را پنهان کند.
در Console، App را باز کنید و به Metrics بروید. این صفحه وضعیت فعلی و نمودار ۲۴ ساعت اخیر را برای این موارد نشان میدهد:
CLI فعلی command جداگانهای برای App metrics ندارد. برای مشاهده این نمودارها از Console استفاده کنید؛ API عمومی نیز endpointهای usage را در قرارداد OpenAPI تعریف میکند.
metric را همراه وضعیت App و ترافیک واقعی تفسیر کنید. CPU یا حافظه بالا بهتنهایی دلیل resize نیست: ابتدا بازه زمانی، restartها، errorها و الگوی درخواست را مقایسه کنید. اگر فشار پایدار و واقعی است، چرخه عمر و تغییر plan را ببینید.
Analytics رفتار ترافیک HTTP را نشان میدهد، نه مصرف CPU و حافظه. این قابلیت باید در plan انتخابشده موجود و برای App فعال باشد. اگر plan آن را پشتیبانی نمیکند یا برای App غیرفعال است، Console داده Analytics را نمایش نمیدهد.
در Console، App را باز کنید و وارد Analytics شوید. بازههای فعلی عبارتاند از:
1h برای بررسی یک رخداد تازه24h برای الگوی روزانه7d برای مقایسه چند روزخلاصه و نمودارها شامل request، error، error rate، latencyهای p50 و p95 و حجم خروجی هستند. breakdownها را میتوان بر اساس route، host، method، status، status class، country، browser، سیستمعامل و نوع device بررسی کرد.
برای محدودکردن نتیجه، روی مقدار یک breakdown کلیک کنید. چند فیلتر میتوانند همزمان فعال باشند؛ هنگام مقایسه دو بازه، فیلترهای فعال را ثابت نگه دارید.
CLI فعلی command اختصاصی برای App Analytics ندارد. Console مسیر پیشنهادی است و endpointهای overview، series، breakdown و filter values در قرارداد عمومی API وجود دارند.
فرض کنید کاربران افزایش خطای 5xx گزارش کردهاند:
--since و یک --filter محدود بخوانید.این ترتیب کمک میکند قبل از restart، resize یا deploy دوباره، علت محتمل را با evidence محدود کنید.
p95، restart و لاگ error را مقایسه کنید.