Home » Archived » COSMOS » BtM Use Cases
| | | |
| Re: BtM Use Cases [message #3550 is a reply to message #3184] |
Thu, 09 November 2006 14:41   |
 Oliver E Cole
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Ok, I have been thinking about this BtM stuff a bunch. I have a
pretty good grasp of what it does now (from IBM). Now the questions is
"What should it mean in the context of eclipse?"
Vasya (at OCS) and I have kicked this around some, until finally I
figured out why I am having a hard time.
BtM is designed to help the software development team make
applications manageable. Ok, what does that mean, the term "Manageable"?
It means operations. It means that the application is easier to
"maintain" during its operation. Now my problem (is and has been) that
I don't see how we can "connect" with operations. (I am going to use
the terms monitoring and managing pretty much interchangably here).
The current BtM is designed to support "instrumentation" being
injected into the application. It can do ARM, CBE and JMX. But where
does that instrumentation write its data when the application is
running? Currently, we have no "runtime" to support BtM. Of course,
lots of vendors support different management frameworks, but does that
mean that BtM would require a proprietary runtime framework to do anything?
Also, there not a single set of monitoring standards that all
monotiring/managing solutions would use. So, does this mean that each
monitoring "vendor" has to have his own BtM? Does that mean that COSMOS
BtM has to target a "free" monitoring solution? If so, which one?
So, a BtM "plan" has to have a data colletion (and viewing)
plan for the operation system before we can call it a plan. Am I wrong
here?
CBE seems to be the lowest hanging fruit. tptp already has a
CBE log analyzer. Perhaps we come out with packages to "CBE enable"
sufficient middle ware (maybe the JLAMP stack) so that the CBE standard
gets a push. Yes, users would need to collect the CBE log files
themselves in the operational system, but that is not too daunting.
ARM is the next easiest to do as a standard. tptp has simple
ARM agents, but the tptp ARM implementation is quite simple and not
intended for operations. Again, perhaps we could push for a set of ARM
instrumentation for JLAMP as a means to promote the standard and a
sufficient set of ARM agents to collect it.
The JMX standard looks hard to promote without a lot more
work. Am I missing something here? Yah, we can support JMX insertion
of instrumentation, but the collecting and viewing of that data at
runtime seems to require a bunch more infrastructure than COSMOS can
commit to.
BtM inserts instrumentation. It also needs to collect the
data from that instrumentation. Looks like CBE and ARM are the best
possibilities to focus on.
|
|
| |
| Re: BtM Use Cases [message #3681 is a reply to message #3615] |
Sat, 11 November 2006 20:55 |
Oliver E Cole
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
I should be more to the point...
I am trying to come up with the use cases for BtM. One use case is
the current BtM one, where one uses BtM to perform the actual
instrumentation. The zillions of other factors (collecting the data and
getting it back to be viewed) to actually monitor, are ignored. I will
call the the "instrument" use case.
One question that should be put forward wrt the instrument use case
is what: What technologies should BtM support? So far, it supports
ARM, CBE, JMX, all for Java .NET capabilities are coming soon.
The use cases given by David Skeen document the above.
The is another set of use cases however that I would like to kick
around: BtM would embrace the whole end-to-end process. For now, I'll
call these the "end-to-end" use cases. An end-to-end use case starts
with the user wanting to "manage" his application with one of (ARM, CBE,
JMX) and goes all the way through actually viewing the data.
Right now, the BtM toolkit does the complete use case for using ARM
to do method level Java profiling, but this is not the compelling use
case for ARM, the compelling use for ARM is a more complicated use case.
But I would like to discuss other end-to-end use cases that may be
candidates for BtM. If we are to get adoption for these, we need to
make it simple to get the data from the standard, not just implement the
standard ;)
Here are some thoughts:
ARM: The real benefit of ARM is in transaction tracking. BtM could
embrace the ene-to-end use case of building ARMed applications and
viewing ARM data.
CBE: tptp already has a log analyzer. It doesn't sound too hard to
have BTM to address the end-to-end use case of Building CBE into the
application. Log file collection would need to be addressed, but this
can be pretty simple I think.
JMX: I am on shakier ground here, I need to read up more about the
current state of things in the JMX world and what standards are
prevelant. An obvious possibility is the end-to-end use case of
building in and monitoring JMX data, but I have the feeling that this is
a big effort. Additionally, there are already some open stuff out
there. Can we build them into our end-to-end use case? Or would they
have to commit to the EPL? I gotta read up more on JMX I think...
Lastly, there are probably some use cases that are in between
instrument and end-to-end.
--oec
Brian Vetter wrote:
> Oliver E Cole wrote:
>
>>
>> The JMX standard looks hard to promote without a lot more
>> work. Am I missing something here? Yah, we can support JMX
>> insertion of instrumentation, but the collecting and viewing of that
>> data at runtime seems to require a bunch more infrastructure than
>> COSMOS can commit to.
>
>
> I'm not sure I understand this comment. Most every commercial Java
> management tool that exists can collect JMX instrumentation from a
> running application server. Many of the commercial J2xx platforms have
> consoles that can managed JMX instrumented applications and most use JMX
> to instrument and manage themselves.
>
> In fact, there are several open source JMX management consoles. MC4J is
> even licensed under Apache and supports JSR 160 and its remote JMX APIs
> and Sun's reference implementation.
>
> So I'm not quite sure what you are saying that it will require a lot
> more work.
>
>> BtM inserts instrumentation. It also needs to collect the
>> data from that instrumentation. Looks like CBE and ARM are the best
>> possibilities to focus on.
>
>
> In the case J2xx applications, it isn't clear to me that JMX isn't just
> as easy and just as valuable.
>
> Brian
|
|
|
| Meeting Notes BtM Nov 15th. [message #4408 is a reply to message #3118] |
Thu, 16 November 2006 14:52 |
Oliver E Cole
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
First, I would like to personally thank those that participated in
the BtM call. It was very productive and we are making good progress
now (sorry for the slow start...)
Matt Ming, Dave Skeen, Mark Weitzel, Vasya Gorshkov and Oliver Cole
were dialed in (these meetings are every Wednesday at 1PM EST for one hour).
If anyone desires to get involved or has any questions, contact
Oliver or post...
First order of discussion was the current BtM value proposition of
instrumentation. All agreed that it should remain, but SNMP should be
added to the list of standards that should be incorporated. No specific
enhancements were proposed to the current functionality. Dave Skeens
current use cases are adequate for this.
Second order, end-to-end use cases were discussed. As it turns
out end-to-end use cases may be closer than we think for the three
technologies ARM, CEB (WEF) and JMX, if we embrace the existing tptp
functionality. It was agreed that a main point of BtM is to promote
standards rather than provide a production level product on those
standards, but to do that people had to find the standards easy to use
in a pre-production environment, and an end-to-end use case is the way
to do that.
It was decided that we first needed to get a firm understanding
of what is already in tptp/BtM, and Matt volunteered to do a Web
demonstration of the existing end-to-end functionality in the next
wednesday BtM meeting. (Matt, OCS has a web broadcasting thing that we
can set up easily for you, just let me know).
There is a sense that there are two deadlines for our work:
March and June. We all agree that a synergy with SML is appropriate
but March is probably too early to plan on something being implemented
for BtM, but June seems doable.
So, at a high level, the idea is to see what is already there
and focus on ease of use for the (pretty much?) existing end-to-end use
cases for BtM/tptp for the three main uses cases of ARM, CBE and JMX for
March. SNMP support still needs to be investigated.
Action items: Dave Skeen, who will get a feeling from IBM as to
whether IBM would consider enahancing the tptp ARM agents/infrastructure
as infringing too much on production.
Matt Ming: have a web demo next week of the
existing capablities in BtM in an end to end scenario.
I think it is important that we not miss any existing
functionality in eclipse/tptp, alphaworks, developerworks, etc. There is
probably a lot we can leverage. As we go forward, the BtM effort (me)
should make sure that we get many people's input, even if they are not
part of the team specifically. I am always surprised how talking to
someone "related" to an effort can yield excellent nuggets of what exists.
For now, let's use the Kevin Bacon approach and all please
identify people that should be included and (as appropriate) I will take
the action item to grovel to them for some of their time for their
review. Feel free to invite guest presenters to the Wednesdays BtM
meetings.
Next call, Wednesday at 1PM at the same dial in specificed
elsewhere in the newsgroup. At any time, feel free to email me or get
me on the phone.....
|
|
| | | |
| Re: BtM Use Cases [message #567744 is a reply to message #3184] |
Thu, 09 November 2006 14:41 |
Oliver E Cole
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Ok, I have been thinking about this BtM stuff a bunch. I have a
pretty good grasp of what it does now (from IBM). Now the questions is
"What should it mean in the context of eclipse?"
Vasya (at OCS) and I have kicked this around some, until finally I
figured out why I am having a hard time.
BtM is designed to help the software development team make
applications manageable. Ok, what does that mean, the term "Manageable"?
It means operations. It means that the application is easier to
"maintain" during its operation. Now my problem (is and has been) that
I don't see how we can "connect" with operations. (I am going to use
the terms monitoring and managing pretty much interchangably here).
The current BtM is designed to support "instrumentation" being
injected into the application. It can do ARM, CBE and JMX. But where
does that instrumentation write its data when the application is
running? Currently, we have no "runtime" to support BtM. Of course,
lots of vendors support different management frameworks, but does that
mean that BtM would require a proprietary runtime framework to do anything?
Also, there not a single set of monitoring standards that all
monotiring/managing solutions would use. So, does this mean that each
monitoring "vendor" has to have his own BtM? Does that mean that COSMOS
BtM has to target a "free" monitoring solution? If so, which one?
So, a BtM "plan" has to have a data colletion (and viewing)
plan for the operation system before we can call it a plan. Am I wrong
here?
CBE seems to be the lowest hanging fruit. tptp already has a
CBE log analyzer. Perhaps we come out with packages to "CBE enable"
sufficient middle ware (maybe the JLAMP stack) so that the CBE standard
gets a push. Yes, users would need to collect the CBE log files
themselves in the operational system, but that is not too daunting.
ARM is the next easiest to do as a standard. tptp has simple
ARM agents, but the tptp ARM implementation is quite simple and not
intended for operations. Again, perhaps we could push for a set of ARM
instrumentation for JLAMP as a means to promote the standard and a
sufficient set of ARM agents to collect it.
The JMX standard looks hard to promote without a lot more
work. Am I missing something here? Yah, we can support JMX insertion
of instrumentation, but the collecting and viewing of that data at
runtime seems to require a bunch more infrastructure than COSMOS can
commit to.
BtM inserts instrumentation. It also needs to collect the
data from that instrumentation. Looks like CBE and ARM are the best
possibilities to focus on.
|
|
| |
| Re: BtM Use Cases [message #567853 is a reply to message #3615] |
Sat, 11 November 2006 20:55 |
Oliver E Cole
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
I should be more to the point...
I am trying to come up with the use cases for BtM. One use case is
the current BtM one, where one uses BtM to perform the actual
instrumentation. The zillions of other factors (collecting the data and
getting it back to be viewed) to actually monitor, are ignored. I will
call the the "instrument" use case.
One question that should be put forward wrt the instrument use case
is what: What technologies should BtM support? So far, it supports
ARM, CBE, JMX, all for Java .NET capabilities are coming soon.
The use cases given by David Skeen document the above.
The is another set of use cases however that I would like to kick
around: BtM would embrace the whole end-to-end process. For now, I'll
call these the "end-to-end" use cases. An end-to-end use case starts
with the user wanting to "manage" his application with one of (ARM, CBE,
JMX) and goes all the way through actually viewing the data.
Right now, the BtM toolkit does the complete use case for using ARM
to do method level Java profiling, but this is not the compelling use
case for ARM, the compelling use for ARM is a more complicated use case.
But I would like to discuss other end-to-end use cases that may be
candidates for BtM. If we are to get adoption for these, we need to
make it simple to get the data from the standard, not just implement the
standard ;)
Here are some thoughts:
ARM: The real benefit of ARM is in transaction tracking. BtM could
embrace the ene-to-end use case of building ARMed applications and
viewing ARM data.
CBE: tptp already has a log analyzer. It doesn't sound too hard to
have BTM to address the end-to-end use case of Building CBE into the
application. Log file collection would need to be addressed, but this
can be pretty simple I think.
JMX: I am on shakier ground here, I need to read up more about the
current state of things in the JMX world and what standards are
prevelant. An obvious possibility is the end-to-end use case of
building in and monitoring JMX data, but I have the feeling that this is
a big effort. Additionally, there are already some open stuff out
there. Can we build them into our end-to-end use case? Or would they
have to commit to the EPL? I gotta read up more on JMX I think...
Lastly, there are probably some use cases that are in between
instrument and end-to-end.
--oec
Brian Vetter wrote:
> Oliver E Cole wrote:
>
>>
>> The JMX standard looks hard to promote without a lot more
>> work. Am I missing something here? Yah, we can support JMX
>> insertion of instrumentation, but the collecting and viewing of that
>> data at runtime seems to require a bunch more infrastructure than
>> COSMOS can commit to.
>
>
> I'm not sure I understand this comment. Most every commercial Java
> management tool that exists can collect JMX instrumentation from a
> running application server. Many of the commercial J2xx platforms have
> consoles that can managed JMX instrumented applications and most use JMX
> to instrument and manage themselves.
>
> In fact, there are several open source JMX management consoles. MC4J is
> even licensed under Apache and supports JSR 160 and its remote JMX APIs
> and Sun's reference implementation.
>
> So I'm not quite sure what you are saying that it will require a lot
> more work.
>
>> BtM inserts instrumentation. It also needs to collect the
>> data from that instrumentation. Looks like CBE and ARM are the best
>> possibilities to focus on.
>
>
> In the case J2xx applications, it isn't clear to me that JMX isn't just
> as easy and just as valuable.
>
> Brian
|
|
|
| Meeting Notes BtM Nov 15th. [message #568036 is a reply to message #3118] |
Thu, 16 November 2006 14:52 |
Oliver E Cole
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
First, I would like to personally thank those that participated in
the BtM call. It was very productive and we are making good progress
now (sorry for the slow start...)
Matt Ming, Dave Skeen, Mark Weitzel, Vasya Gorshkov and Oliver Cole
were dialed in (these meetings are every Wednesday at 1PM EST for one hour).
If anyone desires to get involved or has any questions, contact
Oliver or post...
First order of discussion was the current BtM value proposition of
instrumentation. All agreed that it should remain, but SNMP should be
added to the list of standards that should be incorporated. No specific
enhancements were proposed to the current functionality. Dave Skeens
current use cases are adequate for this.
Second order, end-to-end use cases were discussed. As it turns
out end-to-end use cases may be closer than we think for the three
technologies ARM, CEB (WEF) and JMX, if we embrace the existing tptp
functionality. It was agreed that a main point of BtM is to promote
standards rather than provide a production level product on those
standards, but to do that people had to find the standards easy to use
in a pre-production environment, and an end-to-end use case is the way
to do that.
It was decided that we first needed to get a firm understanding
of what is already in tptp/BtM, and Matt volunteered to do a Web
demonstration of the existing end-to-end functionality in the next
wednesday BtM meeting. (Matt, OCS has a web broadcasting thing that we
can set up easily for you, just let me know).
There is a sense that there are two deadlines for our work:
March and June. We all agree that a synergy with SML is appropriate
but March is probably too early to plan on something being implemented
for BtM, but June seems doable.
So, at a high level, the idea is to see what is already there
and focus on ease of use for the (pretty much?) existing end-to-end use
cases for BtM/tptp for the three main uses cases of ARM, CBE and JMX for
March. SNMP support still needs to be investigated.
Action items: Dave Skeen, who will get a feeling from IBM as to
whether IBM would consider enahancing the tptp ARM agents/infrastructure
as infringing too much on production.
Matt Ming: have a web demo next week of the
existing capablities in BtM in an end to end scenario.
I think it is important that we not miss any existing
functionality in eclipse/tptp, alphaworks, developerworks, etc. There is
probably a lot we can leverage. As we go forward, the BtM effort (me)
should make sure that we get many people's input, even if they are not
part of the team specifically. I am always surprised how talking to
someone "related" to an effort can yield excellent nuggets of what exists.
For now, let's use the Kevin Bacon approach and all please
identify people that should be included and (as appropriate) I will take
the action item to grovel to them for some of their time for their
review. Feel free to invite guest presenters to the Wednesdays BtM
meetings.
Next call, Wednesday at 1PM at the same dial in specificed
elsewhere in the newsgroup. At any time, feel free to email me or get
me on the phone.....
|
|
|
Goto Forum:
Current Time: Tue Apr 23 08:02:56 GMT 2024
Powered by FUDForum. Page generated in 0.05232 seconds |
] 
Search
Help
Register
Login
Home
