That newfangled Journal thing

Posted Nov 21, 2011 11:56 UTC (Mon) by hjh (guest, #4352)
In reply to: That newfangled Journal thing by nim-nim
Parent article: That newfangled Journal thing

> The developers wrote(and rewrote) the frontend so it was fast and easy
> to integrate in apps (their pet peeve) and the user-friendly backend that
> anyone could use without reading the source code never materialised.

not if there is a simple documented streaming interface, to the backends that could even just as well stream into a file. Somthing with log messages like:

#time: <date> #id: org.kernel.subsys.facility.xyz #...
#uuid:<UUID> #other: <other> #future1: <future1>
_ mesg_line_1
_ mesg_lin_e2
_ ...
_ mesg_line_n

#time:<date> # .....
...

such a format should be possible to commit to for developers as it's expandable with new records elements in the future, and as it does not require to commit to more complicated backend storage design. Binaries like core dump shouldn't go to the log anyway, only as references to a file location. Admins concerned can opt out of the provided backend and
use files or a database instead to store the messages with some more
storage space required. I even think that using a database for indexing
purpose is the better solution, than yet another special database for logging only to better with compression.

The best would be, to separate the backend into a second process, which supports the compression, hashing and indexing stuff. The second process could then easily be located on a different host, and gets the records synchronously or in batch mode.