Szolgáltatáshookok hibaelhárítása
Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019
Ez a cikk általános hibaelhárítási útmutatást és válaszokat nyújt a gyakori kérdésekre (GYIK).
Tevékenység és hibakeresési problémák megtekintése
A Szolgáltatáshookok lap a webes hozzáférés rendszergazdájában megjeleníti az egyes előfizetésekhez tartozó legutóbbi (elmúlt 14 nap) tevékenységet, valamint azt, hogy az előfizetés engedélyezve, letiltva vagy korlátozva van-e.
Az előfizetések részletes előzményeit, köztük a kérelmek/válaszok részletes adatait is elérheti, ami hasznos lehet egy problémás szolgáltatás vagy előfizetés hibakereséséhez.
Az előfizetések tevékenységének és állapotának megtekintéséhez nyissa meg a Service Hooks oldalt.
Ha meg szeretné tekinteni az előfizetés részletes tevékenységeit, beleértve a teljes kérelem-, válasz- és esemény-hasznos adatokat, válasszon ki egy előfizetést a táblában, majd válassza az Előzmények lehetőséget.
Előfizetési hibák és próbaidő (korlátozott)
Hibatípusok
A Service Hooks-értesítések hibái a következő kategóriákba vannak csoportosítva:
- Terminálhibák
- Átmeneti hibák
- Tartós hibák
Terminálhibák
Az egyetlen terminálhiba a 410-es HTTP-állapotkód (Eltűnt). Amikor egy előfizetés terminálhibát lát, az a korábbi állapotától függetlenül automatikusan le lesz tiltva.
Átmeneti hibák
Ha egy előfizetés átmeneti hibát lát, legfeljebb nyolc alkalommal kísérli meg újra az értesítést, és az egyes kísérletek között egyre nagyobb a késés. Az átmeneti hibák a következő kódokat tartalmazzák:
- 408 (Kérelem időtúllépése)
- 502 (Rossz átjáró)
- 503 (A szolgáltatás nem érhető el)
- 504 (Átjáró időtúllépése)
Újrapróbálkozások sorozata átmeneti hibák esetén
| Újra # | Várakozási idő |
|---|---|
| 1. újrapróbálkozás előtt | várakozás ~1 másodperc |
| 2. újrapróbálkozás előtt | várakozás ~2 másodperc (3 másodperces teljes késleltetés) |
| 3. újrapróbálkozás előtt | várakozás ~4 másodperc (7 másodperces teljes késleltetés) |
| 4. újrapróbálkozás előtt | várakozás ~8 másodperc (15 másodperces teljes késleltetés) |
| 5. újrapróbálkozás előtt | várakozás ~16 másodperc (31 másodperces teljes késleltetés) |
| 6. újrapróbálkozás előtt | várakozás ~32 másodperc (63 másodperces teljes késleltetés) |
| Újrapróbálkozás előtt 7 | várakozás ~60 másodperc (maximális visszalépési idő, 123 másodperc teljes késleltetés) |
| Újrapróbálkozás előtt 8 | várakozás ~60 másodperc (maximális visszalépési idő, 183 másodperces teljes késleltetés) |
Ha az értesítés kimeríti az összes újrapróbálkozását, és továbbra is átmeneti hiba jelenik meg minden kísérletnél, az előfizetés nem próbálja elküldeni az értesítést, és úgy kezeli az értesítést, mintha tartós hibát látna.
Tartós hibák
A tartós hibák közé tartozik az összes többi HTTP-hibakód, például: 404 (Nem található), 500 (belső kiszolgálói hiba) stb.
Ha egy előfizetés tartós hibát lát, próbaidőre kerül.
Próbaidő
Próbaidő alatt az előfizetések száma korlátozott az általa küldött értesítések számában. Ha az előfizetés továbbra is tartós hibákba ütközik, az egyre korlátozottabbá válik, és végül le lesz tiltva. Ha az előfizetés sikeres választ kap próbaidő alatt, az teljesen engedélyezett állapotba kerül.
Hét maximális újrapróbálkozás sorrendje, amíg az előfizetés próbaidő alatt van
Ha egy előfizetés próbaidőn van, az új események elvesznek. Ha az újrapróbálkozás sikeres, az előfizetés engedélyezve van, és az események újra közzé lesznek téve.
| Újra # | Várakozási idő |
|---|---|
| 1. újrapróbálkozás előtt | várakozás ~20 perc |
| 2. újrapróbálkozás előtt | várakozás ~40 perc (teljes próbaidő 1 óra) |
| 3. újrapróbálkozás előtt | várakozás ~1 óra 20 perc (teljes próbaidő 2,33 óra) |
| 4. újrapróbálkozás előtt | várakozás ~2 óra 40 perc (teljes próbaidő 5 óra) |
| 5. újrapróbálkozás előtt | várakozás ~5 óra 20 perc (teljes próbaidő 10,33 óra) |
| 6. újrapróbálkozás előtt | várakozás ~10 óra 40 perc (teljes próbaidő 21 óra) |
| Újrapróbálkozás előtt 7 | várakozás ~15 óra (maximális visszalépési idő, 36 órás próbaidő) |
Hét újrapróbálkozás után az előfizetés állapota DisabledBySystem lesz, ha a fogyasztó értesítése meghiúsul.
GYIK
K: Mi a service-hook hasznos adatkorlátja?
Válasz: A hasznos adatkorlát 2 MB. Ha a hasznos adatok mérete ennél nagyobb, az rontja a teljesítményt és a megbízhatóságot. Ajánlott eljárásként a szolgáltatáshookoknak legfeljebb 2 MB-ra kell korlátozniuk a hasznos adatok méretét.
K: Mit jelent az engedélyezett (korlátozott) állapot?
Válasz: Az előfizetések korlátozottak lesznek, ha túl sok hiba történik. Az engedélyezve (korlátozott) ugyanaz, mint a próbaidő alatt.
K: Mit jelent a letiltott állapot (hibák miatt) ?
V: Az előfizetések automatikusan le lesznek tiltva, ha hosszabb időn keresztül egymást követő hibák sorozata vagy terminálhiba történik. Az átmeneti hibatípusok többször is újrapróbálkozva lesznek, mielőtt hibát deklarálnak. A tartós hibatípusok nem lesznek újrapróbálkozók. Az alábbiakban példákat láthat a hibák egyes típusaira.
- Átmeneti: 408 (kérelem időtúllépése), 502 (Hibás átjáró), 503 (A szolgáltatás nem érhető el), 504 (átjáró időtúllépése)
- Terminál: 410 (Eltűnt)
- Tartós: Minden olyan hiba, amely nem átmeneti vagy terminál
K: Mit jelent a letiltott állapot (a felhasználó bal oldali projektje) jelentése?
Válasz: Az előfizetést létrehozó felhasználó már nem tagja a csapatnak.
K: Mit kell kipróbálnom, ha egy szolgáltatáshook nem működik?
Válasz: Ellenőrizze a következő elemeket:
Ellenőrizze, hogy az előfizetés engedélyezve van-e
Ellenőrizze, hogy az előfizetés beállításai helyesek-e (eseményszűrők és műveletek)
Tekintse meg az előzményeket, különösen, ha vannak hibák
K: Engedélyezhetem egy normál projektfelhasználó számára a szolgáltatáshook-előfizetések megtekintését és kezelését egy projekthez?
Válasz: Alapértelmezés szerint csak a projektgazdák rendelkeznek ezekkel az engedélyekkel. Ha közvetlenül szeretné megadni az engedélyeket más felhasználók számára, a parancssori eszközt vagy a Security REST API-t használhatja.
K: Létrehozhatok programozott módon előfizetéseket?
Válasz: Igen, használjon REST API-kat.