Difference between revisions of "Reseting state of all alarms and node statuses"

From NetXMS Wiki
Jump to navigation Jump to search
(Created page with "Sometimes, it can be useful to reset the "state" of all your NetXMS objects completely. For example, if you recover the DB from an older date, a lot of alarms and node status...")
 
m (Text replacement - "^" to "{{deprecated}}")
 
(3 intermediate revisions by one other user not shown)
Line 1: Line 1:
Sometimes, it can be useful to reset the "state" of all your NetXMS objects completely.
{{deprecated}}Sometimes, it can be useful to reset the "state" of all your NetXMS objects completely.


For example, if you recover the DB from an older date, a lot of alarms and node statuses will be outdated.<br>
For example, if you recover the DB from an older date, a lot of alarms and node statuses will be outdated.<br>
However, some alarms might not terminate due to the current status of the system differing from the previous state.<br>
However, some alarms might not terminate due to the current status of the system differing from the previous state.<br>


Its also possible that you miss-configured EPP to not close down alarms, etc.
Its also possible that you miss-configured EPP to not close down alarms, etc.<br>
There is many ways when the NetXMS alarms can become abandoned, or out-of-state due to user errors or infrastrucutre issues.
There is many ways when the NetXMS alarms can become abandoned, or out-of-state due to user errors or infrastrucutre issues.<br>


Basically, your NetXMS system will be reset to a state where it "thinks" all things are currently OK.
Basically, your NetXMS system will be reset to a state where it "thinks" all things are currently OK.<br>
So after it starts up, it will regenerate all alarms for things that are not in a state they should be.
So after it starts up, it will regenerate all alarms for things that are not in a state they should be.<br>


After performing this procedure, you can be sure that the outstanding alarms are current.
After performing this procedure, you can be sure that the outstanding alarms are current.
Line 15: Line 15:


To completely reset the state of all object you can:<br>
To completely reset the state of all object you can:<br>
(these commands should be run on the database NetXMS uses)
  UPDATE thresholds SET current_state=0;
  UPDATE thresholds SET current_state=0;
  UPDATE alarms SET alarm_state=3;
  UPDATE alarms SET alarm_state=3;

Latest revision as of 18:13, 13 September 2022

This Wiki is deprecated and we are are currrently migrating remaining pages into product documentation (Admin Guide, NXSL Guide)

Sometimes, it can be useful to reset the "state" of all your NetXMS objects completely.

For example, if you recover the DB from an older date, a lot of alarms and node statuses will be outdated.
However, some alarms might not terminate due to the current status of the system differing from the previous state.

Its also possible that you miss-configured EPP to not close down alarms, etc.
There is many ways when the NetXMS alarms can become abandoned, or out-of-state due to user errors or infrastrucutre issues.

Basically, your NetXMS system will be reset to a state where it "thinks" all things are currently OK.
So after it starts up, it will regenerate all alarms for things that are not in a state they should be.

After performing this procedure, you can be sure that the outstanding alarms are current.

Before you start, make sure to shut down the NetXMS server, and run "nxdbmgr check".

To completely reset the state of all object you can:
(these commands should be run on the database NetXMS uses)

UPDATE thresholds SET current_state=0;
UPDATE alarms SET alarm_state=3;
TRUNCATE TABLE alarm_events;
UPDATE nodes SET runtime_flags = 0;
UPDATE interfaces SET admin_state=0,oper_state=0;
UPDATE object_properties SET status=5 WHERE object_id IN (SELECT id FROM interfaces);
UPDATE items SET status=0 WHERE status=2;

This will:

  • Terminate all alarms
  • Set nodes to properly generate new alarms if down, agent unreachable, etc.
  • Set threshold to properly generate new alarms if violated
  • Set interfaces to properly generate new alarms if not in expected state

You will lose:

  • Any one-time alarms (from Syslog, SNMP traps, etc.)
  • State of alarms (acknowledged, etc.)
  • Comments on alarms