Чому Astrina сповіщає про доступність, якщо сайт онлайн

Чи може сповіщення про доступність бути “правдивим”, навіть якщо головна сторінка відкривається?

Так. Вкладка браузера, на якій відкривається головна сторінка, не доводить, що перевірюваний endpoint пройшов перевірку Astrina, і саме це важливо зрозуміти насамперед, коли ви питаєте, чому Astrina сповіщення доступності сайт онлайн може з’явитися, навіть якщо сайт і далі доступний. Людина може відкрити маркетингову сторінку, побачити логотип і вирішити, що все гаразд. А Astrina може перевіряти /status, /login або JSON-відповідь, а не головну сторінку.

Цей поділ має значення. Головна сторінка може завантажитися з кешу, тоді як сам endpoint на сервері вже не відповідає вчасно. Також сайт може повертати 200 для оболонки сторінки, але все одно провалювати правило вмісту, бо в тексті немає потрібного рядка. Невелика деталь, великий наслідок.

Думайте про це як про два окремі запитання: “чи бачу я щось?” і “чи пройшла саме ця перевірка?” Саме тому корисно розуміти, як зрозуміти збій моніторингу Astrina, а не лише дивитися на факт відкриття сайту. Це не одне й те саме.

Ось простий приклад із 3 елементів: користувач відкриває https://example.com, монітор перевіряє https://example.com/api/health, а API протягом 90 секунд повертає 500. Відвідувачі можуть нічого не помітити, якщо сторінка кешується, але Astrina цілком справедливо спрацьовує, бо перевірюваний endpoint зламаний. Це не суперечність; у цьому й сенс моніторингу.

Яка саме частина перевірки насправді не проходить?

Найшвидший спосіб читати сповіщення про доступність — відокремити зламаний рівень. DNS, TCP, TLS, HTTP, редиректи та перевірки тіла відповіді ламаються з різних причин, і кожна з них залишає свій слід. Якщо пропустити цей крок, ви витратите час на звинувачення “сайту”, хоча з’їхав лише один рівень.

Збій DNS означає, що проба не змогла знайти хост. Збій TCP означає, що хост знайдено, але з’єднання не вдалося відкрити. Збій TLS або SSL означає, що сертифікат, ім’я хоста або рукостискання не задовольнили перевірку. Збій HTTP означає, що сервер відповів, але з неправильним кодом статусу. Збій редиректу означає, що ланцюжок пішов не туди або перевищив ліміт. Збій зіставлення вмісту означає, що сторінка завантажилася, але в тілі відповіді не було очікуваного тексту.

Ці категорії — практичні, а не декоративні. Редирект 301 на сторінку входу може виглядати для людини як “сайт онлайн”, але монітор може провалитися, якщо очікує 200 з початкового шляху. Сертифікат, який спливає за 2 дні, може вже викликати попередження в одних браузерах і не викликати в інших, тоді як Astrina вже може позначити стан TLS. Саме така різниця й перетворюється на незрозуміле сповіщення о 09:17.

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

Чому користувачі й монітори одночасно бачать різні результати?

Користувачі й монітори не дивляться на веб із того самого місця. Браузер може користуватися локальним кешем, активною сесією або швидким CDN-вузлом поруч із відвідувачем. Проба Astrina може йти з іншого регіону, іншим IP-шляхом або як “холодний” запит без будь-якого стану браузера.

Ця різниця пояснює багато чого. Один відвідувач у Лондоні відкриває сайт за 1 секунду. Інша проба в іншому місці бачить тайм-аут на 5 секунд, бо транзитний маршрут перевантажений. Обидва звіти можуть бути правдивими одночасно.

Поведінка CDN — часта причина. Якщо edge віддає головну сторінку, але не віддає вкладений ресурс, сторінка може й надалі виглядати “нормально” неозброєним оком. Кешована оболонка може приховати зламане джерело. Монітор, однак, може перевіряти шлях до origin напряму або маршрут, який CDN не кешує надовго.

Географія теж має значення. Фаєрвол може дозволяти трафік із вашої офісної IP-адреси, але блокувати діапазон IP для проби. Проблема маршрутизації може зачіпати один континент протягом 12 хвилин і не торкатися решти. Такий розрив у картині дратує, але він реальний. Жодні пояснення не змінять шлях пакетів.

Іноді все ще простіше: браузер автоматично повторює спробу, а монітор — ні. Сторінка, яка зрештою завантажується після 3 невдалих спроб, усе одно може викликати сповіщення, якщо перевірка виходить за тайм-аут на першій спробі. Це не означає, що Astrina “занадто сувора”. Це означає, що сервіс наближається до збою.

