# مانیتورینگ آپ‌تایم

> https://docs.errora.org/products/uptime

مانیتور آپ‌تایم یک آدرس را در بازه‌های ثابت از سمت ارورا صدا می‌زند، دربارهٔ پاسخ شرطی را
بررسی می‌کند و وقتی شرط به‌اندازهٔ کافی نقض شود، خطا باز می‌کند.

برخلاف بقیهٔ محصولات، این یکی **هیچ SDKای نمی‌خواهد** — همه‌چیزش در خود ارورا تنظیم می‌شود.

## ساخت مانیتور

**آپ‌تایم ← مانیتور جدید**، یا از راه API:

```bash
curl -X POST "$ERRORA/api/v1/projects/$PROJECT_ID/uptime-monitors" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "name": "Checkout API",
        "url": "https://api.example.com/healthz",
        "method": "GET",
        "interval_seconds": 300,
        "timeout_ms": 10000,
        "environment": "production",
        "headers": [["Authorization", "Bearer …"]],
        "body": "",
        "expected_status_codes": [200, 204],
        "body_match": "\"status\":\"ok\"",
        "downtime_threshold": 3,
        "recovery_threshold": 1,
        "trace_sampling": false
      }'
```

### فیلدها

| فیلد | معنی |
| --- | --- |
| `url` | آدرسی که آزموده می‌شود. ریدایرکت‌ها یکی‌یکی و با اعتبارسنجی دنبال می‌شوند. |
| `method` | `GET`، `POST`، `HEAD` و … |
| `headers` | فهرستی از زوج‌های `[نام, مقدار]` — توکن احراز هویت، هدر Host دلخواه |
| `body` | بدنهٔ درخواست برای بررسی‌های `POST`/`PUT` |
| `interval_seconds` | `60`، `300`، `600`، `1200`، `1800` یا `3600` (یک دقیقه تا یک ساعت) |
| `timeout_ms` | پیش‌فرض `10000`، حداکثر `60000` |
| `expected_status_codes` | خالی یعنی «هر کد ۲xx». در غیر این صورت فهرست مجاز صریح. |
| `body_match` | زیررشته‌ای که باید در بدنهٔ پاسخ باشد |
| `downtime_threshold` | تعداد شکست پشت‌سرهم تا مانیتور *قطع* اعلام شود (پیش‌فرض `3`) |
| `recovery_threshold` | تعداد موفقیت پشت‌سرهم تا دوباره *وصل* شود (پیش‌فرض `1`) |
| `environment` | خطا و هشدارهای حاصل را برچسب می‌زند |
| `trace_sampling` | پیوست‌کردن ترِیس به هر بررسی (وقتی مقصد سرویس ابزارگذاری‌شدهٔ خودتان است مفید است) |
| `is_muted` | بررسی ادامه دارد ولی هشدار فرستاده نمی‌شود |

## شکست یعنی چه

یک بررسی وقتی شکست می‌خورد که خطای اتصال بدهد، تایم‌اوت شود، کد وضعیت غیرمنتظره برگرداند یا
`body_match` در پاسخ نباشد. دلیل شکست به ازای هر بررسی ثبت می‌شود، پس در تاریخچه «اتصال رد
شد» از «کد ۵۰۰ برگشت» و «شرط بدنه برقرار نبود» جدا دیده می‌شود.

پس از `downtime_threshold` شکست پشت‌سرهم، مانیتور **قطع** می‌شود: ارورا یک **خطای قطعی** برای
پروژه باز می‌کند و رویداد هشدار `uptime.down` را فعال می‌کند. پس از `recovery_threshold`
موفقیت، دوباره **وصل** می‌شود، خطا را می‌بندد و `uptime.up` را فعال می‌کند.

## در پنل

صفحهٔ **آپ‌تایم** مانیتورها را با وضعیت فعلی، درصد در دسترس بودن و بررسی‌های اخیر نشان می‌دهد.
با باز کردن یکی، تاریخچهٔ بررسی‌ها (کد وضعیت، زمان پاسخ، دلیل شکست)، آمار و دکمهٔ **بررسی
همین حالا** را دارید که بدون منتظرماندن برای زمان‌بندی، یک آزمون فوری اجرا می‌کند.

## هشدارها

رویدادهای `uptime.down` و `uptime.up` را در **تنظیمات ← وب‌هوک‌ها** به تلگرام، بله،
Mattermost، ایمیل، پیامک یا وب‌هوک وصل کنید — نگاه کنید به [هشدارها](/products/alerts).

## ارورا به چه چیزی دسترسی دارد

بررسی‌ها از سرورهای خود ارورا اجرا می‌شوند، نه از داخل شبکهٔ شما؛ پس آدرس باید از اینترنت
عمومی در دسترس باشد. آدرس‌های خصوصی/داخلی پذیرفته نمی‌شوند، حتی وقتی ریدایرکت به آن‌ها اشاره
کند — اگر لازم است سرویس داخلی را بپایید، یک نقطهٔ سلامت عمومی جلوی آن بگذارید.

## API

