Történt valami az éjjel: hol van valójában a feljegyzés

A riasztás azt mondja meg, hogy történt valami. A napló azt, hogy miért. A csapda az, hogy a leginkább szükséges feljegyzés éppen a gép halálának pillanatát fedi le, és alapértelmezett telepítésnél éppen ez szokott hiányozni.

AtlasPVE ·

A bejegyzés ezekre válaszol

  • proxmox naplók összeomlás után
  • proxmox naplók helye
  • proxmox naplófájl helye
  • proxmox feladatnapló helye
  • proxmox syslog helye

A gép az éjjel újraindult, és senki nem kérte rá. Minden fut újra, semmi nem látszik nyilvánvalóan hibásnak, és az egyetlen őszinte állítás az, hogy történt valami.

A megfigyelésnek három feljegyzése van, és ezek három különböző kérdésre válaszolnak. A riasztás azt mondja meg, hogy történt valami. A metrika azt, milyen alakja volt. A napló azt, miért. Ez a cikk a harmadikról szól, és arról a kellemetlen tényről, hogy éppen az érdekes percet lefedő napló szokott eltűnni.

Az első kérdés kisebb a vártnál

A hardveres elméletek előtt érdemes a legolcsóbb kérdést feltenni: leállították, vagy meghalt?

Egyetlen sor megválaszolja. A szabályos leállítás nyomot hagy az előző indítás naplójának végén: a naplózó szolgáltatás rögzíti, hogy leállítást kértek tőle, majd rögzíti, hogy leállt. Az áramot vesztett gép után nincs semmilyen lezárás. A feljegyzés egyszerűen megszakad a szokásos működés közepén.

Ez az egyetlen megkülönböztetés kettévágja az egész vizsgálatot. A szabályos lezárás azt jelenti, hogy valami az újraindítás mellett döntött, tehát azt kell keresni, ki kérte: egy frissítés, egy watchdog, egy ütemezett feladat, egy ember. Ha nincs lezárás, a gépet megszakították, tehát az áramellátást, a hőt, a memóriát és az alatta lévő tárolót kell nézni.

De csak akkor, ha az előző indítás még megvan

Itt a csapda. A journal csak akkor őrzi meg tartósan az előzményeket, ha egy adott könyvtár létezik a lemezen. Ha nem létezik, a journal a memóriában él, és minden újraindítás pontosan azt a bizonyítékot törli, amiért a keresés indult. Nincs hiba és nincs figyelmeztetés; a válasz az előző indításra egyszerűen az, hogy olyan nincs.

Ezt egy nyugodt délutánon érdemes ellenőrizni, nem azon a reggelen, amikor kell. Egyetlen könyvtárról van szó, és arról a különbségről, hogy van feljegyzés, vagy csak úgy tűnik, hogy van.

Ez ugyanaz az alakzat, mint egy kétszer is megnevezésre méltó csapda: a rögzítő, ami osztozik annak sorsában, amit rögzít. A legjobban hiányzó grafikon az, aminek az írása abban a pillanatban állt le, amikor érdekessé vált, a legjobban hiányzó napló pedig abból az indításból való, ami már nincs meg.

Lehet, hogy nincs is ott az a fájl, aminek elolvasását az internet fele javasolja

Aktuális telepítésen mérve, Proxmox VE 9.2.6 Debian 13.6 rendszeren: a klasszikus rendszernaplózó démon nincs telepítve, és /var/log/syslog nem létezik.

Ez többet jelent, mint amennyinek hangzik. Az elmúlt tizenöt évben írt hibakeresési tanácsok nagy része a /var/log/syslog megnyitásával kezdődik. Egy mai gépen ez a parancs semmit nem ad vissza, és nyomás alatt az eredmény úgy olvasódik, hogy *nincsenek naplóim*, nem pedig úgy, hogy *rossz helyen keresek*. A rendszer feljegyzése ma a journal, és ezt lekérdezni kell, nem szerkesztőben megnyitni.

A Proxmox egy második feljegyzést is vezet, és az más kérdésre válaszol

A rendszer journaljától külön a Proxmox VE saját feladatnaplót vezet. A webes felületen vagy az API-n keresztül indított minden művelet feladattá válik, azonosítóval, kezdési idővel, befejezési idővel és záró állapottal, az egyedi feladatfájlok mellett pedig van egy index is. Egy laborban futó gazdagépen ez az index 283 sort tartalmazott, mögötte nagyjából 960 feladatfájllal.

A két feljegyzés másban jó. A journal abban jó, hogy "mit csinált a rendszer". A feladatnapló abban, hogy "ki mit kért, és befejeződött-e". Ha egy virtuális gépen olyan pillanatkép van, amiről senki nem emlékszik, hogy készítette, vagy ha egy változás szerző nélkül jelent meg, a feladatnapló általában gyorsabban válaszol, mint a journal, mert szándékok listája, nem eseményfolyam.

A felső határról az előzmények szüksége előtt kell dönteni

Alapértelmezés szerint a journal korlátja a fájlrendszer arányában van megadva, nem időtartamban. A fent mért gazdagépen nem volt kifejezett korlát beállítva, és a journal nagyjából 276 MB-ra nőtt.

Két számot érdemes előre tudni: mennyi helyet foglalhat a journal, és ez az adott gépen valójában meddig visszamenőleg elég. A sorrend számít, és ugyanez a sorrend érvényes a metrikákra is. Először azt kell eldönteni, meddig kell visszalátni, aztán ehhez kell beállításokat választani. Ha a válasz egy incidens közben derül ki, akkor a válasz az lesz, hogy "nem elég messzire".

Mit csinál az Atlas, és mit nem

Az Atlas nem váltja ki a journalt, és nem próbálja helyette elolvasni a naplókat. Naplókeresés nincs benne, és ennek az ellenkezőjét állítani egy rossz reggelt készítene elő.

Amit az Atlas visz, az az első fele: a napi összefoglaló tényként jelenti a nem tervezett újraindítást, a géppel és az időponttal együtt, hogy a kérdés egyáltalán felmerüljön. Az olvasás továbbra is emberi feladat, és a válasz továbbra is a journalban lakik.

Ez a megkülönböztetés a lényeg. Az elmúlt éjszaka legrosszabb változata nem az az újraindítás, aminek a vizsgálata rossz fájllal indult. Hanem az, amit senki nem vett észre, mert egy soha meg nem nyitott feljegyzés semmire nem válaszol.

Források

A Proxmox saját dokumentációja. Angol nyelvű, és ebben a kérdésben az övé az utolsó szó.

Kapcsolódó bejegyzések

Hogyan néz ki ez az Atlason belül?

Tovább a termékoldalra