Administration Console Online Help

SNMP Agents

You can use Simple Network Management Protocol (SNMP) to monitor a
WebLogic Server domain. This page summarizes the SNMP agents that have
been configured for the current WebLogic Server domain.

With SNMP, you configure agents to gather and send data about
managed resources in response to a request from managers. You can
also configure agents to issue unsolicited reports to managers when they
detect predefined thresholds or conditions on a managed resource.

In a WebLogic Server domain, you can choose a centralized or
de-centralized model for SNMP monitoring and communication:

In a centralized model, you configure an SNMP agent only on the
Administration Server. This agent communicates with all Managed Servers
in the domain. Your SNMP manager communicates only with the SNMP agent
on the Administration Server. This model is convenient but introduces
performance overhead in WebLogic Server. In addition, if the
Administration Server is unavailable, you cannot monitor the domain
through SNMP.

In a de-centralized model, you configure SNMP agents on each Managed
Server. Your SNMP manager must communicate with the agents on individual
Managed Servers.

To support domains that were created with WebLogic Server release 9.2
and earlier, you can enable and use the domain-scoped SNMP agent instead
of configuring SNMP agents on the Administration Server or Managed Servers
(server SNMP agents). The domain-scoped agent offers the same features as
the server SNMP agent in the centralized model described above. However,
its underlying implementation is different and it will eventually be
deprecated. The domain-scoped agent is overridden if you target a server
SNMP agent to the Administration Server.

The SNMP agent generates automatic notifications when any of the
following events occur:

The WebLogic Server instance that is hosting the SNMP agent
starts.

This type of notification (coldStart) has no variable
bindings.

A server instance starts or stops.

An SNMP agent on a Managed Server generates these notifications
only when its host Managed Server starts or stops. An SNMP agent on
an Administration Server generates these notifications when any
server in the domain starts or stops.

These notification types (serverStart and serverShutdown)
contain variable bindings to identify the server that started or
stopped and the time at which the notification was generated.

The port on which you want this SNMP agent to listen for
incoming requests from SNMP managers that use the UDP protocol.

SNMP managers can use this port to ping the SNMP agent and
request the status of specific attributes.

If you target this SNMP agent to multiple server instances, and
if two or more servers are running on the same computer, WebLogic
Server will automatically increment this UDP port value by 1 for
each agent. WebLogic Server never assigns port 162 because it is
the default port that an agent uses to send notifications. In
addition, if any port is already in use, WebLogic Server skips the
port and assigns the next available port.

For example, if you use the default value of this attribute and
then target this agent to ManagedServer1 and ManagedServer2, and if
both servers are running on the same computer, then the agent on
ManagedServer1 will listen on UDP port 161 and the agent on
ManagedServer2 will listen on UDP port 163.

The incremented port number is not persisted in the domain's
configuration; when WebLogic Server increments port numbers, it
does so in the order in which servers are started on the same
computer.

If WebLogic Server re-assigns the UDP port for an SNMP agent,
look in the agent's SNMPAgentRuntimeMBean to see the agent's
runtime UDP port.

SNMP agents can also communicate through the host server's TCP
listen port (7001 by default) or through a TCP port that is
configured by a custom network channel.

The password (community name) that you want this SNMP agent to
use to secure SNMPv1 or v2 communication with SNMP managers.
Requires you to enable community based access for this agent.

SNMPv3 does not use community names. Instead, it encrypts user
names and passwords in its PDUs.

When you use SNMPv1 or v2, there are two community names that
are needed when the WebLogic SNMP agent and SNMP managers
interact:

The name that you specify in this community prefix. All SNMP
managers must send this name when connecting to this SNMP
agent.

The community name that the SNMP manager defines. The SNMP agent
must send this name when connecting to the manager. (You supply
this community name when you configure a trap destination.)

In addition to using the community prefix as a password, an SNMP
agent on an Administration Server uses the prefix to qualify
requests from SNMP managers. Because the Administration Server can
access data for all WebLogic Server instances in a domain, a
request that specifies only an attribute name is potentially
ambiguous. For example, the attribute serverUptime
exists for each WebLogic Server instance in a domain. To clarify
requests that you send to SNMP agents on Administration Servers,
use the community prefix as follows:

To request the value of an attribute on a specific Managed
Server, when you send a request from an SNMP manager, append the
name of the server instance to the community prefix:
community_prefix@server_name.

To request the value of an attribute for all server instances in
a domain, send a community name with the following form:
community_prefix

To secure access to the values of the WebLogic attributes when
using the SNMPv1 or v2 protocols, it is recommended that you set
community prefix to a value other than public.

You cannot specify a null (empty) value for the community
prefix. If you delete the prefix value, WebLogic Server resets the
value to public. If you do not want this agent to
receive SNMPv1 or v2 requests, instead of trying to set the
community prefix to a null value, disable community based access.
With community based access disabled, WebLogic Server ignores the
community prefix value.

The minimum severity of debug messages that this SNMP agent
generates.

The SNMP agent writes all debug messages to standard out; they
are not written to the WebLogic Server log files. Debug messages
provide a detailed description of the SNMP agent's actions. For
example, the agent outputs a noncritical message each time it
generates a notification.

SNMPv1 and v2 use community strings for authentication. If you
disable community strings for this SNMP agent, the agent will
process only SNMPv3 requests. If an SNMP manager sends a v1 or v2
message, the agent discards the message and returns an error code
to the manager.

The protocol that this SNMP agent uses to ensure that only
authorized users can request or receive information about your
WebLogic Server domain. Applicable only with SNMPv3.

The protocol also ensures message integrity and prevents
masquerading and reordered, delayed, or replayed messages.

To use this protocol when receiving requests from SNMP managers,
you must configure credential mapping in the WebLogic Server
security realm. To use this protocol when sending responses or
notifications, you must configure the security level of your trap
destinations.

If you do not choose an authentication protocol, then the SNMP
agent does not authenticate incoming SNMPv3 requests; anyone can
use SNMPv3 to retrieve information about your WebLogic Server
domain.

The number of milliseconds after which WebLogic Server
invalidates its cache of SNMP security keys. Setting a high value
creates a risk that users whose credentials have been removed can
still access SNMP data.

An SNMP security key is an encrypted version of an SNMP agent's
engine ID and an authentication password or privacy password.
WebLogic Server generates one security key for each entry that you
create in the SNMP credential map. When a WebLogic Server SNMP
agent receives an SNMPv3 request, it compares the key that is in
the request with its WebLogic Server keys. If it finds a match, it
processes the request. The SNMP agent also encodes these keys in
its responses and notifications. (You configure which keys are
encoded when you create a trap destination.)

Instead of regenerating the keys for each SNMPv3 communication,
WebLogic Server caches the keys. To make sure that the cache
contains the latest set of SNMP credentials, WebLogic Server
periodically invalidates the cache. After the cache is invalidated,
the next time an SNMP agent requests credentials, WebLogic Server
regenerates the cache.

Note that making a change to the credential map does not
automatically update the cache. Instead, the cache is updated only
after it has been invalidated.

For example, if you update a privacy password in an existing
entry in the SNMP credential map, the SNMP agent is not aware of
the new password until the key cache is invalidated and
regenerated. An SNMP user with the old security password can still
access WebLogic Server data until the cache is invalidated.

You can invalidate a key immediately instead of waiting for this
invalidation interval to expire.