برای تشخیص وضعیت یک 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 از مراحل و لاگهای استقرار شروع کنید.
خواندن 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 استفاده کنید.
دنبالکردن App eventها
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 مفید را پنهان کند.
بررسی مصرف runtime در Metrics
در Console، App را باز کنید و به Metrics بروید. این صفحه وضعیت فعلی و نمودار ۲۴ ساعت اخیر را برای این موارد نشان میدهد:
- مصرف CPU نسبت به ظرفیت plan
- حافظه مصرفشده نسبت به limit
- ترافیک ورودی و خروجی شبکه
- تعداد restartهای runtime
CLI فعلی command جداگانهای برای App metrics ندارد. برای مشاهده این نمودارها از Console استفاده کنید؛ API عمومی نیز endpointهای usage را در قرارداد OpenAPI تعریف میکند.
metric را همراه وضعیت App و ترافیک واقعی تفسیر کنید. CPU یا حافظه بالا بهتنهایی دلیل resize نیست: ابتدا بازه زمانی، restartها، errorها و الگوی درخواست را مقایسه کنید. اگر فشار پایدار و واقعی است، چرخه عمر و تغییر plan را ببینید.
تحلیل requestهای HTTP
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 گزارش کردهاند:
- در Analytics بازه رخداد را انتخاب و error rate و routeهای درگیر را مشخص کنید.
- در Metrics همان زمان را از نظر CPU، حافظه و restart بررسی کنید.
- runtime log را با
--sinceو یک--filterمحدود بخوانید. - App eventها و deploymentهای همان زمان را برای تغییر release یا state بررسی کنید.
- کوچکترین اصلاح ممکن را انجام دهید و همان چهار signal را دوباره مقایسه کنید.
این ترتیب کمک میکند قبل از restart، resize یا deploy دوباره، علت محتمل را با evidence محدود کنید.
نکات production
- log ساختیافته با timestamp، level و request ID تولید کنید.
- health endpoint را سبک نگه دارید و وابستگیهای حیاتی را جداگانه مشاهده کنید.
- قبل و بعد از هر deploy، error rate،
p95، restart و لاگ error را مقایسه کنید. - برای incident، timezone، بازه، App ID، deployment ID و پیام sanitizeشده را ثبت کنید.
- نبود داده را موفقیت فرض نکنید؛ وضعیت plan، فعالبودن قابلیت و بازه انتخابشده را بررسی کنید.