Мониторинг на времето за отговор

Защо времето за отговор заслужава собствено предупреждение

Стандартните известия за наличност се основават на бинарен сигнал: up или down. Сивата зона между тях – онлайн, но бавно – е мястото, където всъщност се случва повечето от съвременните инциденти. Лошо конфигуриран заявка към база данни започва да отнема 4 секунди вместо 50ms. Memory leak води до скокове в garbage collection. Външно API, към което бекендът прави заявки, започва да се държи нестабилно. Нито едно от тези неща не разваля сайта напълно, но го прави неизползваем – и те са ранни сигнали за срив, който ще настъпи след час или два.

Мониторингът на времето за отговор улавя забавянията, преди да станат инциденти. Конфигурираш праг на монитор, а когато времето за отговор го превиши в няколко поредни проверки, получаваш предупреждение. Още преди известието да дойде, имаш запас да проучиш проблема, да скалираш нагоре, да ограничаваш проблемното извикване или да върнеш деплоймънта, който го е причинил.

Как работят праговете в DiagnoSEO Uptime Monitoring

Всеки монитор може да бъде конфигуриран с два параметъра: rt_threshold_ms и rt_threshold_breaches. Първият е времето за отговор в милисекунди, което смяташ за приемливо. Вторият е колко поредни проверки трябва да го надвишат, за да се изпрати известие. По подразбиране прагът е изключен, а броят надвишавания е три.

Дизайнът с два параметъра предпазва от фалшиви положителни сигнали. Мрежови смущения се случват. Паузи в garbage collection също. Еднократен скок до 1 секунда при базови 200ms не е причина да те буди известие в 3 през нощта. Но три поредни 1-секундни отговора вече са сериозно забавяне, не просто миг. Избери праг на база на обичайното поведение плюс разумен резерв: ако p95 обичайно е 400ms, праг 1000ms. Ако p95 е 50ms (вътрешно API), праг 200ms.

С какво работи добре в комбинация

Предупрежденията за време на отговор работят най-добре заедно с други сигнали от монитора. Пълен поглед: праг за време на отговор ти казва, че системата се влошава; HTTP кодът казва кога наистина се чупи; SSL/доменни предупреждения – за инциденти, свързани с изтичане на сертификати; DNS промени – за конфигурационни отклонения. Заедно четирите сигнала на един монитор заменят бинарното "дали работи" с пълна наблюдаемост.

Таблото също помага. Всеки монитор показва sparkline на последните времена за отговор – бърз визуален индикатор за деградация. Разширеният изглед показва средни стойности за 24ч, 7д и 30д. Ако видиш средното да пъпли нагоре седмица след седмица – това е ранен сигнал, който си заслужава да провериш преди да мине прага за предупреждение.

Практически прагове според типа страница

• Маркетингови landing страници: 1500ms е разумно. Имат много изображения и скриптове за проследяване; абсолютната бързина е по-малко важна от стабилността.
• Продуктови страници/категории за електронна търговия: 800-1200ms. Бавен онлайн магазин убива конверсиите; по-строги прагове улавят проблемите по-рано.
• Приложни dashboards: 500-800ms. Потребителите очакват бързина. Бавните dashboard-и карат продукта да изглежда неработещ.
• Публични API: 200-400ms за прости endpoint-и, по-високо за ресурсни изчисления. Направи tier-иране.
• Вътрешни микросервизни health checks: 50-100ms. Трябва да са почти мигновени; забавяне почти винаги значи сериозен проблем.

Каквото и да избереш, не избирай веднъж и после забравяй. Ревизирай на тримесечие според реалните трендове, които виждаш. Ако често получаваш предупреждения за надвишаване, без реални проблеми – прагът е твърде нисък. Ако имаш срив без предишно предупреждение – прагът е твърде широк.

Маршрутизиране на известията

Известията за прескочен праг се изпращат по същите канали, както при down/recovery: Email, Telegram, Slack, Discord, SMS. Защитени са от нощното мълчание (тихите часове). Логват се в същата таблица с известия. Единствената разлика е типът на събитието ("threshold" вместо "down") и текстът на съобщението – съдържа актуалното време за отговор и конфигурирания праг, за да виждаш веднага с колко е надвишено.

Конфигуриране

Редактирай произволен монитор. Във формуляра задайте "Праг на време за отговор (ms)" на избрана стойност. По желание коригирай "пореден брой надвишавания", ако стандартното 3 не е подходящо. Запази. От следващия цикъл всяка проверка ще сравнява времето за отговор с прага, и след зададения брой поредни надвишавания ще получиш известие.

Често задавани въпроси

• Коя метрика за време на отговор се регистрира?

  Time To First Byte (TTFB) — милисекунди между изпращането на заявката и получаването на първия байт от отговора. Плюс цялото време за изтегляне на пълния отговор. TTFB е най-полезната отделна метрика за здравето на сървъра.

• Какво е "добро" време за отговор?

  Зависи от локацията и съдържанието. За статична страница с CDN: под 100ms е отлично, под 300ms е ОК. За динамични приложения: под 500ms е ОК, под 1000ms е приемливо, над 2000ms вече изглежда бавно. Сравнявай със собствената си историческа база, не с абсолютни стойности.

• Мога ли да получа известие, ако времето за отговор надвиши прага?

  Да. Всеки монитор има по избор праг за време на отговор. Ако 3 поредни проверки надминат прага, получаваш известие за "бавен отговор". Изискването за 3 проверки предотвратява фалшиви аларми от единични мрежови прекъсвания.

• Откъде се измерва времето за отговор?

  От нашите 13 географски точки за проверка (Европа, Северна Америка, Азия, Южна Америка, Океания). За монитор с един регион стойностите идват от най-близкия регион. За multi-region, всеки регион се отчита отделно – полезно за откриване на регионални проблеми с CDN.

• Показва ли таблото трендовете на времето за отговор?

  Да – 30-дневна подвижна средна, дневни max/min и перцентили (p50, p95). Полезно за планиране на капацитет: ако p95 се вдигне от 800ms на 1500ms в рамките на месец, сървърите ти се претоварват, дори uptime процентът да е 100%.