Mistä on kyse?

Nimen mukaisesti tämä artikkeli käsittelee Windows DNS Serverin virheenkorjauslokitustoimintoja. Lukemalla tätä artikkelia saat tietoa siitä, miten voit saada näkemyksiä ympäristösi nimiratkaisuprosesseista. Tämä voi olla erittäin hyödyllistä DNS:ään liittyvien ongelmien vianetsinnässä ja analysoinnissa. Ennen kuin siirrymme yksityiskohtiin, ymmärretään ensin, mitä DNS Serverin virheenkorjauslokitus on ja miksi se -joskus- on tärkeä asia ja käytännöllinen apuväline.

Monissa tapauksissa DNS Server on rooli verkkotunnuksen ohjaimessa Active Directory -ympäristössä. Joka tapauksessa DNS Server on kriittinen osa verkkoinfrastruktuuria. Nimiratkaisu on kaikkialla ja se on perusosa tietokoneiden viestinnässä verkossa.

Mutta mitä tapahtuu, kun jokin menee pieleen, tai jos tätä kriittistä komponenttia on tarpeen muuttaa jostain syystä? Tämä voi tapahtua monista syistä, kuten:

  • Vianetsintä - Joku ilmoittaa nimiratkaisun ongelmista. Ajoittain väärät IP-osoitteet palautuvat asiakkaalle ja sovellus lakkaa toimimasta.
  • Muutto ja muutoksenhallinta - Palvelimia saatetaan tarvita siirrettäväksi muualle. Ehkä uuteen verkkosegmenttiin, hyperskalaajaan, tai yksinkertaisesti organisaatio on päättänyt siirtää DNS:n Active Directorysta verkkolaitteisiin. Asiakkaita saatetaan tarvita konfiguroida uudelleen tässä vaiheessa kohdistamaan uusiin DNS-palvelimiin.
  • Tilastot ja (turvallisuus)analyysi - Kuka kysyy mitä? Millaisia malleja voidaan havaita? Millaisia pyyntöjä tehdään? Onko epäilyttävää toimintaa?

Tällaisissa tapauksissa näkemykset nimiratkaisun yksityiskohdista voivat olla korvaamattomia. Tämä artikkeli yrittää kattaa joitakin tapoja saada nämä näkemykset. Haluan mainita, että puhuessani “DNS-asiakkaasta” tarkoitan mitä tahansa laitetta, joka kysyy nimiratkaisua, kuten työasemaa, palvelinta, tulostinta, IT-infrastruktuurilaitteita tai jopa IoT-laitetta.

Windows DNS Serverin näkymät

Kun kysytään “Miten saada tietoa DNS Serveristä?”, on useita vaihtoehtoja saatavilla. Päätökset, päätökset Katsotaanpa yleisimpiä:

Kyky - Verkkopakettien kaappaaminen

Klassinen ja tehokas. Ehkä ei pitkäaikainen ratkaisu, mutta nopeaan vianetsintään tai reaaliaikaiseen analyysiin se on täysin arvokasta. Kirjoitin tästä viimeisessä artikkelissani [Verkkoliikenteen kaappaaminen Windowsissa][captureNetworkTrafficReference], joten en mene yksityiskohtiin tässä.

Kyky - Palomuurilokit

Jos sinulla on verkon segmentointi käytössä ja pääsy palomuurilokeihin, voit saada tietoa siitä, kuka kommunikoi DNS:n -ja kaikkien muiden palveluiden- kanssa. Tämä ei ole kaikkein yksityiskohtaisin tieto, koska siinä puuttuu tarkkuus ja palvelukohtaiset tiedot, mutta se voi olla hyödyllistä ja nopea voitto, jos se on jo käytössä. Tämä ei ehkä ole vaihtoehto, jos sinulla on tasoitettuja verkkoja, jolloin DNS-asiakkaiden ja DNS-palvelimen välillä ei todennäköisesti ole palomuuria. Voit käyttää paikallista Windows-palomuuria joka tapauksessa, mutta kuten saatat nähdä seuraavissa osioissa, on parempia vaihtoehtoja tässä tapauksessa. Sitten on valitettavasti esteenä “organisatoriset siilot” ja “viestinnän puute” tiimien välillä, jolloin palomuurilokien saaminen ei yksinkertaisesti ehkä ole mahdollista, vaikka ne olisivat olemassa.

Kyky - Tapahtumalokit

Toivottavasti sinulla on EventLog-konfiguraatio, joka lokittaa Kaikki tapahtumat DNS-palvelimellasi. Jos ei, nyt on aika asettaa se, koska se on hyvä lähtökohta toiminnalliselle lokitukselle Windows DNS -palvelussasi.

Se ei ehkä ole kaikkein yksityiskohtaisin tieto, mutta se tuottaa perusnäkemyksiä klassisiin Windows Event Logeihin.

Perinteisten Windows Event Logien lisäksi on myös joitakin DNS Serverille erityisiä sovelluslokeja saatavilla. Monet tuntevat “DNS Server” -lokin “Sovellus- ja palvelulokit” -osiossa Tapahtumien katselijassa, mutta ne eivät ole niin kiinnostavia todellisten näkemysten saamiseksi palvelusta.

Tehokkaasti käytettävissä on kaksi muuta DNS Serverin tapahtumalokia kansiorakenteen alapuolella. Audit-lokki, joka tarjoaa toiminnallista tietoa siitä, millaisia toimintoja DNS-palvelimella tapahtuu: DNS Server Audit Event Log Toisaalta on vähemmän tunnettu Analyyttinen lokki, joka voidaan aktivoida tarpeen mukaan. Se tarjoaa erittäin yksityiskohtaista tietoa käynnissä olevista nimiratkaisuprosesseista, kuten millaisia kyselyjä tehdään, millaisia vastauksia lähetetään ja niin edelleen. DNS Server Analytical Event Log Tämä lokki ei ole aktiivinen oletuksena, mutta se voidaan ottaa käyttöön vianetsintää ja analyysia varten. Valitettavasti, niin kauan kuin tiedän, “Analyyttinen” lokki ei voi siirtyä useisiin tiedostoihin, joten sen käyttö pitkän aikavälin lähestymistavassa voi olla hankalaa. Lyhytaikaiseen vianetsintään tai analyysiin se voi olla vaihtoehto.

