Re: Karaf Decanter log => mail
Great, thanks ! Regards JB On 08/07/2019 16:40, Markus Rathgeb wrote: > Here it is: https://issues.apache.org/jira/browse/KARAF-6355 > > I did not find how to change the "assign to" field. > Perhaps I don't have the power. > > I don't know which title would be a good one - feel free to change it. > > Am Mo., 8. Juli 2019 um 16:25 Uhr schrieb Jean-Baptiste Onofré > : >> >> Sure ! and thanks for your feedback ! >> >> Do you mind to create a corresponding Jira and assign to me ? Else I >> will later today. >> >> Regards >> JB >> >> On 08/07/2019 16:20, Markus Rathgeb wrote: >>> Hi JB, >>> >>> sounds good. >>> Thank you. >>> >>> Can you keep me informed? >>> >>> Would it make sense (e.g. for log alert usage) to enhance the checker >>> configuration also for multiple matches (excludes)? >>> >>> E.g. type log, >>> * property level should match WARN >>> AND >>> * property message should not contain the regex foobar (or should >>> contain the regex) >>> >>> Or we could filter some loc.class and loc.method log messages that we >>> know are "false positives". >>> >>> >>> >>> Am Mo., 8. Juli 2019 um 15:19 Uhr schrieb Jean-Baptiste Onofré >>> : Hi Markus, Correct, but you raised a valid point. Let me do the improvements on the checker, adding an option to "always" send the alert, ignoring previous ones. I imagine something like: log.level.warn.always= I do the change for Decanter 2.3.0 and I will cut the release asap. OK for you ? Regards JB On 08/07/2019 15:04, Markus Rathgeb wrote: >> In the case of log, it's a bit special: you receive an alert as soon as >> you have a log.level in WARN, and it's stored in the Decanter alerts. >> Then, the next log message which is not a WARN will notify you. >> >> I need to improve a bit the mail alerter to only send the first email in >> the case of log (it makes sense for metrics, like the ones coming from >> the JMX collector). > > So, it is more like state entered and state exited. ? > > Let's assume the following log messages: > > * INFO 0 > * WARN 1 > * WARN 2 > * WARN 3 > * WARN 4 > * INFO 5 > * INFO 6 > * WARN 7 > * INFO 8 > > Is it correct that I will only receive mails for "WARN 1", "INFO 5", > "WARN 7" and "INFO 8"? > > If I would like to get a mail per WARN log message, I need to write my > own log appender? > -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com >> >> -- >> Jean-Baptiste Onofré >> jbono...@apache.org >> http://blog.nanthrax.net >> Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Karaf Decanter log => mail
Here it is: https://issues.apache.org/jira/browse/KARAF-6355 I did not find how to change the "assign to" field. Perhaps I don't have the power. I don't know which title would be a good one - feel free to change it. Am Mo., 8. Juli 2019 um 16:25 Uhr schrieb Jean-Baptiste Onofré : > > Sure ! and thanks for your feedback ! > > Do you mind to create a corresponding Jira and assign to me ? Else I > will later today. > > Regards > JB > > On 08/07/2019 16:20, Markus Rathgeb wrote: > > Hi JB, > > > > sounds good. > > Thank you. > > > > Can you keep me informed? > > > > Would it make sense (e.g. for log alert usage) to enhance the checker > > configuration also for multiple matches (excludes)? > > > > E.g. type log, > > * property level should match WARN > > AND > > * property message should not contain the regex foobar (or should > > contain the regex) > > > > Or we could filter some loc.class and loc.method log messages that we > > know are "false positives". > > > > > > > > Am Mo., 8. Juli 2019 um 15:19 Uhr schrieb Jean-Baptiste Onofré > > : > >> > >> Hi Markus, > >> > >> Correct, but you raised a valid point. Let me do the improvements on the > >> checker, adding an option to "always" send the alert, ignoring previous > >> ones. > >> > >> I imagine something like: > >> > >> log.level.warn.always= > >> > >> I do the change for Decanter 2.3.0 and I will cut the release asap. > >> > >> OK for you ? > >> > >> Regards > >> JB > >> > >> On 08/07/2019 15:04, Markus Rathgeb wrote: > In the case of log, it's a bit special: you receive an alert as soon as > you have a log.level in WARN, and it's stored in the Decanter alerts. > Then, the next log message which is not a WARN will notify you. > > I need to improve a bit the mail alerter to only send the first email in > the case of log (it makes sense for metrics, like the ones coming from > the JMX collector). > >>> > >>> So, it is more like state entered and state exited. ? > >>> > >>> Let's assume the following log messages: > >>> > >>> * INFO 0 > >>> * WARN 1 > >>> * WARN 2 > >>> * WARN 3 > >>> * WARN 4 > >>> * INFO 5 > >>> * INFO 6 > >>> * WARN 7 > >>> * INFO 8 > >>> > >>> Is it correct that I will only receive mails for "WARN 1", "INFO 5", > >>> "WARN 7" and "INFO 8"? > >>> > >>> If I would like to get a mail per WARN log message, I need to write my > >>> own log appender? > >>> > >> > >> -- > >> Jean-Baptiste Onofré > >> jbono...@apache.org > >> http://blog.nanthrax.net > >> Talend - http://www.talend.com > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com
Re: Karaf Decanter log => mail
Sure ! and thanks for your feedback ! Do you mind to create a corresponding Jira and assign to me ? Else I will later today. Regards JB On 08/07/2019 16:20, Markus Rathgeb wrote: > Hi JB, > > sounds good. > Thank you. > > Can you keep me informed? > > Would it make sense (e.g. for log alert usage) to enhance the checker > configuration also for multiple matches (excludes)? > > E.g. type log, > * property level should match WARN > AND > * property message should not contain the regex foobar (or should > contain the regex) > > Or we could filter some loc.class and loc.method log messages that we > know are "false positives". > > > > Am Mo., 8. Juli 2019 um 15:19 Uhr schrieb Jean-Baptiste Onofré > : >> >> Hi Markus, >> >> Correct, but you raised a valid point. Let me do the improvements on the >> checker, adding an option to "always" send the alert, ignoring previous >> ones. >> >> I imagine something like: >> >> log.level.warn.always= >> >> I do the change for Decanter 2.3.0 and I will cut the release asap. >> >> OK for you ? >> >> Regards >> JB >> >> On 08/07/2019 15:04, Markus Rathgeb wrote: In the case of log, it's a bit special: you receive an alert as soon as you have a log.level in WARN, and it's stored in the Decanter alerts. Then, the next log message which is not a WARN will notify you. I need to improve a bit the mail alerter to only send the first email in the case of log (it makes sense for metrics, like the ones coming from the JMX collector). >>> >>> So, it is more like state entered and state exited. ? >>> >>> Let's assume the following log messages: >>> >>> * INFO 0 >>> * WARN 1 >>> * WARN 2 >>> * WARN 3 >>> * WARN 4 >>> * INFO 5 >>> * INFO 6 >>> * WARN 7 >>> * INFO 8 >>> >>> Is it correct that I will only receive mails for "WARN 1", "INFO 5", >>> "WARN 7" and "INFO 8"? >>> >>> If I would like to get a mail per WARN log message, I need to write my >>> own log appender? >>> >> >> -- >> Jean-Baptiste Onofré >> jbono...@apache.org >> http://blog.nanthrax.net >> Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Karaf Decanter log => mail
Hi JB, sounds good. Thank you. Can you keep me informed? Would it make sense (e.g. for log alert usage) to enhance the checker configuration also for multiple matches (excludes)? E.g. type log, * property level should match WARN AND * property message should not contain the regex foobar (or should contain the regex) Or we could filter some loc.class and loc.method log messages that we know are "false positives". Am Mo., 8. Juli 2019 um 15:19 Uhr schrieb Jean-Baptiste Onofré : > > Hi Markus, > > Correct, but you raised a valid point. Let me do the improvements on the > checker, adding an option to "always" send the alert, ignoring previous > ones. > > I imagine something like: > > log.level.warn.always= > > I do the change for Decanter 2.3.0 and I will cut the release asap. > > OK for you ? > > Regards > JB > > On 08/07/2019 15:04, Markus Rathgeb wrote: > >> In the case of log, it's a bit special: you receive an alert as soon as > >> you have a log.level in WARN, and it's stored in the Decanter alerts. > >> Then, the next log message which is not a WARN will notify you. > >> > >> I need to improve a bit the mail alerter to only send the first email in > >> the case of log (it makes sense for metrics, like the ones coming from > >> the JMX collector). > > > > So, it is more like state entered and state exited. ? > > > > Let's assume the following log messages: > > > > * INFO 0 > > * WARN 1 > > * WARN 2 > > * WARN 3 > > * WARN 4 > > * INFO 5 > > * INFO 6 > > * WARN 7 > > * INFO 8 > > > > Is it correct that I will only receive mails for "WARN 1", "INFO 5", > > "WARN 7" and "INFO 8"? > > > > If I would like to get a mail per WARN log message, I need to write my > > own log appender? > > > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com
Re: Karaf Decanter log => mail
Hi Markus, Correct, but you raised a valid point. Let me do the improvements on the checker, adding an option to "always" send the alert, ignoring previous ones. I imagine something like: log.level.warn.always= I do the change for Decanter 2.3.0 and I will cut the release asap. OK for you ? Regards JB On 08/07/2019 15:04, Markus Rathgeb wrote: >> In the case of log, it's a bit special: you receive an alert as soon as >> you have a log.level in WARN, and it's stored in the Decanter alerts. >> Then, the next log message which is not a WARN will notify you. >> >> I need to improve a bit the mail alerter to only send the first email in >> the case of log (it makes sense for metrics, like the ones coming from >> the JMX collector). > > So, it is more like state entered and state exited. ? > > Let's assume the following log messages: > > * INFO 0 > * WARN 1 > * WARN 2 > * WARN 3 > * WARN 4 > * INFO 5 > * INFO 6 > * WARN 7 > * INFO 8 > > Is it correct that I will only receive mails for "WARN 1", "INFO 5", > "WARN 7" and "INFO 8"? > > If I would like to get a mail per WARN log message, I need to write my > own log appender? > -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Karaf Decanter log => mail
> In the case of log, it's a bit special: you receive an alert as soon as > you have a log.level in WARN, and it's stored in the Decanter alerts. > Then, the next log message which is not a WARN will notify you. > > I need to improve a bit the mail alerter to only send the first email in > the case of log (it makes sense for metrics, like the ones coming from > the JMX collector). So, it is more like state entered and state exited. ? Let's assume the following log messages: * INFO 0 * WARN 1 * WARN 2 * WARN 3 * WARN 4 * INFO 5 * INFO 6 * WARN 7 * INFO 8 Is it correct that I will only receive mails for "WARN 1", "INFO 5", "WARN 7" and "INFO 8"? If I would like to get a mail per WARN log message, I need to write my own log appender?
Re: Karaf Decanter log => mail
Hi Markus,
you can see the alert using decanter:alert command.
In the case of log, it's a bit special: you receive an alert as soon as
you have a log.level in WARN, and it's stored in the Decanter alerts.
Then, the next log message which is not a WARN will notify you.
I need to improve a bit the mail alerter to only send the first email in
the case of log (it makes sense for metrics, like the ones coming from
the JMX collector).
Regards
JB
On 08/07/2019 14:38, Markus Rathgeb wrote:
> The mails content does not seem to be fully correct.
>
> There is e.g. a mail with subject: Alert on level back to normal
> and body:
> ===
> warn alert: level was out of the pattern match:WARN, but back to normal now
>
> Details:
> hostName: pc05
> alertPattern: match:WARN
> component.name: org.apache.karaf.decanter.collector.log
> loc.class: ...
> level: WARN
> alertLevel: warn
> type: log
> message: no feature found for class: class ...
> MDC: {bundle.version=..., bundle.name=..., bundle.id=22}
> threadName: ...
> loc.method: ...
> loc.file: ...java
> component.id: 43
> alertBackToNormal: true
> karafName: root
> name: log
> org.ops4j.pax.logging.appender.name: DecanterLogCollectorAppender
> hostAddress: 127.0.0.1
> loggerName: ...
> loggerClass: org.ops4j.pax.logging.slf4j.Slf4jLogger
> renderedMessage: no feature found for class: class ...
> alertAttribute: level
> timestamp: 1562588565010
> loc.line: 125
> event.topics: decanter/alert/warn
> ===
>
> and another one with subject: [warn] Alert on level
> and body
> ===
> warn alert: level is out of the pattern match:WARN
>
> Details:
> hostName: pc05
> alertPattern: match:WARN
> component.name: org.apache.karaf.decanter.collector.log
> loc.class: ...
> level: INFO
> alertLevel: warn
> type: log
> message: dropped already queued function for ...
> MDC: {bundle.version=..., bundle.name=..., bundle.id=22}
> threadName: ...
> loc.method: ...
> loc.file: java
> component.id: 43
> alertBackToNormal: false
> karafName: root
> name: log
> org.ops4j.pax.logging.appender.name: DecanterLogCollectorAppender
> hostAddress: 127.0.0.1
> loggerName: ...
> loggerClass: org.ops4j.pax.logging.slf4j.Slf4jLogger
> renderedMessage: dropped already queued function for ...
> alertAttribute: level
> timestamp: 1562588567267
> loc.line: 56
> event.topics: decanter/alert/warn
> ===
>
> I would expect the opposite.
> If "level: WARN" I would expect the subject "[warn] Alert on level"
> and if level is not WARN an subject of "Alert on level back to normal"
>
> Or is my understanding wrong here?
>
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Karaf Decanter log => mail
The mails content does not seem to be fully correct.
There is e.g. a mail with subject: Alert on level back to normal
and body:
===
warn alert: level was out of the pattern match:WARN, but back to normal now
Details:
hostName: pc05
alertPattern: match:WARN
component.name: org.apache.karaf.decanter.collector.log
loc.class: ...
level: WARN
alertLevel: warn
type: log
message: no feature found for class: class ...
MDC: {bundle.version=..., bundle.name=..., bundle.id=22}
threadName: ...
loc.method: ...
loc.file: ...java
component.id: 43
alertBackToNormal: true
karafName: root
name: log
org.ops4j.pax.logging.appender.name: DecanterLogCollectorAppender
hostAddress: 127.0.0.1
loggerName: ...
loggerClass: org.ops4j.pax.logging.slf4j.Slf4jLogger
renderedMessage: no feature found for class: class ...
alertAttribute: level
timestamp: 1562588565010
loc.line: 125
event.topics: decanter/alert/warn
===
and another one with subject: [warn] Alert on level
and body
===
warn alert: level is out of the pattern match:WARN
Details:
hostName: pc05
alertPattern: match:WARN
component.name: org.apache.karaf.decanter.collector.log
loc.class: ...
level: INFO
alertLevel: warn
type: log
message: dropped already queued function for ...
MDC: {bundle.version=..., bundle.name=..., bundle.id=22}
threadName: ...
loc.method: ...
loc.file: java
component.id: 43
alertBackToNormal: false
karafName: root
name: log
org.ops4j.pax.logging.appender.name: DecanterLogCollectorAppender
hostAddress: 127.0.0.1
loggerName: ...
loggerClass: org.ops4j.pax.logging.slf4j.Slf4jLogger
renderedMessage: dropped already queued function for ...
alertAttribute: level
timestamp: 1562588567267
loc.line: 56
event.topics: decanter/alert/warn
===
I would expect the opposite.
If "level: WARN" I would expect the subject "[warn] Alert on level"
and if level is not WARN an subject of "Alert on level back to normal"
Or is my understanding wrong here?
Re: Karaf Decanter log => mail
Yes, if the event property is log.level (you can find it in Kibana for instance). I think it's actually log.level with Log4j2 (loggerLevel is with Log4j1 afair). Does it work like this ? Regards JB On 08/07/2019 14:21, Markus Rathgeb wrote: > After reading the code of > org.apache.karaf.decanter.alerting.checker.Checker I realized that the > checker configuration needs to be equal to: > > === > log.level.error=match:ERROR > log.level.warn=match:WARN > === > > Am Mo., 8. Juli 2019 um 14:10 Uhr schrieb Jean-Baptiste Onofré > : >> >> Let me try to reproduce on my machine. Give me couple of hours, I will >> get back to you. >> >> Regards >> JB >> >> On 08/07/2019 13:51, Markus Rathgeb wrote: >>> Hi, >>> >>> I would like to setup a Karaf based system to send mails for log >>> messages of priority WARN and ERROR. >>> >>> I read some of the "Apache Karaf Decanter 2.x" documentation. >>> >>> $ tar xzf apache-karaf-4.2.6.tar.gz >>> $ cd apache-karaf-4.2.6/ >>> $ bin/karaf >>> >>> karaf@root()> feature:repo-add >>> mvn:org.apache.karaf.decanter/apache-karaf-decanter/2.0.0/xml/features >>> karaf@root()> feature:install decanter-collector-log >>> karaf@root()> feature:install decanter-alerting-email >>> >>> There are now three configuration files: >>> * org.apache.karaf.decanter.alerting.checker.cfg >>> * org.apache.karaf.decanter.alerting.email.cfg >>> * org.apache.karaf.decanter.collector.log.cfg >>> >>> Edit "org.apache.karaf.decanter.alerting.checker.cfg" and add that lines: >>> === >>> loggerLevel.error=match:ERROR >>> loggerLevel.warn=match:WARN >>> === >>> >>> Add the mail setup to "org.apache.karaf.decanter.alerting.email.cfg". >>> >>> Keep the standard "org.apache.karaf.decanter.collector.log.cfg". >>> >>> Let's trigger an ERROR log by trigger a feature installation of an non >>> existing one: >>> karaf@root()> feature:install unknown-feature-name >>> >>> The error contains that message: >>> === >>> 13:40:55.830 ERROR [Karaf local console user karaf] Exception caught >>> while executing command >>> java.lang.IllegalArgumentException: No matching features for >>> unknown-feature-name/0 >>> at >>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.computeFeaturesToAdd(FeaturesServiceImpl.java:835) >>> ~[?:?] >>> at >>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:798) >>> ~[?:?] >>> at >>> org.apache.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:78) >>> ~[?:?] >>> at >>> org.apache.karaf.features.command.FeaturesCommandSupport.execute(FeaturesCommandSupport.java:40) >>> ~[?:?] >>> at >>> org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84) >>> ~[?:?] >>> at >>> org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68) >>> ~[?:?] >>> at >>> org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86) >>> ~[?:?] >>> at >>> org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:599) >>> ~[?:?] >>> at >>> org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526) >>> ~[?:?] >>> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415) >>> ~[?:?] >>> at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416) ~[?:?] >>> at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229) ~[?:?] >>> at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59) ~[?:?] >>> at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:?] >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) >>> ~[?:?] >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) >>> ~[?:?] >>> at java.lang.Thread.run(Thread.java:748) [?:?] >>> === >>> >>> I would expect to receive a mail message now. >>> >>> No mail has been received. >>> >>> If I try to use the TRACE level for the decanter package space to >>> "see" what's going on >>> karaf@root()> log:set TRACE org.apache.karaf.decanter >>> >>> I get the additional log message: >>> === >>> 2019-07-08 13:48:55,021 Karaf local console user karaf ERROR Recursive >>> call to appender PaxOsgi >>> === >>> >>> So, I assume I need to use a debugger to get further information what >>> is going on / wrong. >>> >>> Any other suggestions? >>> >> >> -- >> Jean-Baptiste Onofré >> jbono...@apache.org >> http://blog.nanthrax.net >> Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Karaf Decanter log => mail
After reading the code of org.apache.karaf.decanter.alerting.checker.Checker I realized that the checker configuration needs to be equal to: === log.level.error=match:ERROR log.level.warn=match:WARN === Am Mo., 8. Juli 2019 um 14:10 Uhr schrieb Jean-Baptiste Onofré : > > Let me try to reproduce on my machine. Give me couple of hours, I will > get back to you. > > Regards > JB > > On 08/07/2019 13:51, Markus Rathgeb wrote: > > Hi, > > > > I would like to setup a Karaf based system to send mails for log > > messages of priority WARN and ERROR. > > > > I read some of the "Apache Karaf Decanter 2.x" documentation. > > > > $ tar xzf apache-karaf-4.2.6.tar.gz > > $ cd apache-karaf-4.2.6/ > > $ bin/karaf > > > > karaf@root()> feature:repo-add > > mvn:org.apache.karaf.decanter/apache-karaf-decanter/2.0.0/xml/features > > karaf@root()> feature:install decanter-collector-log > > karaf@root()> feature:install decanter-alerting-email > > > > There are now three configuration files: > > * org.apache.karaf.decanter.alerting.checker.cfg > > * org.apache.karaf.decanter.alerting.email.cfg > > * org.apache.karaf.decanter.collector.log.cfg > > > > Edit "org.apache.karaf.decanter.alerting.checker.cfg" and add that lines: > > === > > loggerLevel.error=match:ERROR > > loggerLevel.warn=match:WARN > > === > > > > Add the mail setup to "org.apache.karaf.decanter.alerting.email.cfg". > > > > Keep the standard "org.apache.karaf.decanter.collector.log.cfg". > > > > Let's trigger an ERROR log by trigger a feature installation of an non > > existing one: > > karaf@root()> feature:install unknown-feature-name > > > > The error contains that message: > > === > > 13:40:55.830 ERROR [Karaf local console user karaf] Exception caught > > while executing command > > java.lang.IllegalArgumentException: No matching features for > > unknown-feature-name/0 > > at > > org.apache.karaf.features.internal.service.FeaturesServiceImpl.computeFeaturesToAdd(FeaturesServiceImpl.java:835) > > ~[?:?] > > at > > org.apache.karaf.features.internal.service.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:798) > > ~[?:?] > > at > > org.apache.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:78) > > ~[?:?] > > at > > org.apache.karaf.features.command.FeaturesCommandSupport.execute(FeaturesCommandSupport.java:40) > > ~[?:?] > > at > > org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84) > > ~[?:?] > > at > > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68) > > ~[?:?] > > at > > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86) > > ~[?:?] > > at > > org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:599) > > ~[?:?] > > at > > org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526) > > ~[?:?] > > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415) > > ~[?:?] > > at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416) ~[?:?] > > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229) ~[?:?] > > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59) ~[?:?] > > at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:?] > > at > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > > ~[?:?] > > at > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > > ~[?:?] > > at java.lang.Thread.run(Thread.java:748) [?:?] > > === > > > > I would expect to receive a mail message now. > > > > No mail has been received. > > > > If I try to use the TRACE level for the decanter package space to > > "see" what's going on > > karaf@root()> log:set TRACE org.apache.karaf.decanter > > > > I get the additional log message: > > === > > 2019-07-08 13:48:55,021 Karaf local console user karaf ERROR Recursive > > call to appender PaxOsgi > > === > > > > So, I assume I need to use a debugger to get further information what > > is going on / wrong. > > > > Any other suggestions? > > > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com
Re: Karaf Decanter log => mail
Let me try to reproduce on my machine. Give me couple of hours, I will get back to you. Regards JB On 08/07/2019 13:51, Markus Rathgeb wrote: > Hi, > > I would like to setup a Karaf based system to send mails for log > messages of priority WARN and ERROR. > > I read some of the "Apache Karaf Decanter 2.x" documentation. > > $ tar xzf apache-karaf-4.2.6.tar.gz > $ cd apache-karaf-4.2.6/ > $ bin/karaf > > karaf@root()> feature:repo-add > mvn:org.apache.karaf.decanter/apache-karaf-decanter/2.0.0/xml/features > karaf@root()> feature:install decanter-collector-log > karaf@root()> feature:install decanter-alerting-email > > There are now three configuration files: > * org.apache.karaf.decanter.alerting.checker.cfg > * org.apache.karaf.decanter.alerting.email.cfg > * org.apache.karaf.decanter.collector.log.cfg > > Edit "org.apache.karaf.decanter.alerting.checker.cfg" and add that lines: > === > loggerLevel.error=match:ERROR > loggerLevel.warn=match:WARN > === > > Add the mail setup to "org.apache.karaf.decanter.alerting.email.cfg". > > Keep the standard "org.apache.karaf.decanter.collector.log.cfg". > > Let's trigger an ERROR log by trigger a feature installation of an non > existing one: > karaf@root()> feature:install unknown-feature-name > > The error contains that message: > === > 13:40:55.830 ERROR [Karaf local console user karaf] Exception caught > while executing command > java.lang.IllegalArgumentException: No matching features for > unknown-feature-name/0 > at > org.apache.karaf.features.internal.service.FeaturesServiceImpl.computeFeaturesToAdd(FeaturesServiceImpl.java:835) > ~[?:?] > at > org.apache.karaf.features.internal.service.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:798) > ~[?:?] > at > org.apache.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:78) > ~[?:?] > at > org.apache.karaf.features.command.FeaturesCommandSupport.execute(FeaturesCommandSupport.java:40) > ~[?:?] > at > org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84) > ~[?:?] > at > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68) > ~[?:?] > at > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86) > ~[?:?] > at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:599) > ~[?:?] > at > org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526) > ~[?:?] > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415) > ~[?:?] > at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416) ~[?:?] > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229) ~[?:?] > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59) ~[?:?] > at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > ~[?:?] > at java.lang.Thread.run(Thread.java:748) [?:?] > === > > I would expect to receive a mail message now. > > No mail has been received. > > If I try to use the TRACE level for the decanter package space to > "see" what's going on > karaf@root()> log:set TRACE org.apache.karaf.decanter > > I get the additional log message: > === > 2019-07-08 13:48:55,021 Karaf local console user karaf ERROR Recursive > call to appender PaxOsgi > === > > So, I assume I need to use a debugger to get further information what > is going on / wrong. > > Any other suggestions? > -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Karaf Decanter log => mail
Hi Markus, can you send the karaf.log to me ? Maybe issue in the SMTP config ? Regards JB On 08/07/2019 13:51, Markus Rathgeb wrote: > Hi, > > I would like to setup a Karaf based system to send mails for log > messages of priority WARN and ERROR. > > I read some of the "Apache Karaf Decanter 2.x" documentation. > > $ tar xzf apache-karaf-4.2.6.tar.gz > $ cd apache-karaf-4.2.6/ > $ bin/karaf > > karaf@root()> feature:repo-add > mvn:org.apache.karaf.decanter/apache-karaf-decanter/2.0.0/xml/features > karaf@root()> feature:install decanter-collector-log > karaf@root()> feature:install decanter-alerting-email > > There are now three configuration files: > * org.apache.karaf.decanter.alerting.checker.cfg > * org.apache.karaf.decanter.alerting.email.cfg > * org.apache.karaf.decanter.collector.log.cfg > > Edit "org.apache.karaf.decanter.alerting.checker.cfg" and add that lines: > === > loggerLevel.error=match:ERROR > loggerLevel.warn=match:WARN > === > > Add the mail setup to "org.apache.karaf.decanter.alerting.email.cfg". > > Keep the standard "org.apache.karaf.decanter.collector.log.cfg". > > Let's trigger an ERROR log by trigger a feature installation of an non > existing one: > karaf@root()> feature:install unknown-feature-name > > The error contains that message: > === > 13:40:55.830 ERROR [Karaf local console user karaf] Exception caught > while executing command > java.lang.IllegalArgumentException: No matching features for > unknown-feature-name/0 > at > org.apache.karaf.features.internal.service.FeaturesServiceImpl.computeFeaturesToAdd(FeaturesServiceImpl.java:835) > ~[?:?] > at > org.apache.karaf.features.internal.service.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:798) > ~[?:?] > at > org.apache.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:78) > ~[?:?] > at > org.apache.karaf.features.command.FeaturesCommandSupport.execute(FeaturesCommandSupport.java:40) > ~[?:?] > at > org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84) > ~[?:?] > at > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68) > ~[?:?] > at > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86) > ~[?:?] > at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:599) > ~[?:?] > at > org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526) > ~[?:?] > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415) > ~[?:?] > at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416) ~[?:?] > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229) ~[?:?] > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59) ~[?:?] > at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > ~[?:?] > at java.lang.Thread.run(Thread.java:748) [?:?] > === > > I would expect to receive a mail message now. > > No mail has been received. > > If I try to use the TRACE level for the decanter package space to > "see" what's going on > karaf@root()> log:set TRACE org.apache.karaf.decanter > > I get the additional log message: > === > 2019-07-08 13:48:55,021 Karaf local console user karaf ERROR Recursive > call to appender PaxOsgi > === > > So, I assume I need to use a debugger to get further information what > is going on / wrong. > > Any other suggestions? > -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
