- **status**: review --> fixed
- **Comment**:
changeset: 5575:e690bed16457
tag: tip
user: Neelakanta Reddy <reddy.neelaka...@oracle.com>
date: Wed Aug 13 21:10:33 2014 +0530
summary: IMM: Dumpimg resource utilization data for IMMsv [#35}
---
** [tickets:#35] IMM: AdminOp on immsv for dumping resource utilization data**
**Status:** fixed
**Milestone:** 4.5.FC
**Created:** Tue May 07, 2013 11:17 AM UTC by Anders Bjornerstedt
**Last Updated:** Mon Aug 04, 2014 01:53 PM UTC
**Owner:** Neelakanta Reddy
Migrated from:
http://devel.opensaf.org/ticket/3080
-------------------------------------------------------
I is currently quite hard to monitor resource utilization for the
IMM service. For example, obtaining a current list of existing
implementer-names, whether the implementer is attached or not and
where. Some of this information is possible to extract by extensive
scans of syslog files.
But for troubleshooting and for ocasional probing of the "health"
of the service, it would be nice to have the possibility to extract
such resource information on demand.
One possibility is to create a representation of such information
as runtime data. But that approach has two drawbacks. First, the
data could be quite large in volume and thus costly to have
represented in the immsv. Even if encoded as pure runtime
attributes, it is not convenient to display large amounts
of information this way. Second, every time the resource report is
to be changed or extended to cover a new set of data, then new
classes and objects would need to be added, possibly also schema
changes in existing ones.
A more lightweight and flexible approach is the use of an admin-
operation directed at opensafImm=opensafImm,safApp=safImmService.
Something like:
immadm -O display -p resource:SA_STRING_T:implementers \
opensafImm=opensafImm,safApp=safImmService
The reply would be provided in two ways: A condensed summary as a
string return parameter and a more extensive printout to the syslog.
The condensed reply would also include a tag that would assist
locating the dump in the syslog.
It would be nice to provide the entire result as return parameters
and this may be possible for some resources. But the crude
type-system supported by the IMM makes this difficult. The problem
is mainly the lack of an ordered collection type. An open-ended
list of 'return parameters' is possible. But this also stretches
the intent of the admin-op mechanism since it would be a 'varargs'
type of return signature.
-------------------------------------------------------------
Changed 7 weeks ago by hafe ¶
I could see a need for the same in AMF and possibly other services. It would be
nice to come up with common approach for this.
Here's another approach, an admin op triggers a "dump" of a service state to
file instead. The name of the file can come from an argument to the admin op.
The format of this file is of course implementation dependent and can change as
the implementation changes (the schema problem you mentioned). But of course it
should be structured with key=value or something. Some services already have
implemented such dump function but the only way to trigger it is using gdb. I
am not in favour of dumping to syslog which seems like strange place to put
this info.
Comments?
---------------------------------------------------------
Changed 7 weeks ago by anders ¶
The main driver for me for this enhancement has been the problems experienced in
troubleshooting imm resource leaks. By 'resource leak' I mean a type of
application
bug where the application allocates resources (search-handles,
implementer-names) and
then does not re-use them or free them (where it is possible to free them).
Perhaps the main tool for troubleshooting is the syslog and so I dont see it as
a strange place to dump such information, given that the intent is to support
troubleshooting.
-------------------------------------------------------
Changed 7 weeks ago by hafe ¶
OK there are different use cases. Dumping the complete state of a service is
one which is what I had in mind for AMF. Another one is more fine grained
operations like getting the value of some service internal variable. Such
request is nice to get back as result strings on the admin op. Then you can
easily script a "monitor" on top of that interface in the style of top, vmstat
etc.
Writing to syslog I see more as a complement. Wouldn't it be nice with an
"immtop" :-)
Let's prototype!
--------------------------------------------
Changed 7 weeks ago by anders ¶
An "immtop" is a bit over the top (pun intended) in my opinion.
I dont see any serious need for realtime monitoring the utilization of the imm
resources.
The need is just to have the ability for the occasional dump.
---------------------------------------------------------------
Changed 7 weeks ago by anwi ¶
I think the tool should print its output to stdout (and error messages to
stderr) rather than to syslog. This way they will be most useful both at the
command prompt and inside scripts. It is easy to redirect stdout to a log file
in cases where this is needed.
----------------------------------------------------------
Changed 7 weeks ago by anders ¶
Oh of course.
No one has suggested anything else about the tool as such (immadm).
The idea was the the OI (server side) would write to the syslog because the
ammount
of data could be large and quite difficult to package as an admin-op reply and
difficlut for the receiver to process. The admin-op in quiestion would not
necessarily
always be invoked using immadm, even if that seems most likely now.
This admin-op is inended for assisting in troubleshooting resource leaks.
IKt is not intended as an end user utility.
So we probably dont want to spend too much time coding a pack/unpack and
pretty print t ostdout for it.
Frankly I dont understand this shyness of using the syslog as a tool for
troubleshooting.
From my point of view, the syslog is the main tool for troubleshooting problems
occurring on production systems. It provides a simple to implement and direct
way
of outputting data needed for troubleshooting.
In this particular case, there would not be any "spamming" the syslog since
there will
only be generated output to the syslog when that is requested through the
admin-op.
---
Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.------------------------------------------------------------------------------
_______________________________________________
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