Kyky - Tapahtumajäljitys

Windows Event Tracing (ETW) on todennäköisesti tehokkain vaihtoehto, kun haluat syventyä Windowsin sisäisiin toimintoihin. Valitettavasti se on myös monimutkaisin, eikä se ole kovin käyttäjäystävällinen. Saatan käsitellä ETW:tä erikseen tulevassa artikkelissa, mutta nyt en mene yksityiskohtiin tässä.

Kyky - DebugLogFile

Windows DNS Serverillä on myös sisäänrakennettu tekstipohjainen virheenkorjauslokitus, joka voidaan konfiguroida helposti. Tämä ominaisuus mahdollistaa samojen yksityiskohtien lokittamisen kuin “Analyyttinen” tapahtumalokki, mutta se kirjoittaa tekstifileihin ja tarjoaa rullaustoimintoja, joten sitä voidaan käyttää pitkän aikavälin lähestymistavassa.

Se voi olla hieman käyttäjäystävällisempi kuin ETW, koska se tarjoaa luettavaa tekstiä ilman tarpeen PerfMonille ja muille ETW-työkaluille. Lokitiedoston muoto ei kuitenkaan ole täydellisesti jäsennelty, mutta tietojen kuluttaminen on silti mahdollista jonkin verran vaivannäöllä.

Kuinka asettaa lokitus

Nyt kun meillä on vaihtoehdot pöydällä, katsotaanpa, miten tämä asetetaan. Kuten aiemmin mainittiin, en käsittele pakettikaappausta, palomuurilokkeja tai tapahtumajäljitystä tässä, mutta katsotaanpa tapahtumalokeja ja DebugLogFilea.

Konfiguroi Analyyttinen Tapahtumalokki

Kuten jo aiemmin mainittiin, “Analyyttinen” tapahtumalokki ei ole aktiivinen oletuksena. Vielä enemmän, se ei ole näkyvissä oletuksena. Ensimmäiseksi, navigoidaan asiaankuuluvaan Palvelulokit-osioon Tapahtumien katselijassa.


Siellä sinun on otettava käyttöön analyyttiset ja debug-lokit DNS-palvelimelle.


Sen jälkeen lokki on edelleen pois päältä eikä näytä mitään merkintöjä, joten sinun on otettava lokki käyttöön.


Kaikille, jotka eivät halua seurata klikkausoperaatioita, tässä on komentorivi analyyttisen lokin ottamiseksi käyttöön:

wevtutil set-log "Microsoft-Windows-DNSServer/Analytical" /e:true

Ottaessasi lokin käyttöön palvelin alkaa kerätä tietoa. Ole tietoinen siitä, että lokissa ei ole live-näkymää kerätyistä tapahtumista. Tietojen kerääminen on pysäytettävä ottamalla lokki pois päältä, ja sitten voit nähdä kerätyt tapahtumat.

wevtutil set-log "Microsoft-Windows-DNSServer/Analytical" /e:false


Sen jälkeen voit nähdä kerätyt tapahtumat lokissa:


Tapahtumalokien luonteen vuoksi on myös saatavilla XML-tietonäkymä, joka tarjoaa jäsennellymmän näkymän kerätyistä tapahtumista. Tämä tarkoittaa, että tapahtumalokin merkinnät eivät sisällä tekstiviestiä yllä olevasta kuvakaappauksesta, vaan ne sisältävät raakadatarakenteen, joka renderöidään tekstiviestinä Windowsin tapahtumien katselijassa.


“Analyyttisessä” lokissa olevat tapahtumat voidaan viedä Tapahtumien katselijan kautta, mutta saatat saada enemmän joustavuutta ja hallintaa käyttämällä PowerShelliä tapahtumien kyselyyn ja vientiin. Merkinnät voidaan kysyä myös PowerShellin kautta:

# Kysyy merkinnät analyyttisestä lokista
$records = Get-WinEvent -LogName "Microsoft-Windows-DNSServer/Analytical" -Oldest

# Näyttää ensimmäiset 5 merkintää
$records | Select-Object -First 5 | Format-List

Ole tietoinen vaaditusta parametrista “-Oldest” Get-WinEvent-komennossa! Cmdlet palauttaa virheen analyyttisessä lokissa, jos et määritä tätä parametria.

Konfiguroi DebugLogFile

Toinen, ja todennäköisesti erittäin arvokas, vaihtoehto on ottaa käyttöön DNS Debug -lokitiedosto. Kuten edellä on kuvattu, se on tekstipohjainen lokitiedosto, joka voidaan helposti ottaa käyttöön ja joka tarjoaa yksityiskohtaista tietoa nimiratkaisutoiminnoista. Debug-lokin konfiguraation perusteella tarjotut tiedot voivat vaihdella perus “kuka kysyi mitä” erittäin, erittäin yksityiskohtaisiin tietoihin pakettitiedoista, sekä paljon.DNS-spesifisten opkoodien ja lippujen osalta.

On kaksi tapaa aktivoida virheenkorjauslokitiedosto, joko käyttöliittymän tai PowerShellin kautta.

Käyttöliittymä on “Windowsin klassinen”, melko suoraviivainen, voit löytää asetukset DNS-hallinnasta “Virheenkorjauslokitus” -osiossa palvelimen ominaisuuksista.

Käytännön vinkki: Jos sinulla on useampi kuin yksi DNS-palvelin (ja oletan, että sinulla on), on erittäin hyvä idea käyttää samoja asetuksia kaikilla palvelimilla, jotta saat johdonmukaista tietoa ympäristössäsi.

Lisäksi suosittelen laittamaan palvelimen nimen lokitiedoston nimeen, jotta voit helposti tunnistaa lokitietojen lähteen.