```text
GET    /api/v1/projects/{project_id}/uptime-monitors
POST   /api/v1/projects/{project_id}/uptime-monitors
GET    /api/v1/projects/{project_id}/uptime-monitors/overview
GET    /api/v1/projects/{project_id}/uptime-monitors/{id}
PATCH  /api/v1/projects/{project_id}/uptime-monitors/{id}
DELETE /api/v1/projects/{project_id}/uptime-monitors/{id}
GET    /api/v1/projects/{project_id}/uptime-monitors/{id}/checks
GET    /api/v1/projects/{project_id}/uptime-monitors/{id}/stats
POST   /api/v1/projects/{project_id}/uptime-monitors/{id}/check-now
```

## صفحهٔ وضعیت عمومی

صفحهٔ وضعیت، مجموعه‌ای از مانیتورهای آپ‌تایم را به صفحه‌ای تبدیل می‌کند که کاربران‌تان
می‌خوانند: `/status/<نشانی>`. این صفحه به حساب کاربری نیاز ندارد، پس وقتی بقیهٔ محصول
از کار می‌افتد هم کار می‌کند.

از مسیر **آپ‌تایم ← صفحه‌های وضعیت** یکی بسازید. هر صفحه چهار بخش دارد:

- **تنظیمات** — عنوان، توضیح کوتاه و متن معرفی، نشانی صفحه، لوگو و پیوند پشتیبانی
  اختیاری، و یک **اعلان بالای صفحه** که تا پاک‌کردن سنجاق می‌ماند. صفحه تا زمانی که
  منتشرش نکنید پیش‌نویس است و `404` برمی‌گرداند.
- **سرویس‌ها** — هرکدام یک مانیتور آپ‌تایم، با نامی که برای کاربر معنا دارد
  (`Checkout API` نه `prod-eu-checkout-lb`) و در صورت نیاز زیر یک گروه. وضعیت هر سرویس
  از بررسی‌های همان مانیتور خوانده می‌شود؛ چیزی برای هم‌گام‌کردن دستی وجود ندارد.
- **رویدادها** — شرح یک قطعی، همراه با خط زمانی. ثبت به‌روزرسانی *همان* تغییر وضعیت
  رویداد است: نمی‌شود وضعیت را بدون توضیح عوض کرد. رویداد باز، صفحه را حتی با وجود
  سبزبودن همهٔ بررسی‌ها «افت کارایی» نشان می‌دهد.
- **نگهداری** — بازهٔ برنامه‌ریزی‌شده به‌همراه متنی که کاربر باید بخواند. تا وقتی بازه
  در جریان است، سرویس‌های آن «در حال نگهداری» گزارش می‌شوند نه «قطع»؛ پس کار
  برنامه‌ریزی‌شده هیچ‌وقت شبیه قطعی دیده نمی‌شود.

هر سرویس برای هر روز از بازهٔ تاریخچهٔ صفحه (تا ۹۰ روز) یک ستون نشان می‌دهد که از همان
تجمیع ساعتی صفحهٔ جزئیات مانیتور محاسبه می‌شود.

```text
GET    /api/v1/status/{slug}                                        (عمومی، بدون احراز هویت)
GET    /api/v1/organizations/{org_id}/status-pages
POST   /api/v1/organizations/{org_id}/status-pages
GET    /api/v1/organizations/{org_id}/status-pages/{id}
PATCH  /api/v1/organizations/{org_id}/status-pages/{id}
DELETE /api/v1/organizations/{org_id}/status-pages/{id}
GET    /api/v1/organizations/{org_id}/status-pages/{id}/components
POST   /api/v1/organizations/{org_id}/status-pages/{id}/components
GET    /api/v1/organizations/{org_id}/status-pages/{id}/incidents
POST   /api/v1/organizations/{org_id}/status-pages/{id}/incidents
POST   /api/v1/organizations/{org_id}/status-pages/{id}/incidents/{incident_id}/updates
GET    /api/v1/organizations/{org_id}/status-pages/{id}/maintenances
POST   /api/v1/organizations/{org_id}/status-pages/{id}/maintenances
```

ویرایش صفحهٔ وضعیت به دسترسی مدیریت سازمان نیاز دارد؛ خواندن صفحهٔ عمومی به هیچ دسترسی‌ای.

## عیب‌یابی

| نشانه | علت / راه‌حل |
| --- | --- |
| خطای «آدرس خصوصی» | آدرس به یک IP خصوصی/داخلی می‌رسد که بررسی‌ها اجازهٔ رسیدن به آن را ندارند |
| قطع و وصل پیاپی | `downtime_threshold` را بالا ببرید، یا برای نقطهٔ کند `timeout_ms` را زیاد کنید |
| هر بررسی `401`/`403` می‌گیرد | مقصد احراز هویت می‌خواهد — هدر `Authorization` اضافه کنید |
| در مرورگر باز می‌شود ولی اینجا شکست می‌خورد | مقصد به کوکی یا هدر `Host` خاص نیاز دارد، یا IP بررسی‌کننده را بلوکه کرده |
| شرط بدنه همیشه رد می‌شود | `body_match` زیررشتهٔ ساده است نه عبارت باقاعده — و ممکن است بدنه HTML فشرده باشد نه JSONای که انتظار دارید |