Undefined method `accept' for nil:NilClass

Elastic Stack Logstash
1

At present, we are operating several instances of Elasticsearch, encompassing both 5.x and 6.x versions, and are in the process of assessing the viability of OpenSearch. However, it is imperative to maintain the current configurations of Filebeat and Logstash unaltered. In alignment with this requirement, we have deployed version 7.16.2 of Logstash. Subsequent to this update, we have observed a proliferation of errors, specifically undefined method 'accept' for nil:NilClass, which were not encountered in preceding versions. The root cause of this anomaly is currently ambiguous and the methodology to rectify it remains elusive. Moreover, the issue manifests in the cessation of log reception from the application servers over time, necessitating a manual restart to reinitiate the log transmission pipeline.

Please advise.

2

OpenSearch/OpenDistro are AWS run products and differ from the original Elasticsearch and Kibana products that Elastic builds and maintains. You may need to contact them directly for further assistance.

(This is an automated response from your friendly Elastic bot. Please report this post if you have any suggestions or concerns :elasticheart: )

3

Hello,

Opensearch is not supported here, but if you think that your issue is in any Logstash filter you need to share both the configuration you are using, the error you are getting and also a sample of your data so the issue can be replicated.

It is not clear where this error is happening, you need to provide more context about it.

4

This is the same filters that is used on all the versions in our environments:


filter {
  mutate {
    remove_tag => ["beats_input_codec_plain_applied","beats_input_raw_event"]
  }
}

# Certain fields are known to be strings but occasionally get interpreted as integers, this will convert their type appropriately.
filter {
  mutate {
    convert => {
        '[body][hid]'   => 'string'
        '[body][id]'    => 'string'
    }
  }
}

# If we find DOBs in MM/DD/YYYY format, rewrite them to
# YYYY-MM-DD and save the original
filter {
    ruby {
      code => "
        require 'date'
        dobstr = event.get('[body][dob]')
        if dobstr
          begin
          dob    = Date.strptime(dobstr, '%m/%d/%Y')
          dobISO = dob.strftime('%Y-%m-%d')
          event.set('[body][dob]', dobISO)
          event.set('[originalDOB]', dobstr)
          rescue
          end
        end
      "
    }
}

filter {
  grok {
    match => ["message", "%{TIMESTAMP_ISO8601:timestamp} %{IP:source} %{WORD:method} %{URIPATH:uripath} (?:-|%{NOTSPACE:uriquery}) %{POSINT:port} (?:-|%{NOTSPACE:username}) %{IP:clientip} %{NOTSPACE:useragent} %{URI:url} %{NUMBER:status}"]
    tag_on_failure => [ ]
  }
}

filter {
  grok {
    match => ["message", "%{IPORHOST:clientip} (?:-|(%{WORD}.%{WORD})) %{USER:ident} \[%{HTTPDATE:timestamp}\] \"(?:%{WORD:verb} %{NOTSPACE:request}(?: HTTP/%{NUMBER:httpversion})?|%{DATA:rawrequest})\" %{NUMBER:response} (?:%{NUMBER:bytes}|-) %{QS:referrer} %{QS:agent}"]
    tag_on_failure => [ ]
  }
}

# TS-13526 When err.response.body is a string it is converted to an object with a single field named source that contains the value. This matches the shape of object logged by services that log user-agent as an object.
filter {
  ruby {
    code => "
      agent = event.get('[user-agent]')
      if agent && agent.is_a?(String)
        event.set('[user-agent]', {'source' => agent})
      end
    "
  }
}

# TS-13568 When err.response.body is a string it is converted to an object with a single field named @text that contains the value.
filter {
  ruby {
    code => "
      body = event.get('[err][response][body]')
      if body && body.is_a?(String)
        event.set('[err][response][body]', {'@text' => body})
      end
    "
  }
}

# TS-13647 When err.request.body is a string it is converted to an object with a single field named @text that contains the value.
filter {
  ruby {
    code => "
      body = event.get('[err][request][body]')
      if body && body.is_a?(String)
        event.set('[err][request][body]', {'@text' => body})
      end
    "
  }
}

# TS-13586 When body.result is a string it is converted to an object with a single field named @text that contains the value.
filter {
  ruby {
    code => "
      bodyResult = event.get('[body][result]')
      if bodyResult && bodyResult.is_a?(String)
        event.set('[body][result]', {'@text' => bodyResult})
      end
    "
  }
}

# TS-13583 body.availability is converted to an object with a single field named @json that contains the JSON representation of the original value.
filter {
  ruby {
    code => "
      require 'json'
      bodyAvailability = event.get('[body][availability]')
      if bodyAvailability
        event.set('[body][availability]', {'@json' => JSON.generate(bodyAvailability)})
      end
    "
  }
}

since we have microservices, there are many servers that has the same filebeat configuration

- type: log
  tags: ["catapultapps"]  
  paths:
    - /catapult/apps/*/current/log/*.log
  json.keys_under_root: true
  json.add_error_key: false
  json.message_key: log
  fields:
    index_name: catapultapps

Below is one sample of the error:

[2023-11-02T00:00:25,302][INFO ][org.logstash.beats.BeatsHandler][main][b735a5d7382cd510fb08d026e77b3c72851aeff150c96ea727a0bc0962ca0134] [local: 10.108.12.16:5044, remote: 10.108.28.32:38018] Handling exception: org.logstash.FieldReference$IllegalSyntaxException: Invalid FieldReference: `vendors[]` (caused by: org.logstash.FieldReference$IllegalSyntaxException: Invalid FieldReference: `vendors[]`)
[2023-11-02T00:00:25,302][WARN ][io.netty.channel.DefaultChannelPipeline][main][b735a5d7382cd510fb08d026e77b3c72851aeff150c96ea727a0bc0962ca0134] An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.
org.logstash.FieldReference$IllegalSyntaxException: Invalid FieldReference: `vendors[]`
5

This is a common issue, if I'm not wrong this was changed here.

On Logstash 7 this was mentioned as a breaking change, saying that this is not configurable anymore and only the mode strict works, and on Logstash 8 another breaking change says that the setting was removed, since it only had one option.

I'm not sure if there is anything you can do on Logstash side to solve this, this field named is not valid for Logstash, it needs to be fixed in the source.

6

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