Vaikka käyttöliittymä vaikuttaa käyttäjäystävälliseltä ja suoraviivaiselta, siinä on joitakin haittoja ja heikkouksia. Itse asiassa se ei tarjoa koko valikoimaa konfigurointivaihtoehtoja, eikä se ole kovin skaalautuva, jos sinulla on enemmän kuin pieni määrä palvelimia. Esimerkiksi, jos haluat aktivoida virheenkorjauslokitiedoston 10 tai useammalle palvelimelle, sinun on oltava erittäin keskittynyt tehdessäsi samoja asetuksia ja oikeaa kirjoitusta kaikilla palvelimilla yhä uudelleen. Kun luku ylittää neljä, suosin yleensä “Dev-Ops” -lähestymistapaa “Click-Ops” -tavan sijaan.

Oma kokemukseni inhimillisestä laiskuudestani ja tarkkuuden puutteesta toistuvissa tehtävissä pakotti minut oppimaan: PowerShell on oikea tapa edetä

Joten, ei yllättäen, PowerShellissä on käytettävissä cmdlet-komentoja “Get” ja “Set” DNS-palvelimen virheenkorjauslokiasetusten hallintaan:

# Hae DNS-palvelimen virheenkorjauslokin asetukset
Get-DnsServerDiagnostic

# Aseta DNS-palvelimen virheenkorjauslokin asetukset
Set-DnsServerDiagnostic

Get-komento palauttaa kaikki käyttöliittymän vaihtoehdot yhdessä joidenkin lisävaihtoehtojen kanssa, joita ei ole saatavilla käyttöliittymässä, kuten lokin rullausasetukset ja kyky lisätä enemmän DNS-palvelinspesifistä sisäistä operatiivista tietoa virheenkorjauslokkiin.

DNS Server Debug Log Settings via PowerShell

TÄRKEÄÄ: Vaikka ominaisuus “MaxMBFileSize” saattaa viitata siihen, että tiedostokoko määritellään MB:ssä, se määritellään itse asiassa tavuina. Joten, jos haluat asettaa tiedostokooksi 10MB, sinun on asetettava arvo 10485760 (10 * 1024 * 1024).

Kiinnitä myös huomiota “LogFilePath” -nimen loppumerkkiin!
Koska haluan kauniita tiedostonimiä ja ominaisuus “EnableLogFileRollover” on käytössä, lokin tiedostonimi päättyy alaviivaan. Palvelin lisää aikaleiman liitteenä annettuun tiedostonimeen, kun se luo lokin. Tällä lähestymistavalla minulla on selkeä erottelu palvelimen nimen ja aikaleiman välillä.

Seuraava kuva näyttää ominaisuuden “EnableLogFileRollover” erilaisen käyttäytymisen tiedostonimessä:


TÄRKEÄÄ: On myös EHDOTTOMAN TÄRKEÄÄ ymmärtää rullausprosessin käyttäytyminen. Yhteistä lokikokoa ei ole asetettu! Tämä tarkoittaa, että jos rullaus on käytössä, palvelin luo uuden tiedoston aina, kun määritetty MaxMBFileSize saavutetaan, mutta luotavien tiedostojen määrälle ei ole rajoitusta.

Se tarkoittaa, ETTÄ SINUN TÄYTYY HUOLEHTIA LOKITIEDOSTOISTA ja VAPAISTA TILOISTA PALVELIMELLASI!

Jos aktivoit virheenkorjauslokitiedoston “asetetaan ja unohdetaan” -lähestymistavalla, ja sinulla on tuottava kuormitus palvelimellasi, saatat täyttää levysi. Kysymysten ja yksityiskohtien tason mukaan tämä voi olla jopa useita gigatavuja päivässä, jos sinulla on paljon DNS-asiakkaita.

TAAS, ÄLÄ TEKEMÄT TÄTÄ ASETETAAN JA UNOHDETAAN!

Sinun on oltava oma strategia huolehtia lokitiedostoista. Automaattista puhdistusta ei ole.

Tässä on esimerkki siitä, kuinka voit aktivoida virheenkorjauslokitiedoston PowerShellin avulla:

# Määritä halutut DNS-palvelimen virheenkorjauslokitusparametrit
$dnsDebugLogParameter = @{
    "Queries"                              = $true
    "Answers"                              = $true
    "Notifications"                        = $true
    "Update"                               = $true
    "QuestionTransactions"                 = $true
    "UnmatchedResponse"                    = $true
    "SendPackets"                          = $true
    "ReceivePackets"                       = $true
    "TcpPackets"                           = $true
    "UdpPackets"                           = $true
    "FullPackets"                          = $false
    "FilterIPAddressList"                  = $null
    "EventLogLevel"                        = 4
    "UseSystemEventLog"                    = $false
    "EnableLoggingToFile"                  = $true
    "EnableLogFileRollover"                = $true
    "LogFilePath"                          = "C:\Administration\Logs\DNSServer\DnsDebugLog_$($env:COMPUTERNAME).$((Get-CimInstance -ClassName "win32_computersystem").Domain)_.log"
    "MaxMBFileSize"                        = (10 * 1mb)
    "SaveLogsToPersistentStorage"          = $false
    "WriteThrough"                         = $false
    "EnableLoggingForLocalLookupEvent"     = $false
    "EnableLoggingForPluginDllEvent"       = $false
    "EnableLoggingForRecursiveLookupEvent" = $false
    "EnableLoggingForRemoteServerEvent"    = $false
    "EnableLoggingForServerStartStopEvent" = $false
    "EnableLoggingForTombstoneEvent"       = $false
    "EnableLoggingForZoneDataWriteEvent"   = $false
    "EnableLoggingForZoneLoadingEvent"     = $false
}

# Käytä määriteltyjä asetuksia
Set-DnsServerDiagnostics @dnsDebugLogParameter

Seuraavassa luvussa tarkastelemme ideoitani siitä, “kuinka hyödyntää luotuja virheenkorjauslokitietoja”. Siinä viittaan omaan PowerShell-moduuliini [DNSServer.DebugLogParser][dNSServerDebugLogParserDef], joka purkaa Windows-palvelun luomia virheenkorjauslokitiedostoja.
Moduuli on saatavilla PowerShell-galleriassa ja omalla [GitHub-tililläni][githubProfile]. GitHub-repositorio sisältää myös [lisäasiakirjoja käyttöoppaineen toimialueympäristössä][dnssLogParserRepository]. Siellä voit löytää skriptejä, joita voit todennäköisesti soveltaa palvelimillasi.

