Description of problem: Currently you have to manipulate multiple log4j.xml files and the jboss configuration at: /usr/share/ovirt-engine/services/ovirt-engine/ovirt-engine.xml.in in order to change logging to use syslog (or other logging tools). I still didn't figure out what would be the correct way to configure the file: /usr/share/ovirt-engine/services/ovirt-engine/ovirt-engine.xml.in In a large centralized environment (where I suppose oVirt runs most of the time) you have centralized syslog servers where _all_ applications must get logged. It is no option at all to first log to file and then grab this output and resend it to a syslog server. Version-Release number of selected component (if applicable): All How reproducible: always Steps to Reproduce: 1. try to configure syslog for all ovirt logs 2. 3. Actual results: you have to alter multiple files, which get overwritten after upgrades of the engine (e.g. the log4j.xml files) Expected results: one place to configure all logs in an easy fashion Additional info: It's not just that you have to work through multiple files, you also have to restore them after upgrades, because ovirt overwrites these files on upgrades with the default values! vdsm is nicer, you can configure the logging there (python is much easier for this than java logging..)
As a first step, it would be cool if ovirt could include a syslog handler for jboss 7.1 as none is included in this version as a module. e.g.: http://randomtekkstuff.blogspot.de/2013/03/jboss-as-7-syslog-handler.html which is apache licensed. The next step would be adding these loghandlers to /usr/share/ovirt-engine/services/ovirt-engine/ovirt-engine.xml.in and the third step would be to introduce some configuration file for logging of all engine components.
This is part of the plan to pluggable the events/messages plan. So we have extension to accept alerts and may also add plain log4j appender into extension, that can do whatever it likes.
(In reply to Alon Bar-Lev from comment #2) > This is part of the plan to pluggable the events/messages plan. > > So we have extension to accept alerts and may also add plain log4j appender > into extension, that can do whatever it likes. This request is about the entire log content not only for events. Do you mean for that extension to add pragmatically an appender to the logger in runtime ?
(In reply to Barak from comment #3) > (In reply to Alon Bar-Lev from comment #2) > > This is part of the plan to pluggable the events/messages plan. > > > > So we have extension to accept alerts and may also add plain log4j appender > > into extension, that can do whatever it likes. > > This request is about the entire log content not only for events. > Do you mean for that extension to add pragmatically an appender to the > logger in runtime ? I truly wish it so, it will make our lives easier, as people will be able to extend the logging without core product configuration dependency. Even as simple as creating a bridge to other loggers such as log4j or slf4j. Another option is to find how in jboss we can programmable effect logging, so we can read our own configuration to create loggers. Current situation in which jboss service.xml must be modified is no solution.
mentioned on the mailing list You could use logstash to ship logs to your central syslog. -- Ernest Beinrohr, AXON PRO ============ http://logstash.net/ * Apache license * rather fat -- 60+ megabyte tarball, and drags in a jruby dependency as well, and Yet Another Package Manager * "You can build rpms and debs, if you need those. Building rpms requires you have [fpm](https://github.com/jordansissel/fpm), then do this: ... " * their archive link is not useful for me in testing, and I do not see it packaged for EPEL so ... so probably not all that great an idea
We introduced extension mechanism, so of we can intercept log entries at, we can send them out to an extension. The extension can do whatever it likes, including and not limited to sending to syslog. The missing but is the log interception, as far as I checked jboss logger does not allow adding appender from within the webapp context. Our options: 1. Have our own log4j instance at webapp, with own log4j properties to call our appender. 2. Introduce jboss module that will provide singleton appender bridge at the service scope, this appender will enable publush/subscriber interface to allow webapp to register their own appender. 3. Any other solution... that will work under jboss. Once log records can be intercepted at the webapp context, it will be trivial to send it out via extension.
(In reply to Alon Bar-Lev from comment #6) > We introduced extension mechanism, so of we can intercept log entries at, we > can send them out to an extension. The extension can do whatever it likes, > including and not limited to sending to syslog. > > The missing but is the log interception, as far as I checked jboss logger > does not allow adding appender from within the webapp context. > > Our options: > > 1. Have our own log4j instance at webapp, with own log4j properties to call > our appender. > > 2. Introduce jboss module that will provide singleton appender bridge at the > service scope, this appender will enable publush/subscriber interface to > allow webapp to register their own appender. > > 3. Any other solution... that will work under jboss. > > Once log records can be intercepted at the webapp context, it will be > trivial to send it out via extension. AFAIK JBoss AS 7.1.x has moved from log4j to java.util.logging. See here a discussion about this - I think using the extensions is a good idea. So what we should probably have is an implementation ofjava.uti.logging.handler that will use an extenion in order to perform logging. Then you can setup up a logging extension as you desire.
This bug is targeted to 3.6.0 and is in status post, but referenced patch is merged in 3.5.0 so this should be targeted to 3.5.0 in status modified. Can you please verify the status of this bug?
work ok with ovirt-engine-extension-logger-log4j-0.0.0-0.0.1.master.el6_5.noarch
oVirt 3.5 has been released and should include the fix for this issue.