opStatus Data saves information about the jobs performed on the queue and the result of the operation. This jobs are internal to NMIS9, related to the health and system maintenance, and it is not always related with a node. Contrary to status data, that save information related to a node.
This is the schema for the opstatus collection:
- Activity: collect - escalations - metrics - selftest
- Details: Detail of the operation; completed successfully - failed: loading failed… - Can’t call method…
- Status: ok - error
- Type: completed - exception
opStatus data can be visualised on the NMIS9 interface:
How NMIS9 handles opStatus data
- Nmisng saves or updates the status of an operation, called by the nmisd demon.
- An opstatus data is created/updated:
- with the result of a queue job
- when the worker starts/performs/stops an operation
- when a job finish with an error, or is completed successfully.
- The expiration date is almost 2 months by default (purge_opstatus_after is 5184000):
- Used by selftest to check where was the most recent operation for update and collect.
- Used by nmisd to check when some operations were last tried/run/performed.
- A node deletes the opstatus data related when it is deleted.
- A node dumps their opstatus data.
- supports.pl exports the last 500 opstatus records. supports.pl exports collect data.
How OMK handles opStatus data
- opCharts records/update the status of an operation on its own database.
- opFlow records the status of an operation.
- opAddress saves an opstatus on the document (As oper_status)
- opHA records/update the status of an operation on its own database.
- The max age values by default (opCommon.nmis) are the following:
opaddress_opstatus_maxage => 604800, # seconds, 1 week
opflow_opstatus_maxage => 1209600, # seconds, 2 weeks
opconfig_opstatus_maxage => 604800, # seconds, 1 week
purge_opstatus_after => 86400*90, # 3 months (opHA).