Mitä tulee artikkelin keskittymiseen, en mene tarkemmin operatiivisiin yksityiskohtiin mahdollisessa tuotantoympäristössä. Toivottavasti olen tehnyt selväksi, että sinun on huolehdittava lisästrategioista ennen tällaisten lokien aktivoimista.

Datan kulutus

OK, edellä mainittuja noudattaen sinulla on dataa eri palvelimillasi. Tämä tarkoittaa, että sinulla on roskia levällään. Seuraavassa vaiheessa sinun on huolehdittava datan kulutuksesta ja todennäköisesti tuoda se keskitettyyn paikkaan.

Ei varmaankaan ole yllätys, että PowerShell voi auttaa sinua matkalla.

Tapahtumalokit

Kuten aiemmin mainittiin, “Analyyttinen” tapahtumaloki voi olla erittäin kätevä nopeassa vianmäärityksessä. Kun puhuimme aiemmissa osioissa siitä, mitä ja miksi, tässä on esimerkki nopeasta vianmäärityssessiosta. Tämä voi olla käytännöllistä tilanteessa, jossa sinun on käsiteltävä ongelmia kuten “Kaveri, DNS-palvelimesi ei palauta mitään, kun kysyn ‘xyz’. Mitä ihmettä!”

Huomaa, että seuraava esimerkki olettaa, että työskentelet hallintotyöasemalla ja sinulla on asianmukaiset palomuuripolitiikat etäyhteyden hallintaan palvelimillesi. Jos työskentelet suoraan palvelimella, voit yksinkertaisesti ohittaa “-ComputerName” -parametrin komennoissa tai käyttää koodia “-ScriptBlock” -parametrissa suoraan.

Ensinnäkin, määritellään joitakin muuttujia, kuten palvelin, jota kysymme:

$Server = "DC01"

Voit määrittää yhden tai useamman palvelimen suoraan.

Nyt, kun olemme ilmoittaneet, mitä palvelimia tarkkailemme, voimme aktivoida analyyttisen lokin näillä palvelimilla. Kun tämä on tehty, odota hetki tai toista ongelma, ja sitten poista loki käytöstä.

# Ota analyyttinen loki käyttöön
Invoke-Command -ComputerName $Server -ScriptBlock {
    wevtutil.exe set-log "Microsoft-Windows-DNSServer/Analytical" /e:true /q
}

# Odota hetki kerätäksesi tietoja

# Poista analyyttinen loki käytöstä
Invoke-Command -ComputerName $Server -ScriptBlock {
    wevtutil.exe set-log "Microsoft-Windows-DNSServer/Analytical" /e:false
}

Seuraavassa vaiheessa kaappaa lokista tiedot. Riippuen datan määrästä, tämä voi kestää jonkin aikaa, joten ole kärsivällinen. Kun tapahtumat on kaapattu, on tehtävä työtä, jotta tiedot olisivat käyttökelpoisempia.
Käytän Message-ominaisuutta tapahtumalokin tietueista yksityiskohtien erottamiseen, koska siinä on jo ValueNames paikallaan. On kuitenkin myös Properties-ominaisuus (🤭 tätä kirjoittaessani tämä kuulostaa 🤪 ohjelmointijutulta) taulukko kaikista arvoista, mutta ilman PropertyNames paikallaan. Jos haluat työskennellä .Properties-ominaisuuden kanssa, sinun on tehtävä enemmän työtä saadaksesi arvot käyttökelpoiseen muotoon, mikä todennäköisesti antaa sinulle vahvempaa johdonmukaisuutta paikallistamisessa ja eri Windows-versioissa…

# Hae tapahtumalokitiedot palvelimelta
$records = Get-WinEvent -ComputerName $Server -LogName "Microsoft-Windows-DNSServer/Analytical" -Oldest | Where-Object Providername -ne ""

# Käsittele tietueita rikastuttaaksesi tietoja
$propNames = @("MachineName", "LogName", "TimeCreated", "LevelDisplayName", "RecordId", "Message", "ProviderName", "Id", "Version", "Level", "Task", "Opcode", "Keywords", "ProviderId", "ProcessId", "ThreadId", "ContainerLog", "OpcodeDisplayName", "TaskDisplayName")
$dataRecords = foreach ($record in $records) {
    $hash = [ordered]@{}
    
    $propNames | ForEach-Object { $hash[$_] = $record.$_}
    $record.Message.split(";").trim() | ForEach-Object { $pair = $_.split("="); $hash[$pair[0].replace(":", "").trim()] = $pair[1].trim() }
    
    [PSCustomObject]$hash
    
}

Nyt, kun meillä on tiedot käyttökelpoisemmassa muodossa, voimme tehdä mitä tahansa sen.
Voimme näyttää sen, viedä sen tai tehdä siitä live PowerShell-analyysiä.

Tässä on joitakin esimerkkejä:

# Näytä tiedot
$dataRecords | Format-Table

$dataRecords | Out-GridView

$dataRecords | Select-Object -First 1 | Format-List

Raaka Format-Table ei ehkä ole niin arvokas, koska konsoli kääntää tulosteen. Out-GridView on hieman käyttäjäystävällisempi, koska se tarjoaa vieritettävän ja lajiteltavan taulukon. Format-List avulla saat vilauksen yksittäisen tietueen yksityiskohdista, mikä antaa sinulle tietoa siitä, mitä ominaisuutta etsiä ja ryhmitellä jatkoanalyysissä.

# Vie tiedot käytettäväksi muissa työkaluissa, kuten Excelissä, PowerBI:ssä tai missä tahansa haluat
$dataRecords | Export-Csv -Path "DNSServer-Analytics.csv" -Delimiter ";" -Encoding UTF8 -NoTypeInformation

CSV:hen vienti ja sen siirtäminen Exceliin vaikuttaa olevan tyypillinen helppo ratkaisu monissa tapauksissa, koska tämä antaa sinulle muiden työkalujen voiman datan pilkkomiseen ja analysoimiseen.

