Problema Grok com vários IP's no NginX Logstash

Question

Eu tenho um problema com o log dos meus servidores da web, que tem um elb e, em seguida, uma camada de verniz na frente da camada nginx.

O

verniz é configurado corretamente para o X-Forwarded-For e os logs são processados normalmente com o 'client.ip' correto sendo registrado.

no entanto, os logs nginx estão chegando com uma lista completa de IPs na solicitação. o comportamento de grok padrão parece definir o IP do cliente como o último da lista, isto é, os servidores elb e verniz, o que bagunça meu campo client.ip para logs nginx. o IP do cliente correto deve ser o primeiro (ou pelo menos o primeiro) na lista.

aqui está um exemplo:

172.31.7.219 - - [28/Sep/2015:12:39:56 +1000] "GET /api/filter/14928/content?api_key=apikey&site=website HTTP/1.1" 403 101 "-" "-" "my.website.com" "1.144.97.102, 1.144.97.102, 1.144.97.102, 127.0.0.1, 172.31.26.59"

problema é que eu não tenho sido capaz de ajustar o grok para lidar com esse resultado, o depurador heroku grok parece não funcionar para esta consulta e meu grok - mas eles estão trabalhando em logstash ou seja. não marcando falha de grok.

Eu tentei depurar as partes específicas, mas não encontrei uma maneira de fazer o que preciso com IP / IPORHOST, onde há uma lista separada por vírgulas de endereços IP. Eu preciso ser capaz de especificar qual IP deve usar. ie. o primeiro da lista deve ser o client.ip não o último.

meu nginx grok é:

NGINXACCESS %{IP:clientip} %{NGUSER:ident} %{NGUSER:auth} \[%{HTTPDATE:timestamp}\] "%{WORD:verb} %{DATA:request} HTTP/%{NUMBER:httpversion}" %{NUMBER:response} (?:%{NUMBER:bytes}|-) (?:"(?:%{URI:referrer}|-)"|%{QS:referrer})(?:;|) %{QS:agent}

alguma idéia sobre grok para cobrir esse registro?

    

Answer 1

Não tenho certeza se você ainda está tendo esse problema, mas se estiver, veja o que funcionará para você.

Dado este formato de registro:

log_format custom '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$host" "$http_x_forwarded_for"';

o padrão de grok que você especificou não leva em consideração a adição da porção "$host" "$http_x_forwarded_for" .

Não sei por que seu grok não está falhando, mas deveria.

Em qualquer evento, esse padrão funcionará com o formato de registro acima:

%{IP:clientip} %{NOTSPACE:ident} %{NOTSPACE:auth} \[%{HTTPDATE:timestamp}\] "%{WORD:verb} %{DATA:request} HTTP/%{NUMBER:httpversion}" %{NUMBER:response} (?:%{NUMBER:bytes}|-) (?:"(?:%{URI:referrer}|-)"|%{QS:referrer})(?:;|) %{QS:agent} "%{NOTSPACE:host}" "(?<x_forwarded_for>%{IP:xff_clientip}, .*)"

E resulta nos seguintes campos

httpversion      1.1
request          /api/filter/14928/content?api_key=apikey&site=website
timestamp        28/Sep/2015:12:39:56·+1000
auth             -
host             my.website.com
agent            "-"
x_forwarded_for    1.144.97.102,·1.144.97.102,·1.144.97.102,·127.0.0.1,·172.31.26.59
clientip         172.31.7.219
bytes            101
response         403
xff_clientip     1.144.97.102
ident            -
port    
verb             GET
referrer    

Note que você tem alguns novos campos do que você teria antes.

O primeiro ("x_forward_for" = > 1.144.97.102, 1.144.97.102, 1.144.97.102, 127.0.0.1, 172.31.26.59 ) é o conteúdo do último conjunto de citações ou $http_x_forwarded_for do formato de registro.
O segundo ("xff_clientip" = > 1.144.97.102 ) é apenas o primeiro IP dessa lista, que deve ser traduzido para o IP de origem real da solicitação.

Se fosse eu, também executaria o campo x_forwarded_for por meio de um filtro mutate para dividi-lo em uma matriz:

mutate {
  split  => { "x_forwarded_for" => ", " }
}