Üzemidő, teljesítmény- és hibamonitorozás
A Zinn Digital® figyelemmel kíséri az általunk megadott webcímeket – az üzemidőt, a Core Web Vitals mutatókat és az erőforrás-felhasználást az Ön jogosultságához képest –, és webhelyenként megjeleníti ezeket az irányítópulton. Riasztások küldhetők e-mailben, Telegramon, Slacken vagy saját webhookon keresztül, és az állapotoldalunk a platformon kívül működik, így akkor is válaszol, amikor mi nem tudunk. Az üzemidő- és oldalsebesség-felügyelet már él: adjon hozzá bármilyen webcímet (minden fiókhoz három ingyenes jár, és nem kell nálunk hosztolnia), és percenként ellenőrizzük a saját hálózatunkon kívülről. Elérhetőség: a webhelyenkénti hibakövetés és a webhelyenkénti erőforrás-statisztika aktív fejlesztés alatt áll, és még nem érhető el. Minden egyéb itt leírt dolog máris élesben működik.
A tárhelykezelő felületek általában azt mutatják meg, hogy miért fizetsz. A miénk azt, hogy mit csinál a weboldalad. Nálunk az összes futó oldalad ugyanazt a jelsorozatot küldi oldalanként, ügynök telepítése és bármiféle bekötés nélkül.
Folyamatos rendelkezésreállási ellenőrzések webhelyenként, a webhely saját előzményéhez viszonyítva, így egy átmeneti hiba és egy valódi leállás megkülönböztethető egymástól. Az üzemidő állapota kiemelt jelzés, amely alapján a platform cselekszik, nem pedig egy olyan grafikon, amelyet senki sem olvas.
Valós teljesítményadatok webhelyenként – azok a metrikák, amelyek alapján a Google a rangsort alakítja. A lassú oldalak cselekvésre ösztönző mérőszámként jelennek meg azokat javító gyorsítótár-vezérlők mellett.
A HTTP- és PHP-hibanaplók webhelyenként elérhetők, így egy hibás bővítményfrissítésből vagy egy elrontott telepítésből adódó végzetes hiba kinyomozható ahelyett, hogy csak talgatni kellene.
Webhelyenkénti sávszélesség, valamint az előfizetésed keretéhez mért erőforrás-használat (beleértve a webhelyenkénti LVE-statisztikákat is), így láthatod, hogy melyik webhely dolgozik a legkeményebben, és hogy közel van-e a korlátjához.
Az olyan irányítópult, amelyet külön meg kell nyitni, nem monitorozás. Minden egyes jel a platform értesítési rétegébe fut be, és te döntöd el, hogy hol landol.
A felügyelt infrastruktúrán hosztolt státuszoldal pontosan abban a pillanatban válik használhatatlanná, amikor a legnagyobb szüksége lenne rá. A miénk szándékosan máshol található.
A nyilvános státuszoldalunk külön infrastruktúrán, teljesen platformon kívül saját magán fut – egy másik gépen, egy másik hibatűrési tartományban, mint a vezérlőréteg és az általa felügyelt géppark. Ha valami elromlik a platformon, a státuszoldal továbbra is elérhető marad, mert semmi olyanra nem támaszkodik, ami az incidens része lenne.
Ez egyedi márkájú, ugyanaz a felügyeleti rendszer táplálja, amely az egyes webhelyekre vonatkozó riasztásokat is biztosítja, és tervezése révén független, nem pedig a véletlen műve. A nyilvános felület ugyanezt az elvet követi: a marketingoldal és a súgóközpont külön van telepítve a vezérlősík-fürtre, így egy platformon bekövetkező incidens nem rántja magával a dokumentációnkat is.
Ugyanez a logika érvényes a platform többi részére is – különálló hibatartományok, nincs közös sors, semmi olyan, ami kiüthetné egyszerre a dolgot és az annak diagnosztizálására használt eszközt.
A szignálok többet érnek, ha valaki cselekedni tud velük. A mieink be vannak kötve az asszisztensbe és az MCP szerverbe, nincsenek egy gráfba zárva.
Amikor hibajegyet nyit, az asszisztens először élő diagnosztikát futtat az érintett webhelyen – az üzemidőt, a HTTP- és PHP-hibákat, az SSL- és DNS-állapotot, az erőforrás-korlátokat és az LVE-hibákat, a kártevőre utaló jeleket, a bővítmények ütközéseit, az adatbázis állapotát és a gyorsítótárat vizsgálva –, mielőtt bárki emberi beavatkozásra sor kerülne.
A jogosultságaitokon és a platform korlátozásain belül törölni fogja a gyorsítótárat, újraindítja a PHP-munkameneteket, kijavítja vagy megújítja az SSL-t, kijavítja az adatbázistáblákat, letilt egy végzetes hibát okozó bővítményt, vagy kiüríti a CDN-t – majd újraellenőrzi a jelet, és megerősíti, hogy valóban megoldódott-e a probléma.
Ha mégis emberre van szükség, a jegy előre kitöltve érkezik a diagnosztikával, a megkísérelt lépésekkel és az eredménnyel – így az ügyfélszolgálat a tényekből indul ki ahelyett, hogy a tünet leírását kérné.
Csatlakoztasson bármilyen MCP-képes AI-eszközt, amely erőforrásként képes olvasni a webhely állapotát, a legfrissebb naplókat, metrikákat, az üzemidőt és a hibákat – így a saját ágense a cselekvés előtt diagnosztizálhatja a problémákat, OAuth 2.1 keretében, szervezet- és szerepkörhöz kötött, visszavonható tokenekkel és teljes naplóhellyel.
A teljesítményfigyelés oda tartozik, ahol a teljesítményt befolyásoló eszközök vannak. A platformunkon ez a gyorsítótárazási réteg és az SEO réteg között helyezkedik el.
A műszerfalad mögött ugyanaz az observability verem fut, mint amilyenre a platformunkat építettük: Prometheus és Grafana a metrikákhoz, OpenTelemetry a motoron, a munkafolyamatokon és a meghajtókon átívelő elosztott nyomkövetéshez, valamint centralizált, bérlőcímkével ellátott strukturált naplók, különálló naplózott auditadatokkal.
A metrikákat szolgáltatásonként, munkavégzőként és bérlőként gyűjtjük, az izolációs rétegből származó webhelyenkénti LVE-statisztikákkal együtt. Minden munkafolyamat-futtatás – legyen szó kiépítésről, migrációról vagy érvényesítésről – elejétől a végéig látható, ezért a támogatási válasz találgatás helyett pontos lehet.
A nagyságrendű felügyelet adamennyiségi probléma, ezért ennek megfelelően is van megtervezve. A nagy volumenű metrikák időalapú partícionálást kapnak és összesítve tárolódnak a helyenkénti és percenkénti örökös megőrzés helyett, a nyomkövetési adatok mintavételezettek, a bérlőnkénti kardinalitásszabályok pedig megakadályozzák, hogy egyetlen zajos fiók lerontsa bárki más vezérlőpultját. A tervezési cél egymillió webhely, nem pedig az a szám, amelyet ma üzemeltetünk.
A riasztások az Alertmanageren keresztül futnak be az ügyeleti beosztásunkba a meghatározott és követett SLO-k szerint – szándékosan elkülönítve a fenti ügyfélsértesítésektől, hogy az operációs zaj soha ne kerüljön az Ön postafiókába, és a riasztásai ne torlódjanak a mieink mögé.
Webhelyenként: rendelkezésre állás, Core Web Vitals és teljesítmény, sávszélesség, valamint az előfizetési csomag kereteihez mérött erőforrás-használat – beleértve az izolációs réteg webhelyenkénti LVE-statisztikáit is. Mindez a vezérlőpulton jelenik meg webhelyenként, telepítendő ügynök nélkül.
Bármely csatornán is csatlakozik: e-mailen, Telegram, Slack vagy a saját webhook végpontján keresztül. Az értesítési beállítások szervezetenként és felhasználónként külön állíthatók be, így ön dönti el, hogy mely események melyik csatornára és kihez jutnak el. A webhook kézbesítések HMAC-alapú aláírással rendelkeznek, hibák esetén várakozási idővel újrapróbálásra kerülnek, és naplózásra is kerülnek, így bármilyen kézbesítést ellenőrizhet vagy újraindíthat.
Pontosan ezt hivatott elkerülni. Az állapotoldal saját infrastruktúrán, teljesen platformon kívül, a vezérlőrétegtől és az általa felügyelt gépparktól eltérő hibatartományban fut, mert az olyan állapotoldal, amely a figyelt infrastruktúrán fut, egy leállás során használhatatlan.
Ez az a rendelkezésre állási cél, amelyre építünk és amellyel dolgozunk, és garanciaként szerepel a Footprint-Free csomagokon. Ez egy elkötelezettség a platform felépítését illetően – webhelyenként izolált számítási kapacitás, horizontálisan skálázható, állapotmentes szolgáltatások, különálló hibatartományok –, nem pedig a korábbi rendelkezésre állás közzétett mérése. Szerződéses elkötelezettségünk egy különálló és szűkebb körű dolog, amely nyilvánosan elérhető: lásd az Uptime SLA-t a /legal/sla címen, amely meghatározza az általunk garantált szintet és az abból adódó szolgáltatási jóváírásokat, ha nem érjük el azt.
Igen. A webhely állapota, a legutóbbi naplók, a metrikák, az üzemidő és a hibák adatai erőforrásként érhetők el a hosztolt MCP-kiszolgálónkon keresztül, így bármilyen MCP-képes AI-eszköz – a Claude, a Cursor, a ChatGPT és mások – képes olvasni ezeket, és diagnosztizálni a cselekvés előtt. A hozzáférés OAuth 2.1 alapú, az Ön szervezetére és a csatlakozó felhasználó szerepkörére korlátozva, eszközönként visszavonható, és minden művelet naplózásra kerül az auditálás érdekében. Az ügyfél-webhookok ugyanezeket a területeket fedik le a hagyományos integrációkhoz.
Az itt leírt megfigyelhetőségi jelek a platform részét képezik, és a nálunk hostolt webhelyekhez tartozó irányítópulton jelennek meg, az ingyenes SEO Basics csempe – indexelt, Trust Flow, homepage Core Web Vitals – pedig minden csomagban benne van. Az olyan mélyebb SEO-monitorozás, mint a helyezéskövetés és a backlink-monitorozás, külön megvásárolható kiegészítőként érhető el, a gyakorlati sebességoptimalizálás pedig megvásárolható extra szolgáltatás.
Igen. A Footprint-Free próbaveridó 14 napos, kártya nélkül igénybe vehető, és legfeljebb 5 webhelyre érvényes – nincs szükség fizetési adatokra, és semmilyen elkötelezettséggel nem jár. Helyezzen üzembe néhány webhelyet, és nézze meg, mit jelez a felület, mielőtt döntést hozna.
Indítson el egy kártyaadatok nélkül igénybe vehető, 14 napos próbaidőszakot, és tekintse meg az üzemidőt, a Core Web Vitals mutatókat, a hibákat és az erőforrás-felhasználást webhelyenként már az első üzembe helyezéstől kezdve – értesítésekkel ott, ahol csak szeretné. Minden mögött ingyenes migráció és 30 napos pénzvisszafizetési garancia áll.
Kezdje ingyen