feedstate is used for viewing log files and feed sources from many different processes. Feeds can also be monitored over a network.
feedstate's current and planned features incude:
Since the majority of logging formats are stored in standard ASCII text files, if a line from a log file can be parsed using a regular expression, then the log file format is supported.
In addition to using regular expressions to extract data from a feed source, XML data and databases are also supported.
The pluggable architecture of Feed State means that any format of feed data can be extracted.
A feed is a source of data. It could be a web-page, application log file, a database table, stream of binary data - anything.
Feed State currently distinguishes two types of feed:
Regular expression captured groups are used to split a message up; each captured group represents a column of information. The user specifies the types of those columns, so one column could be a number, another a string etc.
Consider the following line from a (simple) log file containing grades (given the grade, score, whether a a pass or fail was obtained and the subject, respectively):
B 65 pass maths E 34 fail english D 46 fail history C 55 pass geography
...then the following regular expression (note - the parenthesis are used to capture groups, and \s is whitespace):
...would produce a message with four columns for the first message:
Column 1: B Column 2: 65 Column 3: pass Column 4: maths
The user would then associate columns with this data so that the second column would be a number, the third a boolean etc. How columns are associated with this data is outlined in the user manual.
Later releases will include a wide variety of different regular expression syntax formats, for example sed, Perl 5, POSIX, grep, Emacs and many more.
That's the easiest thing to do and is described in the Quick Setup section of the User Manual.
However, spending a while to set up a regular expression for a feed/log file means that more complex filtering can be done on messages read from the file. If the results are also then passed into a database, querying messages will be a lot faster because users will be able to filter and query specific fields.
You can read raw lines of data in without parsing each line. However, if you want to split the message up into several sections then inevitabley you will end up writing complex expressions.
Future releases will contain plugins and adaptors for dealing with bespoke formats - such as Apache access/error files, Cruise Control continuous integration, Log4J, Log4Net, Syslog, ... Many formats will be supported.
Check out the status of the project regularly in order to find currently out supported log file formats as feedstate continues to mature.
If you plan to monitor database tables or plan to take gathered data from Feed State and wish to persist it for later analysis, you will require the Java JDBC driver for your database.
The demo was used to originally test the core components of Feed State. You can run the demo by running the s5-feedstate-demo shell/batch script that is located in the bin directory of the downloaded distribution.
Currently it does not. However, it is in the planned feature list. Currently, if viewing a log file (for example) named logdata.txt and that file is renamed to logdata.1.txt and logdata.txt is written to from scratch, the feed will stop operating.
Yes - and it's the first ever release of Feed State. This is the first official release and as such there's a lot to iron out. There are many features that have not yet made it into Feed State, as well as a few bugs that haven't yet been dealt with.
You can help by supporting this project by visiting the support section of the project.
It's not surprising since it's only the first release; however, please have patience, and if it's not for you for the time being, do come back occasionally to check out the project status.