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://ad...@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
>
