Server error in '/' application

Server error in '/' application
2022-07-06T13:40:47+02:00
2022-08-05T09:22:28+02:00
2022-12-07T03:00:39+01:00
kingoftailor
Elég idegesítő problémába ütköztem. Van amikor hetekig probléma nélkül üzemel a weboldalam, máskor meg 2-3 naponta random server error in '/' application hibát dob és csak az IIS application pool és a weboldal restart oldja meg. Az viszont mindig, vagyis a hiba esetén a restart azonnal helyrehozza a dolgot.

Nem tudok rájönni, hogy mi lehet a baj. A logban én sem és a rendszergazda sem talált rá okot.

Valakinek valami ötlet? A google-ben csak olyan hibákat találtam, amik nem így random fordulnak elő (pl. hibás web config vagy dontet verzió).
Mutasd a teljes hozzászólást!
Ugye telepakoltad a kódodat ilyesmivel?

$dbConnection = null; try { $dbConnection = new MysqlConnection(...); } catch (Exception $e) { $logger->logFatal("Cannot connect to the database", $e); $metricCollector->recordEvent("DB_CONNECTION_FAILURE"); throw; }

Ami különösen érdekes, hogy írtam egy kis progit ami csekkolja, hogy online van-e az oldal és ha nem, akkor az Application-pool-t éa a website-ot is újraindítja.

Elvileg ezért kódoltál liveness és readiness probe-ot a weblapodba, tehát elvileg van GET /healthz és GET /readyz URI-jaid. A liveness probe azt jelenti, hogy egyáltalán eljut-e a request a szoftveredhez és ki tudsz szolgálni egy HTTP 204-et mindenféle külső függőség (adatbázis, cache, stb.) nélkül. A readiness probe pedig HTTP 204-et ad vissza, ha minden készen áll ahhoz, hogy a weblapod a látogatóid kéréseit ki tudja szolgálni (tehát sikeresen eléred minden külső függőségedet).

Ha vannak metrikáid olyan adatokról, mint pl.
- mennyi ideig tart kiszolgálni egy adott URI request-jeit (mekkora a response time-od)
- hány request végződött HTTP 5xx hibakóddal
- hány request-et szolgál ki a weblapod másodpercenként
- mekkora a CPU és RAM kihasználtság
- milyen gyakorisággal fordul elő probléma az adatbázissal való kommunikációban
- a szoftvered milyen gyorsan kap választ az adatbázistól
és sok más hasonló információkat összegyűjtesz és aggregálod (pl. Prometheus), ezekre tudsz alert-eket tenni. Ha nagyon nagy a gáz, ilyen esetben tudsz automatizálni olyan reaktív lépéseket, minthogy
- új szervereket állítasz csatasorba, hogy skálázódjon a megnövekedett terheléshez
- circiut breaking-et használhatsz, vagyis ha több webszerverből az egyik rakoncátlankodik, tőle elveszed a requesteket és hagyod regenerálódni (ha pedig a readiness probe szerint nem áll helyre, egyszerűen kilövöd az egészet és indítasz újat helyette)
- élesítheted az adatbázis slave instance-át
- vagy egyszerűen csak értesülsz minderről e-mailben.
Mutasd a teljes hozzászólást!

  • Nem tudok rájönni, hogy mi lehet a baj.

    Ennyi alapján sajnos mi sem fogunk rájönni. Ezért termel logokat és metrikákat a weblapod (nem az IIS logjaira gondolok), hogy ilyen esetek nyomozhatóak legyenek. Azokban nem látsz semmit sem?
    Mutasd a teljes hozzászólást!
  • Az IIS logban nincs semmi. A windows event logban sem és a weboldal saját logjában sem.

    Nem tudom Te milyen logra gondolsz, ahol megtalálhatnám az okot.

    Ami különösen érdekes, hogy írtam egy kis progit ami csekkolja, hogy online van-e az oldal és ha nem, akkor az Application-pool-t éa a website-ot is újraindítja. Ez 10-ből 8 esetben működik is.
    Mutasd a teljes hozzászólást!
  • Pl. a saját kódod exceptionjának szövege, amit te tettél bele a saját logodba :)
    Mutasd a teljes hozzászólást!
  • Ugye telepakoltad a kódodat ilyesmivel?

    $dbConnection = null; try { $dbConnection = new MysqlConnection(...); } catch (Exception $e) { $logger->logFatal("Cannot connect to the database", $e); $metricCollector->recordEvent("DB_CONNECTION_FAILURE"); throw; }

    Ami különösen érdekes, hogy írtam egy kis progit ami csekkolja, hogy online van-e az oldal és ha nem, akkor az Application-pool-t éa a website-ot is újraindítja.

    Elvileg ezért kódoltál liveness és readiness probe-ot a weblapodba, tehát elvileg van GET /healthz és GET /readyz URI-jaid. A liveness probe azt jelenti, hogy egyáltalán eljut-e a request a szoftveredhez és ki tudsz szolgálni egy HTTP 204-et mindenféle külső függőség (adatbázis, cache, stb.) nélkül. A readiness probe pedig HTTP 204-et ad vissza, ha minden készen áll ahhoz, hogy a weblapod a látogatóid kéréseit ki tudja szolgálni (tehát sikeresen eléred minden külső függőségedet).

    Ha vannak metrikáid olyan adatokról, mint pl.
    - mennyi ideig tart kiszolgálni egy adott URI request-jeit (mekkora a response time-od)
    - hány request végződött HTTP 5xx hibakóddal
    - hány request-et szolgál ki a weblapod másodpercenként
    - mekkora a CPU és RAM kihasználtság
    - milyen gyakorisággal fordul elő probléma az adatbázissal való kommunikációban
    - a szoftvered milyen gyorsan kap választ az adatbázistól
    és sok más hasonló információkat összegyűjtesz és aggregálod (pl. Prometheus), ezekre tudsz alert-eket tenni. Ha nagyon nagy a gáz, ilyen esetben tudsz automatizálni olyan reaktív lépéseket, minthogy
    - új szervereket állítasz csatasorba, hogy skálázódjon a megnövekedett terheléshez
    - circiut breaking-et használhatsz, vagyis ha több webszerverből az egyik rakoncátlankodik, tőle elveszed a requesteket és hagyod regenerálódni (ha pedig a readiness probe szerint nem áll helyre, egyszerűen kilövöd az egészet és indítasz újat helyette)
    - élesítheted az adatbázis slave instance-át
    - vagy egyszerűen csak értesülsz minderről e-mailben.
    Mutasd a teljes hozzászólást!
  • Konkrétan azzal nem pakoltam tele, amit példának írtál.

    A weboldal nem PHP, hanem ASP.NET MVC 4

    Try-catch-et mindenhol használok. A logba nincs is egyetlen egy exception sem.

    Most módosítottam az uptime kódot, hogy leállás esetén az application pool-t mindenképp indítsa újra, mert az egy másik fájlban volt és az nem állt le (de egy restart jót tesz neki).

    Kibővítettem logolással is a funkciót.
    Mutasd a teljes hozzászólást!
  • A probléma okára nem jöttem rá, viszont kezeltem.

    Átírtam azt a kódot, ami az oldal elérhetőségét ellenörzi és így most újra tudja indítani, ha szükséges 5 percen belül.

    Az eltelt 1 hónapban 2-szer fordult elő a leállás és mindkétszer újraindult, így alig volt kiesés.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd