Skip to content
CA Unified Infrastructure Management Probes
Documentation powered by DocOps

The nas Setup Tab v4.7

Last update June 6, 2016

The Setup tab allows you to configure various elements of the Alarm Server, such as what suppression methods should be used, what to add to the transaction log, forwarding and replication and so on. This section will discuss these elements in detail.

Contents

The General Tab

This tab allows you to set various general parameters such as how detailed the nas should log progress in its log-file.

The fields are:

  • Log-file
    The name of the nas logfile can be changed to the name specified. Before this new logfile name will change the probe must be restarted manually.
  • Log-level
    Sets the level of details written to the log-file. Log as little as possible during normal operation to minimize disk consumption, and increase the amount of detail when debugging.
  • Publish alarm updates every n duplicate messages
    This option specifies how often duplicate NAS events (as subscribed by consoles/gateways) are published.
    A message is considered duplicate when message text, subsystem id and severity are equal to the previous message with the same suppression key. This will reduce the events received by the consoles.
    Example: If you set this parameter to 10, the message count for suppressed messages will be updated after 10 occurrences of the same message.
  • Activate support internationalization
    Supports the internationalized alarms published by probes.
  • Storm Protection
    You can enable storm protection on the NAS. This allows you to choose between Suppression-id, Robot, or Probe as the source of your message filter.

Note: Selecting Suppresstion-id, Robot, or Probe does not limit the suppression key to the defined value. The defined value will change the key "signature" elements to one of the following:

  • Suppression-id - source, domain, robot, probe-id and supp_key
  • Probe - source, domain, robot, probe-id
  • Robot - source, domain, robot
  • Storm Subject
    The subject of the storm alarm message. The default is NAS_QUARANTINE.
  • Storm Threshold
    The number of alarms allowed before the alarms become a message storm.
  • Storm Period
    The length of time monitored for number of alarms for storm threshold. Example: 1000 alarms in 5 minutes.
  • Storm Capacity
    The size of the "quarantine list" of alarms.

The Transaction Log Tab

The NAS probe is capable of logging all transactions to a specific transaction log file. This allows you to follow the complete message life cycle from the initial message to when the message is closed (acknowledged). The transaction log file is automatically compressed at the configured administration interval.

  • Activate transaction-logging
    If this checkmark is set, the NAS logs all steps in the life of an alarm (the alarm transaction) from the alarm is generated until it is acknowledged.
    The data is stored in the NAS database transactionlog.db, located in Program Files/Nimsoft/Probes/service/nas
  • Transaction Log Management
    • Administration interval
      The interval at which the NAS monitors the size of the transaction log files and truncates them.Valid options are:
      • Every hour
      • Every 2 hours
      • Every 6 hours
      • Every 12 hours
      • Daily
    • Compress transactions after
      The events (of type suppression) for alarms stored in the transaction log will be deleted after the number of days specified. Default is 7 days.
    • Keep transaction history
      Specifies how long (in days) the transaction history is stored. The transaction history stores all events for each of the alarms handled by the NAS in the database.
    • Keep transaction summary
      Specifies how long (in days) the transaction summary is stored. The default value is 30 days.
      The transaction summary for each alarm is stored as one row in the database.
    • Log transaction details
      Specifies how often duplicate NAS events are stored in the event transaction log.
      A message is considered duplicate when message text, subsystem id and severity are equal to the previous message with the same suppression key. This will reduce the size of the transaction-log and speed up transaction-log queries.
      If the Log transaction details option is not checked, this log will be empty.
    • Log alarm updates every n duplicate messages
      Enter the number of duplicate messages required before updating the log alarm.
  • Activate network transaction-logging

    Instructs the NAS to publish its transaction-log records onto the network so it can be inserted into a database using the ADO/ODBC gateway.

    Note: This option requires the adogtw probe to be installed and configured.

Configure Network Transaction Logging

Selecting Activate Network transaction logging allows you to store transaction log records in a commercial database other than the NiS. However, before network transaction logging is fully implemented you must also do the following:

  • Create an AlarmTransactionLog table in your target database.
  • Deploy and configure the ADO Gateway probe.

Add the AlarmTransactionLog Table to the Target Database

Create the AlarmTransactionLog table in the your target database using one of the following SQL CREATE TABLE statements:

  • SQL Server

CREATE TABLE [dbo].[AlarmTransactionLog] (

[TypeId] [int] NULL ,

[TypeDesc] [char] (10) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,

[Created] [datetime] NULL ,

[Processed] [datetime] NULL ,

[Hostname] [char] (64) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,

[Source] [char] (64) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,

[AlarmId] [char] (24) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,

[AlarmSeverity] [int] NULL ,

[AlarmSeverityDesc] [char] (16) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,

[AlarmSid] [char] (48) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,

[AlarmSubsystem] [char] (64) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,

[AlarmMessage] [varchar] (512) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,

[TypeData1] [char] (64) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,

[TypeData2] [char] (64) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,

[TypeData3] [char] (64) COLLATE SQL_Latin1_General_CP1_CI_AS NULL

) ON [PRIMARY]

