هشدارها و وبهوکها
یک کانال اعلان را یک بار میسازید و بعد هر تعداد هشدار را به آن وصل میکنید. کانال وبهوک متد، احراز هویت، هدر سفارشی و امضای HMAC میگیرد، پس هر پلتفرم اتوماسیونی میتواند گیرندهاش باشد.
دو چیز جدا: کانال و هشدار#
در نوار کناری، زیر گروه «پیکربندی»، صفحه «هشدارها» در مسیر /alerts هست. صفحه دو کارت دارد و ترتیبشان همان ترتیبی است که باید کار کنید:
- «کانال های اطلاع رسانی» — جایی که اعلان میرود. یک بار ساخته میشود و بین هشدارها مشترک است.
- «هشدارها» — شرطی که روی دادههای دارایی سنجیده میشود و به یک یا چند کانال وصل است.
جدا بودنشان عمدی است: آدرس وبهوک تیم عملیات را یک بار وارد میکنید و بعد ده هشدار به همان یک کانال وصل میشوند. عوض کردن آدرس هم یک جا انجام میشود.
اولین باری که این صفحه را باز میکنید، اگر هیچ کانالی وجود نداشته باشد، ادپیکس یک کانال ایمیل با نام My email و نشانی خودتان میسازد تا بتوانید بدون هیچ تنظیمی اولین هشدار را بسازید. اسمش را با «ویرایش» عوض کنید.
ساخت یک کانال#
حذف کانال، آن را از همه هشدارهایی که استفادهاش میکردند جدا میکند؛ خود هشدارها میمانند، ولی بیکانال. هشداری که هیچ کانالی نداشته باشد ارزیابی میشود و در جدول بهروز میشود، اما هیچ اعلانی نمیفرستد.
کانال وبهوک#
کشوی «کانال جدید» برای نوع «وب هوک» همه چیزی را که یک پلتفرم اتوماسیون لازم دارد میگیرد:
| فیلد | چه میکند |
|---|---|
| «آدرس وب هوک» | مقصد درخواست |
| «متد» | یکی از POST (پیشفرض)، GET، PUT، PATCH، DELETE |
| «احراز هویت» | «هیچ»، «توکن Bearer»، «پایه (کاربر/رمز عبور)» یا «هدر سفارشی» |
| هدرهای سفارشی | هر سطر یک Key: Value — برای برچسبگذاری محیط یا مسیریابی داخلی |
| «امضای HMAC» | کلیدی که بدنه با آن امضا میشود؛ خالی بگذارید تا غیرفعال بماند |
با «هدر سفارشی» میتوانید هر طرحی را پوشش بدهید که Bearer و Basic پوشش نمیدهند — مثلا X-API-Key. نام هدر اجباری است و بدون آن ذخیره رد میشود.
وقتی کلید امضا را پر کنید، هر درخواستی که بدنه دارد این دو هدر را هم حمل میکند:
امضا، HMAC-SHA256 روی بایتهای خام بدنه است. GET و DELETE بدنه ندارند، پس امضا هم نمیگیرند — اگر متد را روی یکی از این دو بگذارید و منتظر امضا بمانید، هیچوقت نمیآید. کد تایید امضا در سه زبان، و تفاوت این مسیر با مسیر مقصدهای خروجی، در وبهوکها و امضای HMAC آمده است.
مهلت هر درخواست هشت ثانیه است. اگر گیرنده پیش از پاسخ دادن کار سنگین انجام دهد، ادپیکس آن را شکست میشمارد و دوباره میفرستد در حالی که کار اول هم دارد تمام میشود. رویداد را در صف خودتان بگذارید، 200 برگردانید، بعد پردازش کنید.
ساخت هشدار#
پنج سنجه در دسترس است و هرکدام دقیقا این را میشمارد:
| «سنجه» | چه چیزی شمرده میشود |
|---|---|
| «کاربران» | کاربران یکتای شناساییشده در پنجره |
| «نشستها» | نشستهای یکتا |
| «رویدادها» | همه رویدادها |
| «رویدادهای کلیدی (تبدیل ها)» | فقط رویدادهایی که در دارایی بهعنوان رویداد کلیدی ثبت شدهاند |
| «درآمد» | جمع مقدار رویدادهای purchase |
اگر در دارایی هیچ رویداد کلیدی ثبت نکرده باشید، سنجه «رویدادهای کلیدی (تبدیل ها)» همیشه صفر برمیگرداند — نه اینکه خطا بدهد. هر شرط «افت کند زیر» روی چنین هشداری در اولین ارزیابی نقض میشود و اعلان میفرستد. اول در رویدادهای کلیدی تبدیلهایتان را ثبت کنید.
«پنجره» بر حسب ساعت است و یک بازه غلتان میسازد: از لحظه ارزیابی، N ساعت به عقب. این بازه عمدا روی UTC حساب میشود و روز تقویمی دارایی را دنبال نمیکند — برخلاف گزارشها که هر مرز پنجره و هر سطلشان در منطقه زمانی دارایی ارزیابی میشود. برای «۲۴ ساعت گذشته» فرقی ندارد؛ اگر منتظر «دیروز» هستید، فرق دارد.
ارزیابی: چه وقت واقعا اتفاق میافتد#
این مهمترین نکته صفحه است و راحت میشود اشتباه فهمید.
هشدار وقتی سنجیده میشود که کسی روی «ارزیابی» در سطر آن بزند، یا سیستم شما همان درخواست را به API بزند. ادپیکس در این نسخه هشدارها را خودش زمانبندی نمیکند. کلید «روشن» وضعیت هشدار را نگه میدارد و ستونهای «آخرین مقدار» و «وضعیت» نتیجه آخرین ارزیابی را نشان میدهند، ولی هیچ زمانبند داخلیای این چرخه را نمیچرخاند. اگر میخواهید هشدارها بیدخالت شما کار کنند، فعلا باید یک کار زمانبندیشده در سمت خودتان بسازید که همان مسیر ارزیابی را صدا بزند.
هر ارزیابی این ترتیب را دارد:
مرحله سوم همان چیزی است که جلوی سیل اعلان را میگیرد: پیام فقط روی گذر از «سالم» به «نقض شده» میرود. تا وقتی هشدار نقضشده بماند، ارزیابیهای بعدی ساکتاند. پیام بازگشت به «سالم» هم فقط وقتی میآید که «نقض + بازیابی» را انتخاب کرده باشید.
تلاش دوباره وقتی گیرنده جواب نمیدهد#
وبهوک هشدار در همان لحظه تا سه بار تلاش میکند، با مکث کوتاه بین تلاشها. قاعدهاش ساده است:
| پاسخ گیرنده | چه میشود |
|---|---|
کمتر از 300 |
موفق؛ تمام |
300 تا 499 |
قطعی؛ تلاش دوباره نمیشود — این خطا با تکرار درست نمیشود |
5xx یا خطای شبکه |
تا سقف سه تلاش دوباره میرود |
بعد از سومین شکست، فقط یک سطر در لاگ سرور میماند و کنسول چیزی نشان نمیدهد. اعلان هشدار در صفی نگه داشته نمیشود و بعدا از نو فرستاده نمیشود. این با مقصدهای خروجی فرق دارد؛ آنها صف بادوام و صف نامه مرده دارند. جزئیاتش در مخاطبان و مقصدها.
آزمایش پیش از اتکا#
دو دکمه «آزمایش» روی صفحه هست و کارشان یکی نیست:
- «آزمایش» در سطر یک کانال یک اعلان نمونه فقط از همان کانال میفرستد. برای وارسی آدرس، احراز هویت و امضا همین کافی است.
- «آزمایش» در سطر یک هشدار همان پیام نمونه را از همه کانالهای وصل به آن هشدار میفرستد و در پیام موفقیت میگوید به چند ایمیل و آیا به وبهوک رفته است. اگر هیچ کانالی وصل نباشد، خطا میدهد.
هر دو پیام آزمایشی صراحتا خودشان را آزمایش معرفی میکنند، پس کسی آن را با یک نقض واقعی اشتباه نمیگیرد. آزمایش وضعیت هشدار را دست نمیزند.
«ارزیابی» چیز دیگری است: واقعا سنجه را حساب میکند، وضعیت را مینویسد، و اگر وضعیت تغییر کرده باشد اعلان واقعی میفرستد. برای وارسی کانال از «آزمایش» استفاده کنید، نه از «ارزیابی».
چه کسی چه کاری میتواند بکند#
| کار | نیازمند |
|---|---|
| دیدن صفحه و فهرست هشدارها | دسترسی خواندن گزارش روی دارایی |
| ساخت، ویرایش یا حذف کانال | اختیار ویرایش مخاطبان |
| ساخت، ویرایش یا حذف هشدار | اختیار ساخت کاوش |
| زدن «ارزیابی» یا «آزمایش» | دسترسی خواندن گزارش |
ساخت و ویرایش و حذف هشدارها و کانالها در گزارش ممیزی ثبت میشود. خود آیتم «هشدارها» در نوار کناری تنها برای کسی نمایش داده میشود که اختیار ویرایش مخاطبان را داشته باشد.
پرسشهای پرتکرار#
هشدارها خودشان بهصورت زمانبندیشده اجرا میشوند؟
نه در این نسخه. ارزیابی وقتی انجام میشود که روی «ارزیابی» بزنید یا سیستم شما همان درخواست را به API بزند. کلید «روشن» وضعیت هشدار را نگه میدارد، ولی هیچ زمانبند داخلیای آن را صدا نمیزند. تا وقتی زمانبندی داخلی نیامده، یک کرون در سمت خودتان بسازید.
چرا هشدار «رویدادهای کلیدی (تبدیل ها)» همیشه نقضشده است؟
چون هیچ رویداد کلیدیای در دارایی ثبت نکردهاید. وقتی فهرست رویدادهای کلیدی خالی باشد، مقدار سنجه صفر حساب میشود و هر شرط «افت کند زیر» بلافاصله نقض میشود. اول رویداد کلیدی را ثبت کنید، بعد هشدار بسازید.
پنجره ۲۴ ساعته با منطقه زمانی دارایی حساب میشود؟
نه. پنجره هشدار یک بازه غلتان است — «از این لحظه به عقب، N ساعت» — و عمدا روی UTC حساب میشود، نه روی روز تقویمی دارایی. برخلاف گزارشها که هر مرز پنجرهشان در منطقه زمانی دارایی ارزیابی میشود.
تا وقتی مشکل ادامه دارد، هر بار اعلان میگیرم؟
نه. اعلان فقط روی تغییر وضعیت میرود: از سالم به نقضشده. تا وقتی هشدار نقضشده بماند، ارزیابیهای بعدی چیزی نمیفرستند. اعلان بازیابی هم فقط وقتی میآید که «نقض + بازیابی» را انتخاب کرده باشید.
ممنون — بازخورد شما به بهتر شدن مستندات کمک میکند.