We have discovered that in some cases and some plaftorms
configuring a default `verify_mode` when creating a SSL/TCPServer
could make the certificate verification fail. Ruby default behavior is
to use `NIL` when creating a new ssl context, this revert that change.
keep in mind that all TCP clients using SSL **must** use `VERIFY_PEER`
as their verify mode to prevent man in the middle attack.
Fix: https://github.com/elastic/logstash/issues/3657
Fix a thread leak which affects apps that perform
manual recovery, including Logstash RabbitMQ plugin.
Plus this kind of latency improvements:
Also add `action` setting to allow logstash to signal document
deletions, updates, etc. The goal is to support any bulk request with
this output plugin, but the early target is simply to allow deletes.
This is one step in the path to having only one elasticsearch output
plugin and eventually removing elasticsearch_http.
The following tests pass
% bin/logstash rspec spec/outputs/elasticsearch.rb
...
Finished in 1 minute 33.94 seconds
3 examples, 0 failures
Tested manually 'elasticsearch { protocol => http }' with success.
Still to be implemented:
* template management
* tests to cover all protocols: node, transport, and http
* mark elasticsearch_http as deprecated?
Java API methods for elasticsearch.rb
Cleaned up documentation for elasticsearch_http.rb
Updated Makefile to use Elasticsearch 0.90.7 (necessary for new template management Java API methods)
Updated logstash.gemspec to use updated jruby-elasticsearch (where the new template management framework is for JRuby)
elasticsearch. (LOGSTASH-102)
- Add 'bind_port' setting to allow users with the default node protocol
to choose what local port is used. (LOGSTASH-1453)
The only change in ftw is that it now only loads backports on ruby 1.8,
which should help speed up the startup time of any plugins (and web)
that use ftw.
Sometimes it's useful to be able to correlate new events with previous
events (e.g., to calculate time duration between events). This filter
queries an elasticsearch host to find the top event matching the given
search criteria and copies specific fields from that event into the new
event.
Here's an example that will determine when an operation started and
store that timestamp into the ending event:
if [type] == "end" {
elasticsearch {
hosts => ["es-server"]
query => "type:start AND operation:%{[opid]}"
fields => ["@timestamp", "started"]
}
date {
match => ["[started]", "ISO8601"]
target => "[started]"
}
}
0.5 and 0.6 installs. (LOGSTASH-1497)
This was observed as a result of ugprading to jruby 1.7.5 (thus
upgrading rubygems). I believe the order of operations in dependency
resolution was changed to trigger this. Basically, ftw wants cabin>0,
logstash wanted cabin=0.5.0, and if ftw is satisfied first then
logstash's dep fails.
Because of this change, the elasticsearch_http output can send data at a
much faster rate (since we aren't waiting for a full segment before
publishing data)
Before this patch, locally I measured elasticsearch_http at 1500 eps;
After this patch, I measured elasticsearch_http at 8500 eps.
