Monitorowanie dostępności, wydajności i błędów
Zinn Digital® monitoruje podane przez Państwa adresy internetowe — czas bezawaryjnej pracy, wskaźniki Core Web Vitals i zużycie zasobów w odniesieniu do Państwa limitu — oraz prezentuje te dane dla każdej witryny w panelu. Alerty są wysyłane na e-mail, do aplikacji Telegram, Slack lub do Państwa własnego webhooka, a nasza strona statusu działa poza platformą, więc odpowiada nawet wtedy, gdy my nie możemy. Monitorowanie czasu bezawaryjnej pracy i szybkości stron działa już teraz: proszę dodać dowolny adres internetowy — trzy bezpłatne na każdym koncie, bez konieczności hostowania u nas — a my będziemy go sprawdzać co minutę spoza naszej własnej sieci. Dostępność: śledzenie błędów dla poszczególnych witryn oraz statystyki zasobów dla poszczególnych witryn są w trakcie aktywnego rozwoju i nie są jeszcze dostępne. Wszystkie pozostałe opisane tutaj funkcje są już aktywne.
Pulpity nawigacyjne hostingu zazwyczaj informują o tym, za co Państwo płacą. Nasz pokazuje, co dzieje się z Państwa witryną. Każda witryna prowadzona u nas zgłasza ten sam zestaw sygnałów dla każdej strony, bez konieczności instalowania agenta i bez potrzeby jakiejkolwiek konfiguracji połączeń.
Ciągłe sprawdzanie dostępności dla każdej witryny, zestawiane z jej własną historią, dzięki czemu chwilowa anomalia i rzeczywista awaria są wyraźnie rozróżniane. Stan dostępności jest kluczowym sygnałem, na który platforma reaguje, a nie wykresem, którego nikt nie czyta.
Rzeczywiste dane o wydajności dla każdej witryny — dane wskaźnikowe, na podstawie których Google faktycznie ustala pozycję w rankingu. Wolne strony pojawiają się w postaci pomiaru umożliwiającego podjęcie działań, tuż obok elementów sterujących buforowaniem, które je naprawiają.
Dzienniki błędów HTTP i PHP są dostępne dla każdej witryny z osobna, więc krytyczny błąd wynikający z nieudanej aktualizacji wtyczki lub wadliwego wdrożenia można łatwo znaleźć, zamiast jedynie zgadywać.
Przepustowość dla każdej witryny oraz użycie zasobów mierzone względem limitów twojego planu — w tym statystyki LVE dla poszczególnych witryn — dzięki czemu możesz sprawdzić, która witryna jest najbardziej obciążona i czy nie zbliża się do limitu.
Pulpit nawigacyjny, o którego otwarciu trzeba pamiętać, to nie monitorowanie. Każdy sygnał zasila warstwę powiadomień platformy, a Państwo wybierają, dokąd trafia.
Strona stanu hostowana na tej samej infrastrukturze, którą monitoruje, jest bezużyteczna dokładnie w momencie, gdy jej Państwo potrzebują. Nasza celowo znajduje się w innym miejscu.
Nasza publiczna strona stanu jest hostowana we własnym zakresie na odrębnej infrastrukturze, całkowicie poza platformą — na innej maszynie, w innej domenie awarii niż płaszczyzna kontrolna i flota, o której raportuje. Kiedy coś pójdzie nie tak z platformą, strona stanu nadal odpowiada, ponieważ nic, od czego zależy, nie znajduje się w strefie incydentu.
Jest w pełni obrandowany, zasilany przez ten sam system monitorowania, który obsługuje alerty dla poszczególnych witryn, oraz niezależny z założenia, a nie przez przypadek. Publiczny frontend działa według tej samej zasady: strona marketingowa i centrum pomocy są wdrażane niezależnie od klastra control-plane, dzięki czemu awaria platformy nie powoduje niedostępności naszej dokumentacji.
Jest to ta sama logika, która przyświeca reszcie platformy — odrębne domeny awarii, brak wspólnego losu i brak elementów, które mogłyby unieruchomić zarówno sam zasób, jak i narzędzie używane przez Państwa do jego diagnostyki.
Sygnały mają większą wartość, gdy można na nie zareagować. Nasze sygnały są połączone z asystentem i serwerem MCP, a nie zablokowane w grafie.
Gdy rozpoczynają Państwo zgłaszanie zgłoszenia, asystent najpierw przeprowadza diagnostykę na żywo dotkniętej witryny — czas działania, błędy HTTP i PHP, stan SSL i DNS, limity zasobów i błędy LVE, flagi złośliwego oprogramowania, konflikty wtyczek, stan bazy danych i pamięć podręczną — zanim jeszcze zaangażuje się w to człowiek.
W ramach twoich uprawnień i zabezpieczeń platformy wyczyści pamięć podręczną, zrestartuje procesy robocze PHP, naprawi lub odnowi certyfikat SSL, naprawi tabele bazy danych, wyłączy wtyczkę powodującą błąd krytyczny lub wyczyści CDN — a następnie ponownie sprawdzi sygnał i potwierdzi, czy problem rzeczywiście został rozwiązany.
Jeśli interwencja człowieka nadal jest potrzebna, zgłoszenie trafia do zespołu ze wstępnie wypełnionymi danymi diagnostycznymi, informacją o podjętych próbach oraz tym, co się wydarzyło — dzięki temu dział wsparcia zaczyna od faktów, zamiast prosić Pana/Panią o opisanie objawów.
Połącz dowolne narzędzie AI obsługujące MCP, a będzie ono mogło odczytywać stan witryny, ostatnie dzienniki, wskaźniki, czas bezawaryjnej pracy oraz błędy jako zasoby — dzięki czemu twój własny agent może przeprowadzić diagnozę przed podjęciem działań, w ramach OAuth 2.1 z odwoływalnymi tokenami o zakresie ograniczonym do organizacji i ról oraz pełnym dziennikiem audytu.
Monitorowanie wydajności powinno znajdować się obok narzędzi, które tę wydajność zmieniają. Na naszej platformie mieści się ono między stosem buforowania a warstwą SEO.
Za twoim panelem znajduje się ten sam stos obserwowalności, na którym uruchamiamy platformę: Prometheus i Grafana do obsługi metryk, OpenTelemetry do rozproszonego śledzenia w obrębie silnika, przepływów pracy i sterowników oraz scentralizowane ustrukturyzowane dzienniki oznaczone tagami najemców z oddzielnie przechowywanymi danymi audytowymi.
Metryki są zbierane dla każdej usługi, procesu roboczego i najemcy, wraz ze statystykami LVE dla poszczególnych witryn z warstwy izolacji. Każde uruchomienie przepływu pracy — aprowizacja, migracja, egzekwowanie — jest widoczne od początku do końca, dlatego odpowiedź działu wsparcia może być konkretna, a nie oparta na domysłach.
Monitorowanie na dużą skalę to problem ilości danych, dlatego tak zostało zaprojektowane. Metryki o dużym wolumenie są dzielone według czasu i agregowane, zamiast być przechowywane bezterminowo dla każdej witryny z dokładnością co do minuty, ślady podlegają próbkowaniu, a kontrola kardynalności na poziomie każdego najemcy zapobiega sytuacji, w której jedno generujące duży ruch konto pogarsza działanie pulpitów nawigacyjnych pozostałych użytkowników. Celem projektu jest milion witryn, a nie liczba, którą obsługujemy obecnie.
Alerty są przekazywane przez Alertmanager do naszego dyżurnego zespołu z określonymi i monitorowanymi celami SLO — celowo oddzielone od powyższych powiadomień dla klientów, dzięki czemu szum operacyjny nigdy nie trafia do Państwa skrzynki odbiorczej, a Państwa alerty nigdy nie czekają w kolejce za naszymi.
Dla każdej witryny: czas bezawaryjnej pracy, Core Web Vitals i wydajność, przepustowość oraz zużycie zasobów mierzone względem limitów Państwa planu — w tym statystyki LVE dla poszczególnych witryn z warstwy izolacji. Wszystko to jest prezentowane w panelu kontrolnym dla każdej witryny, bez konieczności instalowania agenta.
Za pośrednictwem dowolnych połączonych kanałów: e-mail, Telegram, Slack lub własny webhook endpoint. Preferencje powiadomień są ustawiane dla każdej organizacji i każdego użytkownika, dzięki czemu to Państwo decydują, które zdarzenia trafiają do określonego kanału i osoby. Doręczenia webhooków są podpisywane za pomocą HMAC, ponawiane z mechanizmem backoff i rejestrowane w dzienniku, co umożliwia sprawdzenie lub ponowne wysłanie każdego doręczenia.
Zostało to zaprojektowane dokładnie po to, aby tego uniknąć. Strona stanu jest hostowana we własnym zakresie na oddzielnej infrastrukturze, całkowicie poza platformą, w innej domenie awarii niż płaszczyzna sterowania i monitorowana flota — ponieważ strona stanu działająca na tej samej infrastrukturze, którą monitoruje, jest bezużyteczna podczas awarii.
Jest to docelowy czas dostępności, zgodnie z którym budujemy i prowadzimy platformę, określany jako zapewnienie w planach Footprint-Free. Stanowi zobowiązanie dotyczące sposobu zaprojektowania platformy — izolowane zasoby obliczeniowe dla każdej witryny, skalowalne horyzontalnie usługi bezstanowe, odrębne domeny awarii — a nie opublikowany pomiar wcześniejszej dostępności. Nasze zobowiązanie umowne jest kwestią odrębną i węższą, a ponadto zostało opublikowane: prosimy zapoznać się z Uptime SLA pod adresem /legal/sla, gdzie określono poziom, który gwarantujemy, oraz rekompensaty w postaci kredytów usługowych wypłacane w przypadku jego niespełnienia.
Tak. Stan witryny, ostatnie dzienniki, metryki, czas sprawności oraz dane o błędach są udostępniane jako zasoby za pośrednictwem naszego hostowanego serwera MCP, dzięki czemu każde narzędzie AI obsługujące MCP — Claude, Cursor, ChatGPT i inne — może je odczytać i przeprowadzić diagnostykę przed podjęciem działań. Dostęp opiera się na protokole OAuth 2.1, ma zakres ograniczony do Państwa organizacji oraz roli łączącego się użytkownika, może być odwoływany dla poszczególnych narzędzi, a każde działanie jest rejestrowane w dzienniku audytu. Webhooki klienta zapewniają ten sam zakres możliwości w przypadku tradycyjnych integracji.
Opisane tutaj sygnały obserwowalności są częścią platformy i pojawiają się w panelu dla witryn hostowanych u nas, a bezpłatny kafelek SEO Basics — zaindeksowane, Trust Flow, Core Web Vitals strony głównej — jest dołączony do każdego planu. Bardziej zaawansowane monitorowanie SEO, takie jak śledzenie pozycji i monitorowanie linków zwrotnych, jest sprzedawane jako oddzielne płatne dodatki, a praktyczna optymalizacja szybkości jest płatną opcją dodatkową.
Tak. Wersja próbna Footprint-Free trwa 14 dni, nie wymaga karty i obejmuje do 5 witryn — bez danych płatniczych, bez zobowiązań. Przed podjęciem decyzji wdróż kilka witryn i zobacz, co w rzeczywistości raportuje panel kontrolny.
Rozpocznij 14-dniowy okres próbny bez karty i monitoruj czas sprawności, Core Web Vitals, błędy oraz wykorzystanie zasobów dla każdej witryny już od pierwszego wdrożenia — z powiadomieniami tam, gdzie chcesz. Bezpłatne migracje i 30-dniowa gwarancja zwrotu pieniędzy w standardzie.
Rozpocznij za darmo