Чому не надходять сповіщення Astrina

Зникають усі сповіщення Astrina чи лише один шлях доставки?

Почніть із одного запитання: зникають усі сповіщення Astrina чи лише один канал? Саме так найшвидше зрозуміти, чому не приходять сповіщення Astrina, коли ви намагаєтеся з’ясувати, що робити далі. Якщо пошта мовчить, але вебхук і далі спрацьовує, проблема явно не в усьому сервісі.

Виберіть один тип сповіщення, один канал і одну кінцеву точку. Наприклад, «база даних недоступна» на email — це один шлях; «попередження про нестачу дискового простору» в Slack — інший. Перевіряйте кожен шлях окремо, бо зламану пошту й непрацюючий вебхук спричиняють зовсім різні причини.

Якщо не працює лише один шлях, проблема зазвичай локальна. Одна інтеграція може зламатися, поки решта продовжує працювати. Таке часто трапляється через перейменований канал у Slack або email-аліас, якого вже не існує.

Якщо одночасно не працюють усі шляхи, картина швидко змінюється, і саме так може виглядати ситуація, коли Astrina сповіщення не надходять у кілька місць одразу. Тоді потрібно перевіряти спільні налаштування, подію-джерело, яка взагалі не спрацьовує, або зміни на рівні облікового запису. Не думайте, що зламаний механізм сповіщень, лише тому що одна скринька порожня.

Використовуйте назву сповіщення саме так, як вона вказана в Astrina. Одна помилка в назві може приховати інший маршрут. Дрібниця, а різниця велика.

Чи змінилося щось у системі призначення або в правилах поштової скриньки?

Спершу перевірте поза Astrina. Поштову скриньку можуть перейменувати, канал — архівувати, а кінцеву точку вебхука — видалити без попередження. Достатньо однієї зміни з боку адміністратора.

Для email перевірте спам-фільтри, правила пересилання та вимкнені поштові скриньки. Фільтр, який переносить повідомлення в підпапку, може створити враження, що сповіщення зникли, хоча вони насправді надійшли. Це дратує, але трапляється часто.

Для чат-інструментів переконайтеся, що канал усе ще існує, а застосунок і далі встановлений. Деякі команди щомісяця змінюють дозволи в робочому просторі. Після цього сповіщення перестають потрапляти туди, де всі їх очікують.

Для вебхуків переконайтеся, що сервіс-одержувач досі приймає той самий URL і метод. Зміна шляху, ротація токена або нове правило брандмауера можуть заблокувати сповіщення ще до того, як хтось їх побачить. Якщо ваша команда веде облік інтеграцій в іншому місці, порівняйте поточну ціль із останньою робочою.

Якщо вам потрібна швидка довідка щодо налаштування API, сторінка Astrina з кінцевими точками, автентифікацією та квотами — правильне місце, щоб перевірити формат запиту, перш ніж звинувачувати доставку.

Чи Astrina все ще генерує сповіщення в джерелі?

Тепер перевірте саму подію-джерело. Якщо поріг більше не перевищується, сповіщення не спрацює. Попередження про диск на 92% нічого не робить, якщо правило починається з 95%.

Поставте просте запитання: чи сталася подія знову після того, як сповіщення припинили надходити? Якщо сервер так і не досяг тригера, то повідомлення не «зникло» — його просто ніколи не було створено.

Перевіряйте сирий сигнал, а не текст повідомлення. Невдале завдання, падіння трафіку або тайм-аут усе ще мають відображатися в вихідних даних, якщо Astrina стежить за правильною метрикою. Якщо ці дані пласкі, логіка сповіщення, ймовірно, справна, а змінилося саме джерело.

Будьте обережні з мовчазними системами. Cron-завдання може зупинитися без видимої помилки. Форма може перестати приймати заявки після зміни на фронтенді. В обох випадках Astrina чекає на сигнал, який уже не надходить.

Для моніторингу сайтів порівнюйте подію-джерело з трафіком за допомогою посібника з перевірки трафіку на сайті, якщо сповіщення залежать від відвідувань або падіння сесій. Це швидше, ніж гадати. Якщо потрібно, окремо спробуйте як перевірити сповіщення Astrina, зіставивши тригер, журнал і кінцеву точку.

Можливо, сповіщення просто затримується, а не губиться?

Так. Затримки бувають. Черга може перевантажитися, нижчестоячий сервіс — обмежувати кількість запитів, або повторна спроба може відкласти доставку на кілька хвилин.

Час тут має значення. Якщо одне сповіщення має надсилатися негайно, а інше може повторювати спробу, обидва можуть виглядати «зниклими» протягом короткого проміжку часу. Перевірте, чи не прийшло сповіщення пізніше, перш ніж відкривати тікет.

Черги часто з’являються після стрибків трафіку. Велика партія подій може стояти позаду попередніх завдань. Сповіщення все ще в русі — просто не там, де ви його очікуєте.

Обмеження швидкості може виглядати схоже. Деякі кінцеві точки обмежують кількість повідомлень, які вони приймають за короткий час, а решту сповільнюють. Якщо приймач лімітує запити, Astrina може робити повторні спроби.

Перевірте часові позначки доставки в логах Astrina. Порівняйте першу спробу відправлення з наступною повторною. Різниця у 2 хвилини для деяких схем є нормальною; різниця у 2 години — це вже інша проблема.

