Кратък отговор

Следим сайтовете и сървърите на няколко нива: дали сайтът отговаря отвън, как е натоварен сървърът, какво пишат логовете и дали има архиви. Целта е да разберем за проблема от собствения си мониторинг, а не от клиента, който се обажда, че сайтът не зарежда.

Използваме Uptime Kuma за проверки на сайтовете отвън, мониторинга на aaPanel за бърз поглед върху сървъра и Prometheus с Grafana за външни проверки на услугите, история на метриките и алерти. Нито един от тях не е достатъчен сам по себе си. Заедно покриват различни въпроси.

Какво значи „преди да засегнат клиентите“

Когато говорим за клиенти, имаме предвид и клиентите на нашите клиенти. Човекът, който не може да завърши поръчка. Запитването, което не стига до никого. Страницата, която зарежда 15 секунди и посетителят затваря таба.

Част от проблемите идват внезапно. Много други обаче дават сигнали предварително. Дискът се пълни седмици наред. SSL сертификатът има дата на изтичане. Натоварването расте постепенно, докато един ден сървърът не издържи. Ако тези сигнали се виждат навреме, има време да се реагира спокойно, а не в паника.

Какво следим

Дали сайтът отговаря отвън

Това е първото ниво и го правим с Uptime Kuma. Той проверява сайтовете на редовни интервали от външна точка в мрежата, а не от самия сървър, и сигнализира, когато някой не отговаря. Това не е същото като реален посетител с браузър, но показва дали сайтът е достъпен отвън.

Тук има една важна подробност. Сайтът може да върне отговор „всичко е наред“ и пак да показва страница с грешка, празна страница или съобщение от хостинга. Затова проверката може да търси и конкретен текст на страницата, а не само дали сървърът е отговорил.

Uptime Kuma следи и SSL сертификатите. Изтекъл сертификат спира сайта за посетителите толкова ефективно, колкото и паднал сървър, а е напълно предвидим.

Пощата и сертификатите на услугите

Сайтът не е единствената услуга, която трябва да работи. Пощата също има сертификати, и то на няколко порта едновременно. За тях използваме Blackbox Exporter заедно с Prometheus. Те се свързват към услугите отвън и проверяват сертификата, който всяка от тях реално връща. Защо това има значение, се вижда в примера по-долу.

Как е сървърът

За бърз поглед върху VPS сървърите ползваме вградения мониторинг на aaPanel: натоварване, процесор, памет, диск. Това е първото място, което отваряме, когато нещо изглежда необичайно. Повече за това защо работим с панела сме описали в статията Защо използваме aaPanel за VPS сървъри.

Моментната картина обаче не стига. Затова имаме и Prometheus, който събира метрики на равни интервали и пази историята им, и Grafana, която ги показва в табла.

Историята отговаря на въпроси, на които моментната картина не може:

  • Пълни ли се дискът постепенно и кога ще свърши мястото?
  • Нормално ли е това натоварване за този час, или е ново?
  • Кога точно започна проблемът и какво се промени тогава?

Какво пишат логовете

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

Има ли архиви

Архивите не са мониторинг в тесния смисъл, но са част от същата грижа. Не стига да има backup задача. Трябва да е ясно какво се архивира, къде се пазят копията и дали възстановяването е проверено. Архив, който никой не е опитвал да възстанови, е предположение, а не сигурност.

Алерти, които си струва да се четат

Мониторинг без алерти означава, че някой трябва постоянно да гледа таблата. Алерти без мярка означават, че след седмица никой не ги чете.

Затова подреждаме алертите по няколко принципа:

  • Сигнал за нещо, по което трябва да се действа. Кратък пик на натоварването, който изчезва сам, не е повод за тревога.
  • Прагове с продължителност. Сайт, който не отговаря на една проверка, може да е мрежов шум. Сайт, който не отговаря няколко поредни проверки, е проблем.
  • Предупреждение преди повредата. Диск на 85% е предупреждение. Диск на 100% вече е авария.
  • Проверка на самия сигнал. Понякога проблемът е в проверката, а не в услугата, например DNS timeout при самата проверка. Мониторинг, който често вдига фалшива тревога, учи хората да пренебрегват сигналите. Затова следим и надеждността на самия мониторинг.

И Uptime Kuma, и Grafana имат собствени алерти. Grafana Alerting позволява правилата да се пишат върху същите метрики, които виждаме в таблата. Така алертът и графиката, по която го проверяваме, говорят за едно и също нещо.

