🥇Integrating ELK and Exchange. Part 1

Jeg starter en serie artikler, hvor jeg vil dele mine erfaringer med at forbinde Exchange og ELK. Denne stak vil hjælpe med at håndtere store mængder logs og undgå spørgsmål om, hvornår de velkendte logningsværktøjer holder op med at hjælpe os. Lad os lære den nye spiller inden for logs at kende.

Exchange har et temmelig omfattende loggingssystem. De mest efterspurgte logs er tracking-logs, som følger det skridt-for-skridt forløb af en bestemt besked inden for mailorganisationen; webserver-logs, som sporer hver ny bruger-session i systemet; og logs fra specifikke webapplikationer med forskellig detaljeringsgrad af sessionen. Desuden kan Exchange gemme rå logs fra smtp, imap og pop3 protokoller.

Hvilke værktøjer kan vi bruge til arbejde med logs:

Den indbyggede cmdlet Get-MessageTrackingLog: praktisk til behandling af tracking-logs;
Logparser værktøjet: bruger en pseudo-SQL-sprog til søgning i logs og arbejder rigtig hurtigt;
Ekstern SQL-server: til meget specifikke tilfælde (for eksempel, analyse af data over lange perioder).

Alt dette fungerer godt, når vi har et par servere, og mængden af loggede data måles i titusinder til hundrede af gigabyte. Men hvad hvis antallet af servere kommer op på titalls, og logstørrelsen overskrider terabyte? Denne ordning begynder sandsynligvis at svigte.

Og sådan sker der: Get-MessageTrackingLog begynder at falde ud pga. timeout, logparser rammer loftet af 32-bit arkitekturen, og eksport til SQL-server går i stykker på det mest uhensigtsmæssige tidspunkt og kan ikke håndtere en flersidet exception fra tjenesten.

Her træder en ny spiller ind – ELK stakken, der er specielt designet til at jonglere med enorme mængder logs inden for rimelige tidsrammer og med acceptabel ressourceforbrug.

I den første del vil jeg detaljeret beskrive, hvordan man tilslutter filebeat, der tilhører dele af ELK stakken – som er ansvarlig for at læse og sende almindelige tekstfiler, hvori forskellige applikationer skriver deres logs. I de kommende artikler vil vi se nærmere på komponenterne Logstash og Kibana.

Installation

Så agentfilen til filebeat kan downloades fra dette site.

Vi vil installere det ved blot at udpakkes indholdet af zip-filen. For eksempel til c:Program Filesfilebeat. Derefter er det nødvendigt at køre PowerShell-scriptet install-service-filebeat.ps1, der følger med til installationen af filebeat-tjenesten.

Nu er vi klar til at begynde at konfigurere konfigurationsfilen.

Fejltolerance

Filebeat sikrer levering af logfiler til logindsamlingssystemet. Dette opnås ved at føre en register over poster i logfilerne. I registreret opbevares information om de poster, der er blevet læst fra logfilerne, og bestemte poster, som er blevet sendt til bestemmelsesstedet, markeres.

Hvis en post ikke kan leveres, vil filebeat forsøge at sende den igen, indtil den får bekræftelse fra modtagersystemet eller den oprindelige logfil slettes under rotation.

Ved genstart af filebeat-tjenesten vil den læse registreret information om de senest læste og leverede poster og vil læse poster i logfilerne baseret på oplysningerne i registreret.

Dette minimerer risikoen for at miste information om logs, der skal sendes til elasticlogstash-servere, under uforudsete nedbrud og udførelse af vedligeholdelsesopgaver på serverne.

Du kan læse mere om dette i dokumentationen i afsnittene: Hvordan holder Filebeat styr på filernes status og Hvordan sikrer Filebeat mindst-en-gang levering?

Indstillinger

Hele konfigurationen udføres i en konfigurationsfil i yml, som er opdelt i flere sektioner. Lad os se på nogle af dem, der deltager i logindsamlingsprocessen fra Exchange-servere.

Logbehandlingsblok

Logbehandlingsblokken starter med feltet:

filebeat.inputs:

Vi vil bruge et fælles logindsamlingsværktøj:

- type: log

Herefter angiver vi status (aktiveret) og stier til mappen med logfiler. For eksempel kan indstillingerne for IIS-logs være følgende:

    enabled: true
    paths:
	- C:inetpublogsLogFilesW3SVC1*.log
	- C:inetpublogsLogFilesW3SVC2*.log