Чи може частковий збій викликати сповіщення, якщо основний сайт працює?

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

Уявіть e-commerce-сайт із 4 рівнями: головна сторінка, product API, платіжний шлюз і сервіс інвентарю. Якщо головна сторінка кешована, а product API повертає порожні результати, відвідувач усе одно може потрапити на сторінку й побачити банер. Astrina може перевіряти endpoint API і спрацювати одразу. Сайт “працює” в побутовому сенсі, але ключова функція — ні.

Окремий зламаний ресурс теж має значення. Якщо монітор перевіряє, що hero-зображення або JavaScript-бандл присутні, відсутній файл може провалити перевірку вмісту, навіть якщо HTML завантажується. Одного відсутнього файлу може бути достатньо. Це не драматизація; це операційна реальність.

Збої, прив’язані до регіону, створюють схожу проблему. Припустімо, один дата-центр обслуговує користувачів в одній країні, а інший регіон деградував. Основний сайт може завантажуватися з “здорового” регіону, але запити з проблемного регіону або зависають, або повертають помилки. Сповіщення не помиляється. Воно каже вам, що доступність нерівномірна.

Є й тонкіший випадок: одна повільна залежність може вивести відповідь за межі ліміту перевірки. Сторінка може зрештою відрендеритися за 8 секунд, але якщо поріг монітора — 5 секунд, Astrina спрацює. Це корисно. Повільність часто є першим кроком перед падінням.

Які деталі відповіді слід перевірити першими?

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

Читайте ці поля саме в такому порядку. 500 — це не та сама проблема, що 200 із неправильним тілом. Тайм-аут — це ще інша історія. Якщо бачите ланцюжок із 4 переходів, варто запитати, чи повинен монітор проходити всі 4, чи краще стежити за простішим endpoint. Чим більше переходів, тим більше місць, де можна провалитися.

Локація проби заслуговує на окремий погляд. Результат із Франкфурта може відрізнятися від результату із Сінгапура, якщо нестабільний CDN-вузол або upstream-маршрут. Саме ця деталь часто пояснює, чому один оператор бачить збій, а інший — ні. Обидва говорять правду зі своєї сторони.

Якщо в сповіщенні є заголовки, звертайте увагу на ті, що пов’язані з кешем. Відповідь із кешу може деякий час приховувати збій origin. Відповідь із позначкою “stale” або “miss” може показати реальний стан. Маленькі підказки мають значення.

Коли це ймовірніше хибне спрацювання, а коли — реальна проблема з доступністю?

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

Спочатку перевірте нестабільну залежність. Якщо сповіщення з’явилося один раз, зникло й не повернулося протягом наступних 30 хвилин, можлива тимчасова проблема на upstream. Якщо воно спрацьовує кожні 2 хвилини на тому самому endpoint, або перевірка надто сувора, або сервіс справді нестабільний. Шаблони важливіші за історії.

Занадто сувора перевірка часто виглядає так: сторінка рендериться, але правило вмісту очікує точну фразу, яка змінилася в релізі минулого тижня. Команда продукту замінила “Sign in” на “Log in”, і монітор почав провалюватися через невідповідність тіла. Сайт онлайн. Перевірка застаріла.

Натомість справжня проблема часто проявляється одразу в кількох місцях. Головна сторінка повільно завантажується, API повертає 503, а сертифікат уже майже прострочений. Це не одна дивина. Це кілька маленьких попереджень, що вказують в один бік.

Є й випадок “залежить від того, кого питаєш”. Користувачі за корпоративним VPN можуть потрапляти на стабільний маршрут, а проба — на зламаний. Спочатку це може виглядати як хибне спрацювання, але зазвичай це реальна проблема з досяжністю щонайменше для однієї аудиторії. Сайт, який доступний для 80% відвідувачів, не є повністю доступним.

Що змінити, якщо сайт “онлайн”, але Astrina продовжує спрацьовувати?

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

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

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

Якщо проблема в часі відповіді, налаштуйте моніторинг на легший шлях. Повна головна сторінка з 12 ресурсами — слабкий сигнал здоров’я, якщо вам потрібна лише швидка відповідь. Легший endpoint дає кращу відповідь і менше хибних тривог. Швидкі перевірки старіють краще за “розумні”.

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

І остання перевірка: порівняйте те, що каже сповіщення, з точним URL, а не з назвою бренду. Якщо сповіщення спрацьовує на /api/health, а головна сторінка працює, це очікувана поведінка. Якщо ж сповіщення спрацьовує саме на головній сторінці, тоді проблему варто вивчити глибше, бо головна сторінка, яка віддається, але провалює перевірки вмісту, TLS або маршрутизації, — це все одно реальний інцидент для Astrina.