Monitoring integrací — jak se dozvědět o chybě dřív než zákazník
Integrace málokdy spadne nahlas. Častěji tiše přestane posílat data a na chybu přijde zákazník nebo účetní. Ukážeme, co měřit, jak nastavit alerty a jak zachytit i to, co se nestalo.
Integrace e-shopu málokdy spadne nahlas. Častěji tiše přestane posílat data. Objednávky se nepropíšou do ERP, sklad se přestane aktualizovat, dodavatelský feed se dva dny nestáhne. Server přitom běží a web se načítá. Na chybu přijde zákazník, který si koupí zboží, co už není skladem. Nebo účetní na konci měsíce.
Monitoring integrací má jediný cíl: dozvědět se o problému dřív než ten, koho poškodí. V článku ukazujeme, co měřit, jak nastavit alerty, aby nerušily zbytečně, a hlavně jak zachytit chyby, při kterých nic nespadne, jen se něco nestane.
Proč nestačí hlídat, jestli web běží
Klasický uptime monitor zkontroluje, že adresa vrací odpověď. U integrací je to málo. Typické tiché chyby vypadají takto:
- Webhook s novou objednávkou se nedoručí a platforma ho po několika pokusech vzdá.
- Cron úloha se spustí, ale kvůli změně formátu u dodavatele naimportuje nula produktů a skončí „úspěšně“.
- Token k API vyprší a synchronizace skladu od té chvíle jen zapisuje chyby do logu, který nikdo nečte.
- ERP odpovídá, ale pomalu. Fronta zpráv roste a objednávky dorazí se zpožděním několika hodin.
Ve všech případech je server „zelený“. Proto je potřeba měřit tok dat, ne jen dostupnost.
Co platformy dělají s nedoručenými webhooky
Webhooky jsou nejrychlejší způsob, jak se e-shop dozví o nové objednávce nebo platbě. Zároveň jsou nejčastějším místem tiché ztráty dat. Každá platforma má jiná pravidla opakování (dokumentace k 9/2026):
| Platforma | Co se stane při neúspěšném doručení |
|---|---|
| Shoptet | Na odpověď čeká 4 sekundy. Nepotvrzenou notifikaci zopakuje dvakrát po 15 minutách, celkem tedy 3 pokusy. Pak ji označí jako neaktivní a dál ji neposílá. |
| Shopify | Opakuje 8× během 4 hodin. Pokud selžou všechny pokusy u odběru vytvořeného přes Admin API, odběr webhooku smaže a pošle varovný e-mail vývojáři aplikace. |
| WooCommerce | Po sérii zhruba pěti neúspěšných doručení webhook automaticky deaktivuje. Znovu ho musíte zapnout ručně v nastavení. |
Z tabulky plyne praktický závěr. Když váš přijímací server vypadne na hodinu, u Shoptetu část událostí prostě nedorazí. U WooCommerce se webhook vypne úplně a nové objednávky už nepřijdou vůbec, dokud si toho někdo nevšimne. Monitoring proto musí počítat s tím, že webhook není záruka doručení.
Shoptet vede log doručení včetně počtu opakování a stavu. Číst ho jde přes endpoint GET /api/webhooks/notifications. Pravidelná kontrola tohoto logu je jednoduchý první krok, který většina napojení nemá.
Čtyři signály, které stojí za měření
Google ve své knize o Site Reliability Engineering popisuje čtyři „zlaté signály“ monitoringu: latenci, provoz, chyby a saturaci. Pro integrace e-shopu je přeložíme do konkrétních metrik:
| Signál | Co měřit u integrace | Příklad alertu |
|---|---|---|
| Latence | Jak dlouho trvá, než objednávka z e-shopu dorazí do ERP | Objednávka starší 15 minut bez čísla dokladu v ERP |
| Provoz | Počet zpracovaných událostí za hodinu | Za poslední 2 hodiny přišlo 0 objednávek v době, kdy běžně chodí desítky |
| Chyby | Podíl neúspěšných volání API, odpovědi 4xx a 5xx | Víc než 5 % chyb za 10 minut |
| Saturace | Délka fronty, spotřeba limitů API | Fronta roste 30 minut v kuse |
Konkrétní prahy si nastavte podle svého provozu. Uvedená čísla jsou výchozí bod, ne pravidlo.
Samostatnou kapitolou jsou limity API. Když integrace narazí na limit, REST API obvykle vrátí stavový kód 429 Too Many Requests, často s hlavičkou Retry-After, která říká, kdy to zkusit znovu. Shopify u GraphQL Admin API vrací v každé odpovědi objekt throttleStatus s aktuálně dostupnými body a rychlostí jejich doplňování. Tyto hodnoty stojí za to logovat. Uvidíte blížící se problém dřív, než začnou požadavky padat.
Hlídejte i to, co se nestalo
Nejzákeřnější chyby jsou ty, kdy nepřijde žádná chybová hláška. Na ně fungují dvě techniky.
Heartbeat. Každá plánovaná úloha na konci úspěšného běhu pošle signál „jsem hotová“. Monitoring ví, že import skladu z cronu má proběhnout každých 30 minut. Když signál nepřijde do 45 minut, spustí alert. Nezáleží na tom, jestli úloha spadla, zasekla se, nebo ji někdo omylem vypnul.
Kontrola rozdílů (reconciliation). Jednou za hodinu nebo za den porovnáte data na obou stranách. Kolik objednávek vzniklo v e-shopu a kolik jich je v ERP? Sedí skladové zásoby u stovky náhodně vybraných produktů? Rozdíl znamená, že někde po cestě něco zmizelo. Tahle kontrola odhalí i chyby, které žádný jiný monitoring nezachytí. A zároveň opravuje následky ztracených webhooků, protože chybějící záznamy může rovnou dotáhnout.
K heartbeatu patří i kontrola obsahu. Import, který skončil úspěšně, ale zpracoval 0 položek místo obvyklých 12 000, je chyba. Hlídejte proto i počty, ne jen stav „hotovo“. U dodavatelských feedů tomu věnujeme samostatný článek Monitoring a alerty na chyby feedů.
Alerty, které lidi nepřestanou číst
Špatně nastavený monitoring je horší než žádný. Když chodí padesát hlášek denně, lidé je přestanou číst a skutečný problém zapadne. Pár pravidel, která dodržujeme:
- Každý alert musí mít jasnou akci. Pokud na hlášku nikdo nic neudělá, nepatří do alertů, ale do reportu.
- Rozlišujte naléhavost. Nedoručené objednávky jsou okamžitý telefon. Pomalejší import obrázků je položka v ranním souhrnu.
- Alertujte na příznaky, ne na příčiny. „Objednávky nedorazily do ERP“ je užitečnější než „CPU na 90 %“.
- Seskupujte. Jedna hláška „synchronizace skladu selhává 20 minut“ je lepší než dvacet hlášek po minutě.
- Posílejte alert tam, kde ho někdo uvidí. Kanál, který nikdo nesleduje, není kanál.
V alertu má být, co se stalo, od kdy, jaký je dopad a odkaz na log nebo dashboard. Kdo ho dostane ve tři ráno, nemá nic dohledávat.
Logy, které pomohou chybu najít
Monitoring řekne, že je problém. Logy řeknou, kde. U integrací doporučujeme logovat u každého volání alespoň čas, systém, typ operace, identifikátor záznamu (číslo objednávky, kód produktu), stavový kód odpovědi a dobu trvání. S identifikátorem pak dohledáte cestu jedné konkrétní objednávky napříč e-shopem, frontou zpráv i ERP.
Do logů nepatří hesla, API klíče ani celá platební data. Logy bývají přístupné víc lidem než produkční databáze.
Jak na to prakticky
Monitoring integrací nemusíte stavět naráz. Tady je postup, kterým začínáme u většiny e-shopů:
- Sepište všechny integrace a u každé určete, co se stane, když na den vypadne. Podle toho seřaďte priority.
- U kritických toků (objednávky, sklad, platby) nastavte heartbeat a alert na „nic nepřišlo“.
- Zaveďte denní kontrolu rozdílů mezi e-shopem a ERP u objednávek a skladu.
- Pravidelně čtěte log webhooků, který platforma nabízí, a hlídejte deaktivované odběry.
- Sjednoťte logování tak, aby šlo dohledat jednu objednávku napříč systémy.
- Po měsíci projděte alerty. Ty, na které nikdo nereagoval, zrušte nebo přesuňte do reportu.
Chyby v integracích doporučujeme odhalit ještě před spuštěním, podrobně to popisujeme v článku Testování integrací před nasazením do provozu. Monitoring pak hlídá to, co testy předvídat nemohou.
Kdy nám zavolat
Pokud se o výpadku synchronizace obvykle dozvídáte od zákazníků nebo z reklamací, je čas na systematický dohled. V rámci Performance Monitoringu hlídáme dostupnost, feedy i integrace a reagujeme dřív, než problém zasáhne objednávky. Když potřebujete integrace nejdřív opravit nebo přestavět tak, aby šly monitorovat, pomůžeme v rámci služby integrace. Ozvěte se na info@prevedshop.cz nebo na +420 723 000 173.
Potřebujete s tím pomoct?