# Why changing logstash filter config caused i/o timeout event **URL:** \ **Category:** Logstash\ **Created:** [November 27, 2017, 10:02pm UTC](https://discuss.elastic.co/t/why-changing-logstash-filter-config-caused-i-o-timeout-event/109286 "2017-11-27T22:02:26Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Yuri\_Sibirski](https://avatars.discourse-cdn.com/v4/letter/y/4491bb/32.png) [@Yuri\_Sibirski](https://discuss.elastic.co/u/Yuri_Sibirski)\ **Post date:** [November 27, 2017, 10:02pm UTC](https://discuss.elastic.co/t/why-changing-logstash-filter-config-caused-i-o-timeout-event/109286/1 "2017-11-27T22:02:26Z")
Hi there, i am really confused why changing my 10-syslog-filter.conf file caused **i/o timeout** event on all the clients and no data was saved. Initial config is: ```auto filter { if [type] == "syslog" { grok { match => { "message" => "%{SYSLOGTIMESTAMP:syslog_timestamp} %{SYSLOGHOST:syslog_hostname} %{DATA:syslog_program}(?:\[%{POSINT:syslog_pid}\])?: %{GREEDYDATA:syslog_message}" } add_field => ["received_at", "%{@timestamp}"] add_field => ["received_from", "%{host}"] } syslog_pri { } date { match => ["syslog_timestamp", "MMM d HH:mm:ss", "MMM dd HH:mm:ss"] } } } ``` Then i changed on line **if [type] == "log"** that broke everything. The reason i changed it to log is because i can see my data collected on the client is marked and **type=log** thus i was hoping it will apply my filter and parse the way i need it. Maybe i am doing something wrong. Thank you in advance. ---
**Author:** ![guyboertje](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/guyboertje/32/31592_2.png) [@guyboertje](https://discuss.elastic.co/u/guyboertje)\ **Post date:** [November 28, 2017, 8:14am UTC](https://discuss.elastic.co/t/why-changing-logstash-filter-config-caused-i-o-timeout-event/109286/2 "2017-11-28T08:14:30Z")
What version of Logstash? Did you update any plugins? Did the if block where [type] == "syslog" ever get executed? What is your input config? I seems to me that your clients are seeing back pressure but I can't tell for sure without more info. ---
**Author:** ![Yuri\_Sibirski](https://avatars.discourse-cdn.com/v4/letter/y/4491bb/32.png) [@Yuri\_Sibirski](https://discuss.elastic.co/u/Yuri_Sibirski)\ **Post date:** [November 28, 2017, 2:01pm UTC](https://discuss.elastic.co/t/why-changing-logstash-filter-config-caused-i-o-timeout-event/109286/3 "2017-11-28T14:01:06Z")
Here are all the answeres: What version of Logstash? **5.6.2** Did you update any plugins? **I didn't update any plugins but i updated all the ELK components from 2. version to 5.6.2** Did the if block where [type] == "syslog" ever get executed? **It doesn't look like. I have seen it being executed once when i changed type to LOG but then it worked for a day and broke with i/o timeout events on the clients. Also it looks to me if i set TYPE=SYSLOG it parses it with some sort of default filter and not the one that i specify in my filter file** What is your input config? **Here is my input config** > ``` > 02-beats-input.conf > input { > beats { > port => 5044 > ssl => true > ssl_certificate => "/etc/pki/tls/certs/logstash-forwarder.crt" > ssl_key => "/etc/pki/tls/private/logstash-forwarder.key" > } > } > > ``` **And here is my output file** 30-elasticsearch-output.conf: > output { > elasticsearch { > hosts =\> ["localhost:9200"] > sniffing =\> true > manage\_template =\> false > index =\> "%{[@metadata][beat]}-%{+YYYY.MM.dd}" > document\_type =\> "%{[@metadata][type]}" > } > } I can't really understand what causing clients to fail. All the other configurations are pretty much standard. Here is my **filebeat** config just in case: > filebeat.prospectors: > > - input\_type: log Thank you a lot in advance. ---
**Author:** ![Yuri\_Sibirski](https://avatars.discourse-cdn.com/v4/letter/y/4491bb/32.png) [@Yuri\_Sibirski](https://discuss.elastic.co/u/Yuri_Sibirski)\ **Post date:** [November 28, 2017, 4:11pm UTC](https://discuss.elastic.co/t/why-changing-logstash-filter-config-caused-i-o-timeout-event/109286/4 "2017-11-28T16:11:48Z")
Extra information: **bulk\_max\_size set to default 2048** and logstash is listening on **IPV6** ---
**Author:** ![guyboertje](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/guyboertje/32/31592_2.png) [@guyboertje](https://discuss.elastic.co/u/guyboertje)\ **Post date:** [November 28, 2017, 4:33pm UTC](https://discuss.elastic.co/t/why-changing-logstash-filter-config-caused-i-o-timeout-event/109286/5 "2017-11-28T16:33:02Z")
I don't think I can add much more here. Some things to consider: 1. Syslog has two RFCs with two very different timestamp formats. **Which one are you receiving?** 2. Your date filter will try "MMM d HH:mm:ss" first but it only applies for 9 days in a month, you should switch the formats around. ---
**Author:** ![Yuri\_Sibirski](https://avatars.discourse-cdn.com/v4/letter/y/4491bb/32.png) [@Yuri\_Sibirski](https://discuss.elastic.co/u/Yuri_Sibirski)\ **Post date:** [December 21, 2017, 2:41pm UTC](https://discuss.elastic.co/t/why-changing-logstash-filter-config-caused-i-o-timeout-event/109286/6 "2017-12-21T14:41:39Z")
By switching around you mean this: **match =\> ["syslog\_timestamp", "MMM dd HH:mm:ss", "MMM d HH:mm:ss"]** ---
**Author:** ![guyboertje](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/guyboertje/32/31592_2.png) [@guyboertje](https://discuss.elastic.co/u/guyboertje)\ **Post date:** [December 21, 2017, 5:36pm UTC](https://discuss.elastic.co/t/why-changing-logstash-filter-config-caused-i-o-timeout-event/109286/7 "2017-12-21T17:36:44Z")
yes. its a minor perf improvement for 2 thirds of a month. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [January 18, 2018, 5:36pm UTC](https://discuss.elastic.co/t/why-changing-logstash-filter-config-caused-i-o-timeout-event/109286/8 "2018-01-18T17:36:56Z")
Closed on January 18, 2018, 5:36pm UTC This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.