Child pages
  • opCharts Resource Model Description
Skip to end of metadata
Go to start of metadata

Introduction

Resources help present a normalised view of NMIS models. For example they allow for taking different SNMP implementations of CPU's (avgBusy5/ssCpuRawUser/etc) into a single normalised resource with variables named the same so systems like TopN can look at all CPU's and present a list of them.  In order to do this the Resource model definitions are defined per-model, they can import common sections, and override any part of them.  Each section defines how to find the information in the NMIS model, and how it will be presented.

Internal (dev) Info

Internally, resources are accessed like this:
Node -> Resource Types -> Resource Keys -> Resource

Resources are all indexed and are accessed via their key, if there is only one of them then there is only 1 key available. Resource types can be asked for the available keys, then, can be asked for a resource using one of the keys provided.

end of internal dev info.

Example Resource Types:

  • cpu (display name CPU)
  • memory (display name Memory)
  • interface (display name Interface)
  • packets (display name Packets)
  • processes (display name Processes)
  • users (display name Users)

New resource types can be created by simply adding a new section to a resource file, when naming keep in mind that these are meant to be common sections shared over all models (but don't have to be).

Resource models are used in opCharts TopN analysis, opTrend TopN as well as the opCharts Node panel (when enabled).

Resource Definition

Resource section layout example:

Note: the resource MUST contain a property named "resource_enabled", which tells the system if this resource is enabled or disabled.  If this already exists as a property of the thing being resource-ified, that will do, if not, create a virtual property which defines it.

Virtual Options

Virtual options are run through a parser, they are resolved on access so none of the data is actually parsed/calculated until the data is required.

 

There are 3 operation types of for virtual field/properties:

  1. define - create this property/field, give it the value specified.  Handy for renaming fields
  2. define_if_not_defined - create this property and set this value, but only if it does not already exist.  This functionality could be expressed in a calculation but this is faster
  3. calculation - calculate the value of this property/field, variables include any property/field, prepended with $.  Properties can not access field data, fields can access properties.  Any perl can be put in here, just needs to return a value (and not have circular references).

Not really renaming, but defining a second virtual field that has the same value (but different name) as an existing field. Renaming field example:

 

 

  • No labels