Toisaalta, jos haluat tehdä nopeaa ja yksinkertaista analyysiä suoraan PowerShellissä, kun olet vianetsintäpuhelussa, sekin on mahdollista. Tässä on joitakin ideoita:

# Pilko ja analysoi... hae tietoa datasta suoraan PowerShellissä perusryhmittelyllä
$dataRecords | Group-Object TaskDisplayName
$dataRecords | Group-Object QNAME
$dataRecords | Group-Object InterfaceIP
$dataRecords | Group-Object Source

# Joitakin edistyneempiä ryhmittelyesimerkkejä
$dataRecords | Group-Object { "Source '$($_.Source)' on Interface '$($_.InterfaceIP)'" } | Format-Table Count, Name
$dataRecords | Group-Object { "Source '$($_.Source)' on Interface '$($_.InterfaceIP)' with '$($_.QNAME)'" } | Sort-Object Name | Format-Table Count, Name
$dataRecords | Group-Object { "'$($_.QNAME)' - Source '$($_.Source)' ($($_.TaskDisplayName))" } | Sort-Object Name | Format-Table Count, Name
$dataRecords | Group-Object { "'$($_.QNAME)' - Source '$($_.Source)' on Interface '$($_.InterfaceIP)' ($($_.TaskDisplayName))" } | Sort-Object Name | Format-Table Count, Name

# Ryhmittely yhdistettynä suodattamiseen
$dataRecords | Where-Object TaskDisplayName -like "LOOK_UP" | Group-Object { "Source '$($_.Source)' - '$($_.QNAME)'" } | Sort-Object Name | Format-Table Count, Name

# Kun olemme tutkineet mahdollisia arvoja perusryhmittelyssä, voimme suodattaa ja listata tietueet yksityiskohtineen
$dataRecords | Where-Object TaskDisplayName -like "LOOK_UP" | Where-Object Source | Sort-Object TimeCreated | Format-Table MachineName, TimeCreated, Source, InterfaceIP, QNAME, QTYPE
$dataRecords | Where-Object TaskDisplayName -like "LOOK_UP" | Where-Object Source -like "10.1.1.1" | Sort-Object QNAME | Format-Table MachineName, TimeCreated, Source, InterfaceIP, QNAME, QTYPE

Tämän näyttämisellä toivon antavani sinulle ideoita siitä, miten saada tietoa datasta ja miten käyttää PowerShellia siihen.
Tietysti, vaihtoehtoja on paljon lisää, eikä tämä välttämättä skaalaudu erittäin suurille tietojoukoille tai pitkälle aikavälille. Joten katsotaan seuraavaan lukuun…

DebugLogFile

DNS Debug Log -tiedoston tarkastelu tuo ratkaisun käsitellä huomaamatonta ja pitkäaikaista lähestymistapaa. Se voi myös skaalautua paremmin suurilla tietojoukoilla suuremmissa ympäristöissä. Tiedosto itsessään on tekstimuotoinen, joten se voidaan avata Notepadissa. DNS Server Debug Log File Notepadissa

Valitettavasti muoto ei ole täydellisesti jäsennelty, joten tietojen käsittelyyn tarvitaan jonkin verran työtä, jotta saamme tiedot käyttökelpoisempaan muotoon. Joten kuten teimme aiemmin EventLogsien kanssa, mennään PowerShelliin tekemään hieman käsittelytaikuutta.


Tutkiessani ja työskennellessäni AI:n kanssa DebugLogFile-muodon parissa, hauskaa kyllä, AI valitti, että muoto ei ole täydellisesti jäsennelty helppoa käsittelyä varten. 🤪


Tämän haasteen voittamiseksi olen luonut PowerShell-moduulin nimeltä [DNSServer.DebugLogParser][dNSServerDebugLogParserDef].
Moduuli tarjoaa kattavan käsittelylogiikan yhdessä cmdletissä. Se on periaatteessa “yksi pysähdyspaikka” muuntaa “ei niin helposti käsiteltävä lokitiedosto” voimassa olevaan ja helppokäyttöiseen CSV-tiedostoon. Moduuli hoitaa kaikki tarvittavat vaiheet. [assets-kansiossa][dnssLogParserRepositoryExampleFolder] [moduulin GitHub-repossa][dnssLogParserRepository] voit löytää joitakin esimerkkilokitiedostoja ja niiden muunnettuja CSV-tiedostoja tarkasteltavaksi. Ilmeisesti voit ja sinun pitäisi käyttää omia tiedostojasi ympäristöstäsi myös!

Joten, antaakseni sinulle nopean esimerkin muuntoprosessista, tässä on yksinkertainen esimerkki siitä, miten käyttää moduulia muuntaaksesi DebugLogFile CSV-tiedostoksi:

# Tuo moduuli (varmista, että asennat sen ensin)
Import-Module DNSServer.DebugLogParser

# Käsittele DebugLogFile ja vie CSV:hen
Convert-DNSDebugLogFile "DnsDebugLog_DC01.log"

Tällä kaikilla oletusasetuksilla komennosta saat 3 CSV-tiedostoa tuloksena muuntoprosessista.

TiedostoKuvaus
DnsDebugLog_DC01.csvTämä on muunnettu lokitiedosto yksityiskohtineen CSV-tyylisessä muodossa
DnsDebugLog_DC01_Statistic.csvCSV, jossa on tilastotietoja lokissa olevista tietueista päivittäin
DnsDebugLog_DC01_PacketStatistic.csvCSV, jossa on tilastotietoja “Packet”-tyypistä ja yhteenveto kaikista asiakkaista päivittäin

Kuten jo aiemmissa osioissa on mainittu, CSV-tiedostoja voidaan käyttää lisäanalyysiin Excelissä, PowerBI:ssä tai missä tahansa haluat. Useiden tiedostojen tuottamisen tarkoitus on kohdata suuren datan haasteet suuremmissa ympäristöissä.