GO

  • Oracle

CREATE TABLE ALARMTRANSACTIONLOG

(

  TYPEID             NUMBER(10),

  TYPEDESC           VARCHAR2(10),

  CREATED            VARCHAR2(50),

  PROCESSED          VARCHAR2(50),

  HOSTNAME           VARCHAR2(64),

  SOURCE             VARCHAR2(64),

  ALARMID            VARCHAR2(24),

  ALARMSEVERITY      NUMBER(10),

  ALARMSEVERITYDESC  VARCHAR2(16),

  ALARMSID           VARCHAR2(48),

  ALARMSUBSYSTEM     VARCHAR2(64),

  ALARMMESSAGE       VARCHAR2(512),

  TYPEDATA1          VARCHAR2(64),

  TYPEDATA2          VARCHAR2(64),

  TYPEDATA3          VARCHAR2(64)

)

  • MySQL

CREATE TABLE AlarmTransactionLog 

(TypeId int NULL ,

TypeDesc char (10)  NULL ,

Created datetime NULL ,

Processed datetime NULL ,

Hostname char (64)  NULL ,

Source char (64)  NULL ,

AlarmId char (24)  NOT NULL ,

AlarmSeverity int NULL ,

AlarmSeverityDesc char (16)  NULL ,

AlarmSid char (48)  NULL ,

AlarmSubsystem char (64) NULL ,

AlarmMessage varchar (512)  NULL ,

TypeData1 char (64)  NULL ,

TypeData2 char (64)  NULL ,

TypeData3 char (64) NULL

);

Configure the ADO Database Gateway Probe

The ADO Database Gateway (ADOGTW) probe must be deployed and configured to insert data into the AlarmTransactionLog table.

Follow these steps:

  1. In the ADOGTW GUI Connections tab, right click and select new.
  2. Enter a connection name and click ok.
    The New Connection window opens.
  3. Enter the connection parameters for your database.
  4. In the Profile tab, right click and select new.
  5. Enter a profile, select Subscribe.
    The New Publisher window opens.
  6. Click the General tab and select the connection that you created.
  7. Click the Subscribe tab and select Subject as nas_transaction and Table as AlarmTransactionLog.
  8. Activate and save the profile.

The Message Suppression Tab

Message suppression is a feature used to avoid storing multiple alarms caused by the same problem. Alarms with the same source, message, subsystem and severity information will be suppressed into a single message with only a counter indicating the number of occurrences.

The NAS supports two different message suppression models:

  • A model suppressing messages with an exact match on message subsystem id, severity level and message text (standard suppression).
  • A model based on a suppression key following the message (note that the following terms may be used, all meaning the same: suppression key, suppression ID and checkpoint ID).

Sometimes an administrator may choose to ignore the suppression mechanism based on suppression key if they want to view the messages as the probes report them. When the key suppression is enabled, messages with matching suppression key will be suppressed. This means that the following two messages from the same probe are equal:

Filesystem '/usr' is filled 95% (suppkey: FsProbe-/usr)
Filesystem '/usr' is filled 55% (suppkey: FsProbe-/usr)

The result of this would be one message in the alarm server database, but it would have recorded both of them as valid transactions (and therefore logged them in the transaction log). So if the sequence were as displayed (95% first, then 55% as the last status) then the administrator would experience the state as a file-system with 55% filling grade (which is the correct way to see things).

The fields are:

  • Activate message suppression
    When this option is selected, the messages suppression features are activated in order to avoid multiple instances of the same alarm-event.
  • Accept suppression-id in message
    If this checkmark is set, the NAS decides whether a message has occurred before from an internal ID (the suppression key).
    If not, the entire alarm text must be absolutely identical for the messages to be considered identical by the suppression mechanism.
  • Accept automatic ‘acknowledgement’ of alarm
    If this checkmark is set, an alarm with level "clear" will acknowledge and delete all alarms based on the same suppression key.
  • Enable suppression based on core message content
    When this option is selected, alarms where the specified number of characters (e.g. 50) in the message is identical with a message that has occurred before will be suppressed. Note that numbers in the alarm messages does not count, only alpha characters are compared.
    This feature is for probes that do not send a suppression-id in the alarm messages, for example ntevl.
  • Reset suppression counter upon change of severity
    Resets the suppression counter when the severity of an alarm has changed.

A sid (subsystem identification number) used to categorize alarms sent along with the alarm message from the probes.

