A REST API is provided with Opsview Monitor that you can use to interact with Opsview Monitor from either the command line on the Orchestrator server​ or from another system (for example, if you need to pull data into your own portal).

The API is covered in our [documentation](🔗) , but here are some examples of its use, all of which are based upon the command line tool provided on the Orchestrator server.

**Basic Command Line Use** The command and necessary minimum options required are:



The command '_opsview_rest_ ' is available within the directory _/opt/opsview/coreutils/bin_ so either run the command as the _opsview_ user or add this directory to your _PATH_.

Using this, the following command would give you basic information about your system:



As can be seen from the above, the output is a bit messy for interactive use, but it is fine for parsing from a script. To make it easier for us to read what is going on, add the option '--pretty':



If this is going to be used in a script then hard-coding the username and password would be a security risk. Instead, on the first invocation we can save a security token and from then on just use that token along with the username in the script:



If the token is not used for 1 hours then it will expire and a new one must be generated.

**Performing a Reload **A reload can be initiated by running:



The command will return when the reload is complete; the Opsview Monitor User Interface will also reflect the reload is happening. The _server_status _in the output returns '0' when the reload has completed successfully, or any error messages in the _messages_ entry.

**Creating a Host** Some REST API commands require extra data to work, for example when creating a host. For this example, we will create a file containing the minimum amount of configuration required:

Create the file _/tmp/host.json _containing:



Below is a sample command with partial output:



Any fields we have not specified will take the default value, the same as if the Host creation page in the Opsview Monitor User Interface were used. The returned information shows how the configuration was applied along with the Host id - this will be required when we update the host.

Reading through the docs for [configuration](🔗) API calls shows the following:

  • GET - retrieve either an object information or a list of objects.

  • PUT - update. Will also create if the object does not currently exist. Will return the object after update.

  • POST - create when POSTed to an objecttype URL, clone when POSTed to an object URL. However, creations will update if the object already exists. Will return the object after creation.

  • DELETE - delete object. Will return a hash with response `{'€œsuccess'€:1}`

so as this is a new Host we need to use POST (to create) rather than PUSH (to update).

**Amending a Host **The easiest way to amend a Host (or any other object) is to fetch the current configuration into a file, amend the file, then upload that back into Opsview Monitor.

The REST API works on ID's for all objects, so we need to search to get the right object before we can fetch the configuration; here is how we do it for our previously created host:



The output from the command is captured directly into a file (_/tmp/hostname.json_) - we can then edit this file as necessary. To upload the configuration we need to make a note of the value of 'id' in the file - in my case it is:



which is the same as the result we had when we first created the entry.



Notice, in this case, we are using PUT (to update) rather than PUSH (to create or clone).

**Summary **As you can see from the above, the API is straight forward to use but it is also very powerful. Almost anything you can do in the Opsview Monitor User Interface, you can do on the command line, and more functionality is being added all the time.