0

I've searched up and down and was wondering or if this is even an option that is possible within Grok. So my log files are filtered just fine. Except, the %{QS:message} is what contains my ERROR, WARNING, POST, GET etc. I want to be able to query against those in Kibana but do not have them as an option. Is there anything I can do to make these keywords available that are coming back from logstash to kibana

pcproff
  • 612
  • 1
  • 8
  • 30

1 Answers1

1

its probably easiest if you analyze this step by step. add the following to your output section stdout { codec => rubydebug }

When processing a log message it details you all the fields and their values that were created by logstash during processing of your logmessage. As long as you did not specify anything fancy in your elasticsearch output these fields will be stored in elasticsearch (along with their unanalysed .raw counterparts). If that looks okay you could then take a look at the elastisearch side of things using its rest interface interactively (using curl) or by installing the elasticsearch kopf plugin (or something similar) to check out whats actually been stored in elasticsearch.

EDIT: Regarding your last comment.

Assuming your log data looks like this "POST: Form submitted from shoppingcart.php"

You could either use an if statement with a regexp to simply check if your message contains a given character sequence (like POST) and then use mutate filter to add a field or a tag to your event like so:

if [logmessage] =~ /POST/ {
    mutate { add_tag => ["POST"] }
    # or you could also do something like:
    mutate { add_field => ["method","POST"]}
}

Instead of the if statement you could also use a grok filter to further parse your message like so:

grok {
      match => ["logmessage", "(?<method>POST)"]
      tag_on_failure => []
}

Depending on the structure of your log entries and the complexity of what you want to extract its prefereably use method a. or b. If your logs are very structured you could simply build one grok filter that takes care of all variants. Let's say if all your lines looks like this:

method|returnCode|messageText

you could do a simple grok filter like

%{DATA:method}|%{DATA:returnCode}|{GREEDYDATA:messageText}

that takes care of all your lines and parses your logs into fields for kibana analysis.

If however your logs are very unstructured and you only want to look up a small number of keywords you can also go with the if regexp flavour...

markus
  • 1,631
  • 2
  • 17
  • 31
  • Even if the keyword I'm looking for is inside the `%{QOUTEDSTRING:logmessage}` – pcproff Mar 25 '15 at 02:50
  • @pcproff are you trying to parse the logmessage field itself? If so post a sample logmessage and what you are trying to achieve. also take a look at the grok debuuger http://grokdebug.herokuapp.com/ – markus Mar 25 '15 at 05:59
  • I have the final part of the log message parsed. I just want to look within the quoted string and look for certain keywords like FAILED, SUCCESS etc and make them into their own fields so Kibana can filter by them. – pcproff Apr 01 '15 at 15:49
  • @pcproff if you have your message parsed into the logmessage field you can then apply further grok patterns on the logmessage field. can you add an example of your data to your question? – markus Apr 02 '15 at 05:04
  • The message can read something like "POST: Form submitted from shoppingcart.php" If I wanted to search via just the word "POST" here how can I filter it out of the %{QUOTEDSTRING:logmessage}?? – pcproff May 19 '15 at 18:37
  • How about anything preceding a colon ":" so any word preceding a colon. POST: would give the user in kibana the ability to filter by that. Or GET: ability to filter by GET etc. – pcproff May 21 '15 at 15:23
  • 1
    @pcproff hi of course my example was just very specifically looking for POST. You could of course make that way more general. That's why I mentioned looking at your log structure. If your lines follow a fixed structure like say "method: return code - detail data" you can make very flexible GROK filters for that and don't need to specifically look for POST or GET in your patterns... – markus May 22 '15 at 05:26