The NAS maps this number to a string when the alarm message is received.

  • <Subsystems list>
    A list of all subsystems defined to the nas. By right-clicking here, you may edit the list (add and delete).
  • Subsystem name
    A descriptive text name for the subsystem.
  • Subsystem id
    The number sequence, separated by dots, identifying the subsystem.
  • Full path
    The text sequence.

The figure shows that the NAS maps the subsystem identification number 1.1.1.1 to Nimsoft.Alarm.Host.Disk.

This allows for grouping information. The subsystem tab simplifies the management of the subsystem IDs, known to the nas. You may add and delete nodes to existing branches, or create new ones. The configuration tool tries to be smart in determining the actual value of the leaf-node, by incrementing the rightmost element. In addition to a context menu on the tree control, you may use the INS/DEL keys on the keyboard. The sid list is loaded during startup and restart.

The Forwarding and Replication Tab

You can define other alarm servers with which you want to exchange alarms and/or scripts. Right-clicking in the list lets you add, edit or delete such connections.

Checking the "Relay forwarded alarm events" option, alarms received from a remote NAS will be forwarded.

Note 1: When setting up forwarding and replication and making configuration changes on more than one nas, you should first open and edit the GUI for one nas, apply the changes and then exit the GUI. Then you should open and edit the GUI for the next nas, etc. Otherwise the settings may not be saved correctly.

Example: NAS B receives alarms from NAS A, and NAS B forwards alarms to NAS C:

The alarms NAS B receives from NAS A will be forwarded to NAS C only if the "Relay forwarded alarm events" option is set on NAS B.

Note 2: The Queue column in the window shows the current number of items (files, messages etc.) in the replication queue, waiting to be processed. The other columns are explained in the table below.

  • Destination Alarm Server
    Select the destination alarm server from this list.
    This is the alarm server with which you want to exchange alarms and/or scripts.
  • Forwarding
    Select the forwarding properties for the selected nas:
    • Disabled
      Disables the selected NAS replication/forwarding profile.
      Note: If you remove the forwarding configuration from the destination server and the sending nas is down, the sending nas will retain its forwarding configuration even after it is reactivated. It will continue to send import files, unnecessarily consuming resources on both alarm servers. You must manually remove the configuration from the sending nas.
    • All alarm events in both directions
      All alarm events will be sent to and received from the NAS selected as the destination alarm server.
    • All events to destination
      All alarm events will be sent to the NAS selected as destination alarm server.
    • As event responder
      Allows the NAS selected as destination alarm server to act as an event responder, close and assign alarm messages from the NAS forwarding the alarm messages.
      If setting up a queue as "All events to one direction" on NAS A, the queue will appear as "As event responder" on NAS B.
  • Replicate to destination
  • Scripts
    Select if you want to the scripts available on the NAS also be available for the destination NAS defined.
    • None means not available for the destination alarm server defined.
    • Private means that scripts will be available on the destination NAS defined, but it can not be modified there (no write access).
    • Shared means that scripts will be available on the destination NAS defined, in the same script structure as the source NAS, and it is possible to modify the script. Changes will be mirrored between the two NAS’s.
  • Configuration
    Select if you want to the configuration settings (profiles) available on the NAS also be available for the destination alarm server defined.
    None means not available for the destination alarm server defined.
    Private means that the NAS configuration file will be available on the destination NAS defined.
    The file will be located under the directory ..\Nimsoft\probes\service\nas\replication\config\<name of the replicated nas server>\nas.cfg
    If you want to use this configuration file on the destination server, you must paste it manually to ..\Nimsoft\probes\service\nas\nas.cfg.

The Advanced tab fields are:

  • Max. Transfer Blocksize (messages)
    This parameter sets the maximum number of messages transferred at each interval. You may select one of the values available, or preferably select automatic (default).
    The NAS will then attempt to use a blocksize of 10000 messages. If the NAS fails to send so many messages (after 10 attempts), the blocksize will automatically be divided by 10, and the NAS attempts to transfer 1000 messages. If still problems, the blocksize will again be divided by 10 (to 100). This continues until the NAS succeeds to send the current blocksize.
    Then the NAS uses this blocksize for 10 intervals, and then increments the blocksize with 100. If this works OK, the blocksize will again be incremented by 100 for the next 10 intervals. This continues until the highest possible blocksize is reached.
  • Timeout (seconds)
    The sending NAS transfers messages to receiving HUB(s) at regular intervals. This timeout defines the maximum number of seconds the sending NAS attempts to transfer messages to a receiving NAS before starting a new interval.
    If using Max. Transfer Blocksize = Automatic (see above), the blocksize will be reduced after 10 unsuccessful attempts.
Note 3: Sync issue when disabling and then enabling replication

