elasticsearch/logstash — pull request #1549 by ben-denham (2014-07-18 04:55:07+00:00)
Title: Alternative unique key prefix for metrics

When we use the metrics filter in our logstash setup, we intermittently experience slow startup times that can take several minutes.

Our configuration is as follows:

```
input {
generator {
lines => [
"line 1",
"line 2",
"line 3"
]
}
}

filter {
metrics {
meter => "events"
add_tag => "metric_filter"
}
}

output {
stdout { }
}
```

After some debugging, I believe that one statement in particular is causing a significant delay: [SecureRandom.hex](https://github.com/elasticsearch/logstash/blob/master/lib/logstash/filters/metrics.rb#L149)

It also seems to take anywhere from 0-200 seconds to call SecureRandom.hex from a simple script that I wrote (see below), so I'm not sure if this is a deeper problem with jruby/java. It is worth noting that often the first call to SecureRandom.hex after restarting the system usually executes in less than a second, but all subsequent calls take increasing amounts of time:

```bash
while [ true ]; do
jruby -e "
require 'securerandom'
start = Time.now
puts SecureRandom.hex
stop = Time.now
diff = stop - start
puts \"#{diff} seconds to call 'SecureRandom.hex'\""
done
```

Since it seems that the only reason for calling SecureRandom is to prevent collisions between metric keys for separate metric filter objects (see the commit message for https://github.com/elasticsearch/logstash/commit/de0bdacbf70ad9394adfce9d1e96ee63c118b8ca), I've changed the prefix to simply be the [\_\_id\_\_](http://ruby-doc.org/core-2.1.2/Object.html#method-i-object_id) of the metrics filter object, which is guaranteed to be unique for all active ruby objects.

Even if SecureRandom.hex wasn't taking such a long time, it does seem redundant to generate a new random number when the unique object id already exists as a trusted identifier.