Helmut
October 18, 2022, 4:30pm
1
Hi,
I just installed logstash 8.4.3 on Windows Server 2019 and copied over configs from 8.2.3. logstash doesn't start:
[2022-10-18T18:24:26,830][ERROR][logstash.outputs.elasticsearch][main][42989fb99e78bec7495dbe5bfe5a541ef44a4d6032e0d3cd83414ebb23817b03] An unknown error occurred sending a bulk request to Elasticsearch (will retry indefinitely) {:message=>"incompatible encodings: IBM437 and UTF-8", :exception=>Encoding::CompatibilityError, :backtrace=>["org/jruby/ext/stringio/StringIO.java:1162:in
write'", "C:/Program Files/ELK/logstash/8.4.3/vendor/bundle/jruby/2.6.0/gems/logstash-output-elasticsearch-11.6.0-java/lib/logstash/outputs/elasticsearch/http_client.rb:142:in block in bulk'", "org/jruby/RubyArray.java:1865:in
each'", "org/jruby/RubyEnumerable.java:1143:in each_with_index'", "C:/Program Files/ELK/logstash/8.4.3/vendor/bundle/jruby/2.6.0/gems/logstash-output-elasticsearch-11.6.0-java/lib/logstash/outputs/elasticsearch/http_client.rb:125:in
bulk'", "C:/Program Files/ELK/logstash/8.4.3/vendor/bundle/jruby/2.6.0/gems/logstash-output-elasticsearch-11.6.0-java/lib/logstash/plugin_mixins/elasticsearch/common.rb:296:in safe_bulk'", "C:/Program Files/ELK/logstash/8.4.3/vendor/bundle/jruby/2.6.0/gems/logstash-output-elasticsearch-11.6.0-java/lib/logstash/plugin_mixins/elasticsearch/common.rb:228:in
submit'", "C:/Program Files/ELK/logstash/8.4.3/vendor/bundle/jruby/2.6.0/gems/logstash-output-elasticsearch-11.6.0-java/lib/logstash/plugin_mixins/elasticsearch/common.rb:177:in retrying_submit'", "C:/Program Files/ELK/logstash/8.4.3/vendor/bundle/jruby/2.6.0/gems/logstash-output-elasticsearch-11.6.0-java/lib/logstash/outputs/elasticsearch.rb:342:in
multi_receive'", "org/logstash/config/ir/compiler/AbstractOutputDelegatorExt.java:121:in multi_receive'", "C:/Program Files/ELK/logstash/8.4.3/logstash-core/lib/logstash/java_pipeline.rb:300:in
block in start_workers'"]}`
8.2.3 still works fine.
Did I forget anything?
pipeline.id: main
path.config: "C:/Program Files/ELK/logstash/8.4.3/config/conf.d/*.conf"
input {
beats {
host => localhost
port => 5044
}
}
output {
if [@metadata ][pipeline] {
elasticsearch {
hosts => ["https://localhost:9200 "]
ssl => true
ssl_certificate_verification => false
manage_template => false
index => "%{[@metadata ][beat]}-%{[@metadata ][version]}-%{+YYYY.MM.dd}"
pipeline => "%{[@metadata ][pipeline]}"
user =>
password =>
}
} else {
elasticsearch {
hosts => ["https://localhost:9200 "]
ssl => true
ssl_certificate_verification => false
manage_template => false
index => "%{[@metadata ][beat]}-%{[@metadata ][version]}-%{+YYYY.MM.dd}"
user =>
password =>
}
}
}
Thank you!
1 Like
Helmut
October 19, 2022, 10:32am
3
input {
beats {
host => localhost
port => 5044
codec => plain { charset => "UTF-8"}
}
stdin {
codec => plain { charset => "UTF-8"}
}
}
output {
if [@metadata][pipeline] {
elasticsearch {
hosts => ["https://localhost:9200"]
ssl => true
ssl_certificate_verification => false
manage_template => false
index => "%{[@metadata][beat]}-%{[@metadata][version]}-%{+YYYY.MM.dd}"
pipeline => "%{[@metadata][pipeline]}"
user => <USER>
password => <PASSWORD>
codec => plain { charset => "UTF-8"}
}
} else {
elasticsearch {
hosts => ["https://localhost:9200"]
ssl => true
ssl_certificate_verification => false
manage_template => false
index => "%{[@metadata][beat]}-%{[@metadata][version]}-%{+YYYY.MM.dd}"
user => <USER>
password => <PASSWORD>
codec => plain { charset => "UTF-8"}
}
}
}
Still same error.
Rios
(Rios)
October 20, 2022, 11:10am
5
LS and FB are using UTF-8 by default. Try with different charset, but since this data comes from FB, try to set IBM437 in filebeat.yml
codec => plain { charset => "IBM437"}
Helmut
October 20, 2022, 12:17pm
6
I'm using WInLogbeat and I don't see where to configure that.
Anyway, it workes fine with 8.2.3 and seems broken with 8.4.3 and I would like to know why.
Rios
(Rios)
October 20, 2022, 12:29pm
7
Have you try to set on LS side?
From filebeat.reference.yml. The winlogbeat.reference.yml doesn't have it.
# Configure the file encoding for reading files with international characters
# following the W3C recommendation for HTML5 (http://www.w3.org/TR/encoding).
# Some sample encodings:
# plain, utf-8, utf-16be-bom, utf-16be, utf-16le, big5, gb18030, gbk,
# hz-gb-2312, euc-kr, euc-jp, iso-2022-jp, shift-jis, ...
#encoding: plain
simon137
(Simon)
October 20, 2022, 6:08pm
8
I seem to have the same issue, but only on all my windows desktops not on the windows server.
And it somehow magically goes away if I redirect standard output of logstash, which just makes no sense at all.
https://discuss.elastic.co/t/encoding-issue-depending-on-how-logstash-is-started/317136
stevedearl
(Steve Earl)
November 8, 2022, 8:58am
9
Hi all, just to confirm that this issue still exists with Logstash 8.5.0.
Rios
(Rios)
November 9, 2022, 4:51pm
10
Have you submitted the issue on github?
stevedearl
(Steve Earl)
November 10, 2022, 3:29pm
11
@Rios . A related issue was already submitted to Github by @simon137 . See link below:
opened 08:47AM - 21 Oct 22 UTC
bug
status:needs-triage
**Logstash information**:
1. Logstash version: 8.4.3 (i checked the issue came … in from v8.3.3 to v8.4.0)
2. Logstash installation source: expanded from tar or zip archive
3. How is Logstash being run: via commandline or as a windows service
**Plugins installed**: no extra plugins were installed
**JVM** (e.g. `java -version`): Bundled JDK:
openjdk 17.0.4 2022-07-19
OpenJDK Runtime Environment Temurin-17.0.4+8 (build 17.0.4+8)
OpenJDK 64-Bit Server VM Temurin-17.0.4+8 (build 17.0.4+8, mixed mode, sharing)
-> but also tested with:
openjdk 11.0.15 2022-04-19
OpenJDK Runtime Environment Temurin-11.0.15+10 (build 11.0.15+10)
OpenJDK 64-Bit Server VM Temurin-11.0.15+10 (build 11.0.15+10, mixed mode)
**OS version**: Windows 10
**Description of the problem including expected versus actual behavior**:
If I query some some NVARCHAR-Fields from a Microsoft-SQL-Server (which in MSSQL-Server are always encoded in UTF-16) via logstash-jdbc-input plugin without specifying any special encoding or charset settings, neither in the input nor in the output logstash plugins, logstash failes to transfer the events to ElasticSearch by throwing this error over and over again for every document:
````
[2022-10-20T17:01:57,061][ERROR][logstash.outputs.elasticsearch][index_name][9648a8b8c103d11863b72d1b6d9624b2c3b8d672ae4baf73a17af87e6cc0c3e7]
An unknown error occurred sending a bulk request to Elasticsearch (will retry indefinitely) {:message=>"incompatible encodings: CP850 and UTF-8", :exception=>Encoding::CompatibilityError,
:backtrace=>[
"org/jruby/ext/stringio/StringIO.java:1162:in `write'",
"C:/Program Files/ElasticSearch/logstash/vendor/bundle/jruby/2.6.0/gems/logstash-output-elasticsearch-11.6.0-java/lib/logstash/outputs/elasticsearch/http_client.rb:142:in `block in bulk'",
"org/jruby/RubyArray.java:1865:in `each'",
"org/jruby/RubyEnumerable.java:1143:in `each_with_index'",
"C:/Program Files/ElasticSearch/logstash/vendor/bundle/jruby/2.6.0/gems/logstash-output-elasticsearch-11.6.0-java/lib/logstash/outputs/elasticsearch/http_client.rb:125:in `bulk'",
"C:/Program Files/ElasticSearch/logstash/vendor/bundle/jruby/2.6.0/gems/logstash-output-elasticsearch-11.6.0-java/lib/logstash/plugin_mixins/elasticsearch/common.rb:296:in `safe_bulk'",
"C:/Program Files/ElasticSearch/logstash/vendor/bundle/jruby/2.6.0/gems/logstash-output-elasticsearch-11.6.0-java/lib/logstash/plugin_mixins/elasticsearch/common.rb:228:in `submit'",
"C:/Program Files/ElasticSearch/logstash/vendor/bundle/jruby/2.6.0/gems/logstash-output-elasticsearch-11.6.0-java/lib/logstash/plugin_mixins/elasticsearch/common.rb:177:in `retrying_submit'",
"C:/Program Files/ElasticSearch/logstash/vendor/bundle/jruby/2.6.0/gems/logstash-output-elasticsearch-11.6.0-java/lib/logstash/outputs/elasticsearch.rb:342:in `multi_receive'",
"org/logstash/config/ir/compiler/AbstractOutputDelegatorExt.java:121:in `multi_receive'", "C:/Program Files/ElasticSearch/logstash/logstash-core/lib/logstash/java_pipeline.rb:300:in `block in start_workers'"]}
````
This worked fine up until Version 8.3.3 of Logstash, since Version 8.4.0 it doesn't work anymore.
I also tried specifying the Encoding as UTF-16 with jdbc-input-plugins columns_charset option, but this doesn't affect the behaviour of logstash at all.
**Steps to reproduce**:
1. Create a pipeline with the following input.conf (you have to change the Connection String to any Microsoft SQL-Server of course):
````
input {
jdbc {
jdbc_driver_library => "C:\\ProgramData\\ElasticSearch\\logstash\\drivers\\mssql-jdbc-10.2.0.jre8.jar"
jdbc_driver_class => "com.microsoft.sqlserver.jdbc.SQLServerDriver"
jdbc_connection_string => "jdbc:sqlserver://server\instance;databasename=database;trustServerCertificate=true"
jdbc_default_timezone => "Europe/Berlin"
jdbc_user => "user"
jdbc_password => "pw"
schedule => "*/5 6-19 * * *"
statement_filepath => "C:\\ProgramData\\ElasticSearch\\logstash\\pipelines\\index_name\\queries\\sqlQuery.sql"
clean_run => false
use_column_value => true
tracking_column => "editdate"
tracking_column_type => "timestamp"
last_run_metadata_path => "C:\\ProgramData\\ElasticSearch\\logstash\\pipelines\\index_name\\.logstash_jdbc_last_run"
}
}
````
2. In the "sqlQuery.sql" just write any SQL-Query that queries at least one NVARCHAR-Field from any table.
3. Create the following output.conf for the pipeline (with different user/pw of course):
````
output {
elasticsearch {
hosts => [ "http://localhost:9200" ]
index => "index_name"
document_id => "%{document_id}"
action => "update"
doc_as_upsert => true
data_stream => "false"
user => "elastic"
password => "pw"
}
}
````
4. Run logstash either manually from the commandline or as a windows service and you'll get the above error.
(**Oddly enough** if you run the logstash.bat from the commandline and redirect stdout (and/or) stderr to a file, it works perfectly without any errors and indexes everything as it should. I have no idea how it is possible though, that output redirection affects the behaviour of logstash here, to be honest it just makes no sense.)
1 Like
simon137
(Simon)
November 10, 2022, 3:48pm
12
Yes I have. See Steve's answer, thank you. Please feel free to give the issue a thumbs up or a comment
system
(system)
Closed
December 8, 2022, 3:48pm
13
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.