Example:

  • Set up unidirectional replication between two NAS’s.
  • Send 2 alarms with the same suppression key from the ‘sending’ NAS.
  • Disable the replication.
  • Send 3 more alarms with the same suppression key from the ‘sending’ NAS.
  • Enable the replication again.
  • Again send 3 alarms with the same suppression key from the ‘sending’ NAS.

All alarms sent after the replication was disabled (in this example 6 alarms) will be ignored by the ‘receiving’ NAS.

Solution:

When re-activating replication between two NAS’s, you should manually delete all alarms on the ‘receiving’ NAS that are received from the ‘sending’ NAS.

The NiS Bridge Tab

By default, both Log transaction details and Activate NiS bridge are enabled.

The Activate NiS Bridge option duplicates the following tables into the NiS database:

  • NAS_ALARMS - the current open-alarm table.
  • NAS_TRANSACTION_SUMMARY - the transaction summary table (one row per alarm)

The Log transaction details option duplicates the following additional tables:

  • NAS_NOTES - the notes in the system.
  • NAS_ALARM_NOTE - the mapping between the note and the alarm.
  • NAS_TRANSACTION_LOG - the event transaction table (new,suppressed,close, assign,..).

These tables are maintained by the nas using the NiS bridge configuration data. To keep the size of these tables in the NiS database manageable, they are automatically compressed at the configured administration interval.

Note:The NiS Bridge tab is only visible when the data_engine probe is deployed with nas on the same hub, and communication between the two components is not blocked.

When the nas GUI opens, a pop-up window opens to indicate that the NiS Bridge is synchronizing with the database:

Important! The NiS Bridge is designed to have one, and only one, nas populating its database tables (NAS_*). Enabling the NiS Bridge on multiple nas engines is not supported.

The GUI fields are:

  • Activate NiS Bridge
    If this checkmark is set, the nas logs all steps in the life of an alarm (the alarm transaction) from the time the alarm is generated until it is acknowledged. This data is stored in the NiS database.
  • Transaction Log Management
    • Administration interval
      The interval at which nas monitors the size of the transaction log tables in the NiS database and truncates them. Valid options are:
      • Every hour
      • Every 2 hours
      • Every 6 hours
      • Every 12 hours
      • Daily
    • Compress transactions after
      The events (of type suppression) for alarms stored in the NiS database will be deleted after the number of days specified. Default is 7 days.
    • Keep transaction history
      How long (in days) the transaction history is stored. The transaction history stores all events for each of the alarms handled by the nas in the NiS database.
    • Keep transaction summary
      How long (in days) the transaction summary is stored. The default value is 30 days.
      The transaction summary for each alarm is stored as one row in the NiS database.
    • Log transaction details
      This option specifies how often duplicate nas events are stored in the NiS database.
      A message is considered duplicate when message text, subsystem id and severity are equal to the previous message with the same suppression key. This will reduce the size of the transaction tables in the NiS database and speed up transaction queries.
      If the Log transactiondetails option is not checked, the transaction details will not be stored and the tables in the database will be empty.

Computer State Monitor

The Computer State Monitor is enabled only when the NiS Bridge is activated from the Setup > NiS Bridge tab.

The NAS attempts to locate the data_engine on its hub and requests the database connectivity information. If this is obtained and is usable, then the user may activate the NiS bridge by activating the checkbox. This is a configuration file parameter, and can be set by the server installation script.

The Computer State Monitor provides the ability to monitor the computer system (CS) table (CM_COMPUTER_SYSTEM) for changes in the state field. This field indicates whether the computer system (or rather the devices referenced by the CS) is in a maintenance/managed mode or not.

The alarms are tagged with the sender’s device_id and these are then further mapped to the appropriate CS (over the CM_DEVICE table). A state may be examined and used by the current computer system monitor ruleset. This enables to act against the device regardless if it is monitored locally or from one or more remote locations from different probes.

Note: This functionality requires NMS Server 4.10 or higher and robots compatible with NMS Server 4.10 or higher.

The fields are:

  • Activate
    Activates the computer state monitor.
  • Polling interval for updates
    Choose a time-interval in minutes that nas will check for the changes in the state of the monitored systems.
  • Action on ‘Maintenance’ State
    Action to be performed for the systems in the "Maintenance" state. The following options are available:
    • None: perform no action
    • Filter Message: filter the messages from these systems
    • Make Invisible: make the systems ‘invisible’
    • Run Pre-processing Script: choose one of available scripts from the drop-down menu.
  • Action on ‘Ignored’ State
    Action to be performed for the systems in the "Ignored" state. The following options are available:
    • None: perform no action
    • Filter Message: filter the messages from these systems
    • Make Invisible: make the systems ‘invisible’
  • Action on ‘Managed’ State
    Action to be performed for the systems in the "Managed" state. The following options are available:
    • None: perform no action
    • Make Visible: make the systems ‘visible’, in case they were ‘invisible’
Was this helpful?

Please log in to post comments.