📄 rfc2564.txt
字号:
Kalbfleisch, et al. Standards Track [Page 6]
RFC 2564 Application Management MIB May 1999
These groups are organized into various tables. Information for a
particular running managed application appears in the form of entries
in the appropriate tables. The tables are:
- the tables providing a service-level view, including:
- the service name to service instance table
- the service instance to service name table
- the service instance to running application element
table
- the running application element to service instance
table
- the tables providing information on I/O channels, including:
- the table of open channels
- the table of open files
- the open connections table
- the transaction statistics tables
- historical information on I/O channels
- the running application element status and control group
- the running application element status table
- the running application element control table
In order to support SNMPv1, SNMPv2, and SNMPv3 environments, in cases
where counter objects may potentially advance very rapidly, where
sixty-four bit counters have been used thirty-two bit counters
reporting the low-order thirty-two bits of the value have also been
defined.
Since rows in most of these tables will come and go with the running
application elements whose information is contained in them,
sysUpTime.0 is not appropriate as a discontinuity indicator for
counters in these tables. By defining separate discontinuity
indicators for the rows in these tables, entries can come and go as
needed without causing other objects to appear to have
discontinuities. As required by [15], the discontinuity indicators
for the various information objects in these tables are identified in
Kalbfleisch, et al. Standards Track [Page 7]
RFC 2564 Application Management MIB May 1999
the relevant DESCRIPTION clauses. Note that a discontinuity in one
of these counters does not imply a sysUpTime.0 discontinuity, nor
does a sysUpTime.0 discontinuity imply a discontinuity in any of
these counters.
4.1. The service-level tables
The service-level tables permit the identification of one or more
instances of named services on a system, and the association of
running application elements to these services.
Service names are represented as human-readable strings, using values
assigned by IANA where possible. The allocation of unique values for
service instance identifiers is a local administrative issue; the
values allocated must be constant for the lifetime of the service
instance, and re-use of values should be avoided.
It is important to understand that a service is not the same thing as
a protocol. Rather, some services may be at least partially
described by the protocol(s) used to provide that service.
In deciding what should or should not be considered a service, the
following factors merit consideration:
- is there an identifiable set of resources associated with
providing this service?
- is there a reasonably long-lived server or client process?
Following this reasoning, one can see where SMTP and HTTP service
providers would be good candidates for classification as services for
purposes of application management, where finger probably would not.
Of course, implementors of this MIB are free to define additional
services. An applicability statement may be an appropriate vehicle
for standardizing how a specific service's information is reported
using this MIB.
4.1.1. The service name to service instance table
The service name to service instance table uses the service name as
its primary key, and the service instance identifier as its secondary
key. It facilitates the identification and lookup of the instances
of a given service in a system.
Kalbfleisch, et al. Standards Track [Page 8]
RFC 2564 Application Management MIB May 1999
4.1.2. The service instance to service name table
The service instance to service name table uses the service instance
identifier as its primary key, and the service name as its secondary
key. Given a service instance identifier, it facilitates the lookup
of the name of the service being provided.
4.1.3. The service instance to running application element table
The service instance to running application element table uses the
service instance identifier as its primary key, and the running
application element index as its secondary key. This facilitates the
identification of the set of running application elements providing a
given instance of a service.
4.1.4. The running application element to service instance table
The running application element to service instance table uses the
running application element index as its primary key and the service
instance identifier as its secondary key. It identifies the set of
services provided by a given running application element.
4.2. The I/O channel group
Information processed by an application can be modeled using the
concept of a channel. Two kinds of channels, for example, are files
and network connections.
+-------+
| File |
+---------+ /+-------+
+-------------+ | Generic | /
| transaction |----| I/O |-------<
| stream | | Channel | \ +------------+
+-------------+ +---------+ \ | open or |
\| listening |
| connection |
+------------+
For each entry in the open channel table, there will be a
corresponding entry in either the open file table or the open
connection table.
The information flowing on a channel may be structured as
transactions. When the information flow on a channel is being
monitored as a transaction stream, an entry in the transaction stream
table will represent this fact and the associated information about
Kalbfleisch, et al. Standards Track [Page 9]
RFC 2564 Application Management MIB May 1999
that stream.
To facilitate traversal of these tables and retrieval of information
relevant to a specific running application element or service
instances, the initial indexes of these tables are the same. In each
case, the first index determines whether the second index is
interpreted as a running application element identifier or as a
service instance identifier. The third index serves to uniquely
identify a channel (and consequently, an open connection or file) in
the context of a running application element or service instance.
The transaction stream summary table contains per-stream summaries of
transaction statistics. The transaction flow statistics table
contains statistics broken into both transmit and receive counts for
requests and responses on each stream. The transaction kind
statistics table contains information further broken down by
transaction kind.
The transaction tables have a common structure for their indexing,
with additional indexes added for increasing detail. The initial
three indexes are the same as all the other tables in this group,
serving to uniquely identify each transaction stream.
4.2.1. The open channels table
The following information is available in this table:
- time at which the channel was opened
- number of read requests
- number of bytes read
- time at which most recent read operation was initiated
- number of write requests
- number of bytes written
- time at which most recent write operation was initiated
4.2.2. The open files table
The open files table contains one entry for each file in use by a
manageable running application element. (See "Definitions of
System-Level Managed Objects for Applications" [31] for a detailed
definition of a running application element.) The purpose of this
table is to identify the files in use and to record information
Kalbfleisch, et al. Standards Track [Page 10]
RFC 2564 Application Management MIB May 1999
peculiar to files not already covered in the open channel table.
If multiple running application elements open the same file, there
will be an entry for each running application element opening that
file. Similarly, if a running application element opens a file
multiple times, there will be an entry in this table for the file
corresponding to each open.
The task of combining the information for file activity from this
table (organized by running application element) into per-application
statistics can be accomplished by a manager using the System
Application MIB's [31] sysApplInstallPkgTable to find the installed
application, the sysApplRunTable to find the running instances of
that application, and the sysApplElmtRunTable to find the relevant
values of sysApplElmtRunIndex. The manager, armed with a set of
values for sysApplElmtRunIndex, is now able to retrieve the relevant
portions of the applOpenFileTable and other tables in this MIB.
The following information is available in this table:
- file name
- file size
- current mode (read/write) of this file
By convention, the names "stdin", "stdout" and "stderr" are used when
these streams cannot be resolved to actual file names.
4.2.3. The open connections table
This table provides information on channels that are open connections
or listeners.
The following information is available for each connection:
- identification of the transport protocol in use
- near-end address and port
- far-end address and port
- identification of the application layer protocol in use
Kalbfleisch, et al. Standards Track [Page 11]
RFC 2564 Application Management MIB May 1999
4.2.4. The transaction stream summary table
The transaction stream summary table contains per-stream summaries of
transaction statistics. The simple model of a transaction used here
looks like this:
invoker | Request | performer
| - - - - - - > |
| |
| Response |
| < - - - - - - |
| |
Since in some protocols it is possible for an entity to take on both
the invoker and performer roles, information here is accumulated for
transmitted and received requests, as well as for transmitted and
received responses. Counts are maintained for both transactions and
bytes transferred. The information represented in this table
includes:
- identification of the underlying connection or file used for
this transaction stream
- a human-readable description of this stream
- a human-readable description of this stream's notion of what
a unit of work is
- the cumulative amount of time spent (as an operation
invoker) waiting for responses (from queueing of request to
arrival of first response)
- the cumulative amount of time spent (as an operation
invoker) receiving responses (time from the arrival of the
first response to the arrival of the last response in a
series of responses to a particular request)
- the cumulative amount of time spent (as an operation
performer) handling requests (time from receipt of request
to queueing of first outgoing response)
- the cumulative amount of time spent (as an operation
performer) sending responses (time from queuing of first
response to the last response in a series of responses to a
particular request)
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -