|
>> I think the Performance FM is one of MCC's really great points. It
>> corresponds exactly to what several customers said they wanted from a
>> management tool during a recent EIP trip. Sadly, neither they nor I at
>> the time knew that MCC could solve this piece of their problems.
>> However, there is one oddity that I thought I would mention. I notice
>> that in the derived attributes, the error counters are given in delta
>> form, but NOT the traffic counters (bytes/packets sent/received etc).
>> These are only given in a rather more comprehensively digested form,
>> such as throughput. If you wanted to construct a graph showing traffic
>> against time, or raise an alarm if the traffic level was too high, this
>> would be exactly what you would want. There may well be other ways to
>> do both of these, but somehow it seems perverse to leave them out.
>> Could I perhaps suggest that the "raw" delta-form traffic counters be
>> included in the shipping product? I would have thought that this would
>> not be terribly hard to do (except for the slog of changing the MSL
>> files).
The question of providing "normalized counters" (or "delta Counters" though not
the same) has been on our minds for some time now. For our discussion here I won't
make any distinction between the normalized form and the delta form.
There are some issues that need to be resolved before we could provide them. We
didn't have time to find a satisfactory solution for V1.1 and so we provided some
"important" counters as normalized counters. These are the "COUNT OF xxxxxx" attributes,
where xxxxx is the name of the counter. For instance the attribute
COUNT OF response timeouts
gives the change in the value of the counter "response timeouts" during the specified
duration. Not all COUNT OF attributes are for error counters. "Some" traffic counters
are also provided in the delta form. For instance
COUNT OF inbound octets, COUNT OF outbound PDUs etc.
Now let's look at some of the issues to be addressed.
1. What partition do the normalized counters belong to?
Statistics, Counters or a new partition?
2. What about the IDs? Should they be seperate or should
they share the IDs with raw counters.
3. How do we request these attributes? By a SHOW or
a new directive or by specifying something on the
timespec.
Defining the delta form of EVERY counter for EVERY entity in an MSL
is very tedious to say the least.
>> One other thing that occurred to me, though probably less urgent, is
>> that it would be nice if the Perf FM could be used against "other" AMs.
>> The kinds of things it computes are applicable to all sorts of
>> entities. Obviously it would need to be "told", presumably via some MSL
>> extension, which counters (etc) to use for which calculations, although
>> delta-form counters could be derived automatically.
>> (Here is one place where SMI and GDMO score, since the "usual" counters like
>> Bytes Received are all derived from the same attribute and all have the same
>> object identifier wherever they occur).
Agree. Generic (or extensible?) PA is what we need.
|