Prečo správy v Amazon SQS čakajú príliš dlho?
Export čaká, hoci API odpovedá. Zistite, čo vám o oneskorení povedia vek správ, stav spracovania a fronta neúspešných správ.
Používateľ si vyžiada export, web požiadavku prijme a odkaz na súbor sa má zobraziť neskôr. Súbor však neprichádza. Ak export spracúvate cez štandardnú frontu Amazon SQS, pozrite sa, ako dlho sú správy vo fronte a čo s nimi robia procesy, ktoré ich preberajú. Rovnaký počet čakajúcich správ môže počas špičky rýchlo zmiznúť alebo sa celé minúty nehýbať.
Odvoďte hranicu čakania od sľúbeného výsledku
Najprv si určte, dokedy má byť export dostupný. Ak je cieľom 5 minút od prijatia požiadavky a na vytvorenie a sprístupnenie súboru si vyhradíte 1 minútu, na čakanie zostávajú najviac 4 minúty. Je to ilustračný rozpočet. Hranicu upozornenia nastavte s rezervou na vyhodnotenie a doručenie upozornenia.
V CloudWatch sledujte ApproximateAgeOfOldestMessage. Vyjadruje približný vek najstaršej nespracovanej správy v sekundách. Ukáže, že sa práca zdržiava už vo fronte. Splnenie cieľa overíte až v aplikácii, meraním času od prijatia požiadavky po sprístupnenie súboru. SQS nevidí kroky pred vložením správy ani výsledok, ktorý dostane používateľ.
Zistite, či správy čakajú na prevzatie alebo na dokončenie
Na rovnakej časovej osi zobrazte ApproximateNumberOfMessagesVisible a ApproximateNumberOfMessagesNotVisible. Prvá metrika odhaduje počet správ dostupných na prevzatie. Druhá ukazuje správy, ktoré si procesy prevzali a zatiaľ ich neodstránili. Ak vek aj počet dostupných správ rastú a prevzatých správ je málo, overte, či procesy bežia a či dokážu čítať zo správnej fronty. Čas do prvého prevzatia zistíte z rozdielu medzi ApproximateFirstReceiveTimestamp a SentTimestamp. Obe hodnoty môže SQS vrátiť ako systémové atribúty správy.
Ak rastie počet prevzatých správ a pribúda málo hotových exportov, sledujte trvanie spracovania, chyby a odozvu úložiska. Po vypršaní visibility timeoutu môže neodstránenú správu prevziať ďalší proces. V aplikačných logoch porovnajte opakované prevzatia s identifikátorom exportu. Počítadlá prevzatí a vymazaní v SQS môžu zahŕňať opakované operácie. Úspech preto merajte podľa dokončených exportov.
Sledujte aj správy, ktoré sa opakovane vracajú
V štandardnej fronte môže SQS opakovane prevzatú a neodstránenú správu presunúť na koniec. Metrika veku ju potom môže vynechať. Sledujte preto aj chyby spracovania podľa úlohy a pri nastavenej dead-letter queue (DLQ) jej ApproximateNumberOfMessagesVisible. DLQ zhromažďuje správy, ktoré po nastavenom počte prevzatí skončili mimo hlavnej fronty.
Vek vykazovaný pre presunutú správu v DLQ sa počíta od presunu. Ak zisťujete, odkedy používateľ čaká, použite čas prijatia požiadavky uložený v aplikácii. Pred vrátením správ do hlavnej fronty opravte príčinu zlyhania a overte, že opätovné spracovanie tej istej úlohy nevytvorí ďalší export alebo duplicitné oznámenie.
Po zásahu overte aj najstaršie nedokončené úlohy
Po oprave sledujte, či vek správ klesá a pribúdajú hotové exporty. Procesy pridávajte vtedy, keď dokážu spracovať viac práce bez ďalšieho preťaženia úložiska či databázy. Ak ešte niektoré požiadavky chýbajú, dohľadajte ich podľa identifikátora a overte stav v aplikácii a v DLQ.
Dokončite testovací export bežnou cestou. Zmerajte čas od požiadavky po otvorenie súboru a overte, čo sa stalo s požiadavkami, ktoré sa zdržali počas problému. Nový export môže prejsť, aj keď staršia úloha stále potrebuje zásah.
- Nastavte hranicu čakania podľa času, ktorý má používateľ na výsledok.
- Sledujte vek, dostupné aj prevzaté správy na rovnakej časovej osi.
- Skontrolujte opakované prevzatia a počet správ v DLQ.
- Potvrďte, že nové aj oneskorené exporty sú dostupné.
Čo si odniesť
Vek správ vám povie, kedy sa pozrieť do fronty. Počty správ a logy vám pomôžu vybrať miesto zásahu. Obnovu potvrďte podľa toho, kedy používateľ dostane hotový súbor.