Käyttötapauksestasi riippuen saatat haluta vain käyttötilastoja. Tällä lähestymistavalla sinun ei tarvitse tarkastella kaikkia yksityiskohtia täydessä lokissa. Se voi vähentää tallennustilaa huomattavasti, koska se tiivistää tiedot ja jättää huomiotta kaikki meluisat yksityiskohdat.
Jos haluat syventyä metsästämään ja analysoimaan yksityiskohtia, saatat haluta käyttää täydellistä lokia ja jättää tilastot huomiotta, koska ne eivät tarjoa tarpeeksi yksityiskohtia.


Mutta eikö olisi mukavaa olla parametri, jolla voit määrittää, mitkä tulostiedostot haluat?
Tervetuloa -OutputType-parametrille!

Convert-DNSDebugLogFile -InputFile "DnsDebugLog_DC01.log" -OutputType Statistic

Tällä voit määrittää, haluatko vain lokin, vain tilastot tai molemmat. Tämä antaa sinulle enemmän joustavuutta ja voi säästää sinulta paljon tallennustilaa.


Tutkiessasi luotuja CSV-tiedostoja saatat huomata, että CSV:ssä on tyhjää saraketta nimeltä “ComputerName”.

Tämä johtuu siitä, että DNS Debug -lokissa ei ole palvelimen nimeä. 🤷‍♂️

Voit elävöittää tätä saraketta antamalla palvelimen nimen -ComputerName-parametrille komennossa.

# Määritä manuaalisesti tietokoneen nimi
Convert-DNSDebugLogFile -InputFile "DnsDebugLog_DC01.log" -ComputerName "DC01"

Muistatko neuvoni osiossa Configure the DebugLogFile palvelimen nimen laittamisesta lokitiedoston nimeen? Harjoittelun myötä voit laittaa palvelimen nimen CSV-tiedostoon lennossa jakamalla tiedoston nimen.

# Ota tietokoneen nimi automaattisesti tiedoston nimestä
$files = Get-ChildItem c:\logs\*.log

foreach($file in $files) {
    Convert-DNSDebugLogFile -InputFile $file.FullName -ComputerName $file.BaseName.split("_")[1]
}

Tämä on erityisen hyödyllistä, jos sinulla on useita palvelimia ja haluat saada palvelimen nimen CSV:hen paremman tunnistamisen ja analyysin vuoksi.

Toinen asia, johon haluat todennäköisesti kiinnittää huomiota, on päivämäärämuoto luoduissa CSV-tiedostoissa. Oletusarvoisesti käytetään lähdelokin muotoa.
Se voi aiheuttaa haasteita, kun sinulla on kansainvälinen ympäristö, jossa on paikallistettuja palvelimia. Todennäköisesti päivämäärämuoto voi vaihdella palvelimelta toiselle. Tämä luo haasteita, kun haluat tehdä analyysiä päivämääristä työkaluissa kuten Excel tai PowerBI, koska ne eivät ehkä tunnista päivämäärämuotoa oikein. Tämän haasteen voittamiseksi voit käyttää toista parametria komennossa… tervetuloa -OutputCulture-parametrille.

Oma henkilökohtainen mieltymykseni päivämäärämuodossa on ISO-muoto, joten asetankin yleensä ruotsalaisen tuloskulttuurin ("sv-SE"), koska se käyttää ISO-muotoa päivämäärille ja ajalle. Tällä voin varmistaa, että luodun CSV:n päivämäärämuoto on johdonmukainen, lajitteltavissa ja helposti tunnistettavissa riippumatta paikallisista asetuksista.

Convert-DNSDebugLogFile -InputFile "DnsDebugLog_DC01.log" -OutputCulture "sv-SE"

Sivuhuomautuksena on myös -InputCulture-parametri, jos tiedät tarkasti käytetyn muodon lähdeserverillä. Tämä parametri toimii samalla tavalla kuin -OutputCulture-parametri, mutta sitä käytetään määrittämään kulttuuri päivämäärän purkamiseksi lähdelokitiedostosta.


Viimeiseksi, mutta ei vähäisimpänä, kaksi käytännön vinkkiä tuotantokäyttöön:
Kun olet muuntanut alkuperäisen kirjoitetun lokitiedoston CSV:ksi, saatat haluta poistaa sen tallennustilan säästämiseksi. CSV:n pitäisi sisältää kaikki tiedot käyttökelpoisemmassa muodossa. -RemoveSourceFile-parametrin avulla voit tehdä tämän ilman lisävaivannäköä.
Ja koska lokitiedostot ovat tavallista tekstiä ja voivat olla melko suuria, saatat haluta pakata ne muunnoksen jälkeen. -CompressOutput-parametrin avulla voit tehdä tämän myös lennossa.

Convert-DNSDebugLogFile -InputFile "DnsDebugLog_DC01.log" -OutputCulture "sv-SE" -RemoveSourceFile -CompressOutput

Yhdistämällä kaikki edellä mainittu, voit saada melko tehokkaan ja joustavan työkalun, jolla voit saada tietoja lisäanalyysiin DNS-debug-lokeista, samalla kun huolehdit storage space and file management. Viimeisenä esimerkkinä haluan tuoda esiin täydellisemmän esimerkin, jota voit käyttää tuotantoympäristössä:

# hae täysin kirjoitetut (kierrätetyt) lokitiedostot lokikansiosta
$files = Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" | Sort-Object lastwritetime, Name -Descending | Select-Object -Skip 1

# Siirretään tiedostot muunnokseen kaikilla käytännön parametreilla tuotantokäyttöön
foreach($file in $files) {
    $file | Convert-DNSDebugLogFile -ComputerName $file.BaseName.split("_")[1] -Delimiter ';' -OutputType 'Both' -ContextFilter Packet -OutputCulture sv-SE -CompressOutput -RemoveSourceFile
}

Tämä esimerkki, erityisesti tiedostojen valintaprosessin suodattamisen kanssa, on tarkoitettu suoritettavaksi suoraan DNS-palvelimilla. Mutta on myös täysin ok suorittaa se omalla koneella säästääksesi resursseja DNS-palvelimilla. Jos se suoritetaan omalla koneella, sinun ei tarvitse käyttää Select-Object -Skip 1 tiedostojen valintaprosessissa.