Пример: сертификат, който проверките хванаха

В средата на октомври външните проверки отчетоха проблем с пощата на един от домейните, които обслужваме. Портовете за изпращане на поща (465 и 587) не минаваха TLS проверката, докато IMAP на порт 993 работеше нормално.

Причината беше грешна SNI конфигурация в Postfix. SNI е начинът, по който сървърът разбира за кой домейн е връзката и кой сертификат да покаже. Сертификатът беше наред, но услугата показваше грешния. Коригирахме конфигурацията и проверките минаха успешно.

Точно такъв проблем не се вижда, ако се следи само дали сайтът зарежда или само кога изтича сертификатът. Затова проверяваме отвън сертификата, който всяка услуга реално показва.

Как стигаме до причината

Алертът казва, че има проблем. Не казва защо.

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

За част от диагностиката разработваме собствен инструмент, WebComa Infrastructure MCP. Той използва Model Context Protocol, за да даде на AI асистент набор от предварително определени инструменти: информация за сървърите, системните услуги, логовете, мрежовата свързаност и метриките от Prometheus.

Например при сигнал за недостъпна услуга той помага да съберем на едно място състоянието на сървъра и на съответната системна услуга, наличните логове и свързаните показатели. Вместо поредица от отделни ръчни проверки използваме предварително определени инструменти с ограничен достъп. Какво точно е налично зависи от разрешенията и активираните проверки за конкретната среда.

Това не е свободен достъп до сървърите. Инструментът работи с ограничени разрешения и одобрени източници. Операциите, които променят нещо, са изключение, строго ограничени са и изискват изрично разрешение.

Развиваме го постепенно. Новите възможности минават през тестова среда, преди да ги включим в реална работа.

Ролите остават ясни: мониторингът засича отклонението, инструментът помага да се събере контекстът, а специалист преценява какво да се направи.

Какво техническият мониторинг не вижда

Всички табла могат да са зелени, а бизнесът да губи пари. Сайтът отговаря, сървърът е спокоен, но:

  • формата за запитване не изпраща имейли;
  • плащането с карта връща грешка от страна на платежния доставчик;
  • интеграцията с куриер или склад е спряла;
  • след промяна по сайта tracking-ът е спрял да събира данни.

Техническият мониторинг вижда инфраструктурата. Не вижда дали идват поръчки и запитвания. За онлайн магазин или сайт, който носи запитвания, има смисъл отделно да се проверяват и бизнес сигналите, например дали за обичаен период са дошли поръчки или дали ключово събитие продължава да се отчита. Това е настройка за конкретния проект и бизнес, а не нещо, което стандартният мониторинг дава сам.

Има и други граници. Когато сайтът е на хостинг на клиента и нямаме достъп до сървъра, можем да следим само отвън. Мониторингът също не предотвратява проблемите. Той само съкращава времето между появата им и реакцията.

Какво може да провери сам собственикът

Не е нужно да сте технически човек, за да зададете правилните въпроси на този, който поддържа сайта ви:

  1. Кой разбира пръв, ако сайтът спре: вие, клиентът ви или някой, който го наблюдава?
  2. Кога изтичат SSL сертификатът и регистрацията на домейна и кой ги подновява?
  3. Има ли архиви, къде са и кога за последно е пробвано възстановяване?
  4. Има ли история на натоварването, или се гледа само моментът, в който нещо се е случило?
  5. Кой проверява дали формите и поръчките реално стигат до вас?

Ако на повечето от тези въпроси отговорът е „не знам“, това е добър момент да се изясни. Част от тях са описани и в статията Преди публикуването: техническа основа, SEO и поддръжка.

Заключение

Мониторингът не е една програма, а няколко слоя, които отговарят на различни въпроси. Uptime Kuma казва дали сайтът е достъпен. aaPanel дава бърз поглед върху сървъра. Blackbox Exporter проверява услугите и сертификатите им отвън, Prometheus пази резултатите и метриките във времето, а Grafana ги показва и подава алерти, когато нещо се отклонява. Логовете и вътрешните ни инструменти помагат да стигнем до причината.

Това наблюдение е част от абонаментната поддръжка на уеб сайтове и на онлайн магазини, която предлагаме. Ако искате да разберете как стои вашият сайт или сървър, можем да започнем с преглед на хостинга и инфраструктурата.