My recomendataion is to do the simple thing first (#1 below) – essentially what paul suggested, and the see if that is sufficient.
I was thinking there are a few ways to potentially do this (each gets heavier and heavier weight).
1) Implement a simple log4j appender that essentially has a flume sink that writes via some rpc mechanism to a node (possibly to a local agent or to a remote collector). This would be best effort and would have exponential backoff in the case of failures.
1a) For an end-to-end reliability mode version, create a log4j appender that writes a flume agent's internal log files and moves them into the e2e's import dir. Periodically call import() on that wal manager to load the data so that it will deliver it.
1b) For store on failure mode, use the same log4j appender that writes to flume agent's internal log files on network failures but otherwise relay to a local agent or remote collector.
2) Embed a flume logical node into a log4j appender. This will have the logger inside a logger problem, and probably would heartbeat and thus would not not be reconfigurable (for failovers, etc).
3) Embed a flume physical node into a log4j appender. This will have the logger inside a logger problem. It would heartbeat and could be reconfigurable but may be more heavy weight than desired.