Joka tapauksessa sinun on huolehdittava tiedostojen keräämisestä, riippumatta siitä, ovatko ne lopullisesti käsiteltyjä tiedostoja vai alkuperäisiä lokitiedostoja. Näytetyn esimerkin etuna on, että kuljetat vain jo pakattuja ZIP-tiedostoja. Tämä voi olla hyvä tapa säästää verkkokaistaa, erityisesti jos sinulla on laajasti hajautettuja palvelimia, joilla on paljon lokitietoja.

Raportin luominen

Konfiguroinnin ja tietojen keräämisen jälkeen haluat todennäköisesti hyödyntää niitä luodaksesi arvokkaita näkemyksiä ja raportteja. Käyttötapasi mukaan on saatavilla erilaisia työkaluja tämän tekemiseen. Katsotaanpa joitakin vaihtoehtoja.

Olen täysin tietoinen siitä, että käytettävissä on monia muita työkaluja ja lähestymistapoja, joten käsittele seuraavia osioita vain perusesimerkkeinä saadaksesi käsityksen mahdollisuuksista.

PowerShell - nopea ratkaisu

Kuten jo mainittiin osiossa Tietojen kulutus - EventLogs, voit tehdä nopeita analyysejä suoraan PowerShellissä tuomalla tiedot. Tämä voi olla kätevää nopeissa vianetsintätilanteissa, joissa haluat vain nopeasti saada perusinfoa. Tämä ei tietenkään ole ensiluokkainen ratkaisu monimutkaisille analyyseille tai pitkäaikaisille raporteille, mutta se on mahdollista.

En mene tässä yksityiskohtiin, koska olemme jo käsitelleet perusryhmittely- ja suodatusvaihtoehtoja osiossa Tietojen kulutus - EventLogs. Toinen esimerkki on, että samaa lähestymistapaa Group-Object voidaan soveltaa myös DebugLogFile CSV-tiedostoihin:

# Tuo tiedot luodusta CSV-tiedostosta
$dataRecords = Get-ChildItem C:\Administration\Logs\DNSServer\*_PacketStatistic.csv -File -Recurse | Import-Csv -Delimiter ";" -Encoding utf8

# Yhteenveto siitä, kuinka monta DNS-kyselyä on tehty
$dataRecords | Measure-Object Count -Sum

# Mitkä palvelimet ovat tiedoissa
$dataRecords | Group-Object ComputerName -NoElement

# Minkä tyyppisiä DNS-kyselyjä on kerätty
$dataRecords | Group-Object QuestionType -NoElement

# Mitkä DNS-asiakkaiden IP-osoitteet ovat yhteydessä palvelimeen
$dataRecords | Group-Object ClientIP -NoElement

# Mitkä DNS-asiakkaat puhuvat minkäkin palvelimen kanssa erikseen
$dataRecords | Group-Object { "$($_.ClientIP) --> $($_.ComputerName)" } | Format-Table Name -AutoSize

Erityisesti viimeinen esimerkki ryhmittelystä ClientIP:n mukaan voi olla erittäin kätevä IP-osoitteiden ja järjestelmän vastaavien nimien korrelaatiotaulukon rakentamiseen. Tämä vaatii tietenkin asianmukaisen DNS-infrastruktuurin, jossa kaikki laitteet on rekisteröity. Tässä on, miten voit tehdä tämän PowerShellin avulla:

# Hae ainutlaatuisten asiakas-IP-osoitteiden lista tiedotiedoista
$clientIPList = $dataRecords | Group-Object ClientIP -NoElement | Select-Object -ExpandProperty Name

# Ratkaise asiakas-IP-osoitteet isäntänimiksi ja luo kartoitustaulukko
$clientMapping = foreach ($clientIP in $clientIPList) {
    if ($clientIP -in ("127.0.0.1", "0.0.0.0", "::1", ".")) {
        [pscustomobject]@{
            ClientIP = $clientIP
            Name     = "Paikallinen isäntä DNS-palvelimella"
        }
    } else {
        $result = Resolve-DnsName -Name $clientIP -Type PTR -QuickTimeout -ErrorAction SilentlyContinue 
        
        if (([array]$result).count -ge 1) {
            [pscustomobject]@{
                ClientIP = $clientIP
                Name     = (($result.NameHost | Sort-Object) -join "; ")
            }
        } else {
            [pscustomobject]@{
                ClientIP = $clientIP
                Name     = "<nimi ei ratkaistavissa DNS:llä>"
            }
        }
    }
}

# Tulosta asiakas kartoitustaulukko
$clientMapping | Format-Table -AutoSize

# Vie asiakas kartoitus CSV-tiedostoon jatkokäyttöä varten
$clientMapping | Export-Csv -Path "ClientIP_Mapping.csv" -Delimiter ";" -Encoding UTF8 -NoTypeInformation

Tällainen asiakas kartoitus voi olla kätevä ja hyödyllinen. Tulokset voivat näyttää tältä:

Excel - klassinen ja joustava vaihtoehto

Excelin käyttö on todennäköisesti yleisin lähestymistapa nopeaan ja joustavaan CSV-pohjaiseen analyysiin. Ja siinä ei ole mitään väärää, koska Excel tarjoaa paljon vaihtoehtoja tietojen suodattamiseen, ryhmittelyyn ja visualisointiin arvokkaiden tietojen saamiseksi. Se on myös melko käyttäjäystävällinen, ja useimmat ihmiset ovat jollain tavalla tuttuja sen kanssa. Ainoa haittapuoli on, että se ei ehkä skaalaudu kovin hyvin erittäin suurilla tietojoukoilla.

Nopeassa analyysissä kysymykselle “Kuka käyttää DNS-palvelimiani minkälaisiin kyselyihin?” Excel on täysin riittävä. Laita vain luodut PacketStatistic CSV-tiedostot kansioon ja kerro Excelille tuoda kansio tietovälilehden kautta.


