I have one question though. If one is using default logging settings (like me at the time) all state updates are displayed also in the log. Tailer finds a warning and updates a string channel with warning line contents. On next read [WARN ] is found as a “false positive” in that log line. Did you handle this or am I just blind?
In reader I have this covered with line.replace("[WARN ]", " "). And there’s a todo marking if someone finds a proper way to match only from specific part of the string.
State changes are direct to events.log by default. At least in OH 2.2 and can’t remember how this has been in older version. Additionally state changes should logged in INFO level not WARN level. Blacklisting feature could also be used to bypass unwanted lines.
I’ve been following your repo and can see that you made it much more better than I ever could. I’m quite sure that you should take the tailer part to your self and make a PR straight to OH. That would be a proper binding that really well covers all. And with those custom patterns you should be able to read any log you want.
Or what do you think @pauli_anttila? Also I’d like to hear what others has to say. I’m ready for proposals.
“Others” mostly have no programming skills and therefore are very thankful for your both work.
So why not just combining forces and creating an even better binding as it already is
@gitMiguel, I’m fine with that, but I definitely don’t want to “steal” your idea, so I will give credits to you as well when I do the PR to OH repo.
I did even more refactoring, and now I’m pretty happy to binding structure. Channels are still fixed (warning, error and one custom), but I think they should be dynamic, so that user could define one or more search based channels dynamically. As I have never implemented dynamic channels which are defined in runtime rather than statically, I will postpone that to the future.
Compiled binding can downloaded from here for testing purposes and documentation can be found here.
Sounds good to me. I’ll update the first post accordingly and add a link to your recent post so all users can catch up. I’ll keep the “original” LogReader to my self and change its name to avoid confusion.
I got inspired by your code and I’m rewriting my original logreader. Trying to keep the functionalities as is but implement it in same way as apaches tailer. I would like to reuse parts of your code. Espcelially searchEngine. Is it ok?
I tried to implement binding modular, so if you want to replace Tailer, you could just write new file reader which extends AbstractLogFileReader implements LogFileReader (like FileTailer does). Then in LogReaderHandlerFactory, you create LogHandler, but with new file reader rather than FileTailer. In the end, there could be new thing type or user could configure used file reader from binding configuration. This is how journalctl based solution should be implemented as well. Not sure if there are any java based implementation available or should command line util be used.
I’ll be forking your repo then. Just have to be careful with namings so it won’t get to confusing. I like more creating a new thing type because I want few of the channels different.
Regarding journalctl this is what I have read a few times https://stackoverflow.com/questions/27178431/calling-journalctl-from-java but you propably have seen this already. Imho replacing Tailer with jctlTailer and creating another thing type. Passing lines from json response to handle method should do it.
I’m wrote another Tailer named Parser which contains my old reading method which is now runnable. Also theres a new thing type parser with few new channels and less config options. Can this be handled with the same configuration class if somebody decides to run both things paraller?
And because there’s different methods in Parser should new interface and abstract class be written to replace FileReaderListener and abstractLogFileReader? Seems that handlers cannot be made abstract so all methods have to be implemented, even unused ones. Or what is the best way?
Just so you get my idea I want this to be something that doesn’t read lines continuously but between longer intervals and gathers all information into single update. For example I was testing out my alarm rules for modbus binding. As soon as I physically disconnected the modbus server from network there were lots of errors in logs and I don’t want them flooding my telegram account.
Edit
I uploaded my logreader branch to my github account. I ran out of time this evening and it’s a mess. Work in progress as they say Would be happy to receive some guidelines how to proceed and implement things your way.
@gitMiguel, are you implementing this log reader (Parser) for fun or is there use case behind which Apache Tailer doesn’t match? Apache Tailer go throw whole log file only ones, then monitor when new lines are available and read only those new lines, so it’s from resource (CPU, IO, etc) use point of view very efficient way.
No, I’m not doing this for fun and this is more or less for my own use. I tried to explain what I’m after in my earlier post and your implementation imho is a really good base for further features. You are absolutely right about Tailer being more efficient and I remember saying that this is how LogReader should be functioning in the end. You got there first and made it so that a PR can be made in official repo. And I am pleased it is so.
But as my OH system is still in developement, I’m using snapshots and alpha state bindings, errors and warnings are not so rare. This is why I want my version of logreader to not flood my mobile phone with notifications if lots of errors happen. Gathering updates in a rule and sending them once an hour doesn’t seem reasonable to me so thats why i want this to happen at binding level. Prove me wrong because I might be totally on thr wrong tracks here.
Why not? You can pretty easily implement and change log aggregation and time based rules for notifications. E.g. prevent notification sending in the night, collect errors in certain time period or even make collection dynamic, so that first alarm is send immediately and then next ones are aggregated e.g. in 10 minutes and if lot of errors are still received, increase the notification time even further. Or send one email every morning which include all previous day/night errors.
Would be happy to receive some guidelines how to proceed and implement things your way.