Jatkamme uppoamistamme kiehtovaan arvaamisen maailmaan... lokien vianmäärityksen. SISÄÄN sovimme peruskäsitteiden merkityksestä ja katsoimme Veeamin kokonaisrakennetta yhtenä sovelluksena yhdellä silmällä. Tämän tehtävänä on selvittää, miten lokitiedostot muodostuvat, millaista tietoa niissä näytetään ja miksi ne näyttävät siltä, miltä ne näyttävät.
Mitä nämä "lokit" mielestäsi ovat? Useimpien mielestä minkä tahansa sovelluksen lokit tulisi asettaa eräänlaisen kaikkivaltiaan entiteetin rooliin, joka suurimman osan ajasta kastelee jossain takapihalla, mutta oikealla hetkellä ilmestyy tyhjästä kiiltävässä haarniskassa ja pelastaa kaikki. Toisin sanoen niiden tulisi sisältää kaikki, kunkin komponentin pienimmistä virheistä yksittäisiin tietokantatapahtumiin. Ja niin, että virheen jälkeen kirjoitettiin heti, miten se muuten korjataan. Ja kaiken tämän pitäisi mahtua pariin megatavuun, ei enempää. Se on vain tekstiä! Tekstitiedostot eivät voi kestää kymmeniä gigatavuja, kuulin sen jostain!
Joten lokit
Todellisessa maailmassa lokit ovat vain diagnostisten tietojen arkisto. Ja mitä sinne tallentaa, mistä saa tietoa varastointia varten ja kuinka yksityiskohtaista sen tulee olla, on kehittäjien itsensä päätettävissä. Joku seuraa minimalismin polkua pitämällä kirjaa ON/OFF-tasosta, ja joku haravoi ahkerasti kaikkea, mitä tavoittaa. Vaikka on olemassa myös välivaihtoehto, jossa on mahdollisuus valita ns. Logging Level, kun ilmoitat itse kuinka yksityiskohtaista tietoa haluat tallentaa ja kuinka paljon ylimääräistä levytilaa sinulla on =) VBR:ssä on muuten kuusi tällaista tasoa. Ja usko minua, et halua nähdä, mitä tapahtuu yksityiskohtaisimmalla kirjauksella, jossa on vapaata levytilaa.
Hieno. Ymmärsimme suunnilleen, mitä haluamme säästää, mutta herää oikeutettu kysymys: mistä saada tämä tieto? Tietenkin olemme osa tapahtumia, joissa itsemme kirjataan sisäisillä prosesseillamme. Mutta mitä tehdä, kun on vuorovaikutusta ulkoisen ympäristön kanssa? Jotta ei liukua kainalosauvojen ja polkupyörien helvetin, Veeam ei yleensä keksi jo keksittyjä keksintöjä. Aina kun on olemassa valmis API, sisäänrakennettu toiminto, kirjasto jne., annamme etusijalle valmiit vaihtoehdot ennen kuin alamme aitata konttejamme. Vaikka jälkimmäinenkin riittää. Siksi lokeja analysoitaessa on tärkeää ymmärtää, että suurin osa virheistä osuu viesteihin kolmannen osapuolen API-liittymistä, järjestelmäkutsuista ja muista kirjastoista. Tässä tapauksessa VBR:n tehtävänä on välittää nämä virheet lokitiedostoihin. Ja käyttäjän päätehtävä on oppia ymmärtämään, mikä rivi on keneltä ja mistä tämä "kuka" on vastuussa. Joten jos VBR-lokin virhekoodi vie sinut MSDN-sivulle, se on hyvä ja oikein.
Kuten aiemmin sovimme: Veeam on ns. SQL-pohjainen sovellus. Tämä tarkoittaa, että kaikki asetukset, kaikki tiedot ja yleensä kaikki, mikä on tarpeen vain normaaliin toimintaan - kaikki on tallennettu sen tietokantaan. Siksi yksinkertainen totuus: mitä ei ole lokeissa, on todennäköisesti tietokannassa. Mutta tämäkään ei ole hopealuodi: jotkin asiat eivät ole Veeamin komponenttien paikallisissa lokeissa eikä sen tietokannassa. Siksi sinun on opittava tutkimaan isäntälokeja, paikallisen koneen lokeja ja kaiken varmuuskopiointi- ja palautusprosessiin liittyvän lokeja. Ja tapahtuu myös niin, että tarvittavaa tietoa ei ole saatavilla ollenkaan. Se on tapa.
Joitakin esimerkkejä tällaisista sovellusliittymistä
Tämä luettelo ei pyri olemaan poikkeuksellisen täydellinen, joten perimmäistä totuutta siitä ei tarvitse etsiä. Sen tarkoitus on vain näyttää yleisimmät tuotteissamme käytetyt kolmannen osapuolen API:t ja teknologiat.
Aloitetaan VMware.
Ensimmäinen listalla tulee olemaan vSphere API. Käytetään todentamiseen, hierarkian lukemiseen, tilannekuvien luomiseen ja poistamiseen, koneiden tietojen pyytämiseen ja paljon muuta. Ratkaisun toiminnallisuus on erittäin laaja, joten voin suositella versiolle VMware vSphere API Referencea и . Uusimmissa versioissa kaikki on vain googletettu.
VIX API. Hypervisorin musta magia, jolle on olemassa erillinen . VMware-sovellusliittymä, jonka avulla voit työskennellä isännässä olevien tiedostojen kanssa muodostamatta niihin yhteyttä verkon kautta. Variantti viimeisenä keinona, kun sinun täytyy laittaa tiedosto koneeseen, johon ei ole parempaa viestintäkanavaa. On tuskaa ja kärsimystä, jos tiedosto on suuri ja isäntä on ladattu. Mutta tässä toimii sääntö, että jopa 56,6 Kb / s on parempi kuin 0 Kb / s. Hyper-V:ssä tätä asiaa kutsutaan PowerShell Directiksi. Mutta se oli vain ennen
vSpehere Web Services API VSphere 6.0:sta alkaen (suunnilleen siitä lähtien, kun tämä API esiteltiin ensimmäisen kerran versiossa 5.5), sitä käytetään työskentelyyn vieraskoneiden kanssa ja se on syrjäyttänyt VIX:n melkein kaikkialla. Itse asiassa tämä on toinen API vSpheren hallintaan. Kiinnostuneille suosittelen opiskelua manuaalinen.
VDDK (Virtual Disk Development Kit). Kirjasto, josta tässä osittain keskusteltiin . Käytetään virtuaalilevyjen lukemiseen. Se oli kerran osa VIX:ää, mutta ajan myötä se siirrettiin erilliseksi tuotteeksi. Mutta perillisenä se käyttää samoja virhekoodeja kuin VIX. Mutta jostain syystä itse SDK:ssa ei ole kuvausta näistä virheistä. Siksi havaittiin empiirisesti, että muiden koodien VDDK-virheet ovat vain käännös binäärikoodista desimaalikoodiin. Se koostuu kahdesta osasta - ensimmäinen puoli on dokumentoimatonta tietoa kontekstista, ja toinen osa on perinteisiä VIX / VDDK-virheitä. Esimerkiksi jos näemme:
VDDK error: 21036749815809.Unknown error
Sitten muunnetaan rohkeasti heksadesimaaliksi ja saadaan 132200000001. Hylkäämme yksinkertaisesti 132200:n epätietoisen alun, ja loppuosa on virhekoodimme (VDDK 1: Tuntematon virhe). Yleisimmistä VDDK-virheistä oli äskettäin erillinen .
Katsotaan nyt ikkunat.
Täältä löydät standardista kaikki, mikä on meille kaikkein tarpeellisinta ja tärkeintä Tapahtumienvalvonta. Mutta siinä on yksi saalis: pitkän perinteen mukaan Windows ei kirjaa virheen koko tekstiä, vaan vain sen numeroa. Esimerkiksi virhe 5 on "Pääsy kielletty" ja 1722 on "RPC-palvelin ei ole käytettävissä" ja 10060 on "Yhteyden aikakatkaisu". Tietysti on hienoa, jos muistat tunnetuimmat, mutta entäs tähän asti näkemättömät?
Ja jotta elämä ei näytä ollenkaan hunajalta, virheet tallennetaan myös heksadesimaalimuodossa etuliitteellä 0x8007. Esimerkiksi 0x8007000e on itse asiassa 14, Muisti täynnä. Miksi ja kenelle tämä tehtiin, on hämärän peittämä mysteeri. Täydellinen luettelo virheistä voidaan kuitenkin ladata ilmaiseksi ja ilman tekstiviestejä osoitteesta .
Muuten, joskus on muita etuliitteitä, ei vain 0x8007. Tällaisessa surullisessa tilanteessa ymmärtääksesi HRESULTin ("tuloksen kahva"), sinun täytyy kaivaa vielä syvemmälle kehittäjille. Tavallisessa elämässä en suosittele sinua tekemään tätä, mutta jos painat yhtäkkiä seinää vasten tai olet vain utelias, nyt tiedät mitä tehdä.
Mutta Microsoftin toverit säälivät meitä hieman ja näyttivät maailmalle hyödyllisyyden . Tämä on pieni pala konsolin iloa, joka voi kääntää virhekoodit ihmisiksi ilman Googlea. Se toimii näin.
C:UsersrootDesktop>err.exe 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# as an HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# 2 matches found for "0x54f"Herää oikeutettu kysymys: miksi emme heti kirjoita salauksen purkua lokeihin, vaan jätämme nämä salaperäiset koodit? Vastaus löytyy kolmannen osapuolen sovelluksista. Kun vedät itse jonkin WinAPI-kutsun, sen vastauksen tulkitseminen ei ole vaikeaa, koska tätä varten on jopa erityinen WinAPI-kutsu. Mutta kuten jo mainittiin, kaikki, mikä tulee meille vastauksina, päätyy lokiimme. Ja tässä sen salauksen purkamiseksi pitäisi jatkuvasti seurata tätä tietoisuusvirtaa, vetää siitä Windows-virheitä sisältäviä paloja, purkaa ne ja liittää takaisin. Olkaamme rehellisiä, ei jännittävin toiminta.
Windowsin tiedostonhallintasovellusliittymä käytetään kaikin mahdollisin tavoin tiedostojen käsittelyssä. Tiedostojen luominen, poistaminen, avaaminen kirjoittamista varten, attribuuttien käsittely ja niin edelleen ja niin edelleen.
mainittu yllä PowerShell Direct VIX API:n analogina Hyper-V-maailmassa. Valitettavasti ei niin joustava: paljon rajoituksia toimivuudelle, se ei toimi jokaisen isäntäversion eikä kaikkien vieraiden kanssa.
RPC (Remote Procedure Call) En usko, että yksikään henkilö, joka on työskennellyt WIndowsin kanssa, ei olisi nähnyt RPC:hen liittyviä virheitä. Yleisestä väärinkäsityksestä huolimatta tämä ei ole yksittäinen protokolla, vaan mikä tahansa asiakas-palvelin-protokolla, joka täyttää useita parametreja. Kuitenkin, jos lokeissamme on RPC-virhe, 90 % ajasta se on virhe Microsoft RPC:ltä, joka on osa DCOM:ia (Distributed Component Object Model). Löydät verkosta valtavan määrän dokumentaatiota tästä aiheesta, mutta leijonanosa siitä on melko vanhentunutta. Mutta jos on akuutti halu tutkia aihetta, voin suositella artikkeleita , ja pitkä lista .
Lokeissamme olevien RPC-virheiden pääasialliset syyt ovat epäonnistuneet yritykset kommunikoida VBR-komponenttien välillä (esim. palvelin > välityspalvelin) ja useimmiten tietoliikenneongelmista johtuvat syyt.
Kaikkien huippujen joukossa on virhe RPC-palvelin ei ole saatavilla (1722). Yksinkertaisesti sanottuna asiakas ei voinut muodostaa yhteyttä palvelimeen. Miten ja miksi - yksiselitteistä vastausta ei ole, mutta yleensä se on ongelma autentikaatiossa tai verkkoon pääsyssä porttiin 135. Jälkimmäinen on tyypillistä dynaamisille porttimäärityksille. Tästä aiheesta löytyy jopa . Ja Microsoftilla on löytääkseen epäonnistumisen syyn.
Toiseksi suosituin virhe: Päätepisteiden kartoittajasta (1753) ei ole enää saatavilla päätepisteitä. RPC-asiakas tai -palvelin ei pystynyt määrittämään itselleen porttia. Yleensä tapahtuu, kun palvelin (tässä tapauksessa vieraskone) on määritetty varaamaan dynaamisesti portit kapealta alueelta, joka on päättynyt. Ja jos kirjaudut sisään asiakaspuolelta (tapauksessamme VBR-palvelimelta), tämä tarkoittaa, että VeeamVssAgent ei joko käynnistynyt tai sitä ei rekisteröity RPC-liittymäksi. On myös tästä aiheesta .
No, täydentääksesi 3 suosituinta RPC-virhettä, muistakaamme, että RPC-funktiokutsu epäonnistui (1726). Näkyy, jos yhteys on muodostettu, mutta RPC-pyyntöjä ei käsitellä. Pyydämme esimerkiksi tietoja VSS:n tilasta (yhtäkkiä sinne tehdään varjomiina, ja yritämme kiivetä), ja vastauksena meille, hiljaisuus ja huomiotta.
Windows Tape Backup API tarvitaan nauhakirjastojen tai asemien kanssa työskentelyyn. Kuten alussa mainitsin: meillä ei ole iloa kirjoittaa omia ajureita ja sitten kärsiä jokaisen laitteen tuesta. Siksi vimillä ei ole omia ajureita. Kaikki standardi API:n kautta, jonka tuen laitteistotoimittajat toteuttavat itse. Niin paljon loogisempaa, eikö?
SMB / CIFS Tottumuksesta kaikki kirjoittavat niitä vierekkäin, vaikka kaikki eivät muista, että CIFS (Common Internet File System) on vain yksityinen versio SMB:stä (Server Message Block). Ei siis ole mitään väärää näiden käsitteiden yleistämisessä. Samba on jo LinuxUnix-toteutus, ja sillä on omat erityispiirteensä, mutta poikkean siitä. Mikä tässä on tärkeää: kun Veeam pyytää kirjoittamaan jotain UNC-polkuun (palvelinhakemistoon), palvelin käyttää tiedostojärjestelmän ajurien hierarkiaa, mukaan lukien mup ja mrxsmb, kirjoittaakseen palloon. Vastaavasti nämä ohjaimet tuottavat myös virheitä.
Ei pärjää ilman Winsock API. Jos jotain on tehtävä verkon kautta, VBR toimii Windows Socket API:n kautta, joka tunnetaan yleisesti nimellä Winsock. Joten jos näemme lokissa joukon IP:Porttia, se on tässä. Virallisissa asiakirjoissa on hyvä luettelo mahdollisista .
mainittu yllä WMI (Windows Management Instrumentation) on eräänlainen kaikkivaltias API kaiken ja kaikkien hallintaan Windows-maailmassa. Esimerkiksi Hyper-V:n kanssa työskennellessä lähes kaikki isännälle lähetetyt pyynnöt kulkevat sen läpi. Sanalla sanoen asia on ehdottoman korvaamaton ja ominaisuuksiltaan erittäin voimakas. Yritetään selvittää missä ja mikä on rikki, sisäänrakennettu WBEMtest.exe-työkalu auttaa paljon.
Ja viimeinen listalla, mutta ei suinkaan vähäisimpänä - VSS (Volume Shadow Storage). Aihe on yhtä ehtymätön ja salaperäinen kuin siitä on kirjoitettu paljon dokumentaatiota. Shadow Copy ymmärretään yksinkertaisimmin erityiseksi tilannekuvaksi, jota se pohjimmiltaan on. Hänen ansiosta voit tehdä sovelluskohtaisia varmuuskopioita VMwaressa ja melkein kaikkea Hyper-V:ssä. Minulla on suunnitelmissa tehdä erillinen artikkeli jossa on hieman puristus VSS:stä, mutta toistaiseksi voit yrittää lukea . Ole vain varovainen, koska. yrittäminen ymmärtää VSS:tä nopeasti voi johtaa aivovammaan.
Tähän voimme ehkä lopettaa. Pidän alkeellisten asioiden selittämisen valmiiksi, joten seuraavassa luvussa tarkastellaan jo lokeja. Mutta jos sinulla on kysyttävää, kysy ne kommenteissa.
Lähde: will.com