Question

Um analista está implementando um pipeline no Zip-Directory, da
pilha ELK, para tratar registros de acesso HTTP oriundos de um
servidor Apache.
Para isso, foi usada a seguinte configuração de filtro:
filter {
grok {
match => {
"message" => "%{IP:client_ip} - - $$%{HTTPDATE:raw_date}$$
"%{WORD:http_method} %{URIPATHPARAM:request}
HTTP/%{NUMBER:http_version}" %{NUMBER:status_code}
%{NUMBER:bytes}"
}
}
date {
match => [ "raw_date", "dd/MMM/yyyy:HH:mm:ss Z" ]
}
mutate {
convert => { "status_code" => "integer" }
rename => { "client_ip" => "[source][ip]" }
}
}
Considere que uma linha de entrada válida seja:
192.168.1.10 - - [22/Mar/2026:14:09:58 +0000] "GET /index.php
HTTP/1.1" 200 5120
Com base no funcionamento do Logstash e dos plugins usados,
com a específica configuração e sintaxe apresentados, assinale a
afirmativa correta.

Accepted Answer

C) O campo status_code será convertido para tipo numérico inteiro, enquanto o campo bytes permanecerá textual, salvo conversão adicional explícita.

Answer

A) O plugin date converte o campo raw_date em inteiro epoch, sobrescrevendo automaticamente o campo status_code, desde que o grok tenha sido executado com sucesso.

Answer

B) Após o processamento, o campo client_ip permanece no evento e, adicionalmente, é copiado para o campo aninhado [source][ip], já que a operação rename não remove o campo original.

Answer

D) O padrão %{URIPATHPARAM:request} captura
exclusivamente o caminho da URI, mas nunca os parâmetros
de consulta (query string), razão pela qual o filtro falharia caso
a URL contenha ?id=10.

Answer

E) O plugin grok já converte automaticamente os campos
%{NUMBER:status_code} e %{NUMBER:bytes} para tipo
numérico, tornando redundante o uso de mutate { convert =>
... }.

Mais questões de Outros temas