En anden vigtig indstilling: hvordan filebeat skal læse flere linjer af poster. Som standard betragter filebeat en linje fra logfilen som en post. Dette fungerer godt, indtil vi begynder at få undtagelser knyttet til serviceproblemer. I sådanne tilfælde kan undtagelser bestå af flere linjer. Derfor skal filebeat betragte en flerlinjepost som én, hvis den næste linje begynder med en dato. Formatet for logposter i Exchange er sådan, at hver ny post i logfilen begynder med en dato. I konfigurationen ser denne betingelse således ud:

multiline:
	pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
	negate: true
	match: after

Det giver mening at tilføje tags til den sendte post, for eksempel:

  tags: ['IIS', 'ex-srv1']

Og glem ikke at ekskludere linjer, der starter med hashtags:

  exclude_lines: ['^#']

Således vil blokken til læsning af logs se sådan ud:

filebeat.inputs:
- type: log
  enabled: true
  paths:
	- C:inetpublogsLogFilesW3SVC1*.log
	- C:inetpublogsLogFilesW3SVC2*.log
  multiline:
	pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
	negate: true
	match: after
  tags: ['IIS', 'ex-srv1']
  exclude_lines: ['^#']

Blok til sending af logs

De enkelte poster i logfilen sender filebeat som en json-objekt, hvor den specifikke post fra loggen er indeholdt i det eneste felt message. Hvis vi vil arbejde med denne information, skal vi først parse dette felt til separate felter. Dette kan gøres for eksempel i logstash. Det vil være modtageren af posterne fra filebeat. Her er hvordan det kan se ud i konfigurationsfilen for filebeat:

output.logstash:
  hosts: ["logstash1.domain.com:5044"]

Hvis der er flere servere, kan du aktivere load balancing: så vil filebeat sende logs ikke til den første tilgængelige server fra listen, men fordele de sendte logs mellem flere servere:

hosts: ["logstash1.domain.com:5044", "logstash2.domain.com:5044"]
  loadbalance: true

Filebeat tilføjer under behandlingen af logs i den sendte json udover logposten, der findes i feltet message, en række metadata, som påvirker størrelsen af dokumentet, der kommer ind i elastic. Disse metadata kan selektivt udelades fra sendingen. Dette gøres i blokken processor ved hjælp af processoren drop_fields. Du kan for eksempel udelukke følgende felter:

processors:
- drop_fields:
	fields: ["agent.ephemeral_id", "agent.hostname", "agent.id", "agent.type", "agent.version", "agent", "ecs.version", "ecs", "input.type", "input", "log.offset", "version"]

Valget af udeladte felter skal gøres omhyggeligt, da nogle af dem kan anvendes af elastic til opbygning af indekser.

Således vil blokken til sending af logs se sådan ud:

output.logstash:
  hosts: ["logstash1.domain.com:5044", "logstash2.domain.com:5044"]
  loadbalance: true
 
processors:
- drop_fields:
	fields: ["agent.ephemeral_id", "agent.hostname", "agent.id", "agent.type", "agent.version", "agent", "ecs.version", "ecs", "input.type", "input", "log.offset", "version"]

Logningsindstillinger for filebeat

Det giver mening at angive følgende logningsindstillinger:

Logningsniveau info;
Optag logs i filer, der er placeret som standard (mappen logs i installationsmappen for filebeat);
Navnet på logfilen er filebeat;
Behold de sidste 10 logfiler;
Start rotation when reaching a size of 1MB.

The final logging configuration block will look like this:

logging.level: info
logging.to_files: true
logging.files:
  name: filebeat
  keepfiles: 10
  rotateeverybytes: 1048576

Final configuration

We have assembled the configuration, and it now looks like this:

filebeat.inputs:
- type: log
  enabled: true
  paths:
    - C:inetpublogsLogFilesW3SVC1*.log
    - C:inetpublogsLogFilesW3SVC2*.log
  multiline:
    pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
    negate: true
    match: after
  tags: ['IIS', 'ex-srv1']
  exclude_lines: ['^#']
 
output.logstash:
  hosts: ["logstash1.domain.com:5044", "logstash2.domain.com:5044"]
  loadbalance: true
 
processors:
- drop_fields:
    fields: ["agent.ephemeral_id", "agent.hostname", "agent.id", "agent.type", "agent.version", "agent", "ecs.version", "ecs", "input.type", "input", "log.offset", "version"]
 
logging.level: info
logging.to_files: true
logging.files:
  name: filebeat
  keepfiles: 10
  rotateeverybytes: 1048576

It is important to understand that the configuration file format is yml. Therefore, it is crucial to place spaces and minus signs correctly.

Filebeat can check the configuration file and will indicate if there are syntax errors, specifying which line and where in the line the syntax is incorrect. The check is performed as follows: