Grok Pattern for Apache Access logs (facing _grokparsefailure error)


(Akshara) #1

Code
input {
file {
path => "/data/Ops_analytics_EBS/oracle_ebs_eu/j201s648/access_log.1476316800"
start_position => "beginning"
type => "apache_access"
}
}
filter
{
grok
{
match => {'message'=>'%{IP:clientip}* %{USER:ident} %{USER:auth} /[%{HTTPDATE:apache_timestamp}/] %{WORD:method} %{NOTSPACE:request_page} HTTP/%{NUMBER:http_version} %{NUMBER:server_response}'}
}
date
{
match => ["apache_timestamp" , "dd/MMM/yyyy:HH:mm:ss Z"]
target => "apache_timestamp"
}
}

output {
elasticsearch {
hosts => "localohost:9200"
index => "apache_access_parsing2_index"
}
stdout {codec => rubydebug }
}

Logstash o/p:
{
"message" => "10.10.216.223 - - [14/Oct/2016:01:56:08 +0200] "GET /oa_servlets/AppsLogin HTTP/1.1" 302 422 0",
"@version" => "1",
"@timestamp" => "2017-09-17T16:03:34.705Z",
"host" => "j051s319.jci.com",
"path" => "/data/Ops_analytics_EBS/oracle_ebs_eu/j201s648/access_log.1476316800",
"type" => "apache_access",
"tags" => [
[0] "_grokparsefailure"
]
}

access log example
10.10.241.81 - - [30/Nov/2016:04:44:24 +0100] "GET /OA_MEDIA/nlsf.gif HTTP/1.1" 200 282 0


(Magnus Bäck) #2

/[%{HTTPDATE:apache_timestamp}/]

Use backslashes for escaping, not forward slashes.

Why not use the predefined patterns for standard Apache logs?


(Akshara) #3

I replaces with blackslashes, no changes in output.

And tried with below code as well,

input {
file {
path => "/data/Ops_analytics_EBS/oracle_ebs_eu/j201s648/access_log.09172017"
start_position => "beginning"
type => "apache"
}
}
filter
{
grok
{
match => { "message" => "%{COMBINEDAPACHELOG}" }
}
date
{
match => [ "timestamp" , "dd/MMM/yyyy:HH:mm:ss z" ]
target => "timestamp"
}
}
output
{
elasticsearch
{
hosts => "localhost:9200"
index => "logstash_parsing01_access_index"
}
stdout {codec => rubydebug }
}

Facing same _grokparsefailure issue. Can you suggest me where i am doing wrong .


(Magnus Bäck) #4

Your log is not a combined log but a common log so try HTTPD_COMMONLOG instead.


(Akshara) #5

Thanks Magnus, Issue is resolved using HTTPD_COMMONLOG pattern :+1:


(system) #6

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.