RAMissa ajettava VPN ei kerro lokeista mitään

VPN-palvelin, joka käynnistyy vain luku -kuvasta ja pitää ajonaikaisen tilansa tmpfsissä, on todellinen ja hyödyllinen suunnittelu. Se on myös helppo kuvata lokittomaksi, mitä suunnittelu ei osoita. Tallennuspaikka määrää, missä kopio elää; kerääminen ja säilytys määräävät, onko tietuetta lainkaan olemassa, ja uudelleenkäynnistys vaikuttaa vain ensimmäiseen. Näiden erottaminen on koko katsaus.

Aloita listaamalla jokainen prosessi, joka voi kirjoittaa tilaa: daemon, todennuspalvelu, journal, mikä tahansa valvonta-agentti ja hallintatyökalut.

Tallennus ja kerääminen ovat eri kysymyksiä

Jokaisella kirjoittajalla on oma määränpäänsä ja oma käytäntönsä. VPN-daemon kirjoittaa tilatiedostoja, todennuksen tausta kirjoittaa tilitapahtumia, journal kerää palveluiden tulostetta ja valvonta-agentti lähettää mittarit aivan muualle. Suunnittelu, joka saa yhden niistä katoamaan uudelleenkäynnistyksessä, ei ole sanonut muista kolmesta mitään. Seuraa jokainen kirjoittaja sen määränpäähän ja kirjaa, onko määränpää ylipäätään koneella.

Sovelluskohtaiset tiedostot, ladatut diagnostiikat ja ulkoiset palvelut tarvitsevat saman kohtelun. Tutun paikallisen lokin puuttuminen ei todista, ettei yhteys- tai tilitietueita ole missään; se todistaa, ettet ole vielä löytänyt, minne ne menevät.

tmpfs ei ole tae

Linuxin tmpfs ei ole fyysinen RAM-levy. Ytimen dokumentaatio sanoo selvästi, että sivuja voidaan kirjoittaa swapiin, kun liitospiste sallii sen, joten tmpfs-tiedosto voi päätyä levylle ilman, että sovellus koskaan kopioi sitä sinne. mount näyttää, onko pelissä swapiin tukeutuva tmpfs, ja muut muistitiedostojärjestelmät käyttäytyvät jälleen eri tavoin. Lue todelliset liitosvaihtoehdot sen sijaan, että olettaisit polun /run alla tarkoittavan haihtuvuutta.

Kartoita sitten asiat, jotka selviävät uudelleenkäynnistyksestä tavoilla, jotka ihmiset unohtavat: pysyvä ylempi kerros, liitetty tallennustila, horrostuskuvat, kaatumisdumpit ja koko VM:n infrastruktuurin tilannekuvat. Jokainen on mahdollinen määränpää tilalle, jota pidit hetkellisenä. Lista on tarkistettava asia, ei väite, että jokaisella isännällä on ne kaikki.

Journaldilla on kaksi määränpäätä ja edelleenlähettäjä

Journald havainnollistaa jaon siististi. Haihtuva tallennus pitää tietueet /run/log/journal alla, pysyvä /var/log/journal alla, ja automaattinen tila valitsee niiden välillä; voimassa oleva tila tulee käynnissä olevasta järjestelmästä, ei kuvan kuvauksesta. Haihtuvaan vaihtaminen ei poista sitä, mikä on jo kirjoitettu pysyvästi. Edelleenlähetys on myös erillinen kanava: jopa tallennusasetus, joka ei pidä mitään paikallisesti, voi luovuttaa viestit toiselle kohteelle.

Lue voimassa oleva tila journalista itsestään tai sen asetustiedostosta ja tarkista sitten edelleenlähetyksen kohteet erikseen, koska yksi asetus ei ohjaa toista.

Mikä on säilyttävä uudelleenkäynnistyksen yli

Tilaton ajonaikainen ympäristö tukee toistettavaa korvaamista, ja se tarvitsee tarkoitukselliset lähteet kokoonpanolle, valtuutukselle ja palautusmateriaalille, jota palvelu ei voi keksiä. Ainoan toimivan rekisteröinti- tai peruutustilan menettäminen paikallisten kirjoitusten katoamiseksi on huono kauppa, ja yleinen. Päätä, minkä on tarkoituksella selvittävä, ja varmista sitten, että se selviää.

Sama päättely pätee toiminnallisiin tietueisiin. Päätä, mitkä tapahtumat turvallisuus ja palvelunhallinta todella vaativat, perustellulla laajuudella ja säilytyksellä, ja minimoi loput. Minimointi ei ole sama kuin kaiken diagnostiikan poistaminen käytöstä.

Vertaa voimassa olevaa tallennus- ja edelleenlähetysasetusta muutamaan vaarattomaan tapahtumaan, käynnistä sitten kone uudelleen tai vaihda se ja tarkista uudelleen, mitä jäi jäljelle ja mistä palvelu palautti tilansa.