Чи було сповіщення тихо приглушене правилом або фільтром?

Приглушення легко не помітити, бо нічого не «ламається». Подія відбувається, але Astrina вирішує не надсилати сповіщення. Дедуплікація, вікна без звуку та режим технічного обслуговування можуть робити саме це.

Дедуплікація зводить повтори до одного. Якщо одна й та сама проблема спрацьовує 10 разів за 10 хвилин, Astrina може надіслати одне сповіщення й приглушити решту. Це корисно, доки хтось не очікує нового пінгу для кожного випадку.

Вікна без звуку ще тихіші. Команда може вимкнути сповіщення під час розгортання, а потім забути, що вікно досі активне. Один забутий прапорець може пояснити порожню скриньку о 3:00 ночі.

Режим техобслуговування може блокувати доставку навмисно. Умовна маршрутизація також може переспрямувати сповіщення в інше місце, наприклад до іншого каналу команди. Якщо перевіряєте лише одну кінцеву точку, можна пропустити сповіщення, хоча Astrina зробила саме те, що їй наказали.

Правила приглушення варто перевіряти окремо, особливо після змін конфігурації. Якщо сповіщення мало спрацювати, але цього не сталося, набір правил зазвичай — перше місце для пошуку.

Якщо ви керуєте сповіщеннями для змішаної команди, Astrina для власників сайтів без технічного досвіду може допомогти нетехнічним колегам зрозуміти, чому один вимкнений маршрут може виглядати як збій системи.

Які логи або часові позначки слід порівняти першими?

Використовуйте мінімальний набір доказів. Вам не потрібен кожен рядок логів. Почніть із чотирьох часових позначок: час події, час спроби відправлення, час спроби доставки та час отримання на стороні призначення, якщо він доступний.

Ця послідовність показує точку, де все зламалося. Якщо час події є, але після нього немає спроби відправлення, Astrina не пройшла далі тригера-джерела. Якщо спроба відправлення є, але спроби доставки немає, проблема між Astrina та кінцевою точкою.

Якщо час отримання на боці призначення відсутній, підозра падає на останню ділянку шляху. Якщо він є, але користувач так і не побачив повідомлення, тоді, ймовірно, втрутилися правила скриньки або дозволи каналу. Малий ланцюжок — чіткий винуватець.

Залишайте порівняння вузьким. Одне сповіщення, одна дата, одна кінцева точка. Так набагато легше зрозуміти, де зупинилося сповіщення: під час створення, передачі чи отримання.

Невелика таблиця може допомогти розібратися.

І ще одне: порівнюйте часові позначки в одному часовому поясі. Зсув у три години може створити враження, що справне сповіщення відсутнє. Через таку помилку губляться цілі післяобідні години.

Коли варто ескалювати проблему до підтримки Astrina або вашого адміністратора?

Ескалуйте після того, як перевірили подію-джерело, маршрутизацію, зміни у кінцевій точці та налаштування приглушення. Якщо все це виглядає нормально, а сповіщення все одно не приходить, проблема вже не проста.

Надайте конкретні докази. Вкажіть назву сповіщення, дату й час, канал або кінцеву точку, останнє відоме робоче сповіщення та будь-який текст помилки, який можете дослівно скопіювати. Команда підтримки працює швидше з шістьма фактами, ніж із однією нечіткою скаргою.

Якщо вам допомагає адміністратор, попросіть спершу переглянути нещодавні зміни. Одне оновлене право доступу, одне відредаговане вікно без звуку або одна видалена інтеграція можуть зламати шлях, який учора працював увесь день. Саме про таке люди часто забувають згадати.

Коли проблема зачіпає більше ніж одну кінцеву точку, скажіть про це прямо. Один непрацюючий вхідний канал — це один випадок. Три непрацюючі кінцеві точки можуть вказувати на спільну проблему конфігурації. Інша реакція, інший відповідальний.

Якщо вам потрібно порівняти пов’язану поведінку доставки, стаття як виправити відсутній живий трафік стане хорошим доповненням, коли на тому ж сайті зникають і сигнали в реальному часі. А якщо ви намагаєтеся зрозуміти межі системи перед ескалацією, перегляньте як порівняти Astrina з Matomo, щоб зрозуміти, як рішення щодо обробки даних можуть впливати на те, що надсилається.

Надсилайте ескалацію лише після того, як у вас є одна чітка хронологія. Без цього перша відповідь буде лише серією запитань, на які ви могли б відповісти самі. Охайний запис економить довгу переписку.

Тримайте тікет коротким, але не розмитим. Напишіть, що зупинилося, коли саме це сталося і що змінилося приблизно в той самий час. Цього достатньо, щоб зрушити проблему з місця.

Якщо ваша команда підтримує кілька шляхів сповіщень, попросіть адміністратора перевірити, чи правило змінилося глобально, чи лише для одного маршруту. Це важливо, бо глобальна зміна може пояснити, чому кілька сповіщень зникли одночасно, тоді як редагування на рівні одного маршруту зазвичай не чіпає решту.

Не чекайте тиждень мовчання, перш ніж ескалювати. Якщо сповіщення Astrina перестали надходити після відомої зміни, а в логах видно повторні невдалі спроби, цього вже достатньо, щоб упевнено передати проблему далі.