Valitsemalla kansion Excel tuo automaattisesti kaikki siellä olevat CSV-tiedostot ja yhdistää ne yhdeksi taulukoksi. Koska packetstatistic-tiedostot eivät ole kovin suuria, tämän pitäisi toimia melko hyvin jopa keskikokoisissa ympäristöissä, joissa on muutama palvelin.
Kun tiedot on tuotu, voit käyttää Excelin ominaisuuksia analysoidaksesi ja visualisoidaksesi tietoja haluamallasi tavalla. Lisäinvestoinnilla tietojen tuontilogiikkaan PowerQueryssä tai käyttämällä lisäkaaviosarakkeita myöhemmin, voit korreloida CSV-tiedostojen Client IP:t ClientIP_Mapping.csv-tiedoston kanssa saadaksesi asiakkaiden nimet samaan taulukkoon.
Hyödyntämällä “PivotTable”-ominaisuutta yhdistettynä Pivot-diagrammeihin, tietojen visualisointi on melko helppoa ja tarjoaa paljon vaihtoehtoja leikata ja pilkkoa. Tämä voi olla yleiskatsaus, kuten yllä esitetty, tai aikapohjaisia kaavioita.


Unohtamatta monidimensionaalisia tietotauluja, kuten tämä, joka näyttää kyselytyyppien jakautumisen eri DNS-asiakkaiden kesken.


Kaiken tämän pitäisi olla vain esimerkki… ja haluan selvästi korostaa, että tämä ei välttämättä sovi tarpeisiisi tai yrityksesi tai asiakkaasi suunnitteluun. Käsittele sitä inspiraationa luodaksesi omaa. Jos haluat tarkastella kaavoja ja Pivot-logiikkaa, jota olen käyttänyt esitettyjen esimerkkien rakentamiseen, tässä on [Excel-tiedosto tiedoilla ja esimerkeillä][dnsStatisticsFile].

PowerBI - moderni, tehokas valinta

Kun puhutaan “suuresta datasta” “suurissa yritysympäristöissä”, PowerBI on vahva kilpailija. Excel voi saavuttaa rajansa, koska se ei ole suunniteltu käsittelemään erittäin suuria tietojoukkoja. Kun sinulla on muutama sata palvelinta, tiedostojen määrä ja jopa tiedostojen tietueet voivat nopeasti nousta tuhansiin, miljooniin tai jopa miljardeihin.

Tässä PowerBI tekee vaikutuksensa, koska se on suunniteltu käsittelemään suuria tietojoukkoja, tarjoamaan voimakkaita analyysejä ja visualisointeja, sekä mahdollistamaan automaattisen päivityksen säännöllisesti ja useiden käyttäjien kulutettavaksi ilman tarvetta tietää, miten käsitellä taustalla olevaa dataa.

Tuontilogiikka PowerBI:ssä on sama kuin Excelin tietojen tuonnissa, [PowerQuery][powerQueryDocLink]. Tämä tarkoittaa, että PowerBI:ssä ja Excelissä on enemmän tai vähemmän sama tuontilogiikka. Ero alkaa siinä, miten PowerBI käsittelee tietoja tuonnin jälkeen ja miten se tarjoaa vaihtoehtoja visualisointiin ja jakamiseen.
Olen melko varma, että PowerBI- ja Fabric-asiantuntijat saattavat haluta rangaista minua PowerBI:n vertaamisesta Exceliin, mutta perusymmärryksen vuoksi pysykäämme siinä. En mene paljon syvemmälle PowerBI:n erityisominaisuuksiin, koska se ylittää tämän artikkelin aiheen, mutta haluan antaa sinulle ainakin joitakin ideoita siitä, miltä se todennäköisesti voi näyttää.



Sama asia kuin edellisessä osiossa Excel-esimerkeille… Kaikki on vain esimerkki ja ei välttämättä sovi tarpeisiisi. En ole panostanut paljon vaivannäköä PowerBI-raporttien suunnitteluun, koska haluan vain antaa esimerkkejä perusymmärryksestä. Ympäristösi koosta ja datan määrästä riippuen raporttisi voi näyttää täysin erilaiselta.

Pääpointti on, että PowerBI:llä sinulla on valta luoda omia raportteja ja koontinäyttöjä, jotka voidaan automaattisesti päivittää.on a regular basis and are easily accessible by multiple users without knowing how to deal with the underlying data.

In case you still want to have a look on the PowerBI file with the examples, here is the [PowerBI file with the data and the examples][pbiStatisticsFile].

Yhteenveto

Kaiken tämän myötä olet nyt hyvin varustautunut sukeltamaan DNS-palvelimen virheenkorjauslokien maailmaan.


Sinulla on tietoa virheenkorjauslokien aktivoinnista ja konfiguroinnista sekä luodun datan käyttämisestä ja analysoimisesta. Valitsetko nopean analyysin PowerShellissä vai yksityiskohtaisten raporttien luomisen Excelissä tai PowerBI:ssä, valinta on sinun. Muista vain, että suureen voimaan liittyy suuri vastuu, joten ole tietoinen keräämäsi datan määrästä ja siitä, miten käytät sitä.

🚀 Onnea lokitukseen ja analysoimiseen! 🚀



Liittyvät linkit

  • [Microsoft Docs: Virheenkorjauslokitus DNS-palvelimessa][msDebugLoggingInDnsServer] - Virallinen dokumentaatio virheenkorjauslokituksen aktivoinnista ja käytöstä DNS-palvelimessa.
  • [PowerShell Gallery: DNSServer.DebugLogParser][dNSServerDebugLogParserDef] - PowerShell-moduuli DNS-palvelimen virheenkorjauslokitiedostojen käsittelyyn.
  • [GitHub Repository: DNSServer.DebugLogParser][dnssLogParserRepository] - GitHub-repositorio DNSServer.DebugLogParser-moduulille, mukaan lukien dokumentaatio ja esimerkkiskriptit.
  • [PowerQuery-dokumentaatio][powerQueryDocLink] - Virallinen dokumentaatio PowerQuerylle, tehokkaalle datan muunnos- ja analysointityökalulle, jota voidaan käyttää Excelin ja PowerBI:n kanssa.
  • [PowerBI-dokumentaatio][powerBIDocLink] - Virallinen dokumentaatio PowerBI:lle, tehokkaalle liiketoiminta-analytiikkatyökalulle, jota voidaan käyttää interaktiivisten raporttien ja hallintapaneelien luomiseen.

Muut linkit

Meemit osoitteesta [makeameme.org][makeAMemeLink]