Server Agent Guide
Chapter 1 - Planning for the Server Agent Option
This guide describes the major concepts and features of the Banyan Distributed Enterprise Management Architecture (DeMarcTM) Server Agent option and related services. It is written for network administrators and assumes that these administrators have a good understanding of network interfaces, communications protocols, and industry standards for network management.
DeMarc allows network administrators to easily manage and control network resources and services across an enterprise. The architecture is based on a set of distributed services that collect and store management information throughout the network.
This chapter describes how to plan for setting up the DeMarc Server Agent option in your network and explains necessary administrative tasks. It also identifies and defines the key network services that participate with enterprise management and the DeMarc option.
Components of the Server Agent Architecture
Within the DeMarc Server Agent architecture, there are several interacting components. They are:
![]()
Simple Network Management Protocol (SNMP) service ![]()
History Collector Service (HCS) ![]()
Event Management Service (EVS)
The following sections describe each of these components in detail.
Simple Network Management Protocol Service
The Simple Network Management Protocol (SNMP) service runs on a server. The SNMP service is an SNMP master agent, which interacts with multiple SNMP sub-agents on the same server (see Figure 1-1). An SNMP sub-agent exists for each participating service running on the server. The SNMP master agent handles communications with the SNMP management application.
The SNMP management application communicates directly with an SNMP master agent. The interactions between the master agent and the management application follow a request and response model over a computer network. The master agent accepts incoming SNMP requests and routes the requests to the appropriate SNMP sub-agent on the server. The sub-agent provides the information requested by the master agent. The master agent hides the complexity of the multiple sub-agents from the SNMP management application by acting as a point contact.
Also on the server is the History Collector Service (HCS), which gathers and stores network management data in a local history database. This historical data can be used by management applications for performance management and trend analysis.
Note: To view and use HCS data, you need to have a suitable management application installed. For information on how to use a management application to view and use HCS data, see the documentation for the application.
System administrators can configure HCS to collect information and then later retrieve all the information at once. For example, a system administrator may be interested in collecting load average information from a particular server known to experience high-usage periods. The administrator configures HCS to collect load averages for the server over a period of time. The administrator specifies how often to sample the data, how to group the information, and how long to keep valid information in the history database. Once configured, the HCS service automatically gathers and stores the information. Upon the administrator's request, HCS retrieves the load average data and makes it available to the management application for performance management.
HCS allows you to automate data collection and storage, saving you from continuously monitoring network management data either on your own or using toolkit functions to call a particular service.
HCS uses SNMP to collect network management data. HCS acts as an SNMP management entity, making requests to an SNMP agent for that data which the administrator wants to collect. HCS can collect data both locally from the server on which it resides and remotely from other network devices (see Figure 1-2). A network device does not have to be a Banyan server, it only needs to contain an SNMP agent. Although HCS can collect data remotely, it is optimized to collect data locally.
Also on the server is the Event Management Service (EVS), which is a core service that interacts with the other network services. EVS collects and stores important events. An event is real-time information that represents a unit of network or service activity. An event can indicate a network problem, such as a session becoming lost, a failed login attempt, or a performance problem. Or, an event can indicate other dynamic information about network activity, such as a session becoming active, a service being shut down by a system administrator, or a threshold level being reached. Events are initiated by individual services. Refer to Appendix B for a description of events.
EVS runs on each VINES 6.x and greater server and manages the network events that are initiated by the local services (see Figure 1-3). Each service sends its network events to EVS, which stores the events in a database and applies filters to the events. A filter is a mechanism for selecting a particular event and specifying an action to take on the event in real-time.
EVS allows you to automate event processing and storage, saving you from continuously monitoring the network on your own. Instead of having to poll a server or service to determine status, you can configure EVS to automatically notify you as soon as a potential problem or other important situation occurs.
For example, a system administrator may be interested in knowing about a particular event, all events of a particular type, all events from a particular service, or any combinations of these events. The administrator configures a filter that specifies the events to report and the form of notification. Currently, the notification actions supported are network messages, mail messages, and SNMP traps. A trap is a message that contains the SNMP format of the event.
In addition to supporting real-time notification, EVS allows management applications to retrieve event history information from its local database. The management application uses the filter criteria to specify what events it wants to receive. For example, an auditing application may retrieve only auditing events from the database. A performance management application may retrieve all events generated during a time period in which a server's performance was poor.
Figure 1-4 shows the relationship among the various components of the Server Agent architecture.
Examples of the interactions between the various components of the Server Agent architecture are as follows:
![]()
An SNMP management application requests statistics or other information from the SNMP master agent. The master agent routes the request to the appropriate SNMP sub-agent on the server. The sub-agent provides the information requested by the master agent. The master agent responds to the SNMP management application request. ![]()
A management application requests trend analysis data from HCS. HCS retrieves the data from its local history database and provides the data to the application. ![]()
An SNMP management application issues set requests to the SNMP master agent. A set request asks the master agent to perform a certain operation, such as setting a configuration parameter or a threshold value. The set request is sent to the appropriate sub-agent to perform the action. ![]()
A service initiates an event in the network and sends it to EVS. EVS stores the event in the database and processes the event based on configured filters. When required by the filter criteria, a trap is generated and sent to the SNMP management application.
Units of management information relating to resources to be managed are known as managed objects. Load averages and numbers of active sessions are examples of managed objects. These objects are defined in Management Information Bases (MIBs), which are collections of related managed objects. Each managed object is represented by its object identifier (OID) in ASN.1 format, such as:
1.3.6.1.4.1.130.1.3.1.9.0
A MIB can define a collection of Banyan's managed objects, such as statistics retrievable from and configuration parameters settable on Banyan servers. Or, a MIB can define other product-specific managed objects, such as those related to a third-party router. All Banyan's managed objects are hierarchically arranged under the root:
1.3.6.1.4.1.130
MIBs are ASCII files compiled with the SNMP management application software.
Table 1-1 lists the MIBs currently supported with the DeMarc Server Agent option.
Communication and Network Management
In the Server Agent architecture framework, SNMP management applications and SNMP master agents communicate directly. When an SNMP management application and master agent communicate, no other computer that supports SNMP is involved - the management application and master agent communicate without requiring the assistance of an intermediary computer.
Note: The proxy approach, in which an SNMP agent acts as a proxy for servers with no SNMP software installed, is not supported by the DeMarc Server Agent.
To communicate, an SNMP management application and an SNMP master agent must both support either Transmission Control Protocol/Internet Protocol (TCP/IP) communication protocols or VINES IP protocols.
With TCP/IP, each server that has an SNMP master agent must run either the Banyan TCP/IP Routing option or limited TCP/IP, which is the TCP/IP software that is bundled with VINES 6.x and greater. Limited TCP/IP allows the master agent to be a TCP/IP end node, but not a router. See the Banyan TCP/IP Guide for more information.
Figure 1-5 shows how SNMP master agents communicate directly with SNMP management applications.
In Figure 1-5, two of the servers are equipped with the TCP/IP Routing option. This option gives these master agents the following capabilities:
![]()
Communicate directly with the SNMP management application ![]()
Route TCP/IP traffic, including tunneling TCP/IP traffic through the Banyan network
The other two servers are equipped with limited TCP/IP. This software allows servers that have SNMP master agents to communicate directly with SNMP management applications as TCP/IP end points. It does not allow SNMP master agents to route TCP/IP traffic or tunnel TCP/IP traffic through the network. Refer to "Verifying Your Network Configuration" later in this chapter for more information on tunneling TCP/IP traffic through Banyan networks.
This section provides an overview of the tasks you need to perform to plan the DeMarc Server Agent option before you install it. The tasks are as follows:
![]()
Identify SNMP management applications. ![]()
Verify the SNMP management application configuration. ![]()
Verify your network configuration. ![]()
Plan for adding the enterprise management services (SNMP and HCS). ![]()
Determine configuration settings for the enterprise management services (SNMP, HCS, and EVS).
Identifying SNMP Management Applications
Identify the SNMP management applications in your network. Typically, the SNMP management application is run on a workstation, such as a UNIX, Windows, or Windows NT workstation. Examples of management applications are SunNetTM Manager and OutLookTM for HP OpenViewTM for Windows.
Depending on the kind of network that connects the SNMP master agent and the SNMP management application, you should verify the network configuration of the SNMP management application. For example, to verify the configuration in TCP/IP networks, obtain the IP addresses of SNMP management applications. Consult the administrators of the SNMP management applications in the network if you cannot provide this information.
In addition, you need to verify that the SNMP management application contains the information required to communicate with the SNMP master agents. For example, the SNMP management application configuration should specify the following elements:
![]()
Master agent location ![]()
SNMPv1 communities or SNMPv2 parties
The exact way in which SNMP management applications specify these elements depends on the management application. For information on the exact configuration requirements of the management application, see the documentation for the application.
Likewise, you need to verify that the SNMP master agent contains the information required to communicate with the SNMP management applications.
Verifying Your Network Configuration
You must verify the network configuration of the server where the SNMP master agent resides. Verification ensures that the SNMP master agent can communicate with the SNMP management application.
SNMP master agents and management applications can be connected by the following kinds of networks:
![]()
TCP/IP connected ![]()
VINES IP connected
The following sections help you to verify each kind of network configuration.
TCP/IP Networks
If SNMP management applications communicate with agents over TCP/IP networks, make sure that the server containing the SNMP master agent runs either the Banyan TCP/IP Routing option or the limited TCP/IP software that comes with VINES 6.x and greater.
TCP/IP Routing Option
If the agent has the TCP/IP Routing option, see the Banyan TCP/IP Guide for more information on configuring TCP/IP.
Limited TCP/IP
Limited TCP/IP does not allow your server to be a TCP/IP router. The server can act as a TCP/IP end point only. Because of this limitation, the TCP/IP configuration is not complex. See the Banyan TCP/IP Guide for more information on configuring TCP/IP.
TCP/IP Configuration
The network configuration of the server on which the SNMP master agent resides must contain the necessary TCP/IP configuration parameters. In many cases, the only information that you need to specify in the TCP/IP configuration is as follows:
![]()
The IP addresses of the agent's TCP/IP interfaces. An interface gives your server access to a physical medium, such as an Ethernet LAN, or a logical network such as a VINES network. An interface is associated with a LAN card or with a VINES network. ![]()
The IP address of the default gateway. In these cases, the SNMP master agent uses the default gateway to reach all TCP/IP destinations that are not directly connected to it.
In the context of TCP/IP, the default gateway forwards IP traffic to destinations for which you have not defined specific routes. A specific route in the TCP/IP configuration specifies the following items:
![]()
The IP address of the IP gateway through which a destination is reached. A gateway typically forwards IP traffic, such as SNMP statistics, to destinations, switching the traffic from one physical connection to another in the process. For example, an IP gateway may receive SNMP traffic on one LAN and switch the traffic to another LAN for delivery to its destination. ![]()
The interface that connects your server to the IP gateway. ![]()
The IP address of the destination. The destination can be an IP network, subnetwork, or individual TCP/IP host, such as a UNIX workstation that runs the SNMP management application.
When the TCP/IP software on the server cannot use any of the specific routes to reach destinations, the TCP/IP software forwards IP traffic to the default gateway. The default gateway, in turn, must have the appropriate routing information in its configuration to reach these destinations.
If your server has a direct connection to a destination, such as an Ethernet LAN connection, the route does not specify an IP gateway. An IP gateway is specified only when the destination does not share a direct connection with your server.
See the Banyan TCP/IP Guide for more information.
Tunneling
The server on which the SNMP master agent resides does not require a physical connection to a TCP/IP network, such as an Ethernet connection. Instead, if the server has the TCP/IP Routing option, it can tunnel SNMP traffic through a Banyan network. Tunneling is a routing technique in which TCP/IP packets are encapsulated by VINES packet headers for transmission through a VINES network.
Figure 1-6 shows a SNMP master agent server tunneling SNMP traffic through a VINES network.
The server on which the SNMP master agent resides (see Figure 1-6) still needs the TCP/IP Routing option installed and configured, even though it is not directly connected to a TCP/IP network. You have to run the TCP/IP configuration program to configure a TCP/IP route through VINES.
Make sure your TCP/IP configuration is set up to reach the appropriate SNMP management applications. You may have to consult the administrators responsible for the SNMP management applications at your site or at other sites. In turn, administrators who are responsible for the SNMP management applications at other sites should check that their TCP/IP configurations are set up to reach you. See your TCP/IP documentation for details.
VINES Protocols
If you have SNMP management applications that can communicate with SNMP agents using VINES protocols, you do not need to perform any special network configuration tasks on the SNMP agent. VINES protocols automatically set up the network configurations of servers and workstations.
Planning for Adding Enterprise Management Services
You need to create the various services that make up the DeMarc Server Agent option:
![]()
SNMP service, which handles communications with SNMP management applications. This service includes the SNMP master agent. ![]()
HCS service, which maintains a local database of network management information.
The EVS service is a core service on servers running VINES 6.x and greater. EVS is created and started automatically as part of the server software installation.
You create the SNMP service and HCS service on each server that participates in enterprise management in the network. You cannot create more than one SNMP or HCS service on a server.
To make the services available, you must:
1. Decide on a StreetTalk name for the particular service.
2. Add the service name to the StreetTalk database.
3. Start the service.
Entering service configuration settings is not required to add and start the service. However, the SNMP management applications in your network may require these settings. For more information on how to configure the particular service (SNMP service, HCS service, or EVS service), refer to the appropriate section later in this chapter.
The steps required to make the services available are described in detail in the following sections.
Decide on a StreetTalk name for the SNMP service and for HCS. Each service in the network has a StreetTalk name in the format:
item@group@organization
where item is a unique name within the service's group, group is the name of the group, and organization is the name of the organization to which the group belongs. The name should indicate what service it is. For example, for the SNMP service, use a name, such as:
SNMP@servername@Servers
for the SNMP master agent, where servername is the name of the server on which the service is created.
For HCS, use a name, such as:
HCS@servername@Servers
The EVS service is a default service on servers running VINES 6.x and greater. EVS is created and started automatically as part of the server software installation. EVS is named:
EVS@servername@Servers
After you decide on a StreetTalk name for the SNMP service and for HCS, add the names to the StreetTalk database. The section, "To Add the SNMP and HCS Services," in Chapter 3 describes how to add the service names to the StreetTalk database.
Once you add the StreetTalk names, start the SNMP service and HCS. For details, see the section, "To Add the SNMP and HCS Services," in Chapter 3.
Determining SNMP Service Configuration Settings
SNMP service configuration settings are stored in five StreetTalk attributes. Specifically, these attributes are:
![]()
Party table attribute - Specifies initial party table information for parties associated with the SNMP master agent ![]()
View table attribute - Specifies MIB view information for SNMPv1 community strings and SNMPv2 parties ![]()
Context table attribute - Specifies context information for SNMPv1 community strings and SNMPv2 parties ![]()
ACL table attribute - Specifies access control privileges (ACLs) SNMPv1 community strings and SNMPv2 parties ![]()
SNMP agent attribute - Initializes system variables and defines authentication-failure traps
Refer to Appendix A for a detailed description of the configuration attributes for SNMP.
The SNMP service configuration attributes are only visible and accessible to individuals on the AdminList of the server that maintains the SNMP service. The section, "Configuring the Services," in Chapter 3 describes how to supply configuration information in the StreetTalk attributes.
For details on how to configure SNMP traps to be sent to SNMP management applications, refer to "Determining EVS Service Configuration Settings" later in this chapter.
For additional information on SNMP, refer to the SNMP RFCs:
SNMPv1
RFC 1155 - Structure and identification of management information for TCP/IP-based networks
RFC 1157 - A Simple Network Management Protocol
RFC 1212 - Concise MIB definitions
RFC 1213 - MIB-II for network management of TCP/IP-based networks
RFC 1215 - Convention for defining traps for use with SNMP
SNMPv2
RFC 1441 - Introduction to SNMPv2
RFC 1442 - Structure of management information for SNMPv2
RFC 1443 - Text conventions for SNMPv2
RFC 1444 - Conformance statements for SNMPv2
RFC 1445 - Administrative model for SNMPv2
RFC 1446 - Security protocols for SNMPv2
RFC 1447 - Party MIB for SNMPv2
RFC 1448 - Protocol operations for SNMPv2
RFC 1449 - Transport mappings for SNMPv2
RFC 1450 - MIB for SNMPv2
RFC 1451 - Manager to manager MIB
RFC 1452 - Coexistence between SNMPv1 and SNMPv2
You can obtain these RFCs from the Internet. To do so, perform the following steps:
1. FTP to ftp.internic.net.
2. CD to the RFC directory. The RFC directory contains the Internet RFCs.
Tips for SNMP Service Configuration
The SNMP master agent understands both SNMPv1 and SNMPv2 requests. Thus, the SNMP service configuration attributes include settings for SNMPv1 entities and SNMPv2 entities.
For an SNMPv1 entity, the required configuration information is fairly simple. Only a few of the settings relate to the SNMPv1 entity; the other, SNMPv2-related settings are ignored. Thus, if you want to configure an SNMP service that will receive requests only from SNMPv1 entities, you need to specify only the settings that relate to the SNMPv1 entity and leave the other settings as system default values.
To configure an SNMP service that will receive requests only from SNMPv1 entities, use the default settings that shipped with the service, making modifications where necessary. The next section describes how to specify settings for SNMPv1 entities using the default settings that shipped with the SNMP service.
Default SNMPv1 Configuration Settings
The SNMP service ships with a default configuration setting that defines one SNMPv1 community string. This community string, public, has an associated access control list (ACL) that allows basic read access (Get, GetNext, and sending of traps). The community string has an associated MIB view that makes visible all objects under the "internet" branch of the SNMP MIB tree.
The definition of the community string is provided in the party table attribute. Refer to Appendix A for a detailed description of the party table attribute.
The default settings in the party table that relate to the SNMPv1 entity are as follows:
![]()
partyName - Although party names do not apply to SNMPv1 interactions, the partyName is a required parameter. The value represents a unique entry into the party table. ![]()
TDomain - The value indicates that the entry is an SNMPv1 entry defining a community string. ![]()
partyIndex - The value is a unique index used to define the ACL and view for this community string. ![]()
AuthPrivateSecret - The value is the ASCII representation of the community string.
Figure 1-7 illustrates the default SNMPv1 entry for the party table.
The definition of the access control for the community string is provided in the ACL table attribute. The Target and Subject entries are identified as those that match the partyIndex for the community string. The actual access control value is an integer representing the sum of allowed operations. Refer to Appendix A for a detailed description of the ACL table attribute.
Figure 1-8 illustrates the default entry for the ACL table.
The definition of the MIB view of the community string is provided in the view table attribute. The entries specify which MIB subtrees can be seen and are therefore available to the associated community string. A single view can be associated with many community strings. Refer to Appendix A for a detailed description of the view table attribute.
Figure 1-9 illustrates one of the default entries for the view table.
This entry indicates that any context with a contextViewIndex of 2 has the viewSubtree of internet included in its MIB view. The community strings identified by viewIndex can see the internet group, unless limited by another entry.
The entries in the context table are used to link the view table with the ACL table.
Figure 1-10 illustrates one of the default entries for the context table.
Figure 1-11 illustrates the default table entries and how the values in the entries correspond to one another.
Specifically, the partyIndex value in the party table corresponds to the Target and Subject values in the ACL table entry. The matching value 7 maps these table entries together. This ACL table entry specifies the set of access privileges for the party.
The Resources value in the ACL table corresponds to the contextIndex values in the context table. The matching value 2 maps these table entries together.
The contextViewIndex value in the context table corresponds to the viewIndex value in the view table. The matching value 2 maps these table entries together. This view table entry specifies the subtree family to be included in the party's MIB view (internet).
To simplify the process of configuring the SNMP service, modify the default attributes that shipped with the service. Most of the arguments can remain as default settings; you only need to increment certain identifiers, make certain indexes match, and modify some arguments.
For example, for each entry you add to the party table, make the following modifications to the default settings:
1. Increment the index value of the PartyName argument to a unique value.
2. Match the partyIndex value in the party table to the Target and Subject values in an ACL table entry.
3. Modify the AuthPrivateSecret value to a represent the secrets string for authentication protocol (see Figure 1-12).
4. Match the Resources value in one or more entries in the ACL table to the contextIndex value in a context table entry.
5. Modify the Privileges value in the ACL table entry to represent the set of allowed management operations for the party (see Figure 1-13).
6. Match the contextViewIndex value in one or more entries in the context table to a viewIndex value in a view table (see Figure 1-14).
7. Modify the view table arguments to specifies the subtree families to be included or excluded from the party's MIB view (see Figure 1-15).
If, after you make modifications to the default settings, you decide that the service configuration values you entered are incorrect, you can delete the configuration attributes and restore the system default values. To do so, follow these steps:
1. Stop the SNMP service that contains incorrect configuration values.
2. Use the MATTR program to delete the configuration attributes. The section, "Configuring the Services," in Chapter 3 describes how to use the MATTR program.
3. Restart the SNMP service to allow the service to write its system default settings to the configuration file.
Once you have restored the system default values, you can follow the procedure described in this section to modify the default attributes with the correct values.
Default SNMPv2 Configuration Settings
The SNMP service ships with default configuration settings that define the six SNMPv2 initial parties described in RFC 1447. If you want to configure an SNMP service that will receive requests from any SNMPv2 entities, you need to modify several of the default values. For example, for each entry in the party table, you need to modify the PartyName argument. Change the default value 127.0.0.1. to the TCP/IP address of the server on which the master agent resides. Keep in mind that you need to verify that the SNMP management applications in you network contain the information required to communicate with this master agent. To specify the settings that relate to SNMPv2 entities, refer to Appendix A for a detailed description of the syntax used to configure SNMPv2 parties.
Special Configuration with Multiple Instances of a Service
A special case you need to consider when accessing certain MIB variables is with multiple instances of a Banyan service residing on a server. Although each instance of a service supports the same service MIB, each has unique values for its separate MIB objects. Thus, to access specific MIB variables, you must identify which service instance you are targeting. Further, for the request to be accepted by the agent, you must configure the SNMP service for each service instance.
How you identify the service instance depends on whether the requests are SNMPv1 or SNMPv2 requests.
SNMPv1 Requests
To target one of multiple instances of a service with an SNMPv1 request, the request must contain the community string and the StreetTalk name of the particular service. Append the StreetTalk name of the service to the community string using the syntax @service-name, where service-name is the three-part StreetTalk name of the service.
For example, if two print services reside locally on a server, use @service-name to specify which service to target:
public@printer1@sales@WCTUS
Keep in mind that management applications may restrict the length of the community string included in a request. Make sure that the combined length of the community string and service name does not exceed that maximum.
The community string and service name strings are case-sensitive. SNMP accepts the case of community string exactly as entered. Thus, verify that you enter the case correctly.
If you omit the @service-name argument when performing a Get operation, you may not obtain the data you expect. For example, SNMP may request information from the instance of the service that registered most recently with the SNMP master agent. If you omit the @service-name argument when performing a Set operation, the target service will not honor the request.
For an SNMPv1 request to be accepted by the agent, you must also configure the community string and service name value into the party table attribute. Include a separate party entry for each service instance you want to target.
Refer to Appendix A for a detailed description of the party table attribute.
SNMPv2 Requests
To target one of multiple instances of a service with an SNMPv2 request, the request must contain a context party configured to identify the particular service. The LocalEntity argument in the context table attribute contains the StreetTalk name of the particular service.
For example, if two print services reside locally on a server, use the LocalEntity to specify which service to target:
printer1@sales@WCTUS
The service name string is case-sensitive. SNMP accepts the case of community string exactly as entered. Thus, verify that you enter the case correctly.
Include a separate context entry for each service instance you want to target.
If the context party you supply when performing a Get operation is not configured to identify the particular service, you may not obtain the data you expect. For example, SNMP may request information from the instance of the service that registered most recently with the SNMP master agent. If you attempt to perform a Set operation, the target service will not honor the request.
Refer to Appendix A for a detailed description of the context table attribute.
Determining HCS Service Configuration Settings
You can configure the HCS service to retrieve and store tables of data in a local history database for use by management applications. You instruct HCS to collect a table of data for a specified targeted entity based on a specified collection of MIB objects. You specify how frequently to sample the entity for data and how long to maintain the historical data in the database.
Note: Some management applications configure HCS for you. For information on how to use a management application to configure HCS, see the documentation for the application.
HCS service configuration settings are stored in a StreetTalk attribute. The section, "Configuring the Services," in Chapter 3 describes how to supply configuration information in the StreetTalk attribute.
When planning to configure an HCS service to collect data, familiarize yourself with the MIBs (see Table 1-1). Each MIB details the information supported by the particular SNMP component. Select the OIDs for which you want to collect historical data. Depending on what data you are interested in capturing, you create a table of information for HCS to collect. Each table should represent a logical grouping of information. For example, decide what management information you want from a particular service and how you want the information grouped. Once you have decided on logical collections of information, decide how often you want to sample the SNMP entity and how long you want HCS to maintain the data.
Consider the location of the individual HCS services in the network when deciding which entities you want HCS to sample. In most cases, it is more efficient for an HCS service to retrieve data locally than from a remote entity. Thus, if an HCS service resides on each server in the network, it would be most efficient for each HCS to collect data locally. However, depending on your network, you may want to configure an HCS service to gather data from entities located nearby in the network.
It is recommended that you create a trusted time source list on every server in the network on which an HCS service resides. This list contains the names of other servers that can update the server's time. Without this list, the server's time will be frequently adjusted by other servers in the network, affecting HCS's history sampling and data timestamps. For more information on how to create a trusted time source list, refer to the Server Operations Guide.
HCS uses SNMPv1 to collect data. When HCS makes an SNMP request, it must supply a community string as part of the request. The community string defines the access control for specific MIB objects. For example, the commonly used community string public allows HCS to perform SNMP Get operations on MIB objects.
When planning to configure an HCS service to collect data, record the configuration specifics for each table of information on a worksheet:
![]()
Name of the server that maintains the HCS service. ![]()
StreetTalk name of the HCS service. ![]()
Name of the table of information. ![]()
Time, in days, to maintain the data. ![]()
Frequency, in minutes, to sample for data. ![]()
Community string required to retrieve the data:
Is the target SNMP entity a single service or one of multiple instances of a Banyan service?
- If the target entity is a single instance of a service, specify the C: keyword with the CommunityString argument, identifying the community name required for the data to be collected from the target entity.
- If the target entity is one of multiple instances of a Banyan service, specify the C: keyword with the CommunityString argument. Append the StreetTalk name of the particular service you want to target to the C: CommunityString argument.
![]()
Transport type and address to which HCS will make SNMP requests:
Is the target SNMP entity located on the server where the HCS service resides? Is it a single service or one of multiple instances of a Banyan service?
- If the target entity is a local entity and is a single instance of the service, specify an Address argument with the value local (A: local). Omit the Transport argument.
- If the target entity is a local entity and is one of multiple instances of a Banyan service, specify the communication protocol suites (such VINES IP or TCP/IP) that the HCS service uses to communicate with the target SNMP entity. Specify the network location, which is either an IP address for TCP/IP or a server name for VINES IP.
- If the target entity is a remote entity, specify the communication protocol suites (such VINES IP or TCP/IP) that the HCS service uses to communicate with the target SNMP entity. Specify the network location, which is either an IP address for TCP/IP or a server name for VINES IP.
![]()
Object identifiers (OIDs) representing the data to collect, in ASN.1 format.
The next section describes the configuration attribute for HCS.
The HCS table attribute defines the tables of data to collect and store in the HCS database. The vendor attribute pair of this attribute is <35:200>.
Syntax
Specify whether HCS collects data for the default table (hcsdef) using the following optional parameter as the first line in the attribute file:
GETDEFAULT: value
Each entry in the attribute file consists of the following arguments:
TABLE: tablename
K: KeepTime
S: SampleTime
C: CommunityString
A: Transport Address
O: OID
The arguments must appear in correct order. Each line must begin with the required keyword (TABLE:, K:, and so on). A blank character is required between the keyword and its value. If a value contains a blank character, enclose the value in quotation marks.
For more information on syntax requirements, refer to "Syntax Rules" later in this section.
GETDEFAULT: value
GETDEFAULT: value specifies whether to collect data for the default table named hcsdef. When value is on, HCS collects data for the table hcsdef. When value if off, HCS does not collect data for the table.
GETDEFAULT: value is an optional parameter. If you omit it, HCS does not collect data for the table. The GETDEFAULT: keyword and the value argument are not case-sensitive.
To determine whether collection of the default table hcsdef has been turned on or off, use the HCS MIB object hcsDefaultFileFlag. See "Configuring HCS Through the HCS MIB" later in this section.
For a definition of hcsdef, see "Example 1" later in this section.
TABLE: tablename
TABLE: tablename specifies the name of an individual table of data to collect and maintain in the history database.
The TABLE: keyword and the tablename argument are not case-sensitive. The tablename argument represents a filename with a maximum eight-character prefix and three-character extension. Try to create a table name that identifies what data the table represents. For example, for a table that gathers NetRPC® statistics from several services on a server, you might use a name such as rpcstats. For a table that gathers information from a StreetTalk service, you might use a name such as st.tab.
The name must be unique for the tables configured for an HCS service. The HCS service ignores any table without a unique name. Thus, if you configure two valid tables for an HCS service, each named loadavg, HCS accepts the first instance of the table and ignores the second instance.
The maximum number of user-configurable tables per HCS service is 15. If specified, the HCS service maintains an additional table named hcsdef. This default table cannot be modified or overwritten. The HCS service ignores any other table with the name hcsdef.
K: KeepTime
K: KeepTime specifies a time, in days, representing how long to maintain data in the history database. The oldest data stored in the database is data collected at the following time:
current time - KeepTime value
The HCS service deletes data as it exceeds that time.
The K: keyword is not case-sensitive. The minimum value allowed for the KeepTime argument is 1 day. The maximum value allowed is 30 days.
S: SampleTime
S: SampleTime specifies a time, in minutes, representing how frequently to sample the target entity for data.
The S: keyword is not case-sensitive. The minimum value allowed for the SampleTime argument is 1 minute. The maximum value allowed is 1440 minutes (24 hours).
C: CommunityString
C: CommunityString identifies the community name that represents access control required for the data to be collected from the target SNMP entity. Refer to "Party Table Attribute" in Appendix A for more information on community strings.
In most cases, you only need to specify the community name for the CommunityString argument. A special case of the community name is with multiple instances of a Banyan service residing on a server. To target one of the services, append the StreetTalk name of the particular service to the CommunityString argument. Use the syntax @service-name, where service-name is the three-part StreetTalk name of the service. If the community string or the service name contains a blank character, enclose it in quotation marks. The maximum length for the community string and service name is 128 characters.
For example, if two print services reside locally on a server, use the @service-name to specify which service to target:
c: public@"color printer@sales@WCTUS"
The C: keyword and the @service-name argument are not case-sensitive. However, the CommunityString argument is case-sensitive. HCS accepts the case of community string exactly as entered. Thus, you should verify that you entered the case correctly before you write the HCS table attribute to StreetTalk.
If you enter only the C: keyword and omit the CommunityString argument, HCS uses the community name public. If you also omit the @service-name argument when multiple instances of a service reside on the server, HCS retrieves information for the instance of the service that registered most recently with the SNMP master agent.
A: Transport Address
A: Transport Address specifies the transport type and address to which HCS will make SNMP requests.
The A: keyword is not case-sensitive. If the target entity is local, the Transport argument is not required. Valid values for the Transport argument are as follows:
![]()
T instructs HCS to make SNMP requests over TCP/IP. ![]()
V instructs HCS to make SNMP requests over VINES IP.
The Address argument must be either an address or the value local. When Transport is T, the address is an IP address in dot notation. When Transport is V, the address is a server name. If the server name contains a blank character, enclose it in quotation marks.
In most cases, when you configure a table of information that is local to HCS (is located on the same server as HCS), specify the value local. This value instructs HCS to make a request to the local SNMP master agent on the server rather than make a network request that would add to network traffic.
A special case is with multiple instances of a Banyan service residing on a server. When you configure a table of information that is local to HCS and targets one or more instances of a service, you must specify an address, rather than use the value local.
O: OID
O: OID specifies the object identifiers that represents the data you want HCS to collect in this table.
The O: keyword is not case-sensitive. Include from 1 to 10 OID arguments per table, each on its own line. Each OID argument must be in ASN.1 format. For scalar objects, the OID ends in .0, defining an exact instance that HCS uses to make an SNMP Get request. For example:
1.3.6.1.4.1.130.1.3.1.22.6.1.0
For tabular objects, the OID ends in an index that identifies an entry point into the table. Some SNMP management applications allow you to walk a table, so that you can determine the index value to use to target a tabular object.
The HCS assumes that each OID argument is a valid object identifier and is supported by the target entity. If HCS receives an error when attempting to retrieve an object, HCS does not write any data to the history database. Instead, HCS writes a warning message to the service log. If you see errors in the log, verify that an SNMP agent is running on the target entity and that the OID argument you entered is valid.
HCS imposes a size limit when writing certain types of data to the history database. For OID arguments defined as octet strings or as display strings (such as a service name), HCS imposes a limit of 128 characters. If an OID exceeds this maximum, HCS does not write the value to the history database. Instead, HCS writes a warning message to the service log, indicating which OID exceeded the maximum octet string length. No limit is imposed on OID arguments defined as integers.
HCS does not collect its own object identifiers. If it encounters one of its own object identifiers in the list, HCS removes the identifier from the list and continues to the next identifier. In addition, HCS writes a warning message to the service log.
If HCS encounters a duplicate object identifier in the list, HCS removes the duplicate identifier from the list and continues to the next identifier. In addition, HCS writes a warning message to the service log.
HCS parses each line of the configuration attribute. It expects each argument in correct order. Each line must begin with the required keyword and its colon (:). A blank character is required between the keyword and its value. If a value contains a blank character, enclose the value in quotation marks.
If HCS encounters any argument out of order, or without the required keyword, colon, or blank space, HCS considers the entire table invalid.
HCS writes a warning message to the service log for each line of the table that it considers in error. For example, if you omit a parameter, HCS writes a warning message indicating the missing parameter. Then, it continues parsing through the invalid table, searching for the TABLE: keyword of the next table. As it encounters each remaining argument of the invalid table, it writes a warning message to the service log, indicating that each line contains an invalid TABLE: parameter.
HCS uses the TABLE: keyword to identify when a new table definition begins. If you omit this keyword, colon, or blank space, HCS continues parsing for OID arguments for the previous table. As it encounters the OID arguments of the invalid table, it adds them to the definition of the previous table.
HCS expects a maximum of 10 OID arguments per table, each on its own line. If HCS encounters more than 10 OID arguments, it accepts the first 10 and ignores the others. If HCS encounters more than 1 OID argument per line, it accepts the first one and ignores any others on the line.
HCS assumes that each OID argument is a valid object identifier and is supported by the target entity. If a table contains an invalid object identifier, HCS writes a warning message to the service log each time it attempts to sample the OID.
HCS expects a maximum of 15 user-defined tables. If HCS encounters more than 15 tables, it accepts the first 15 and ignores any additional ones. It writes a warning message to the log indicating that the maximum was reached. The warning message lists the last valid table accepted.
Example 1 HCS service's default table
If specified by the DEFAULT: value argument, the HCS service maintains a default table named hcsdef. This default table cannot be modified or overwritten. The HCS service ignores any other table with the name hcsdef.
To instruct HCS to collect data for hcsdef, enter the following parameter as the first line in the attribute file:
getdefault: on
The settings in hcsdef are as follows:
table: hcsdef
k: 7
s: 15
c: public
a: local
o: 1.3.6.1.4.1.130.1.3.1.22.6.1.0
o: 1.3.6.1.4.1.130.1.3.1.22.6.4.0
The table is defined as follows:
The TABLE is hcsdef.
KeepTime is set to 7. The HCS service stores data for 7 days.
SampleTime is set to 15. The HCS service samples the target entity every 15 minutes.
The CommunityString is public.
Address is set to local. The HCS service collects data locally from a service. The Transport argument is omitted since the target entity is local.
The HCS service collects the two MIB objects from the Security Service MIB. The data it collects is the total number of users currently logged in (vsTotalActiveUsers) and the total number of active sessions (vsTotalActiveSessions).
Example 2 Table Targeting a Remote Entity
This table targets a remote entity.
The settings in the table are as follows:
getdefault: on
table: evs1
k: 1
s: 15
c: public
a: t 131.100.22.21
o: 1.3.6.1.4.1.130.1.3.1.1.5.7.0
The GETDEFAULT is on, instructing HCS to collect data for the default table hcsdef.
The table is defined as follows:
The TABLE is evs1.
KeepTime is set to 1. The HCS service stores data for 1 day.
SampleTime is set to 15. The HCS service samples the target entity every 15 minutes.
The CommunityString is public.
The Transport argument is set to T, instructing HCS to make SNMP request over TCP/IP. Address is set to the IP address where the target entity resides.
The HCS service collects the MIB object from the EVS MIB. The data it collects is the average number of events processed by EVS over the past five minutes (evsEventsRate).
Example 3 Tables Targeting Multiple Banyan Services on a Server
These tables target two print services that reside locally on a server.
The settings in the tables are as follows:
tablename: print1
k: 5
s: 60
c: public@"print 1@sales@WCTUS"
a: v serverx
o: 1.3.6.1.4.1.130.1.3.1.7.6.5.0
o: 1.3.6.1.4.1.130.1.3.1.7.6.6.0
tablename: print2
k: 5
s: 60
c: public@"print 2@sales@WCTUS"
a: v serverx
o: 1.3.6.1.4.1.130.1.3.1.7.6.5.0
o: 1.3.6.1.4.1.130.1.3.1.7.6.6.0
The tables are defined as follows:
Table 1
The TABLE is print1.
KeepTime is set to 5. The HCS service stores data for 5 days.
SampleTime is set to 60. The HCS service samples the target entity every 60 minutes.
The CommunityString is public. The StreetTalk name of the print service, print 1@sales@WCTUS, is appended to the CommunityString argument. The HCS service collects data from this particular print service.
The Transport argument is set to V, instructing HCS to make SNMP request over VINES IP. Address is set to the name of the server on which the target entity resides. The HCS service collects data from this particular print service on serverx.
The HCS service collects the two MIB objects from the Print Service MIB. The data it collects is the total number of print jobs waiting to be printed (psTotalPending) and the total number of print jobs spooling to the service (psTotalSpooling).
Table 2
The TABLE is print2.
KeepTime is set to 5. The HCS service stores data for 5 days.
SampleTime is set to 60. The HCS service samples the target entity every 60 minutes.
The CommunityString is public. The StreetTalk name of the print service, print 2@sales@WCTUS, is appended to the CommunityString argument. The HCS service collects data from this particular print service.
The Transport argument is set to V, instructing HCS to make SNMP request over VINES IP. Address is set to the name of the server on which the target entity resides. The HCS service collects data from this particular print service on serverx.
The HCS service collects the two MIB objects from the Print Service MIB. The data it collects is the total number of print jobs waiting to be printed (psTotalPending) and the total number of print jobs spooling to the service (psTotalSpooling).
Example 4 Table Targeting MIB II variables
This table targets MIB II variables.
The settings in the table are as follows:
table: ipstat
k: 1
s: 15
c: public
a: t 131.100.10.111
o: 1.3.6.1.2.1.4.3.0
o: 1.3.6.1.2.1.4.10.0
The table is defined as follows:
The TABLE is ipstat.
KeepTime is set to 1. The HCS service stores data for 1 day.
SampleTime is set to 15. The HCS service samples the target entity every 15 minutes.
The CommunityString is public.
The Transport argument is set to T, instructing HCS to make SNMP request over TCP/IP. Address is set to the IP address where the target entity resides.
The HCS service collects the MIB objects from MIB II. The data it collects is the total number of input datagrams received from interfaces (ipInReceives) and the total number of IP datagrams supplied to IP in requests for transmission (ipOutRequests).
To retrieve data from an HCS history database, you use an application that issues HCS Application Programming Interface (API) functions. These functions submit requests to the HCS service:
![]()
VnsRetrieveHistory - Retrieves a table of data from an HCS service for a specified time period. ![]()
VnsRetrieveTableList - Retrieves a list of tables currently configured in an HCS service's configuration database.
For a complete description of each function, refer to the Banyan Applications Toolkit.
HCS consumes disk space to store its configuration database and the history database. The amount of disk space consumed increases with the number of tables and the amount of data they contain. Each database sample (OID) uses approximately 200 to 250 bytes of disk space.
To estimate how much disk space a particular table uses over its storage time period, multiply the following values:
Number of samples in the table (OIDs)
225 bytes per database sample
KeepTime value, in days
1440 minutes per day
Divide the product of these values by the SampleTime, in minutes. The result is an approximation of the disk space, in bytes, consumed by the table over its storage period.
Example Estimating Disk Usage of HCS's default table
If specified by the DEFAULT: value argument, the HCS service maintains a default table named hcsdef. The values used to estimate disk usage of hcsdef are as follows:
Number of OIDs in the table = 2
225 bytes per database sample
KeepTime value = 7 days
1440 minutes per day
SampleTime value = 15 minutes
To estimate the disk space consumed by the table during its 7-day storage period, perform the following calculation:
(2 samples * 225 bytes/sample * 7 days * 1440 min/day) / 15 min
The result, 302400 bytes, is an approximation of the disk space consumed by the table over its 7-day storage period.
Disk space usage can be monitored and configured through the HCS MIB. The next section describes the MIB objects used to configure HCS.
Configuring HCS Through the HCS MIB
You can configure HCS through the HCS MIB. Specifically, you can perform the following tasks:
![]()
Configure disk space usage of the HCS databases ![]()
Retrieve HCS statistics
The HCS MIB contains several objects that manage the combined disk space usage of the HCS configuration database and the history database. Two objects manage the size of the database files: hcsDBThres sets a threshold disk usage size, hcsDBMaxDiskSize sets a maximum disk usage size. Both objects specify the size in bytes. HCS checks the size of the HCS configuration database and the history database every 30 minutes. If the combined disk usage reaches the threshold size, HCS sends a event to the EVS service. If the disk usage reaches the maximum size, HCS stops writing to the history database and sends a real-time notification.
Note: You must configure filters through EVS to receive notification that the threshold and maximum disk usage sizes have been reached.
The system default values of hcsDBThres and hcsDBMaxDiskSize are 4608000 and 5120000 bytes, respectively. You can set these objects to any other values, as long as the threshold database size does not exceed the maximum database size. The values of hcsDBThres and hcsDBMaxDiskSizeIf are stored by the HCS service. If you stop and start the HCS service, these objects are set to the last configured values.
HCS maintains administrative statistics. You can use these statistics to monitor server disk usage. The object hcsCurrDiskSize measures the current disk space usage of the HCS configuration database and the history database.
The object hcsDefaultFileFlag indicates whether collection of the default table hcsdef has been turned on or off.
For details on the objects available from HCS, refer to the HCS MIB.
Determining EVS Service Configuration Settings
The EVS service stores all events in a local database and processes the events according to filters. Filters can be configured either by:
![]()
SNMP management applications ![]()
System administrators
Filters allow SNMP management applications or system administrators to select the events they considered relevant. For example, an accounting application interested in events related to measurable accountable objects, such as how much CPU or disk space a user or system consumes, can configure a filter for that information. Or, a system administrator interested in all events from a particular server can configure an appropriate filter. Only the events that match the filter criteria will be forwarded to the management application or the system administrator.
The method system administrators use to configure filters is to store the filter either in EVS service configuration settings or in a StreetTalk attribute. This feature allows you to specify limited filter criteria without requiring an SNMP management application to do so. You specify what events to report and what action to take. For example, you can be notified of an event by a network message or a mail message. For an action to be taken, values in an event must match those specified in the filter.
In addition to configuring filters, you can limit the events sent to EVS for processing by specifying an event mask at the individual service level. When a service initiates an event, it uses the mask to determine whether to send the event to EVS. For more information on how to specify event masks, refer to the Server Operations Guide.
The section, "Configuring the Services," in Chapter 3 describes how to configure filters using EVS service configuration settings and using the StreetTalk attribute.
EVS can also be configured through the EVS MIB. For example, the event database is managed solely through the EVS MIB. Refer to "Configuring EVS Through the EVS MIB" later in this section for a description of the MIB objects used to configure EVS.
The next section describes the filter attribute for EVS.
The EVS filter attribute defines the specific events to take action on and what action to take. The vendor attribute pair of this attribute is <1:700>.
Syntax
Specify the events to process using the following syntax:
EVID: EventID
EVSVC: Service-name
EVTYPE: EventType
Specify an action to take on the events using the following syntax:
ACTION: BLEEP Recipient Language
ACTION: MAIL Recipient Language
ACTION: TRAPV1_IP CommunityString Address
ACTION: TRAPV1_VIP CommunityString Port
ACTION: TRAPV2 PartyOID
Each line must begin with the required keyword (EVSVC:, ACTION:, and so on). A blank character is required between the keyword and its value.
Events
Specify one or more events to process. To specify a particular event, use the EVID: argument. To specify events from a particular service, use the EVSVC: argument. To specify events of one type, use the EVTYPE: argument. You can use EVSVC: in conjunction with EVTYPE: to specify a particular event type from a service. To do so, enter both arguments on the same line (see "Example 2" later in this section).
EVID: EventID
EVID: EventID specifies the unique ID of the event you want processed. Use this argument to specify a particular event.
The unique ID for an event can be obtained from a MIB description or help file. Refer to Appendix B for a description of events. The EVID: keyword is not case-sensitive.
EVSVC: Service-name
EVSVC: Service-name specifies the StreetTalk name of the service generating the events you want processed.
Specify only one Service-name argument value. The EVSVC: keyword and the value for the Service-name argument are not case-sensitive. If the service name contains a blank character, enclose the name in quotation marks.
EVTYPE: processed.
EVTYPE: EventType specifies the types of the events you want EventType Valid values for the EventType argument are as follows:
![]()
alarm - Processes alarm events. An alarm is an event that needs immediate attention, such as a service shutting down due to errors, a communication problem such as a lost session or failure to communicate with another service, or other critical problem. ![]()
warning - Processes warning events. A warning is an event that conveys information about service performance or function, such as a threshold level being reached, or a recoverable error with a service. ![]()
audit - Processes audit events. An audit event is an event that indicates security or accounting information, such as a login or logout, or a session with a service becoming active.
Specify only one EventType argument value.
The EVTYPE: keyword and the values for the EventType argument are not case-sensitive.
Action
Specify the action to take on the specified events. Each filter can specify only one action. If you need multiple actions to be taken, set up more than one filter, each specifying the same events and a single action.
ACTION: BLEEP Language
ACTION: BLEEP Recipient Language sends a network message to a user about the event. The Recipient argument specifies the person or group of people to receive the message. Valid values for this argument are:
![]()
StreetTalk name of a user or a list. If you specify a list, it cannot contain any other lists. ![]()
StreetTalk pattern, such as *@MIS@WTCUS. The pattern cannot contain other patterns.
If the StreetTalk name or pattern contains a blank character, enclose the name in quotation marks.
The Language argument specifies the language of the message. For example, the value USA sends the message in English. Use this argument to select a specific language in a multilingual network.
The ACTION keyword and the BLEEP argument are not case-sensitive. The values for the Recipient and Language arguments are not case-sensitive.
ACTION: MAIL Recipient Language
ACTION: MAIL Recipient Language sends a mail message to a user about the event. The Recipient argument specifies the person or group of people to receive the mail message. Valid values for this argument are:
![]()
StreetTalk name of a user or a list. If you specify a list, it cannot contain any other lists. ![]()
StreetTalk pattern, such as *@MIS@WTCUS. The pattern cannot contain other patterns.
If the StreetTalk name or pattern contains a blank character, enclose the name in quotation marks.
The Language argument specifies the language of the message. For example, the value USA sends an English message. Use this argument to select a specific language in a multilingual network.
The ACTION keyword and the MAIL argument are not case-sensitive. The values for the Recipient and Language arguments are not case-sensitive.
ACTION: TRAPV1_IP CommunityString Address
ACTION: TRAPV1_IP CommunityString Address sends an SNMPv1 trap over TCP/IP. The CommunityString argument specifies the community name to which the target entity belongs. The Address argument specifies the transport address to which to send the trap. The address is an IP address in dot notation.
The ACTION keyword and the TRAPV1_IP argument are not case-sensitive. The value for the CommunityString argument is case-sensitive.
ACTION: TRAPV1_VIP CommunityString Port
ACTION: TRAPV1_VIP CommunityString Address sends an SNMPv1 trap over VINES IP. The CommunityString argument specifies the community name to be included in the trap protocol data unit (PDU). For SNMPv1, this community name is customarily public. The Port argument specifies the management application's IPC port. The Port argument is an ASCII representation of the port. Because of the dynamic nature of VINES IP, the ASCII representation of the port should be obtained programmatically. This argument is primarily for use by application developers.
The ACTION: keyword and the TRAPV1_VIP argument are not case-sensitive. The value for the CommunityString argument is case-sensitive.
ACTION: TRAPV2
ACTION: TRAPV2 PartyOID sends an SNMPv2 trap over TCP/IP. The PartyOID argument identifies the SNMPv2 party that is the target entity. The OID is in ASN.1 format.
The PartyOID argument must identify an existing SNMPv2 party. The actual address and port that define where to send that trap are configured in the party table for the party. Refer to "Party Table Attribute" in Appendix A for more information.
The ACTION: keyword and the TRAPV2 argument are not case-sensitive.
Example 1 Filter for a Particular Event
This filter specifies the unique ID of the single event to be processed. The filter specifies that EVS send a network message regarding the event to the specified user, and that the message be in English.
The settings in filter attribute are as follows:
evid: 1.24t
action: bleep "Pat Stone@MIS@WTCUK" usa
Example 2 Filter for All Auditing Events for a Service
This filter specifies that EVS process all the auditing events generated by the mail service ms@server8@servers. The filter specifies that EVS send an SNMPv1 trap for each of these events. The traps are sent to the IP address 131.100.105.8 in the community public.
The settings in filter attribute are as follows:
evtype: audit evsvc: ms@server8@servers
action: trapv1_ip public 131.100.105.8
Example 3 Filter for All Events for a Server
This filter specifies that EVS process all events for a server. The filter specifies that EVS send a mail message regarding each event to the specified user, and that the message be in English.
The settings in filter attribute are as follows:
evtype: alarm
action: mail "Ed Monsoon@MIS@WTCUK" usa
evtype: warning
action: mail "Ed Monsoon@MIS@WTCUK" usa
evtype: audit
action: mail "Ed Monsoon@MIS@WTCUK" usa
Each event received by EVS contains the following common information:
![]()
Event ID - A unique identifier for the event. ![]()
Service-name - The StreetTalk name of the service that generated the event. ![]()
Time stamp - The date and time at which the event occurred. ![]()
Event type - The type of information that the event represents. Events are classified as either alarm, warning, audit, information, or debug events. However, the only event types sent to EVS are alarm, warning, and audit events. ![]()
Server name - The name of the server that generated the event.
To retrieve data from an EVS event database, you use an application that issues the EVS Application Programming Interface (API) VnsRetrieveEvents function. This function submits a request to the EVS service to retrieve events stored in the database that correspond to a configured filter.
For a complete description of the VnsRetrieveEvents function, refer to the Banyan Applications Toolkit.
Configuring EVS Through the EVS MIB
You can configure EVS through the EVS MIB. Specifically, you can perform the following tasks:
![]()
Set up filters to receive real-time notification of events ![]()
Configure the event database ![]()
Retrieve EVS statistics
Refer to "EVS Filter Attribute" earlier in this section for a detailed description of the syntax used to configure filters.
The EVS MIB contains several objects that manage the event database files. The object evsDataBaseLoc specifies where to store the EVS event database. By default, the event database is stored on disk1. To maximize performance on a server that has multiple disks, use evsDataBaseLoc to specify a server disk that is used less often than disk1. The change takes affect when EVS rolls over the database files the following day.
EVS maintains a database file for each data of the week. The object evsDBSaved specifies how long, in days, to store each day's event file. Two objects manage the size of the event files: evsDBThres sets a threshold file size, evsDBMaxSize sets a maximum file size. EVS checks the size of the current day's event file every 5 minutes. If the event file reaches the threshold size, EVS sends a real-time notification. If the event file reaches the maximum size, EVS stops writing to the database and sends a real-time notification.
Note: You must configure filters to receive notification that the threshold and maximum file sizes have been reached.
The object evsRemoveTodaysFile purges the current day's event file. This object is useful when the event file reaches the maximum size. If you set this object, all the current day's events are lost.
The object evsRemoveAllDBFiles purges all stored database files, including the current day's event file. This object is useful when you need to clear disk space or want to start new analysis without history data. If you set this object, all event history data is lost.
For details on these and other objects used to configure the event database, refer to the EVS MIB.
EVS maintains administrative statistics. You can use these statistics to monitor server activity. The object evsEventsProcessed represents the number of events received by EVS. The object evsTrapsGenerated represents the number of traps generated by EVS. For details on these and other statistics available from EVS, refer to the EVS MIB.
Once you have planned the Server Agent architecture, you need to install the DeMarc Server Agent option. See Chapter 2 for more information on installing the DeMarc Server Agent option.