os_mon(7) [linux man page]

os_mon(7)						   Erlang Application Definition						 os_mon(7)

NAME

       os_mon - OS Monitoring Application

DESCRIPTION

       The operating system monitor, OS_Mon, provides the following services:

	 * cpu_sup CPU load and utilization supervision (Unix)

	 * disksup Disk supervision(Unix, Windows)

	 * memsup Memory supervision (Unix, Windows, VxWorks)

	 * os_sup Interface to OS system messages (Solaris, Windows)

       To  simplify usage of OS_Mon on distributed Erlang systems, it is not considered an error trying to use a service at a node where it is not
       available (either because OS_Mon is not running, or because the service is not available for  that  OS,	or  because  the  service  is  not
       started).  Instead, a warning message is issued via error_logger and a dummy value is returned, which one is specified in the man pages for
       the respective services.

CONFIGURATION

       When OS_Mon is started, by default all services available for the OS, except os_sup , are automatically started. This configuration can	be
       changed using the following application configuration parameters:

	 start_cpu_sup = bool() :
	   Specifies if cpu_sup should be started. Defaults to true .

	 start_disksup = bool() :
	   Specifies if disksup should be started. Defaults to true .

	 start_memsup = bool() :
	   Specifies if memsup should be started. Defaults to true .

	 start_os_sup = bool() :
	   Specifies if os_sup should be started. Defaults to false .

       Configuration parameters effecting the different OS_Mon services are described in the respective man pages.

       See config(5) for information about how to change the value of configuration parameters.

SNMP MIBS

       The following MIBs are defined in OS_Mon:

	 OTP-OS-MON-MIB :
	   This MIB contains objects for instrumentation of disk, memory and CPU usage of the nodes in the system.

       The  MIB  is  stored  in  the  mibs directory. It is defined in SNMPv2 SMI syntax. An SNMPv1 version of the MIB is delivered in the mibs/v1
       directory.

       The compiled MIB is located under priv/mibs , and the generated .hrl file under the include directory. To compile a MIB	that  IMPORTS  the
       OTP-OS-MON-MIB , give the option {il, ["os_mon/priv/mibs"]} to the MIB compiler.

       If  the MIB should be used in a system, it should be loaded into an agent with a call to os_mon_mib:load(Agent) , where Agent is the pid or
       registered name of an SNMP agent. Use os_mon_mib:unload(Agent) to unload the MIB. The implementation of this MIB uses  Mnesia  to  store  a
       cache with data needed, which implicates that Mnesia must be up and running. The MIB also use functions defined for the OTP-MIB , thus that
       MIB must be loaded as well.

SEE ALSO

       cpu_sup(3erl) , disksup(3erl) , memsup(3erl) , os_sup(3erl) , nteventlog(3erl) , snmp(3erl) .

Ericsson AB							   os_mon 2.2.5 							 os_mon(7)

Check Out this Related Man Page

nteventlog(3erl)					     Erlang Module Definition						  nteventlog(3erl)

NAME

       nteventlog - Interface to Windows Event Log

DESCRIPTION

       nteventlog  provides a generic interface to the Windows event log. It is part of the OS_Mon application, see os_mon(7) . Available for Win-
       dows versions where the event log is available. That is, not for Windows 98 and some other older Windows  versions,  but  for  most  (all?)
       newer Windows versions.

       This module is used as the Windows backend for os_sup , see os_sup(3erl) .

       To  retain  backwards  compatibility, this module can also be used to start a standalone nteventlog process which is not part of the OS_Mon
       supervision tree. When starting such a process, the user has to supply an identifier as well as a callback function to handle the messages.

       The identifier, an arbitrary string, should be reused whenever the same application (or node) wants to start  the  process.  nteventlog	is
       informed about all events that have arrived to the eventlog since the last accepted message for the current identifier. As long as the same
       identifier is used, the same eventlog record will not be sent to nteventlog more than once (with the exception of when graved system  fail-
       ures arise, in which case the last records written before the failure may be sent to Erlang again after reboot).

       If  the event log is configured to wrap around automatically, records that have arrived to the log and been overwritten when nteventlog was
       not running are lost. It however detects this state and loses no records that are not overwritten.

       The callback function works as described in os_sup(3erl) .

EXPORTS

       start(Identifier, MFA) -> Result
       start_link(Identifier, MFA) -> Result

	      Types  Identifier = string() | atom()
		     MFA = {Mod, Func, Args}
		     Mod = Func = atom()
		     Args = [term()]
		     Result = {ok, Pid} | {error, {already_started, Pid}}
		     Pid = pid()

	      This function starts the standalone nteventlog process and, if start_link/2 is used, links to it.

	      Identifier is an identifier as described above.

	      MFA is the supplied callback function. When nteventlog receives information about a new event,  this  function  will  be	called	as
	      apply(Mod, Func, [Event|Args]) where Event is a tuple

       stop() -> stopped

	      Types  Result = stopped

	      Stops nteventlog . Usually only used during development. The server does not have to be shut down gracefully to maintain its state.

SEE ALSO

       os_mon(7) , os_sup(3erl)

       Windows NT documentation

Ericsson AB							   os_mon 2.2.5 						  nteventlog(3erl)

Linux and UNIX Man Pages

os_mon(7) [linux man page]

Check Out this Related Man Page