📄 rfc2287.txt
字号:
Network Working Group C. Krupczak
Request for Comments: 2287 Empire Technologies, Inc.
Category: Standards Track J. Saperia
BGS Systems Inc.
February 1998
Definitions of System-Level Managed Objects for Applications
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Table of Contents
1 Abstract .............................................. 2
2 The SNMPv2 Network Management Framework ............... 2
2.1 Object Definitions .................................. 2
3 Overview .............................................. 3
4 Architecture for Application Management ............... 3
5 The Structure of the MIB .............................. 4
5.1 System Application Installed Group .................. 5
5.2 System Application Run Group ........................ 5
5.2.1 sysApplRunTable and sysApplPastRunTable ........... 5
5.2.2 sysApplElmtRunTable and sysApplElmtPastRunTable
.................................................... 6
5.3 System Application Map Group ........................ 7
6 Definitions ........................................... 7
7 Implementation Issues ................................. 40
7.1 Implementation with Polling Agents .................. 40
7.2 sysApplElmtPastRunTable Entry Collisions ............ 40
8 Security Considerations ............................... 41
9 Acknowledgements ...................................... 42
10 Author's Address ..................................... 42
11 References ........................................... 42
12 Full Copyright Statement ............................. 44
Krupczak & Saperia Standards Track [Page 1]
RFC 2287 MIB for Applications February 1998
1. Abstract
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes a basic set of managed objects for fault,
configuration and performance management of applications from a
systems perspective. More specifically, the managed objects are
restricted to information that can be determined from the system
itself and which does not require special instrumentation within the
applications to make the information available.
This memo does not specify a standard for the Internet community.
2. The SNMPv2 Network Management Framework
The SNMPv2 Network Management Framework consists of the following
major components:
o RFC 1902 Structure of Management Information for Version
2 of the Simple Network Management Protocol (SNMPv2) [2]
o RFC 1903 Textual Conventions for Version 2 of the Simple
Network Management Protocol (SNMPv2) [3]
o RFC 1904 Conformance Statements for Version 2 of the
Simple Network Management Protocol (SNMPv2) [4]
o RFC 1905 Protocol Operations for Version 2 of the Simple
Network Management Protocol (SNMPv2) [5]
o RFC 1906 Transport Mappings for Version 2 of the Simple
Network Management Protocol (SNMPv2) [6]
o RFC 1907 Management Information Base for Version 2 of the
Simple Network Management Protocol (SNMPv2) [7]
o RFC 1908 Coexistence between Version 1 and Version 2 of
the Internet-standard Network Management Framework [8]
The Framework permits new objects to be defined for the purpose of
experimentation and evaluation.
2.1. Object Definitions
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the subset of Abstract Syntax Notation One (ASN.1) [1],
defined in the Structure of Management Information (SMI) (See RFC
Krupczak & Saperia Standards Track [Page 2]
RFC 2287 MIB for Applications February 1998
1902 [2]). In particular, each object type is named by an OBJECT
IDENTIFIER, an administratively assigned name. The object type
together with an object instance serves to uniquely identify a
specific instantiation of the object. For human convenience, we often
use a textual string, termed the object descriptor, to refer to the
object type.
3. Overview
The primary purpose of computing technologies is the execution of
application software. These applications, typically specialized
collections of executables, files, and interprocess communications,
exist to solve business, scientific or other "problems". The
configuration, fault detection, performance monitoring and control of
application software across its life on a host computer is of great
economic importance. For the purposes of our work, we define
applications as one or more units of executable code and other
resources, installed on a single host system that a manager may think
of as a single object for management purposes.
The information described by the objects in the System Application
MIB support configuration, fault, and performance management; they
represent some of the basic attributes of application software from a
systems (non-application specific) perspective. The information
allows for the description of applications as collections of
executables and files installed and executing on a host computer.
This memo is concerned primarily with, and defines a model for,
application information resident on a host computer which can be
determined from the system itself, and not from the individual
applications. This system-level view of applications is designed to
provide information about software applications installed and running
on the host system without requiring modifications and code additions
to the applications themselves. This approach was taken to insure
ease and speed of implementation, while allowing room for future
growth.
4. Architecture for Application Management
In the area of application management it is fully acknowledged and
even expected that additional MIB modules will be defined over time
to provide an even greater level of detail regarding applications.
This MIB module presents the most general case: a set of management
objects for providing generic information about applications and
whose object values can be determined from the computer system itself
without requiring instrumentation within the application.
Krupczak & Saperia Standards Track [Page 3]
RFC 2287 MIB for Applications February 1998
A finer-grained level of detail is planned for the future "appl MIB"
which will be a common set of management objects relating to generic
applications, but which require some type of instrumentation in the
application in order to be determined. Since the applmib MIB module
will provide a finer level of detail, any connection to the sysAppl
MIB should be made by having references from the more detailed appl
MIB back to the more generic sysAppl MIB. Likewise, as application-
specific MIB modules such as the WWW MIB, etc., are developed over
time, these more specific MIBs should reference back to the more
generic MIBs.
While this MIB module does not attempt to provide every detailed
piece of information for managing applications, it does provide a
basic systems-level view of the applications and their components on
a single host system.
5. The Structure of the MIB
The System Application MIB structure models application packages as a
whole, and also models the individual elements (files and
executables) which collectively form an application. The MIB is
structured to model information regarding installed application
packages and the elements which make up each application package. The
MIB also models activity information on applications (and in turn,
their components) that are running or have previously run on the host
system. In modeling applications and their elements, this MIB module
provides the necessary link for associating executing processes with
the applications of which they are a part.
The objects are arranged into the following groups:
- System Application Installed Group
- sysApplInstallPkgTable
- sysApplInstallElmtTable
- System Application Run Group
- sysApplRunTable
- sysApplPastRunTable
- sysApplElmtRunTable
- sysApplElmtPastRunTable
- (scalars for restricting table sizes)
- System Application Map Group
- sysApplMapTable
Krupczak & Saperia Standards Track [Page 4]
RFC 2287 MIB for Applications February 1998
As can be seen by the arrangement above, for each category, the MIB
first treats an application package as a whole, and then breaks down
the package to provide information about each of the elements
(executable and non-executable files) of the package.
5.1. System Application Installed Group
The System Application Installed group consists of two tables.
Through these two tables, administrators will be able to determine
which applications have been installed on a system and what their
constituent components are. The first table, the
sysApplInstallPkgTable, lists the application packages installed on a
particular host. The second, the sysApplInstallElmtTable, provides
information regarding the executables and non-executable files, or
elements, which collectively compose an application.
NOTE: This MIB is intended to work with applications that have been
installed on a particular host, where "installed" means that the
existence of the application and the association between an
application and its component files can be discovered without
requiring additional instrumentation of the application itself. This
may require that certain conventions be used, such as using a central
software installation mechanism or registry, when installing
application packages. For example, many UNIX systems utilize a
"pkgadd" utility to track installed application packages, while many
PC systems utilize a global registry.
5.2. System Application Run Group
This group models activity information for applications that have
been invoked and are either currently running, or have previously
run, on the host system. Likewise, the individual elements of an
invoked application are also modeled to show currently running
processes, and processes that have run in the past. This information
is modeled using two pairs of tables: a pair of tables for currently
running applications and past run applications, and a pair of tables
for the currently running elements and the past run elements. Seven
scalars are also defined to control the size of the past run tables.
5.2.1. sysApplRunTable and sysApplPastRunTable
The sysApplRunTable and the sysApplPastRunTable make up the first
pair of tables. The sysApplRunTable contains the application
instances which are currently running on the host. Each time an
application is invoked, a new entry is created in the sysApplRunTable
to provide information about that particular invocation of the
application. An entry will remain in this table until the
Krupczak & Saperia Standards Track [Page 5]
RFC 2287 MIB for Applications February 1998
application instance terminates, at which time the entry will be
deleted from the sysApplRunTable and placed in the
sysApplPastRunTable.
The sysApplPastRunTable maintains a history of instances of
applications which have previously executed on the host. Entries to
this table are made when an invoked application from the
sysApplRunTable terminates; the table entry which represents the
application instance is removed from the SysApplRunTable and a
corresponding entry is added to the sysApplPastRunTable.
Because the sysApplPastRunTable will continuously grow as
applications are executed and terminate, two scalars are defined to
control the aging-out of table entries. The value of
sysApplPastRunMaxRows specifies the maximum number of entries the
table may contain, while the sysApplPastRunTblTimeLimit specifies the
maximum age of the table entries. Oldest entries are removed first.
It is important to note that the sysApplRunTable and
sysApplPastRunTable contain entries for each INVOCATION of an
application. A single application package might be invoked multiple
times; each invocation is properly recorded by a separate entry in
the sysApplRunTable.
In order to implement this group, the agent must be able to recognize
that an application has been invoked, and be able to determine when
that invocation terminates. This poses a complex problem since a
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -