Tudástár / Üzemeltetés

Magento 2 hibakeresés: így találjuk meg, mi romlott el

A Magento hibakeresés módszer, nem találgatás. A vaktában cache-ürítés és modul-kikapcsolgatás gyakran eltünteti a tüneteket, miközben a hibát nem, így az a legrosszabbkor tér vissza.

frissítve 2026. szeptember 17. · sürgős hibánál soron kívül · WebPot DEV

Sürgősség

Azonnal hívj, ha a hiba a fizetést vagy a rendelés-feldolgozást érinti, ha betörés gyanúja merül fel vagy ha az áruház elérhetetlen.

  • Fizetési hibaazonnal
  • Áruház elérhetetlenazonnal
  • Betörés gyanújaazonnal
  • Beragadt rendelésekmég ma
  • Lassulástervezhető

A hibakeresés módszer, nem találgatás

A Magento 2 összetett rendszer: webszerver, PHP, adatbázis, Redis, keresőmotor, Varnish, cron és tucatnyi modul dolgozik együtt. Éppen ezért a kapcsoljuk ki-be módszer itt nem működik, sőt árt: eltünteti a tünetet, de nem az okát.

A profi hibakeresés mindig ugyanaz a három lépés: a hiba pontos reprodukálása, a megfelelő napló megtalálása, majd az ok megszüntetése. Nem a tünet elfedése.

A Magento beszédes, ha tudod, hol hallgatózz

A rendszer részletes naplókat vezet: az alkalmazás fő hibanaplói mellett külön naplója van a cron futásoknak, a fizetési modulnak, az integrációknak, a webszervernek és a PHP-nak is. A hibaüzenet helye maga is diagnózis: ha a webszerver naplójában van, a kérés el sem érte rendesen a Magentót; ha az alkalmazáséban, akkor kód- vagy konfigurációs probléma; ha egyikben sincs, jellemzően cache-ből jön a hibás tartalom.

Hol keressük?

  • Magento alkalmazás hibanaplók
  • Cron futások naplója és állapota
  • Fizetési és integrációs modulok naplói
  • PHP-FPM és webszerver naplók
  • Adatbázis lassú query napló
  • Redis és keresőmotor állapot

Élesben futó áruháznál a hibák részletei szándékosan nem jelennek meg a látogatónak, ezért a felszínen csak annyi látszik: valami nem megy. A napló nélküli hibabejelentés ezért mindig második körrel indul.

Hibaképek

Tünet és tipikus ok

A leggyakoribb bejelentések és az, hogy tapasztalatunk szerint mi áll mögöttük.

TünetTipikus ok
Fehér képernyő vagy általános hibaoldalPHP hiba: jellemzően modulütközés vagy elfogyott memória. A pontos okot a hibanapló mondja meg.
Checkout hiba, elakadó fizetésFizetési kapu válaszának hibás kezelése, session probléma vagy egy checkoutba nyúló modul. A legdrágább hibatípus.
Beragadt rendelés-státuszok, nem menő emailekSzinte mindig a cron: leállt, beragadt vagy egymásra torlódott feladatok.
Elavult árak és készletek az oldalonIndexelési vagy cache-érvénytelenítési hiba; gyakran importtal vagy MSI foglalás-elcsuszással függ össze.
Hirtelen lassulásFriss modul-telepítés, megtelt Redis, túlnőtt naplótáblák vagy lassú külső szolgáltatás.
Admin belépési problémákSession tár gond vagy éppen támadás jele. Utóbbi esetén a biztonsági teendők lépnek életbe.

A lassulásról részletesen a sebesség cikkben, a készlet-eltérésekről az MSI cikkben, a támadás-gyanús jelekről a biztonsági cikkben írunk.

Megelőzés

A hibajavítás ideje az áruház állapotán múlik

Ahol van staging környezet, verziókezelt kód, monitoring és naplógyűjtés, ott a hiba percek alatt lokalizálható és biztonságosan javítható. Ahol élesben kell nyomozni, dokumentálatlan módosítások között, ott ugyanaz a hiba napokig tarthat.

Ezért a karbantartási csomagjaink lényege nem az, hogy hibánál kit hívsz, hanem hogy a rendszer eleve úgy üzemel, hogy a hibák kiderüljenek, mielőtt a vásárló találkozik velük.

Ami megelőzi a bajt

  • Szolgáltatás-monitoring riasztással
  • Cron-őrzés: szól, ha leáll vagy torlódik
  • Hibanapló-figyelés és riasztás
  • Staging környezet minden változáshoz
  • Verziókezelt kód, visszafordítható telepítés
  • Dokumentált hozzáférések és architektúra
GYIK

Gyakran ismételt kérdések a hibakeresésről

Fehér képernyőt látok a webshop helyett. Mit tegyek?

Ne kezdj találomra cache-t ürítgetni: először a hibanaplót kell megnézni, az szinte mindig megmondja az okot. Ha nincs hozzáférésed vagy rutinod hozzá, ez gyors, távoli diagnózissal megoldható.

A vásárlók nem tudnak fizetni. Mennyire sürgős?

A legsürgősebb kategória: minden óra közvetlen bevételkiesés. Ilyen hibánál soron kívül, élesben diagnosztizálunk.

Nem mennek ki a rendelés-visszaigazoló emailek. Mi lehet az oka?

Tízből kilencszer a cron állt le vagy torlódott. A cron egészsége a Magento üzemeltetés egyik legfontosabb, mégis legtöbbet elhanyagolt eleme.

Modul frissítés után romlott el valami. Visszavonható?

Verziókezelt, mentett környezetben igen, percek alatt. E nélkül kockázatos élesben visszalépni; ez is érv a staging környezet mellett.

Tudtok segíteni, ha nem ti készítettétek az áruházat?

Igen, a munkáink jó része más által épített áruház átvétele. A hibajavításhoz hozzáférések kellenek, a diagnózishoz gyakran még teljes átadás sem szükséges.
Tovább a tudástárban

Kapcsolódó cikkek

Most van hiba?

Hívj, és a diagnózissal kezdjük. A javítás után megkapod az okot és a megelőzési javaslatot is írásban, mert a jó hibajavítás tanulsággal zárul.

Fel az oldal tetejéreAz oldal megosztása

#Magento hibakeresés #hibanapló #checkout hiba #cron