Monitoring czasu pracy bez przestojów, wydajności i błędów
Zinn Digital® monitoruje podane przez Państwa adresy URL – dostępność, wskaźniki Core Web Vitals oraz wykorzystanie zasobów w odniesieniu do przysługujących limitów – i prezentuje te dane dla każdej witryny w panelu sterowania. Alerty są wysyłane pocztą elektroniczną, do aplikacji Telegram, Slack lub na własny webhook, a nasza strona statusu działa poza platformą, dzięki czemu odpowiada również wtedy, gdy my nie możemy. Monitorowanie dostępności i prędkości wstrzykiwanych stron działa już teraz: można dodać dowolny adres internetowy – trzy bezpłatne na każdym koncie, przy czym nie musimy go hostować – a my sprawdzamy go co minutę spoza naszej sieci. Dostępność: śledzenie błędów dla poszczególnych witryn oraz statystyki zasobów dla poszczególnych witryn są w fazie aktywnego rozwoju i nie są jeszcze dostępne. Wszystko inne opisane w tym miejscu działa już dzisiaj.
Panele hostingowe zazwyczaj pokazują, za co płacisz. Nasz pokazuje, co robi Twoja strona. Każda witryna, którą u nas prowadzisz, przesyła ten sam zestaw sygnałów dla każdej strony osobno, bez konieczności instalowania agenta ani niczego podłączania.
Ciągłe kontrole dostępności dla każdej witryny, odniesione do jej własnej historii, dzięki czemu chwilowy spadek i prawdziwa awaria wyglądają inaczej. Stan czasu pracy to pierwszorzędny sygnał, na który platforma reaguje, a nie wykres, którego nikt nie czyta.
Rzeczywiste dane wydajnościowe dla każdej witryny – wskaźniki, na podstawie których Google faktycznie pozycjonuje strony. Wolne strony pojawiają się jako pomiar, na który można zareagować, tuż obok kontrolek pamięci podręcznej, które je naprawiają.
Dzienniki błędów HTTP i PHP są dostępne dla każdej strony, więc błąd krytyczny po nieudanej aktualizacji wtyczki lub zepsutym wdrożeniu można sprawdzić zamiast 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 zobaczyć, która witryna jest najbardziej obciążona i czy zbliża się do swojego limitu.
Panel, o którym musisz pamiętać, żeby go otworzyć, to nie monitoring. Każdy sygnał zasila warstwę powiadomień platformy, a Ty decydujesz, gdzie trafi.
Strona statusu hostowana na tej samej infrastrukturze, którą monitoruje, jest bezużyteczna dokładnie w tym momencie, w którym jej potrzebujesz. Nasza celowo znajduje się gdzie indziej.
Nasza publiczna strona statusu jest hostowana na niezależnej infrastrukturze, całkowicie poza platformą – na innym serwerze i w innej domenie awarii niż płaszczyzna sterowania oraz flota, której dotyczy raport. Kiedy z platformą dzieje się coś niedobrego, strona statusu nadal odpowiada, ponieważ żaden element, od którego jest zależna, nie znajduje się wewnątrz incydentu.
Jest spersonalizowany, zasilany tym samym systemem monitorowania, który obsługuje powiadomienia dla poszczególnych stron, i niezależny z założenia, a nie przez przypadek. Publiczny frontend kieruje się tą samą zasadą: strona marketingowa i centrum pomocy są wdrażane oddzielnie od klastra płaszczyzny sterowania, dzięki czemu awaria platformy nie pociąga za sobą naszej dokumentacji.
To samo rozumowanie przewija się przez resztę platformy — oddzielne domeny awarii, brak wspólnego losu, nic, co mogłoby zniszczyć zarówno zasób, jak i narzędzie służące do diagnozowania go.
Sygnały są tym cenniejsze, im szybciej można na ich podstawie podjąć działanie. Nasze są zintegrowane z asystentem i serwerem MCP, a nie zamknięte w wykresie.
Zanim w sprawę zaangażuje się człowiek, asystent uruchamia na początku na żywo diagnostykę dla dotkniętej problemem witryny: dostępność, błędy HTTP i PHP, stan SSL i DNS, limity zasobów i błędy LVE, flagi złośliwego oprogramowania, konflikty wtyczek, kondycję bazy danych oraz pamięć podręczną.
W granicach Twoich uprawnień oraz mechanizmów zabezpieczających platformy wyczyści pamięć podręczną, zrestartuje procesy PHP, naprawi lub odnowi certyfikat SSL, naprawi tabele bazy danych, wyłączy wtyczkę powodującą krytyczny błąd lub wyczyści CDN, a następnie ponownie sprawdzi sygnał i potwierdzi, czy problem faktycznie został rozwiązany.
Jeśli nadal potrzebny będzie człowiek, zgłoszenie dociera wstępnie uzupełnione o dane diagnostyczne, informacje o podjętych próbach i ich wynikach — dzięki czemu dział wsparcia zaczyna od faktów, zamiast prosić Cię o opisanie objawu.
Połącz dowolne narzędzie AI obsługujące protokół MCP, aby mogło ono odczytywać stan witryny, ostatnie logi, metryki, czas bezawaryjnej pracy oraz błędy jako zasoby – dzięki czemu Twój własny agent może dokonać diagnozy przed podjęciem działania, w oparciu o protokół OAuth 2.1 z tokenami o ograniczonym zakresie ról i organizacji, z możliwością ich unieważnienia oraz pełnym dziennikiem audytu.
Monitorowanie wydajności znajduje się obok narzędzi, które tę wydajność zmieniają. Na naszej platformie leży ono pomiędzy stosem pamięci podręcznej a warstwą SEO.
Za Twoim panelem stoi ten sam stos obserwowalności, na którym opieramy naszą platformę: Prometheus i Grafana dla metryk, OpenTelemetry do śledzenia rozproszonego w całym silniku, przepływach pracy i sterownikach, oraz scentralizowane logi strukturalne oznaczone identyfikatorem najemcy, z oddzielnie przechowywanymi danymi audytowymi.
Metryki są zbierane dla każdej usługi, każdego workera i każdego tenanta, ze statystykami LVE dla każdej strony z warstwy izolacji. Każde uruchomienie workflow – provisionowanie, migracja, egzekwowanie – jest widoczne od początku do końca, dlatego odpowiedź wsparcia technicznego może być konkretna, a nie oparta na domysłach.
Monitorowanie na dużą skalę to problem wielkości danych, więc i zaprojektowano je w ten sposób. Metryki o dużej objętości są partycjonowane czasowo i agregowane zamiast być trzymane dla każdej witryny co minutę na zawsze, śledzenia (traces) są prókowane, a kontrola kardynalności dla poszczególnych najemców (tenants) uniemożliwia jednemu hałaśliwemu kontu pogarszanie działania pulpitów wszystkich pozostałych. Celem projektowym jest milion witryn, a nie liczba, którą obsługujemy dzisiaj.
Alerty są kierowane przez Alertmanager do naszego grafiku dyżurów ze zdefiniowanymi i śledzonymi wskaźnikami SLO – celowo oddzielonymi od powyższych powiadomień dla klientów, dzięki czemu szum operacyjny nigdy nie trafia do Twojej skrzynki odbiorczej, a Twoje alerty nigdy nie stoją w kolejce za naszymi.
Dla każdej strony: czas bezawaryjnej pracy, Core Web Vitals i wydajność, przepustowość oraz zużycie zasobów w odniesieniu do limitów Twojego planu – w tym statystyki LVE dla poszczególnych stron z warstwy izolacji. Wszystko to jest widoczne w panelu dla każdej strony, bez konieczności instalowania jakichkolwiek agentów.
Za pomocą wybranych kanałów połączenia: e-mail, Telegram, Slack lub własny punkt końcowy webhook. Preferencje powiadomień są ustawiane dla każdej organizacji i każdego użytkownika, dzięki czemu sam decydujesz, które zdarzenia docierają do jakiego kanału i jakiej osoby. Dostarczenia webhooków są podpisane kluczem HMAC, ponawiane z użyciem mechanizmu wycofywania i rejestrowane w dzienniku, co umożliwia sprawdzenie lub ponowne wysłanie dowolnego dostarczenia.
Właśnie temu ma to zapobiegać. Strona statusowa jest hostowana samodzielnie na osobnej infrastrukturze, całkowicie poza platformą, w innej domenie awarii niż płaszczyzna sterowania i obsługiwana przez nią flaga — ponieważ strona statusowa działająca na monitorowanej przez siebie infrastrukturze jest bezużyteczna w czasie awarii.
Jest to cel dotyczący dostępności, do którego dążymy i który realizujemy, a także deklaracja zawarta w planach Footprint-Free. Jest to zobowiązanie dotyczące sposobu zaprojektowania platformy – izolowane zasoby obliczeniowe dla każdej strony, hipotetycznie skalowalne usługi bezstanowe, oddzielne domeny awarii – a nie publikowany pomiar wcześniejszej dostępności. Nasze zobowiązanie umowne jest kwestią osobną i bardziej węższą oraz zostało opublikowane: zobacz umowę SLA dotyczącą dostępności pod adresem /legal/sla, która określa gwarantowany przez nas poziom oraz kredyty za usługi wypłacane w przypadku jego niedotrzymania.
Tak. Stan witryny, ostatnie logi, metryki, dostępność i dane o błędach są udostępniane jako zasoby na naszym hostowanym serwerze MCP, dzięki czemu każde narzędzie AI obsługujące MCP — takie jak Claude, Cursor, ChatGPT i inne — może je odczytać i zdiagnozować problem przed podjęciem działania. Dostęp odbywa się za pomocą protokołu OAuth 2.1, z uprawnieniami ograniczonymi do organizacji i roli łączącego się użytkownika, z możliwością odwołania uprawnień dla każdego narzędzia, a każde działanie jest rejestrowane w dzienniku audytu. Webhooki klientów obejmują ten sam zakres w przypadku konwencjonalnych integracji.
Sygnały obserwowalności opisane tutaj są częścią platformy i są widoczne w Twoim panelu dla stron, które u nas hostujesz, a darmowy kafelek SEO Basics — zindeksowane, Trust Flow, Core Web Vitals strony głównej — jest dołączony do każdego planu. Głęboki monitoring SEO, taki jak śledzenie pozycji i monitorowanie linków zwrotnych, jest sprzedawany jako osobne płatne dodatki, a praktyczna optymalizacja prędkości jest płatną usługą dodatkową.
Tak. 14-dniowy okres próbny Footprint-Free nie wymaga podawania karty i obejmuje do 5 witryn – żadnych danych płatności ani zobowiązań. Wdróż kilka witryn i zobacz, co naprawdę raportuje panel, zanim podejmiesz decyzję.
Rozpocznij 14-dniowy okres próbny bez podawania karty i od pierwszego wdrożenia monitoruj czas bezawaryjnej pracy, wskaźniki Core Web Vitals, błędy oraz zużycie zasobów dla każdej strony — z powiadomieniami tam, gdzie ich potrzebujesz. Wszystko to z darmowymi migracjami i 30-gwarancją zwrotu pieniędzy.
Rozpocznij za darmo