You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by "michal.warecki" <mi...@gmail.com> on 2012/02/19 18:34:33 UTC
[DISCUSS] Camel Alerts
Hello All!
Looking for an appropriate subject for the Google Summer of Code, I started
to think about the functionality of alerts. I think this functionality can
help Camel meet some of the requirements of mission-critical systems.
Alerts are kind of events which may indicate threat to the proper
functioning of the integration platform such as:
- specified thread pool reaches a specified threshold ratio,
- low memory (i.e. 70% Perm Gen is used)
- specified URL location is invalid (i.e. returns specified code),
- specified JMS attribute has specifies value (it really can be a point to
custom alert guard),
- specified exception type occurs (i.e. IOException may be caused by lack of
disk space),
- route did not finish its execution within specified period of time,
- some specified expression based on headers values.
Alerts should send predefined notifications (configured by standard Camel
components like email or SNMP). Additionally, it should be possible to set
severity level of alert.
Such alerting mechanism should be rather global with abillity to turn it off
for specified route.
Do you think it is a good idea to implement such functionality? Maybe do you
have some ideas that may be extend/modify above-mentioned mechanism?
My last thread about Spring Batch integration
(http://camel.465427.n5.nabble.com/DISCUSS-Camel-Spring-Batch-td5457726.html)
is too simple to work for 3-4 months (as provided in GSoC).
I want to ask also about mentoring in Google competition. Does anyone from
PMC of Camel could help me with this project? For my part, I can promise
strong commitment to the project. The task of a mentor is to advise during
the project.
Maybe let me introduce myself:
I'm 24 years old student of Military Uniwersity of Technology from Poland. I
have about 4-5 years of commercial experience. Currently I work at Ministry
of Education where I am responsible for creating a new system of educational
information. And most importantly, I'm a fan of open source software :-)
Thanks in advance for feedback.
--
View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-Camel-Alerts-tp5497221p5497221.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: [DISCUSS] Camel Alerts
Posted by Christian Schneider <ch...@die-schneider.net>.
Ooops ... I meant Hi Michal :-)
Christian
Am 20.02.2012 17:24, schrieb Christian Schneider:
> Hi Johan,
>
> that sounds great.
>
> The only thing we should take care of here is to not couple the
> alerting too much too the things we want to monitor. So I propose to
> only generate internal events in the
> camel core. Like an event when a thread pool is accessed or a
> exception is caused. The alerting could then be in its own module and
> analyze the low level events and create new events like
> you described. The current event system can be a quite good base for
> these efforts.
>
> Btw. when you work on the even system you could check if it can be
> made less intrusive. Currently the eventing couples where the events
> are generated to much to the eventing. I also plan to improve some of
> this for camel 3.
>
> Christian
>
>
> Am 20.02.2012 09:43, schrieb michal.warecki:
>> Thanks for you feedback!
>>
>> Chistian:
>> Exacly, general idea can present the following hypothetical
>> configuration:
>>
>> <camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
>>
>> <alerts>
>> <threadPoolAlert id="tpa" profile="fooProfile" severity="major"
>> threshold="70%" />
>> <lowMemoryAlert id="lma" pool="PermGen" severity="critical"
>> threshold="80%" />
>> <exceptionAlert id="xa" type="com.foo.MyException"
>> severity="critical" />
>> </alerts>
>>
>> <threadPoolProfile id="fooProfile" poolSize="20" maxPoolSize="50"
>> maxQueueSize="-1"/>
>>
>> <route>
>> <from uri="alert?id=tpa"/>
>> <to uri="smtp://admin@mymailserver.com?password=secret"/>
>> </route>
>>
>> </camelContext>
>>
>> Alert will generate an event and specified route can receive this event.
>> Christain, do you mean something like that?
>>
>> Johan,
>> thanks for thanks for the support.
>>
>> Michal
>>
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/DISCUSS-Camel-Alerts-tp5497221p5498485.html
>> Sent from the Camel Development mailing list archive at Nabble.com.
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [DISCUSS] Camel Alerts
Posted by "michal.warecki" <mi...@gmail.com>.
Camel management support for runtime information build on the top of JMX is
interesting idea.
We could add some notification broadcasters and MBean's. "Alert" will
analyze informations from notifications and if needed (based on
configuration) send to SMNP or SMTP.
SMNP should be preconfigured with: IOD, address, version, username,
password, passphrase.
For SMTP: server, port, username, password.
How do you think, what are the pros and cons of such a solution to support
JMX?
--
View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-Camel-Alerts-tp5497221p5502403.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: [DISCUSS] Camel Alerts
Posted by Willem Jiang <wi...@gmail.com>.
Maybe we could consider to build a common notfication layer for sending
this kind alerts across JMX and other management Agent.
On Tue Feb 21 02:53:49 2012, Łukasz Dywicki wrote:
> The monitoring of things like thread pools, memory or exceptions can be easily built on top of JMX layer. I would rather see a Camel events published to snmp than another DSL extension in default camel namespace.
>
> Best regards,
> Lukasz Dywicki
> --
> Code-House
> http://code-house.org
>
> Wiadomość napisana przez Christian Schneider w dniu 20 lut 2012, o godz. 17:24:
>
>> Hi Johan,
>>
>> that sounds great.
>>
>> The only thing we should take care of here is to not couple the alerting too much too the things we want to monitor. So I propose to only generate internal events in the
>> camel core. Like an event when a thread pool is accessed or a exception is caused. The alerting could then be in its own module and analyze the low level events and create new events like
>> you described. The current event system can be a quite good base for these efforts.
>>
>> Btw. when you work on the even system you could check if it can be made less intrusive. Currently the eventing couples where the events are generated to much to the eventing. I also plan to improve some of this for camel 3.
>>
>> Christian
>>
>>
>> Am 20.02.2012 09:43, schrieb michal.warecki:
>>> Thanks for you feedback!
>>>
>>> Chistian:
>>> Exacly, general idea can present the following hypothetical configuration:
>>>
>>> <camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
>>>
>>> <alerts>
>>> <threadPoolAlert id="tpa" profile="fooProfile" severity="major"
>>> threshold="70%" />
>>> <lowMemoryAlert id="lma" pool="PermGen" severity="critical"
>>> threshold="80%" />
>>> <exceptionAlert id="xa" type="com.foo.MyException" severity="critical" />
>>> </alerts>
>>>
>>> <threadPoolProfile id="fooProfile" poolSize="20" maxPoolSize="50"
>>> maxQueueSize="-1"/>
>>>
>>> <route>
>>> <from uri="alert?id=tpa"/>
>>> <to uri="smtp://admin@mymailserver.com?password=secret"/>
>>> </route>
>>>
>>> </camelContext>
>>>
>>> Alert will generate an event and specified route can receive this event.
>>> Christain, do you mean something like that?
>>>
>>> Johan,
>>> thanks for thanks for the support.
>>>
>>> Michal
>>>
>>> --
>>> View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-Camel-Alerts-tp5497221p5498485.html
>>> Sent from the Camel Development mailing list archive at Nabble.com.
>>
>>
>> --
>>
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
>
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
Re: [DISCUSS] Camel Alerts
Posted by "michal.warecki" <mi...@gmail.com>.
I read a little bit about SNMP and MIB used by some alerting modules.
Generally, most of these modules does not impose a top-down defined MIB.
User must create a MIB at his own and map suitable OID for a particular type
of alert.
In my view, we can offer a proposal Camel MIB but this is unlikely anything
complicated. It will be rather a MOTable placed in the extension of OID from
the standard MIB (like .iso.org.dod.internet.mgmt.mib-2.system or.
iso.org.dod.internet.mgmt.mib-2.interfaces).
Johan, what do you think about that?
What we certainly need to do is SnmpTrapProducer in SNMP component. I will
try to slightly extend the SNMP component during work on the alerting
module.
In the near future I will design an API for alerting module and will try to
present a proposal.
Do any of you have any thoughts on this?
Cheers,
Michał
--
View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-Camel-Alerts-tp5497221p5575667.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: [DISCUSS] Camel Alerts
Posted by "michal.warecki" <mi...@gmail.com>.
Ohh, now I know what you mean. I was sure that there is a MIB designed for
such tasks. I'll do research, which MIB uses similar platforms to Camel. If
necessary, we will need to design custom MIB or extend existing one.
Johan, many thanks for your help and understanding.
Will there be someone so kind and register as a mentor? I'll try to be a
good student and do not take too much time :-)
--
View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-Camel-Alerts-tp5497221p5573608.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: [DISCUSS] Camel Alerts
Posted by Johan Edstrom <je...@savoirtech.com>.
Well, a user designed OID is a derivative of a MIB, that
is what tells you what is what.
And there are the two sides to snmp, alerting events and
the polling monitoring side.
So if you look at a router say, CPU/Memory are predefined OID's
in a system mib, then you have interfaces x.25, frame relay and so on.
There are a few mibs I know of in the Java world, like oracle mibs
for their databases
You need those mibs to integrate to traditional monitoring software.
Nothing inappropriate about good questions!
/je
On Mar 16, 2012, at 2:51 PM, michal.warecki wrote:
> List of organizations approved by Google is available on
> http://www.google-melange.com/gsoc/accepted_orgs/google/gsoc2012.
>
> I would like to return to this topic and again to summarize the basic
> assumptions.
>
> The monitoring mechanism of the basic metrics such as memory, the
> availability of the URL, exceptions etc. will be based on JMX, which will
> send the appropriate notifications.
>
> Configuration will be responsible for defining levels of alerts (something
> like SLA's) and destinations.
> The two protocols that we support are SNMP and SMTP.
>
> So in total I came across a division into 3 layers:
> JMX notification layer; a layer of SLA-defined analyzes, and sending alerts;
> alerts receiving client layer.
>
> Question for Johan on SNMP:
> I have never used the SNMP so forgive me if my questions are inappropriate.
> Why should we worry about the MIB? Is it not sufficient if we just send
> information such as name of alert, alert type, description, severity, and
> the date and assign the user-defined OID?
>
> I understand that we are giving up the support of generic and decide to
> support the two protocols as shown in the following example?:
>
> <camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
>
> <alerts>
> <threadPoolAlert id="tpa" profile="fooProfile"
> severity="major" threshold="70%"
> destination="smtp://admin@mymailserver.com?password=secret"/>
> <lowMemoryAlert id="lma" pool="PermGen" severity="critical"
> threshold="80%"
> destination="snmp:192.168.178.23:161?protocol=udp&oids=1.3.6.1.2.1.1.5.0" />
> <exceptionAlert id="xa" type="com.foo.MyException"
> severity="critical"
> destination="snmp:192.168.178.23:161?protocol=udp&oids=1.3.6.1.2.1.1.5.0" />
> </ alerts>
>
> <threadPoolProfile id="fooProfile" poolSize="20" maxPoolSize="50"
> maxQueueSize="-1"/>
>
> </ camelContext>
>
> Does anyone of you would be willing to register as a mentor and help me in
> this project as an official mentor? Of course I will be grateful for the
> support of all but I must be assigned to an official mentor :-)
>
> I will be grateful for more clues as to the above described solution.
>
> Cheers,
> Michał
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-Camel-Alerts-tp5497221p5572465.html
> Sent from the Camel Development mailing list archive at Nabble.com.
Re: [DISCUSS] Camel Alerts
Posted by "michal.warecki" <mi...@gmail.com>.
List of organizations approved by Google is available on
http://www.google-melange.com/gsoc/accepted_orgs/google/gsoc2012.
I would like to return to this topic and again to summarize the basic
assumptions.
The monitoring mechanism of the basic metrics such as memory, the
availability of the URL, exceptions etc. will be based on JMX, which will
send the appropriate notifications.
Configuration will be responsible for defining levels of alerts (something
like SLA's) and destinations.
The two protocols that we support are SNMP and SMTP.
So in total I came across a division into 3 layers:
JMX notification layer; a layer of SLA-defined analyzes, and sending alerts;
alerts receiving client layer.
Question for Johan on SNMP:
I have never used the SNMP so forgive me if my questions are inappropriate.
Why should we worry about the MIB? Is it not sufficient if we just send
information such as name of alert, alert type, description, severity, and
the date and assign the user-defined OID?
I understand that we are giving up the support of generic and decide to
support the two protocols as shown in the following example?:
<camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
<alerts>
<threadPoolAlert id="tpa" profile="fooProfile"
severity="major" threshold="70%"
destination="smtp://admin@mymailserver.com?password=secret"/>
<lowMemoryAlert id="lma" pool="PermGen" severity="critical"
threshold="80%"
destination="snmp:192.168.178.23:161?protocol=udp&oids=1.3.6.1.2.1.1.5.0" />
<exceptionAlert id="xa" type="com.foo.MyException"
severity="critical"
destination="snmp:192.168.178.23:161?protocol=udp&oids=1.3.6.1.2.1.1.5.0" />
</ alerts>
<threadPoolProfile id="fooProfile" poolSize="20" maxPoolSize="50"
maxQueueSize="-1"/>
</ camelContext>
Does anyone of you would be willing to register as a mentor and help me in
this project as an official mentor? Of course I will be grateful for the
support of all but I must be assigned to an official mentor :-)
I will be grateful for more clues as to the above described solution.
Cheers,
Michał
--
View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-Camel-Alerts-tp5497221p5572465.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: [DISCUSS] Camel Alerts
Posted by Hadrian Zbarcea <hz...@gmail.com>.
+1. That makes sense. Thanks Johan,
Hadrian
On 02/20/2012 06:29 PM, Johan Edstrom wrote:
> I actually think SNMP would be more than enough.
> The problem resides in designing a MIB.
>
> One of the biggest culprits of Java is JMX, while great it isn't that "greatly and happily"
> adopted, combining snmp traps with snap OID reads (Which JMX set out to do) would
> provide a ton of info not to mention on a service provider level actually work as most monitoring
> systems expect data to be delivered.
>
> That said, :) Major undertaking.
>
> On Feb 20, 2012, at 1:11 PM, Christian Schneider wrote:
>
>> I think snmp publishing would be great but snmp would never be enough. So a more general aproach seems useful.
>> Of course the snmp case is important so it would be great if we could support that easily.
>> So for example it would be great if we could just have a route like from("event:alert*").to("snmp:server") to activate that.
>>
>> Christian
>>
>>
>> Am 20.02.2012 19:53, schrieb Łukasz Dywicki:
>>> The monitoring of things like thread pools, memory or exceptions can be easily built on top of JMX layer. I would rather see a Camel events published to snmp than another DSL extension in default camel namespace.
>>>
>>> Best regards,
>>> Lukasz Dywicki
>>> --
>>> Code-House
>>> http://code-house.org
>>>
>>> Wiadomość napisana przez Christian Schneider w dniu 20 lut 2012, o godz. 17:24:
>>>
>>>> Hi Johan,
>>>>
>>>> that sounds great.
>>>>
>>>> The only thing we should take care of here is to not couple the alerting too much too the things we want to monitor. So I propose to only generate internal events in the
>>>> camel core. Like an event when a thread pool is accessed or a exception is caused. The alerting could then be in its own module and analyze the low level events and create new events like
>>>> you described. The current event system can be a quite good base for these efforts.
>>>>
>>>> Btw. when you work on the even system you could check if it can be made less intrusive. Currently the eventing couples where the events are generated to much to the eventing. I also plan to improve some of this for camel 3.
>>>>
>>>> Christian
>>>>
>>>>
>>>> Am 20.02.2012 09:43, schrieb michal.warecki:
>>>>> Thanks for you feedback!
>>>>>
>>>>> Chistian:
>>>>> Exacly, general idea can present the following hypothetical configuration:
>>>>>
>>>>> <camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
>>>>>
>>>>> <alerts>
>>>>> <threadPoolAlert id="tpa" profile="fooProfile" severity="major"
>>>>> threshold="70%" />
>>>>> <lowMemoryAlert id="lma" pool="PermGen" severity="critical"
>>>>> threshold="80%" />
>>>>> <exceptionAlert id="xa" type="com.foo.MyException" severity="critical" />
>>>>> </alerts>
>>>>>
>>>>> <threadPoolProfile id="fooProfile" poolSize="20" maxPoolSize="50"
>>>>> maxQueueSize="-1"/>
>>>>>
>>>>> <route>
>>>>> <from uri="alert?id=tpa"/>
>>>>> <to uri="smtp://admin@mymailserver.com?password=secret"/>
>>>>> </route>
>>>>>
>>>>> </camelContext>
>>>>>
>>>>> Alert will generate an event and specified route can receive this event.
>>>>> Christain, do you mean something like that?
>>>>>
>>>>> Johan,
>>>>> thanks for thanks for the support.
>>>>>
>>>>> Michal
>>>>>
>>>>> --
>>>>> View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-Camel-Alerts-tp5497221p5498485.html
>>>>> Sent from the Camel Development mailing list archive at Nabble.com.
>>>>
>>>> --
>>>>
>>>> Christian Schneider
>>>> http://www.liquid-reality.de
>>>>
>>>> Open Source Architect
>>>> Talend Application Integration Division http://www.talend.com
>>>>
>>>
>>
>>
>> --
>>
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
>
--
Hadrian Zbarcea
Principal Software Architect
Talend, Inc
http://coders.talend.com/
http://camelbot.blogspot.com/
Re: [DISCUSS] Camel Alerts
Posted by Johan Edstrom <jo...@acj-consulting.com>.
I actually think SNMP would be more than enough.
The problem resides in designing a MIB.
One of the biggest culprits of Java is JMX, while great it isn't that "greatly and happily"
adopted, combining snmp traps with snap OID reads (Which JMX set out to do) would
provide a ton of info not to mention on a service provider level actually work as most monitoring
systems expect data to be delivered.
That said, :) Major undertaking.
On Feb 20, 2012, at 1:11 PM, Christian Schneider wrote:
> I think snmp publishing would be great but snmp would never be enough. So a more general aproach seems useful.
> Of course the snmp case is important so it would be great if we could support that easily.
> So for example it would be great if we could just have a route like from("event:alert*").to("snmp:server") to activate that.
>
> Christian
>
>
> Am 20.02.2012 19:53, schrieb Łukasz Dywicki:
>> The monitoring of things like thread pools, memory or exceptions can be easily built on top of JMX layer. I would rather see a Camel events published to snmp than another DSL extension in default camel namespace.
>>
>> Best regards,
>> Lukasz Dywicki
>> --
>> Code-House
>> http://code-house.org
>>
>> Wiadomość napisana przez Christian Schneider w dniu 20 lut 2012, o godz. 17:24:
>>
>>> Hi Johan,
>>>
>>> that sounds great.
>>>
>>> The only thing we should take care of here is to not couple the alerting too much too the things we want to monitor. So I propose to only generate internal events in the
>>> camel core. Like an event when a thread pool is accessed or a exception is caused. The alerting could then be in its own module and analyze the low level events and create new events like
>>> you described. The current event system can be a quite good base for these efforts.
>>>
>>> Btw. when you work on the even system you could check if it can be made less intrusive. Currently the eventing couples where the events are generated to much to the eventing. I also plan to improve some of this for camel 3.
>>>
>>> Christian
>>>
>>>
>>> Am 20.02.2012 09:43, schrieb michal.warecki:
>>>> Thanks for you feedback!
>>>>
>>>> Chistian:
>>>> Exacly, general idea can present the following hypothetical configuration:
>>>>
>>>> <camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
>>>>
>>>> <alerts>
>>>> <threadPoolAlert id="tpa" profile="fooProfile" severity="major"
>>>> threshold="70%" />
>>>> <lowMemoryAlert id="lma" pool="PermGen" severity="critical"
>>>> threshold="80%" />
>>>> <exceptionAlert id="xa" type="com.foo.MyException" severity="critical" />
>>>> </alerts>
>>>>
>>>> <threadPoolProfile id="fooProfile" poolSize="20" maxPoolSize="50"
>>>> maxQueueSize="-1"/>
>>>>
>>>> <route>
>>>> <from uri="alert?id=tpa"/>
>>>> <to uri="smtp://admin@mymailserver.com?password=secret"/>
>>>> </route>
>>>>
>>>> </camelContext>
>>>>
>>>> Alert will generate an event and specified route can receive this event.
>>>> Christain, do you mean something like that?
>>>>
>>>> Johan,
>>>> thanks for thanks for the support.
>>>>
>>>> Michal
>>>>
>>>> --
>>>> View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-Camel-Alerts-tp5497221p5498485.html
>>>> Sent from the Camel Development mailing list archive at Nabble.com.
>>>
>>> --
>>>
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> Talend Application Integration Division http://www.talend.com
>>>
>>
>
>
> --
>
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
Re: [DISCUSS] Camel Alerts
Posted by "michal.warecki" <mi...@gmail.com>.
I think that we should not be limited only to SNMP. A great idea is to help
to link with SNMP and SMTP as much as possible.
Łukasz:
Thanks for the tip on JMX.
I'll deeply analyze the mechanism of events in Camel and see how it can be
extended to meet the requirements of alerting.
Thanks again for your very helpful comments.
--
View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-Camel-Alerts-tp5497221p5501483.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: [DISCUSS] Camel Alerts
Posted by Christian Schneider <ch...@die-schneider.net>.
I think snmp publishing would be great but snmp would never be enough.
So a more general aproach seems useful.
Of course the snmp case is important so it would be great if we could
support that easily.
So for example it would be great if we could just have a route like
from("event:alert*").to("snmp:server") to activate that.
Christian
Am 20.02.2012 19:53, schrieb Łukasz Dywicki:
> The monitoring of things like thread pools, memory or exceptions can be easily built on top of JMX layer. I would rather see a Camel events published to snmp than another DSL extension in default camel namespace.
>
> Best regards,
> Lukasz Dywicki
> --
> Code-House
> http://code-house.org
>
> Wiadomość napisana przez Christian Schneider w dniu 20 lut 2012, o godz. 17:24:
>
>> Hi Johan,
>>
>> that sounds great.
>>
>> The only thing we should take care of here is to not couple the alerting too much too the things we want to monitor. So I propose to only generate internal events in the
>> camel core. Like an event when a thread pool is accessed or a exception is caused. The alerting could then be in its own module and analyze the low level events and create new events like
>> you described. The current event system can be a quite good base for these efforts.
>>
>> Btw. when you work on the even system you could check if it can be made less intrusive. Currently the eventing couples where the events are generated to much to the eventing. I also plan to improve some of this for camel 3.
>>
>> Christian
>>
>>
>> Am 20.02.2012 09:43, schrieb michal.warecki:
>>> Thanks for you feedback!
>>>
>>> Chistian:
>>> Exacly, general idea can present the following hypothetical configuration:
>>>
>>> <camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
>>>
>>> <alerts>
>>> <threadPoolAlert id="tpa" profile="fooProfile" severity="major"
>>> threshold="70%" />
>>> <lowMemoryAlert id="lma" pool="PermGen" severity="critical"
>>> threshold="80%" />
>>> <exceptionAlert id="xa" type="com.foo.MyException" severity="critical" />
>>> </alerts>
>>>
>>> <threadPoolProfile id="fooProfile" poolSize="20" maxPoolSize="50"
>>> maxQueueSize="-1"/>
>>>
>>> <route>
>>> <from uri="alert?id=tpa"/>
>>> <to uri="smtp://admin@mymailserver.com?password=secret"/>
>>> </route>
>>>
>>> </camelContext>
>>>
>>> Alert will generate an event and specified route can receive this event.
>>> Christain, do you mean something like that?
>>>
>>> Johan,
>>> thanks for thanks for the support.
>>>
>>> Michal
>>>
>>> --
>>> View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-Camel-Alerts-tp5497221p5498485.html
>>> Sent from the Camel Development mailing list archive at Nabble.com.
>>
>> --
>>
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [DISCUSS] Camel Alerts
Posted by Łukasz Dywicki <lu...@code-house.org>.
The monitoring of things like thread pools, memory or exceptions can be easily built on top of JMX layer. I would rather see a Camel events published to snmp than another DSL extension in default camel namespace.
Best regards,
Lukasz Dywicki
--
Code-House
http://code-house.org
Wiadomość napisana przez Christian Schneider w dniu 20 lut 2012, o godz. 17:24:
> Hi Johan,
>
> that sounds great.
>
> The only thing we should take care of here is to not couple the alerting too much too the things we want to monitor. So I propose to only generate internal events in the
> camel core. Like an event when a thread pool is accessed or a exception is caused. The alerting could then be in its own module and analyze the low level events and create new events like
> you described. The current event system can be a quite good base for these efforts.
>
> Btw. when you work on the even system you could check if it can be made less intrusive. Currently the eventing couples where the events are generated to much to the eventing. I also plan to improve some of this for camel 3.
>
> Christian
>
>
> Am 20.02.2012 09:43, schrieb michal.warecki:
>> Thanks for you feedback!
>>
>> Chistian:
>> Exacly, general idea can present the following hypothetical configuration:
>>
>> <camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
>>
>> <alerts>
>> <threadPoolAlert id="tpa" profile="fooProfile" severity="major"
>> threshold="70%" />
>> <lowMemoryAlert id="lma" pool="PermGen" severity="critical"
>> threshold="80%" />
>> <exceptionAlert id="xa" type="com.foo.MyException" severity="critical" />
>> </alerts>
>>
>> <threadPoolProfile id="fooProfile" poolSize="20" maxPoolSize="50"
>> maxQueueSize="-1"/>
>>
>> <route>
>> <from uri="alert?id=tpa"/>
>> <to uri="smtp://admin@mymailserver.com?password=secret"/>
>> </route>
>>
>> </camelContext>
>>
>> Alert will generate an event and specified route can receive this event.
>> Christain, do you mean something like that?
>>
>> Johan,
>> thanks for thanks for the support.
>>
>> Michal
>>
>> --
>> View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-Camel-Alerts-tp5497221p5498485.html
>> Sent from the Camel Development mailing list archive at Nabble.com.
>
>
> --
>
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
Re: [DISCUSS] Camel Alerts
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Johan,
that sounds great.
The only thing we should take care of here is to not couple the alerting
too much too the things we want to monitor. So I propose to only
generate internal events in the
camel core. Like an event when a thread pool is accessed or a exception
is caused. The alerting could then be in its own module and analyze the
low level events and create new events like
you described. The current event system can be a quite good base for
these efforts.
Btw. when you work on the even system you could check if it can be made
less intrusive. Currently the eventing couples where the events are
generated to much to the eventing. I also plan to improve some of this
for camel 3.
Christian
Am 20.02.2012 09:43, schrieb michal.warecki:
> Thanks for you feedback!
>
> Chistian:
> Exacly, general idea can present the following hypothetical configuration:
>
> <camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
>
> <alerts>
> <threadPoolAlert id="tpa" profile="fooProfile" severity="major"
> threshold="70%" />
> <lowMemoryAlert id="lma" pool="PermGen" severity="critical"
> threshold="80%" />
> <exceptionAlert id="xa" type="com.foo.MyException" severity="critical" />
> </alerts>
>
> <threadPoolProfile id="fooProfile" poolSize="20" maxPoolSize="50"
> maxQueueSize="-1"/>
>
> <route>
> <from uri="alert?id=tpa"/>
> <to uri="smtp://admin@mymailserver.com?password=secret"/>
> </route>
>
> </camelContext>
>
> Alert will generate an event and specified route can receive this event.
> Christain, do you mean something like that?
>
> Johan,
> thanks for thanks for the support.
>
> Michal
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-Camel-Alerts-tp5497221p5498485.html
> Sent from the Camel Development mailing list archive at Nabble.com.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [DISCUSS] Camel Alerts
Posted by "michal.warecki" <mi...@gmail.com>.
Thanks for you feedback!
Chistian:
Exacly, general idea can present the following hypothetical configuration:
<camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
<alerts>
<threadPoolAlert id="tpa" profile="fooProfile" severity="major"
threshold="70%" />
<lowMemoryAlert id="lma" pool="PermGen" severity="critical"
threshold="80%" />
<exceptionAlert id="xa" type="com.foo.MyException" severity="critical" />
</alerts>
<threadPoolProfile id="fooProfile" poolSize="20" maxPoolSize="50"
maxQueueSize="-1"/>
<route>
<from uri="alert?id=tpa"/>
<to uri="smtp://admin@mymailserver.com?password=secret"/>
</route>
</camelContext>
Alert will generate an event and specified route can receive this event.
Christain, do you mean something like that?
Johan,
thanks for thanks for the support.
Michal
--
View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-Camel-Alerts-tp5497221p5498485.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: [DISCUSS] Camel Alerts
Posted by Christian Schneider <ch...@die-schneider.net>.
Basically alerts are a good idea. I would make it a little more general
though.
Camel already has an event mechanism. We could extend this to the cases
you specified.
I would decouple the sending of external notifications from the events.
The external notifications could
be sent by camel routes that start with an event listener.
Christian
Am 19.02.2012 18:34, schrieb michal.warecki:
> Hello All!
>
> Looking for an appropriate subject for the Google Summer of Code, I started
> to think about the functionality of alerts. I think this functionality can
> help Camel meet some of the requirements of mission-critical systems.
>
> Alerts are kind of events which may indicate threat to the proper
> functioning of the integration platform such as:
> - specified thread pool reaches a specified threshold ratio,
> - low memory (i.e. 70% Perm Gen is used)
> - specified URL location is invalid (i.e. returns specified code),
> - specified JMS attribute has specifies value (it really can be a point to
> custom alert guard),
> - specified exception type occurs (i.e. IOException may be caused by lack of
> disk space),
> - route did not finish its execution within specified period of time,
> - some specified expression based on headers values.
>
> Alerts should send predefined notifications (configured by standard Camel
> components like email or SNMP). Additionally, it should be possible to set
> severity level of alert.
> Such alerting mechanism should be rather global with abillity to turn it off
> for specified route.
>
> Do you think it is a good idea to implement such functionality? Maybe do you
> have some ideas that may be extend/modify above-mentioned mechanism?
>
> My last thread about Spring Batch integration
> (http://camel.465427.n5.nabble.com/DISCUSS-Camel-Spring-Batch-td5457726.html)
> is too simple to work for 3-4 months (as provided in GSoC).
>
> I want to ask also about mentoring in Google competition. Does anyone from
> PMC of Camel could help me with this project? For my part, I can promise
> strong commitment to the project. The task of a mentor is to advise during
> the project.
>
> Maybe let me introduce myself:
> I'm 24 years old student of Military Uniwersity of Technology from Poland. I
> have about 4-5 years of commercial experience. Currently I work at Ministry
> of Education where I am responsible for creating a new system of educational
> information. And most importantly, I'm a fan of open source software :-)
>
> Thanks in advance for feedback.
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-Camel-Alerts-tp5497221p5497221.html
> Sent from the Camel Development mailing list archive at Nabble.com.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [DISCUSS] Camel Alerts
Posted by Johan Edstrom <jo...@acj-consulting.com>.
+1, I like the proposal, well-written nice ideas.
I also appreciate the fact that you acknowledge that the spring batch integration
would not be sufficient work.
I'm sure there are several that would want to help, sometimes splitting
up the mentoring work a little bit isn't a bad idea, something I've learned
after 3 years of participation in other projects.
/je
On Feb 19, 2012, at 10:34 AM, michal.warecki wrote:
> Hello All!
>
> Looking for an appropriate subject for the Google Summer of Code, I started
> to think about the functionality of alerts. I think this functionality can
> help Camel meet some of the requirements of mission-critical systems.
>
> Alerts are kind of events which may indicate threat to the proper
> functioning of the integration platform such as:
> - specified thread pool reaches a specified threshold ratio,
> - low memory (i.e. 70% Perm Gen is used)
> - specified URL location is invalid (i.e. returns specified code),
> - specified JMS attribute has specifies value (it really can be a point to
> custom alert guard),
> - specified exception type occurs (i.e. IOException may be caused by lack of
> disk space),
> - route did not finish its execution within specified period of time,
> - some specified expression based on headers values.
>
> Alerts should send predefined notifications (configured by standard Camel
> components like email or SNMP). Additionally, it should be possible to set
> severity level of alert.
> Such alerting mechanism should be rather global with abillity to turn it off
> for specified route.
>
> Do you think it is a good idea to implement such functionality? Maybe do you
> have some ideas that may be extend/modify above-mentioned mechanism?
>
> My last thread about Spring Batch integration
> (http://camel.465427.n5.nabble.com/DISCUSS-Camel-Spring-Batch-td5457726.html)
> is too simple to work for 3-4 months (as provided in GSoC).
>
> I want to ask also about mentoring in Google competition. Does anyone from
> PMC of Camel could help me with this project? For my part, I can promise
> strong commitment to the project. The task of a mentor is to advise during
> the project.
>
> Maybe let me introduce myself:
> I'm 24 years old student of Military Uniwersity of Technology from Poland. I
> have about 4-5 years of commercial experience. Currently I work at Ministry
> of Education where I am responsible for creating a new system of educational
> information. And most importantly, I'm a fan of open source software :-)
>
> Thanks in advance for feedback.
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-Camel-Alerts-tp5497221p5497221.html
> Sent from the Camel Development mailing list archive at Nabble.com.