# Using River for indexing log messages **URL:** \ **Category:** Elasticsearch\ **Created:** [January 5, 2012, 7:25pm UTC](https://discuss.elastic.co/t/using-river-for-indexing-log-messages/6294 "2012-01-05T19:25:45Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Jan\_Fiedler](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jan_fiedler/32/2518_2.png) [@Jan\_Fiedler](https://discuss.elastic.co/u/Jan_Fiedler)\ **Post date:** [January 5, 2012, 7:25pm UTC](https://discuss.elastic.co/t/using-river-for-indexing-log-messages/6294/1 "2012-01-05T19:25:45Z")
I am currently working on a prototype for indexing aggregated syslogng log messages. My current design features a syslogng river (that I implemented) that internally runs a syslog4j server that I use to consume and index log message (via tcp or udp). This is working great so far. However, I have second thoughts about my choice of using a river. From the river's prospective, the communication is a push model (syslog daemon or apps pushing data to ES to be consumed by the river). I therefore do not really benefit from the great river features (i.e. state management by ES). If the node running the river dies, I am sure ES will restart the river it at another node. However, this is not really helping as the entity pushing messages will still target the old node (tcp connection). Also since the river is only receiving there is little benefit in tracking the last message seen. Is my assumption correct that a river is primarily useful in scenarios where ES would be pulling data? If yes, any ideas on how to better solve the log indexing problem ? ---
**Author:** ![Berkay\_Mollamustafao](https://avatars.discourse-cdn.com/v4/letter/b/22d042/32.png) [@Berkay\_Mollamustafao](https://discuss.elastic.co/u/Berkay_Mollamustafao)\ **Post date:** [January 5, 2012, 7:58pm UTC](https://discuss.elastic.co/t/using-river-for-indexing-log-messages/6294/2 "2012-01-05T19:58:24Z")
Have you looked at logstash? Berkay On Thursday, January 5, 2012, Jan Fiedler [fiedler.jan@gmail.com](mailto:fiedler.jan@gmail.com) wrote: > I am currently working on a prototype for indexing aggregated syslogng > log messages. My current design features a syslogng river (that I > implemented) that internally runs a syslog4j server that I use to consume > and index log message (via tcp or udp). This is working great so far. > However, I have second thoughts about my choice of using a river. From > the river's prospective, the communication is a push model (syslog daemon > or apps pushing data to ES to be consumed by the river). I therefore do not > really benefit from the great river features (i.e. state management by ES). > If the node running the river dies, I am sure ES will restart the river it > at another node. However, this is not really helping as the entity pushing > messages will still target the old node (tcp connection). Also since the > river is only receiving there is little benefit in tracking the last > message seen. > Is my assumption correct that a river is primarily useful in scenarios > where ES would be pulling data? If yes, any ideas on how to better solve > the log indexing problem ? -- Regards, Berkay Mollamustafaoglu Ph: +1 (571) 766-6292 mberkay on yahoo, google and skype ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 3:43am UTC](https://discuss.elastic.co/t/using-river-for-indexing-log-messages/6294/3 "2017-07-06T03:43:43Z")
Closed on July 6, 2017, 3:43am UTC