У меня проблема с логированием с моих веб-серверов, у которых есть elb, а затем слой лака перед слоем nginx.
varnish правильно настроен для X-Forwarded-For, и журналы проходят нормально с правильным файлом client.ip.
однако журналы nginx проходят через весь список IP-адресов в запросе. поведение Grok по умолчанию, похоже, устанавливает IP-адрес клиента последним в списке, т.е. серверы elb и varnish, что портит мое поле client.ip для журналов nginx. правильный IP-адрес клиента должен быть первым (или, по крайней мере, несколькими первыми) в списке.
вот пример:
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"
проблема в том, что я не смог настроить Grok для обработки такого результата, отладчик heroku grok, похоже, не работает для этого запроса и моего Grok, но они работают в logstash, т.е. не помечает ошибку Grok.
Я попытался отладить определенные части, но не нашел способа сделать то, что мне нужно, с IP / IPORHOST, где есть список IP-адресов, разделенных запятыми. мне нужно указать, какой IP он должен использовать. т.е. первым в списке должен быть client.ip, а не последний.
мой 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}
есть идеи на Grok, чтобы закрыть этот журнал?
Не уверен, что у вас все еще есть эта проблема, но если да, вот что сработает для вас.
Учитывая этот формат журнала:
log_format custom '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$host" "$http_x_forwarded_for"';
указанный вами шаблон Grok не учитывает добавление "$host" "$http_x_forwarded_for" часть.
Не уверен, почему ваш Grok не дает сбоев, но должно.
В любом случае этот шаблон будет работать с указанным выше форматом журнала:
%{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}, .*)"
И результаты в следующих полях
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
Обратите внимание, что у вас появилось несколько новых полей, чем было бы раньше.
Первый ("x_forward_for" => 1.144.97.102, 1.144.97.102, 1.144.97.102, 127.0.0.1, 172.31.26.59) - это содержимое последнего набора кавычек, или $http_x_forwarded_for из формата журнала.
Второй ("xff_clientip" => 1.144.97.102) является просто первый IP-адрес в этом списке, который должен преобразовываться в фактический исходный IP-адрес запроса.
Если бы это был я, я бы также запустил x_forwarded_for поле через mutate фильтр, чтобы разбить его на массив:
mutate {
split => { "x_forwarded_for" => ", " }
}
В последней части решение Антона Рослова будет соответствовать только строкам журнала «ip1, ip2» и «single-ip», но не «ip1, ip2, ip3».
ИМХО что-то вроде
(?<x_forwarded_for>%{IP:clientip}(?:, [^,]+)*)
должен сделать свое дело. Просто проверяю...
... \"(?:%{DATA:user_agent}|-)\" \"(?<x_forwarded_for>%{IP:clientip}(?:, [^,]+)*)?|-\"
или
... \"(?:%{DATA:user_agent}|-)\" \"(-|(?<x_forwarded_for>%{IP:clientip}(?:, [^,]+)*)?)\"
должен быть вашим выбором. Проверено на grokdebug.herokuapp.com.