Checkmk
Deutsch
masterlatest (2.3.0)2.2.02.0.01.6.0
to checkmk.com

Configuration via HTTP-API Checkmk on the command line Retrieving status data via Livestatus

Important: The Web-API (also called HTTP-API) is deprecated and will be removed in the next Checkmk version 2.2.0. The Web-API will be replaced by the REST API. For more information, see the update to version 2.1.0 article.

This article contains a description of every command available in the Web-API. A general knowledge of the API’s syntax and other requirements as described in the main article will be assumed.

1. Activating changes

All changes made to the Checkmk-Server can be activated with the activate_changes command. In the request-part you are allowed to add several options:

  • mode: With this option you can decide that only a list of sites should be activated. In this case you set specific as a value.

  • sites: If you changed the mode to specific, here you need to specify which sites should be activated.

  • allow_foreign_changes: It is sometimes the case that other users also added changes at the same time. With this option you can define explicitly indicate that you also want to activate them. Pass the value 1 for this. If you specify 0 here instead, the changes will only be activated if there are no changes made by other users. If there are changes by other users though, the activation will not be carried out.

  • comment: Add a comment to your activation in the same way as in the web interface.

{"mode": "dirty",
 "sites": [ "central", "remote1", "remote2" ],
 "allow_foreign_changes": "0",
 "comment: "Änderungen aus der WebAPI."}

Such a command can look like this, for example:

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?_secret=myautomationsecret&_username=automation&action=activate_changes" -d 'request={"sites":["mysite"],"allow_foreign_changes":"0"}'
{"result": {"sites": {"mysite": {"_time_updated": 1507118620.897177, "_status_details": "Started at: 14:03:33. Finished at: 14:03:40.", "_phase": "done", "_status_text": "Success", "_pid": 10633, "_state": "success", "_time_ended": 1507118620.897177, "_expected_duration": 10.0, "_time_started": 1507118613.630956, "_site_id": "mysite", "_warnings": []}}}, "result_code": 0}

2. Host commands

For hosts, the following commands can be executed in the API:

  • get_host

  • add_host

  • edit_host

  • delete_host

  • delete_hosts

  • get_all_hosts

  • discover_services

2.1. get_host

This command can be used to call up an individual host’s configuration. For this only the name of the host to be called up is needed. In the example below the output is in a format conveniently readable for humans. In practice the output will always be in a single line:

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=get_host&_username=automation&_secret=myautomationsecret&output_format=python" -d 'request={"hostname":"myserver123"}'
{'result': {'attributes': {'alias': u'someAlias', 'tag_agent': 'cmk-agent', 'tag_criticality': 'prod', 'management_address': '192.168.1.42', 'contactgroups': {'use_for_services': False, 'recurse_perms': False, 'recurse_use': False, 'use': True, 'groups': ['ad_admins']}, 'management_protocol': 'snmp', 'ipaddress': '192.168.0.42', 'site': 'prod', 'tag_address_family': 'ip-v4-only', 'management_snmp_community': 'public'}, 'hostname': 'myserver123', 'path': ''}, 'result_code': 0}

Structured readably, the output can look like this:

{'result':
    {'attributes': {
        'alias': u'My Server Alias',
                    'contactgroups': {'groups': ['ad_admins'],
                                      'recurse_perms': False,
                                      'recurse_use': False,
                                      'use': True,
                                      'use_for_services': False},
                    'ipaddress': '192.168.0.42',
                    'management_address': '192.168.1.42',
                    'management_protocol': 'snmp',
                    'management_snmp_community': 'public',
                    'site': 'prod',
                    'tag_address_family': 'ip-v4-only',
                    'tag_agent': 'cmk-agent',
                    'tag_criticality': 'prod'},
     'hostname': 'myserver123',
     'path': ''}
 'result_code': 0}

Note that in the response only the fields explicitly defined for the host in Setup will be output. Values which include the defaults, or values inherited from a directory will not be output here. A response containing only the explicitly defined fields will therefore look like this:

{'result':
    {'attributes': {},
     'hostname': 'myserver123',
     'path': ''},
 'result_code': 0}

This behaviour can be altered by passing the effective_attributes parameter and setting it to ‘1’. The output will then include all attributes – these are not listed again in the example:

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=get_host&_username=automation&_secret=myautomationsecret&effective_attributes=1&output_format=python" -d 'request={"hostname":"myserver123"}'

2.2. add_host

To add a host, the command must specify at least the host name and the directory. Should the host be located in the home directory simply set two empty quotes (‘’). Optionally the attributes – if available – can be set, nodes specified if a cluster host is to be created, or the automatic creation of directories can be suppressed. For the attributes you can use the output from the get_host as a reference, so that the configuration can look like below, for example:

{'hostname': 'myserver123',
 'folder': 'munich/network',
 'attributes': {'ipaddress': '192.168.0.42',
                'site': 'prod',
                'tag_agent': 'cmk-agent'},
 'create_folders': '0'}

The command will then be processed as usual. In the example, with the create_folders option, the creation of new directories will be suppressed. If nothing is specified it will be assumed that the creation of currently non-existent directories is allowed. The attributes will be listed in braces ({}) (as Dictionary). Host tags can also be set here. To access these take the tag-group’s ID and specify a tag_ as a prefix.

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=add_host&_username=automation&_secret=myautomationsecret&request_format=python" -d 'request={"hostname":"myserver123","folder":"munich/network","attributes":{"ipaddress":"192.168.0.42","site":"prod","tag_agent":"cmk-agent"},"create_folders":"0"}'
{"result": null, "result_code": 0}

2.3. edit_host

With this command a host’s attributes can be customised, or reset to its standard values with unset_attributes.

{'hostname': 'myserver123',
 'unset_attributes': [ 'site', 'alias' ],
 'attributes': {'parents': [ 'myRouter1', 'myRouter2' ],
                'tag_agent': 'cmk-agent'}
}

Only the host name is obligatory here. Note that the attribute to be reset should be specified in a list.

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=edit_host&_username=automation&_secret=myautomationsecret&request_format=python" -d 'request={"hostname":"myserver123","unset_attributes":["site","alias"],"attributes":{"parents":["myRouter1","myRouter2"],"tag_agent":"cmk-agent"}}'
{"result": null, "result_code": 0}

2.4. delete_host

To delete a host only the host’s name is required in the request-part since it must always be explicit in Checkmk:

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=delete_host&_username=automation&_secret=myautomationsecret" -d 'request={"hostname":"myserver123"}'
{"result": null, "result_code": 0}

2.5. delete_hosts

From Version 1.5.0 you can use this command to delete more than one host at a time. You should be careful to spell the command correctly. The hosts will be delivered as a list:

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=delete_hosts&_username=automation&_secret=myautomationsecret" -d 'request={"hostnames":["myserver123","myserver234"]}'
{"result": null, "result_code": 0}

2.6. get_all_hosts

This command is the only one for the hosts which requires no additional data to be entered. It simply outputs the info for all of the hosts in Checkmk. Likewise as with get_host — in this command it can also be specified whether only the explicitly-coded, or all attributes should be output. Note that under some circumstances a very comprehensive response can be produced. For this reason the response’s output will be omitted from the example here.

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=get_all_hosts&_username=automation&_secret=myautomationsecret&output_format=pythyon"

2.7. discover_services

With this command all of a host’s services can be discovered and added. The syntax of the request command is the same as for get_host, however a summary of the results will be output with the response:

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=discover_services&_username=automation&_secret=myautomationsecret" -d 'request={"hostname":"myserver123"}'
{'result': 'Service discovery successful. Added 7, Removed 0, Kept 52, New Count 59', 'result_code': 0}

Additionally – as in Setup – using mode it can be specified how to handle the newly-discovered and the already configured services. The possible options are:

  • new: Only add new services. This is the default setting when no options are entered.

  • remove: Removes only services that are no longer available.

  • fixall: Removes services that are no longer available, and adds new ones.

  • refresh: Removes all services, and then adds all services as new.

The parameter will then be additionally passed with the host names:

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=discover_services&_username=automation&_secret=myautomationsecret" -d 'request={"hostname":"myserver123","mode":"refresh"}'
{"result": "Service discovery successful. Added 6, Removed 5, Kept 48, New Count 54", "result_code": 0}

3. Directory commands

From Version 1.5.0 Checkmk provides the following commands for managing the directories in Setup:

  • get_folder

  • add_folder

  • edit_folder

  • delete_folder

  • get_all_folders

3.1. get_folder

Querying the configuration of a directory is not much different from that for a host. Enter the name of the directory, and all attributes where applicable will be output. In the example the output_format will be converted to Python, and all of the directory’s attributes will be output. Note that in the response all tuples will be converted to lists if the output is formatted in JSON.

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=get_folder&_username=automation&_secret=myautomationsecret&output_format=python&effective_attributes=1" -d 'request={"folder":"munich/network"}'
{'result': {'attributes': {'network_scan': {'scan_interval': 86400, 'exclude_ranges': [], 'run_as': u'automation', 'ip_ranges': [], 'time_allowed': 0, 0), (24, 0}, 'tag_agent': 'cmk-agent', 'snmp_community': None, 'ipv6address': '', 'alias': '', 'management_protocol': None, 'site': 'heute', 'tag_room': 'weisses_haus', 'tag_criticality': 'prod', 'contactgroups': (True, []), 'network_scan_result': {'start': None, 'state': None, 'end': None, 'output': ''}, 'parents': ['heute'], 'tag_address_family': 'ip-v4-only', 'management_address': '', 'tag_networking': 'lan', 'ipaddress': '', 'management_snmp_community': None}, 'configuration_hash': '7001db7f20eee1cae51f9c696cddff42'}, 'result_code': 0}

As can be seen in the example, a directory must always be specified relative to the home directory since the path is always unique, but not the name.

The (readable) response will then appear like this (since some of the information delivered is not relevant here, the example shown has been abbreviated for clarity):

{'result': {'attributes': {'alias': '',
                           'contactgroups': (True, []),
                           'network_scan': {'exclude_ranges': [],
                                            'ip_ranges': [],
                                            'run_as': u'automation',
                                            'scan_interval': 86400,
                                            'time_allowed': 0, 0),                                                              (24, 0},
                           'network_scan_result': {'end': None,
                                                   'output': '',
                                                   'start': None,
                                                   'state': None},
                           'parents': [],
                           'site': 'prod',
                           'snmp_community': None,
                           'tag_address_family': 'ip-v4-only',
                           'tag_agent': 'cmk-agent',
                           'tag_criticality': 'prod',
                           'tag_networking': 'lan'},
            'configuration_hash': '7001db7f20eee1cae51f9c696cddff42'}
 'result_code': 0}

The ‘alias’ attribute will always be empty in the output – since directories are only created once and never internally renamed, via this attribute the display name in Setup can subsequently be customised. Note then that the name in Setup must not necessarily match the real name!

The configuration_hash can be used if the directory must be modified.

3.2. add_folder

The insertion of directories also works in a similar way to that for hosts. As a minimum the name and the attribute will be required. The latter can also be blank as in the example below:

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=add_folder&_username=automation&_secret=myautomationsecret" -d 'request={"folder":"munich/network/router","attributes":{}}'
{"result": null, "result_code": 0}

As can be seen, the path here is likewise always specified relative to the home directory. If a parent directory is not present one will be created. This action can be suppressed if – in a similar way to add_host – the create_parent_folders option is added and set to ‘0’.

3.3. edit_folder

To be able to edit a directory, as a minimum its name will be required. Additionally, the attributes described in get_folder can be customised. With the optional configuration_hash it can be ensured that the directory’s configuration will in the interim not be altered. If the hash is not identical Checkmk will not alter the directory. In the example the result from get_folder can be used in order to customise the configuration. Make sure to use Python as the request_format, since tuples can be present in the settings for the network scan:

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=add_folder&_username=automation&_secret=myautomationsecret&request_format=python" -d 'request={"folder":"munich/network","attributes":{"network_scan":{"time_allowed":"18,0),(24,0"}},"configuration_hash":"7001db7f20eee1cae51f9c696cddff42"}'
{"result": null, "result_code": 0}

3.4. delete_folder

Deleting a directory is very easy. Simply enter its name. As always for directories that will be its relative path:

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=delete_folder&_username=automation&_secret=myautomationsecret -d 'request={"folder":"munich/network"}'
{"result": null, "result_code": 0}

3.5. get_all_folders

Equally easy is the output of all directories. This is done in a similar way to get_all_hosts. Note that the output format should be Python as with get_folder:

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=get_all_folders&_username=automation&_secret=myautomationsecret&output_format=python"
{'result': {'': {}, 'munich/windows': {}, 'munich/network': {'network_scan': {'run_as': 'automation', 'exclude_ranges': [], 'ip_ranges': [('ip_network', ('192.168.20.0', 24))], 'scan_interval': 86400, 'time_allowed': 20, 0), (24, 0}, 'tag_agent': 'snmp-only'}, 'munich': {}, 'berlin': {'tag_networking': 'dmz'}, 'berlin/databases': {'tag_criticality': 'critical'}, 'essen': {'tag_networking': 'wan'}, 'essen/linux': {}}, 'result_code': 0}

The output (in a readable form) looks like below. It differs from the query of an individual directory only in detail. The top line with the empty name field is the main directory.

{'result': {'': {},
            'berlin': {'tag_networking': 'dmz'},
            'berlin/databases': {'tag_criticality': 'critical'},
            'essen': {'tag_networking': 'wan'},
            'essen/linux': {},
            'munich': {},
            'munich/network': {'network_scan': {'exclude_ranges': [],
                                                'ip_ranges': [('ip_network',
                                                               ('192.168.20.0',
                                                                24))],
                                                'run_as': 'automation',
                                                'scan_interval': 86400,
                                                'time_allowed': 20, 0),                                                                  (24, 0},
                               'tag_agent': 'snmp-only'},
            'munich/windows': {}},
 'result_code': 0}

4. Group commands

With the Web-API, contact, host and service groups can be created, edited, deleted and of course also queried in Checkmk. The following commands are available for these tasks:

  • add_contactgroup

  • edit_contactgroup

  • delete_contactgroup

  • get_all_contactgroups

  • add_servicegroup

  • edit_servicegroup

  • delete_servicegroup

  • get_all_servicegroups

  • add_hostgroup

  • edit_hostgroup

  • delete_hostgroup

  • get_all_hostgroups

The command syntax is the same for the different types of groups. Only the command will be matched as appropriate to each group. For this reason each command type will only be explained once. The examples can then be carried-over for both of the other types of group. To make this clearer, different groups will be used in each of the examples.

Important: All commands must always include the group type. If the subject is add_group and a host group is to be added, the required command is add_hostgroup.

4.1. get_all_groups

This command – like other similar commands – will be invoked without extra parameters. The response will contain all groups with their names and aliases:

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=get_all_contactgroups&_username=automation&_secret=myautomationsecret"
{"result": {"oracle": {"alias": "ORACLE Administrators"}, "windows": {"alias": "Windows Administrators"}, "all": {"alias": "Everything"}, "linux": {"alias": "Linux Administrators"}}, "result_code": 0}

In an easy to read format the response will look like this. As can be seen the syntax is very simple:

{'result': {'all': {'alias': 'Everything'},
            'linux': {'alias': 'Linux Administrators'},
            'oracle': {'alias': 'ORACLE Administrators'},
            'windows': {'alias': 'Windows Administrators'}},
 'result_code': 0}

4.2. add_group

In order to add a group the syntax get_all_groups can be used. Only the group’s ID and its alias need to be given. Note that when adding a new group, its ID with its groupname key will be given:

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=add_hostgroup&_username=automation&_secret=myautomationsecret" -d 'request={"groupname":"linux", "alias":"All Linux Servers"}'
{"result": null, "result_code": 0}

4.3. edit_group

Due to the low complexity of the invocation, editing a group functions in a similar way to its creation. The group name (groupname) must obviously already exist in order to be able to edit its alias. In the example the service group ‘cpu_util’ does not exist yet and so the response contains an error. In a successful action with the curl-invocation the same response will be produced as with add_group:

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=add_servicegroup&_username=automation&_secret=myautomationsecret" -d 'request={"groupname":"cpu_util", "alias":"CPU utilization of all servers"}'
{"result": "Check_MK exception: Unknown group: linux", "result_code": 1}

4.4. delete_group

Deleting a group is also very easy. Only the group’s name needs to be entered.

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=delete_hostgroup&_username=automation&_secret=myautomationsecret" -d 'request={"groupname":"linux"}'
{"result": null, "result_code": 0}

5. User commands

The following commands can be used for managing the users. Note however that users synchronised over LDAP or Active Directory can be queried but not edited.

  • add_users

  • edit_users

  • delete_users

  • get_all_users

5.1. add_users

To create a user, the minimum requirement is a user name (ID) and an alias. So that the user can subsequently log in, a password will also need to be defined. This password will be stored encrypted so that during a query the password will not be transmitted as plain text. Only the password for the automated user automation_secret will not be encrypted. All further attributes for a user are optional. To get an overview of a few possible attributes, you can view the response example from get_all_users.

The request-part will begin with users, so that multiple users can be created with a single action. Each entry begins with the new user’s ID:

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=add_users&_username=automation&_secret=myautomationsecret" -d 'request={"users":{"hhirsch":{"alias":"Harry Hirsch","password":"myStrongPassword","pager":"+49176555999222"},"customAutomation":{"alias":"Custom Automation User","automation_secret":"mySuperStrongSecret"}}}'
{"result": null, "result_code": 0}

5.2. edit_users

Editing a user functions in almost the same way as creating the user. The user’s ID will be required, and the changes are specified with set_attributes. With unset_attributes the attributes can be reset to their default values. With these commands it is also possible to edit multiple users in a single action.

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=edit_users&_username=automation&_secret=myautomationsecret" -d 'request={"users":{"hhirsch":{"set_attributes":{"email":"hhirsch@myCompany.org","contactgroups":["windows"]},"unset_attributes":["pager"]}}}'
{"result": null, "result_code": 0}

To recap, here is the request-part in a readable form:

{'users': {'hhirsch': {'set_attributes': {'contactgroups': ['windows'],
                                          'email': 'hhirsch@myCompany.org'},
                       'unset_attributes': ['pager']}}}

5.3. delete_users

To delete one or more users, simply enter the user’s ID(s) in users.

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=delete_users&_username=automation&_secret=myautomationsecret" -d 'request={"users":["customAutomation"]}'
{"result": null, "result_code": 0}

5.4. get_all_users

No additional parameters are needed in the request-part to retrieve the configurations of all users. The response will then contain all user-IDs and their associated attributes. Note that some attributes will only be output if they are explicitly specified.

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=get_all_users&_username=automation&_secret=myautomationsecret

The output can be very comprehensive. For that reason only two examples of outputs listing a user’s attributes, amongst other things, are presented here:

{'automation': {'alias': u'Check_MK Automation - used for calling web services',
                'automation_secret': 'myautomationsecret',
                'contactgroups': [],
                'disable_notifications': {},
                'email': u'',
                'enforce_pw_change': False,
                'fallback_contact': False,
                'force_authuser': False,
                'force_authuser_webservice': False,
                'last_pw_change': 1504517726,
                'locked': False,
                'notifications_enabled': False,
                'num_failed_logins': 0,
                'pager': '',
                'password': '$1$508982$cA48GmuUHxRZn3w2GJUnK0',
                'roles': ['admin'],
                'serial': 2,
                'start_url': 'dashboard.py'},
 'hhirsch': {'alias': u'Harry Hirsch',
             'connector': 'htpasswd',
             'contactgroups': ['windows'],
             'disable_notifications': {'disable': True},
             'email': u'hhirsch@myCompany.org',
             'enforce_pw_change': True,
             'fallback_contact': True,
             'force_authuser': False,
             'force_authuser_webservice': False,
             'idle_timeout': 600,
             'language': None,
             'last_pw_change': 1504713006,
             'locked': False,
             'num_failed_logins': 1,
             'pager': '+49176555999222',
             'password': '$1$238168$dGIr7ja6DVn3E8rMlp1aD.',
             'roles': ['admin', 'user'],
             'serial': 1,
             'start_url': 'dashboard.py'}}

6. Rule Set commands

From Version 1.5.0 Checkmk also provides the facility for defining and retrieving rule sets via the Web-API. An in-depth knowledge of the rules’ syntax is a requirement for working with the following commands, meaning that they are really only recommended for advanced Checkmk users.

  • get_ruleset

  • set_ruleset

  • get_ruleset_info

6.1. get_ruleset

Rules must already have been defined in a rule set in order for a rule set to be retrievable. As input the rule set’s ID is required, and Python must be defined as the output_format since many rule sets work with tuples.

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=get_ruleset&_username=automation&_secret=myautomationsecret&output_format=python" -d 'request={"ruleset_name":"checkgroup_parameters:filesystem"}'
{'result': {'ruleset': {'': [{'conditions': {'host_specs': ['myserver123'], 'service_specs': [u'/media/customers$'], 'host_tags': []}, 'options': {}, 'value': {'levels': (90.0, 95.0)}}, {'conditions': {'host_specs': ['myserver123'], 'service_specs': [u'/media/meetings$'], 'host_tags': []}, 'options': {}, 'value': {'show_levels': 'onproblem', 'levels': (90.0, 95.0), 'trend_range': 24, 'trend_perfdata': True}}]}, 'configuration_hash': 'e069408225932bbfe2a485f22b9fc40e'}, 'result_code': 0}

As can be seen in the following readably-formatted response, only the elements used in the rule will be listed. In addition the rules will be assigned as a list to a directory:

{'result': {'ruleset': {'munich': [{'conditions': {'host_specs': ['myserver123'],
                                                   'host_tags': [],
                                                   'service_specs': [u'/media/customer$']},
                                    'options': {},
                                    'value': {'levels': (90.0, 95.0)}},
                                   {'conditions': {'host_specs': ['myserver123'],
                                                   'host_tags': [],
                                                   'service_specs': [u'/media/meeting$']},
                                    'options': {},
                                    'value': {'levels': (90.0, 95.0),
                                              'show_levels': 'onproblem',
                                              'trend_perfdata': True,
                                              'trend_range': 24}}]},
            'configuration_hash': 'e069408225932bbfe2a485f22b9fc40e'}
 'result_code': 0}

A query always requires the respective rule’s internal name. The internal names (IDs) for all rules can be listed with the get_rulesets_info command, for example. For each entry – among other info – the rule’s title as can be found in Setup will also be listed. Use such functions if a rule set’s ID is unknown.

6.2. set_ruleset

Rule sets can also only be set as complete packets with which one or more rules are defined for a specified directory. These rules will be summarised in a list. It is advisable to first call up the current content of a rule set, and to then use it as the basis for customising a new version. The configuration_hash parameter is also available here to be able to understand interim changes. In the following example we will use the response from above, and delete only one of the two rules — so that we rewrite only one rule to this directory. Note that the request_format is coded in Python – i.e., that the request element is enclosed in double-quotes (“ ”):

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=set_ruleset&_username=automation&_secret=myautomationsecret&request_format=python" -d "request={'ruleset_name':'checkgroup_parameters:filesystem','ruleset': {'': [{'conditions': {'host_specs': ['myserver123'], 'service_specs': [u'/media/customers$'], 'host_tags': []}, 'options': {}, 'value': {'levels': (90.0, 95.0)}}],'configuration_hash': 'e069408225932bbfe2a485f22b9fc40e'}}"
{'result': None, 'result_code': 0}

The (readable) request part looks like the following:

request={
    'ruleset_name':'checkgroup_parameters:filesystem',
    'ruleset': {
        '': [{
            'conditions': {
                'host_specs': ['myserver123'],
                'service_specs': [u'/media/customers$'],
                'host_tags': []
            },
            'options': {},
            'value': {'levels': (90.0, 95.0)}
            }],
        'configuration_hash': 'e069408225932bbfe2a485f22b9fc40e'
    }
}

6.3. get_rulesets_info

If an overview of which rule sets are in Checkmk is desired, they can be called up with this command. As can be seen Python is also recommended as the output format here:

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=get_rulesets_info&_username=automation&_secret=myautomationsecret&output_format=python"

Since all available rule sets can be called up with this command, its output will be omitted here. It is coded like the other commands. Here are examples of two typical rule sets in an easily-readable format:

{'result': {'cmc_service_rrd_config': {'help': 'This configures how many datapoints will be stored of the performance values of services. Please note, that these settings only apply for new services. Existing RRDs cannot be changed.',
                                       'number_of_rules': 1,
                                       'title': 'Configuration of RRD databases of services'},
            'static_checks:ipmi':     {'help': None,
                                       'number_of_rules': 0,
                                       'title': 'IPMI sensors'}},
 'result_code': 0}

This information is especially useful if the rule set’s title is known but not its ID, and it will help when coding scripts for automation by being able to use the normal titles, thus increasing the readability for maintenance or alterations.

7. Host tag commands

From Version 1.5.0 host tags can be set as well as read with the following two commands:

  • get_hosttags

  • set_hosttags

7.1. get_hosttags

All tags can be called up with this command. The Host tag groups as well as the Auxiliary tags will be output.

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=get_hosttags&_username=automation&_secret=myautomationsecret"
{"result": {"aux_tags": [{"id": "snmp", "title": "monitor via SNMP"}, {"id": "tcp", "title": "monitor via Check_MK Agent"}], "tag_groups": [{"tags": [{"aux_tags": [], "id": "prod", "title": "Productive system"}, {"aux_tags": [], "id": "critical", "title": "Business critical"}, {"aux_tags": [], "id": "test", "title": "Test system"}, {"aux_tags": [], "id": "offline", "title": "Do not monitor this host"}], "id": "criticality", "title": "Criticality"}, {"tags": [{"aux_tags": [], "id": "lan", "title": "Local network (low latency)"}, {"aux_tags": [], "id": "wan", "title": "WAN (high latency)"}, {"aux_tags": [], "id": "dmz", "title": "DMZ (low latency, secure access)"}], "id": "networking", "title": "Networking Segment"}], "configuration_hash": "4c2a236ffeabb0c52d4770ea03eff48e"}, "result_code": 0}

Formatted for readability the response is structured as below:

{'result': {'aux_tags': [{'id': 'snmp', 'title': 'monitor via SNMP'},
                         {'id': 'tcp', 'title': 'monitor via Check_MK Agent'}],
            'tag_groups': [{'id': 'agent',
                            'tags': [{'aux_tags': ['tcp'],
                                      'id': 'cmk-agent',
                                      'title': 'Check_MK Agent (Server)'},
                                     {'aux_tags': ['snmp'],
                                      'id': 'snmp-only',
                                      'title': 'SNMP (Networking device, Appliance)'},
                                     {'aux_tags': ['snmp'],
                                      'id': 'snmp-v1',
                                      'title': 'Legacy SNMP device (using V1)'},
                                     {'aux_tags': ['snmp', 'tcp'],
                                      'id': 'snmp-tcp',
                                      'title': 'Dual: Check_MK Agent + SNMP'},
                                     {'aux_tags': [],
                                      'id': 'ping',
                                      'title': 'No Agent'}],
                            'title': 'Agent type'},
                           {'id': 'criticality',
                            'tags': [{'aux_tags': [],
                                      'id': 'prod',
                                      'title': 'Productive system'},
                                     {'aux_tags': [],
                                      'id': 'critical',
                                      'title': 'Business critical'},
                                     {'aux_tags': [],
                                      'id': 'test',
                                      'title': 'Test system'},
                                     {'aux_tags': [],
                                      'id': 'offline',
                                      'title': 'Do not monitor this host'}],
                            'title': 'Criticality'},
                           {'id': 'networking',
                            'tags': [{'aux_tags': [],
                                      'id': 'lan',
                                      'title': 'Local network (low latency)'},
                                     {'aux_tags': [],
                                      'id': 'wan',
                                      'title': 'WAN (high latency)'},
                                     {'aux_tags': [],
                                      'id': 'dmz',
                                      'title': 'DMZ (low latency, secure access)'}],
                            'title': 'Networking Segment'}],
            'configuration_hash': '32deebf233cade1d42387c6a0639ceb1'},
 'result_code': 0}

7.2. set_hosttags

A configuration in the host tags will, for technical reasons, always be written as a completely new version, even if only a single entry has been added or altered. For this reason, here it is advisable to call up the configuration with the aid of get_hosttags and then insert the alterations. The altered configuration is then written back to Checkmk.

At this point the configuration_hash is useful. If when storing the configuration the hash on the Checkmk server does not match the one being provided, the data will be rejected and an error produced. In this way it can be ensured that the configuration has not been altered in the interim, and that a change is not inadvertently overwritten or deleted.

In the following example the configuration which we called up with the command above will be extended with the host tag ‘location’ and its selection options ‘munich’, ‘essen’ and ‘berlin’, so that the new version of the configuration will look like this:

{'aux_tags': [{'id': 'snmp', 'title': 'monitor via SNMP'},
              {'id': 'tcp', 'title': 'monitor via Check_MK Agent'}],
 'tag_groups': [{'id': 'agent',
                 'tags': [{'aux_tags': ['tcp'],
                           'id': 'cmk-agent',
                           'title': 'Check_MK Agent (Server)'},
                          {'aux_tags': ['snmp'],
                           'id': 'snmp-only',
                           'title': 'SNMP (Networking device, Appliance)'},
                          {'aux_tags': ['snmp'],
                           'id': 'snmp-v1',
                           'title': 'Legacy SNMP device (using V1)'},
                          {'aux_tags': ['snmp', 'tcp'],
                           'id': 'snmp-tcp',
                           'title': 'Dual: Check_MK Agent + SNMP'},
                          {'aux_tags': [],
                           'id': 'ping',
                           'title': 'No Agent'}],
                 'title': 'Agent type'},
                {'id': 'criticality',
                 'tags': [{'aux_tags': [],
                           'id': 'prod',
                           'title': 'Productive system'},
                          {'aux_tags': [],
                           'id': 'critical',
                           'title': 'Business critical'},
                          {'aux_tags': [],
                           'id': 'test',
                           'title': 'Test system'},
                          {'aux_tags': [],
                           'id': 'offline',
                           'title': 'Do not monitor this host'}],
                 'title': 'Criticality'},
                {'id': 'networking',
                 'tags': [{'aux_tags': [],
                           'id': 'lan',
                           'title': 'Local network (low latency)'},
                          {'aux_tags': [],
                           'id': 'wan',
                           'title': 'WAN (high latency)'},
                          {'aux_tags': [],
                           'id': 'dmz',
                           'title': 'DMZ (low latency, secure access)'}],
                 'title': 'Networking Segment'},
                {'id': 'location',
                 'tags': [{'aux_tags': [],
                           'id': 'munich',
                           'title': 'Munich'},
                          {'aux_tags': [],
                           'id': 'essen',
                           'title': 'Essen'},
                          {'aux_tags': [],
                           'id': 'berlin',
                           'title': 'Berlin'}],
                 'title': 'Location'}],
 'configuration_hash': '32deebf233cade1d42387c6a0639ceb1'},

This configuration can be included in the curl invocation and sent to the Checkmk server:

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=set_hosttags&_username=automation&_secret=myautomationsecret" -d 'request={"aux_tags":[{"id":"snmp","title":"monitor via SNMP"},{"id":"tcp","title":"monitor via Check_MK Agent"}],"tag_groups":[{"title":"Agent type","id":"agent","tags":[{"aux_tags":["tcp"],"id":"cmk-agent","title":"Check_MK Agent (Server)"},{"aux_tags":["snmp"],"id":"snmp-only","title":"SNMP (Networking device, Appliance)"},{"aux_tags":["snmp"],"id":"snmp-v1","title":"Legacy SNMP device (usingV1)"},{"aux_tags":["snmp","tcp"],"id":"snmp-tcp","title":"Dual: Check_MK Agent + SNMP"},{"aux_tags":[],"id":"ping","title":"No Agent"}]},{"title":"Criticality","id":"criticality","tags":[{"aux_tags":[],"id":"prod","title":"Productive system"},{"aux_tags":[],"id":"critical","title":"Business critical"},{"aux_tags":[],"id":"test","title":"Test system"},{"aux_tags":[],"id":"offline","title":"Do not monitor this host"}]},{"title":"Networking Segment","id":"networking","tags":[{"aux_tags":[],"id":"lan","title":"Local network (low latency)"},{"aux_tags":[],"id":"wan","title":"WAN (high latency)"},{"aux_tags":[],"id":"dmz","title":"DMZ (low latency, secure access)"}]},{"tags":[{"aux_tags":[],"id":"munich","title":"Munich"},{"aux_tags":[],"id":"essen","title":"Essen"},{"aux_tags":[],"id":"berlin","title":"Berlin"}],"id":"location","title":"Location"}],"configuration_hash":"32deebf233cade1d42387c6a0639ceb1"}'
{"result": null, "result_code": 0}

8. Sites

From Version 1.5.0 the Distributed Monitoring can be used to establish or delete links to other sites. In this way completely new locations can be automatically integrated into Checkmk. The following commands are available:

  • get_site

  • set_site

  • delete_site

  • login_site

  • logout_site

8.1. get_site

Calling up a site works almost identically to other queries over the Web-API. Enter the ID of the site to be called up in the request-part. Note that this command requires Python for its output_format:

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=get_site&_username=automation&_secret=myautomationsecret&output_format=python" -d 'request={"site_id":"myRemote"}'
{'result': {'site_id': 'myRemote', 'site_config': {'url_prefix': 'http://myRemoteServer/myRemote/', 'user_sync': None, 'user_login': True, 'insecure': False, 'disabled': False, 'replication': 'slave', 'multisiteurl': 'http://myRemoteServer/myRemote/check_mk/', 'replicate_mkps': True, 'status_host': ('heute', 'myRemote'), 'socket': ('proxy', {'params': None, 'socket': ('myRemoteServer', 6557)}), 'disable_wato': True, 'alias': u'My Remote Check_MK', 'timeout': 10, 'persist': True, 'replicate_ec': True}, 'configuration_hash': '136bd84ff62dfa4e0a4325c6431e294b'}, 'result_code': 0}

In lesbarer Form sieht die Antwort so aus:

{'result': {'site_id': 'myRemote',
            'site_config': {'alias': u'My Remote Check_MK',
                            'disable_wato': True,
                            'disabled': False,
                            'insecure': False,
                            'multisiteurl': 'http://myRemoteServer/myRemote/check_mk/',
                            'persist': True,
                            'replicate_ec': True,
                            'replicate_mkps': True,
                            'replication': 'slave',
                            'socket': ('proxy',
                                       {'params': None,
                                        'socket': ('myRemoteServer', 6557)}),
                            'status_host': ('mysite', 'myRemote'),
                            'timeout': 10,
                            'url_prefix': 'http://myRemoteServer/myRemote/',
                            'user_login': True,
                            'user_sync': None},
            'configuration_hash': '136bd84ff62dfa4e0a4325c6431e294b',},
 'result_code': 0}

8.2. set_site

Connections to sites can only be altered in their entirety – thus if a customisation is to be performed over the Web-API any existing connections must be recreated as completely new versions. Here again, if performing a customisation it is advisable to first call up the current version with get_site, to make the alterations in the response, and then store this new version in Checkmk. Here also, as in get_folder, the configuration_hash can be used to ensure that in the interim no other alterations can be made to the configuration.

In the following example we take the configuration shown above, and alter only the Alias (alias) and the Persistent Connection (persist). The request format in this situation must be in Python, and the request-part in double-quotes (“”):

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=set_site&_username=automation&_secret=myautomationsecret&request_format=python" -d "request={'site_id': 'myRemote', 'site_config': {'url_prefix': 'http://myRemoteServer/myRemote/', 'user_sync': None, 'user_login': True, 'insecure': False, 'disabled': False, 'replication': 'slave', 'multisiteurl': 'http://myRemoteServer/myRemote/check_mk/', 'replicate_mkps': True, 'status_host': ('heute', 'myRemote'), 'socket': ('proxy', {'params': None, 'socket': ('myRemoteServer', 6557)}), 'disable_wato': True, 'alias': u'My Remote', 'timeout': 10, 'persist': False, 'replicate_ec': True}, 'configuration_hash': '136bd84ff62dfa4e0a4325c6431e294b'}"
{"result": null, "result_code": 0}

8.3. delete_site

Only the site’s ID is required to delete the connection to a site. In this case the configuration_hash function can also be used.

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=delete_site&_username=automation&_secret=myautomationsecret" -d 'request={"site_id":"myRemote"}'{"result": null, "result_code": 0}

8.4. login_site & logout_site

To be able to directly use a site connection established via Web-API, a login to, and a logout from the site can be performed. For the login, in addition to the site’s ID enter the user name and password.

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=login_site&_username=automation&_secret=myautomationsecret" -d 'request={"site_id":"myRemote","username":"cmkadmin","password":"cmk"}'
{"result": null, "result_code": 0}

Entering the site’s ID is sufficient for logging out

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=logout_site&_username=automation&_secret=myautomationsecret" -d 'request={"site_id":"myRemote"}'{"result": null, "result_code": 0}

9. Agent Bakery commands

CEE Automated agents can also be baked via the API. In this way the automatically-created configurations can be fed directly into the agents. Only the signing of the agents still needs to be performed manually, so that the freshly-baked agent’s configuration can be verified one final time, and that you retain full control over which agents will actually be delivered to the hosts.

Calling up is very easy and it uses the bake_agents command:

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=bake_agents&_username=automation&_secret=myautomationsecret"
{"result": "Successfully baked agents", "result_code": 0}

10. Commands for status data

10.1. Metrics

CEE Checkmk in fact provides the facility for integrating external metrics data bases. In principle however, with the get_graph command Checkmk’s metrics data can be accessed by any third-party software. In this way the user is not bound to our standard-issue graphs and can utilise their own self-created custom graphs. The data will then always be produced for a complete graph, even when the graph includes multiple metrics.

If you wish to call up one of our standard graphs, the syntax for the request-part is as follows:

{'specification': ['template',
                   {'graph_index': 0,
                    'host_name': 'myserver123',
                    'service_description': 'Memory',
                    'site': 'mysite'}],
 'data_range': {'time_range': [1504623158, 1504626758]}}

Be sure to enter the time range in Unix Time. The graph_index command specifies the graph to be retrieved. In the example the first graph we have retrieved is from the Memory service, which under Linux is located in the Memory RAM + Swap overview service. If instead of this you want to retrieve the RAM used graph, count through the graphs, beginning with 0. A complete retrieval for a time range of 10 minutes (600 Seconds) will look like this, for example:

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=get_graph&_username=automation&_secret=myautomationsecret" -d 'request={"specification":["template",{"service_description":"Memory","site":"heute","graph_index":4,"host_name":"heute"}],"data_range":{"time_range":[1504626158, 1504626758]}}'
{"result": {"step": 60, "start_time": 1504626180, "end_time": 1504626780, "curves": [{"color": "#80ff40", "rrddata": [3752390000.0, 3746380000.0, 3770930000.0, 3773230000.0, 3796020000.0, 3787010000.0, 3777880000.0, 3781040000.0, 3798920000.0, 3805910000.0], "line_type": "area", "title": "RAM used"}]}, "result_code": 0}

Querying a self-created graph is somewhat simpler since this is not bound to a particular host or service or to a particular site. Neverless, remember that an automated user, e.g. automation, can only retrieve such a graph if it has been enabled for all users:

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=get_graph&_username=automation&_secret=myautomationsecret" -d 'request={"specification":["custom","all_disk_utilization"],"data_range":{"time_range":[1504709932, 1504710532]}}'
{"result": {"step": 60, "start_time": 1504709940, "end_time": 1504710540, "curves": [{"color": "#ea905d", "rrddata": [6.2217, 0.728733, 0.7748, 0.158085, 1.90726, 15.2222, 22.6851, 7.31163, 1.96834, 0.413633], "line_type": "stack", "title": "Disk utilization sdb"}, {"color": "#a05830", "rrddata": [1.45488, 0.101608, 0.0832167, 0.0342933, 0.235585, 0.166253, 14.9513, 25.112, 11.2032, 0.400437], "line_type": "stack", "title": "Disk utilization sda"}]}, "result_code": 0}

10.2. SLAs

CEE From 1.5.0 SLAs can be retrieved with the get_sla command. For such a query, the following time data can be used:

Time Range ID in the query

Today

d0

Yesterday

d1

This week

w0

Last week

w1

This month

m0

Last month

m1

This year

y0

Last year

y1

The last…​

last:86400

Time range

range:1530271236:1530281236

The actual syntax for retrieving one or more SLAs is as follows:

{'query': [[['my_sla_id1'],
           ['w1', w0],
           [['myhost123', 'CPU load'], ['myhost234', 'CPU load']]],
          [['my_sla_id2'],
           ['m0'],
           [['myhost123', 'CPU load']]]],
}

You can specify any number of values in each list, and for single or multiple SLAs also include multiple host/service pairs and multiple timers. So in the example shown the first list would return four results – (2 time periods x 2 host/service pairs) – and the second list a single result. In the following example call we will only retrieve the second list:

curl "http://myserver/mysite/check_mk/webapi.py?action=get_sla&_username=automation&_secret=myautomationsecret" -d "request={'query':       [[['my_sla_id2'],['m0'],[['myhost123','CPU load']]]]}"

The output in readable form is then structured as follows:

{'result': {'mysite':
                {'myhost123':
                    {'CPU load': {(
                        ('myhost123', 'CPU load'),
                        'my_sla_id2',
                        ('sla_period_range',
                        (0, 1)),
                        'weekly'):
                            {'plugin_results': [{
                                'plugin_id': 'service_state_percentage',
                                'timerange_sla_duration': 1000934.0,
                                'period_results': [{
                                    'duration': 604800.0,
                                    'sla_broken': False,
                                    'subresults': [{
                                        'sla_broken': False,
                                        'requirement': (0, 'min', 0.0),
                                        'error_instances': [],
                                        'deviation_info': {
                                            'deviation': 0.0,
                                            'limit': 0.0,
                                            'levels': (0, 0),
                                            'deviation_state': 2}}],
                                    'statistics': {
                                        'duration': {-1: 604800.0},
                                        'percentage': {-1: 100.0}},
                                        'timerange': (1529272800.0, 1529877600.0)},
                                {'duration': 396134.0,
                                'sla_broken': False,
                                'subresults': [{
                                    'sla_broken': False,
                                    'requirement': (0, 'min', 0.0),
                                    'error_instances': [],
                                    'deviation_info': {
                                        'deviation': 2.7202916184927326,
                                        'limit': 0.0,
                                        'levels': (0, 0),
                                        'deviation_state': 0}}],
                                'statistics': {
                                    'duration': {0: 10776, -1: 385358.0},
                                    'percentage': {0: 2.7202916184927326, -1: 97.27970838150726}},
                                'timerange': (1529877600.0, 1530273734)}]}],
                            'sla_id': 'sla_configuration_1',
                            'sla_period': 'weekly'}}}}},
 'result_code': 0}

11. Commands for Grafana

Special commands are needed in order to be able to use the Grafana plug-in — which Checkmk implements as a Datasource. Of course you can also use these commands independently of Grafana or the plug-in:

  • get_user_sites

  • get_host_names

  • get_metrics_of_host

  • get_graph_recipes

11.1. get_user_sites

A user is not necessarily allowed to access all sites. The following command can be used to find out which sites are available to the automation user. It does not require any options:

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=get_user_sites&_username=automation&_secret=myautomationsecret"

The output contains a list of the sites together with their alias:

{'result':
    [['mysite', 'My Site Alias'],
    ['myremote1', 'My Remote 1 Alias']]
}

11.2. get_host_names

A typical Web-API command always targets a single specific Checkmk site. With this command you can get a list of the host names for all connected sites. It doesn’t matter whether there are remote sites that are configured via the one being retrieved, or if there is only a reading connection. The Checkmk command only outputs the names of the hosts that are known to the individual sites. You can optionally limit the query to a single site:

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=get_host_names&_username=automation&_secret=myautomationsecret" -d 'request={"site_id":"mysite"}'

The output will contain a simple list of the host names:

{'result':
    ['myhost123', 'myhost234', 'myremotehost345']
}

Important: The response does not contain any information showing on which site the host is running. Duplicate names can therefore no longer be assigned.

11.3. get_metrics_of_host

You can use this command when you need information about what metrics a host uses. It is also very suitable as a basis for the already long-available command get_graph. Here too you can optionally specify a particular site:

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=get_metrics_of_host&_username=automation&_secret=myautomationsecret" -d 'request={"hostname":"myremotehost345", "site_id":"myremote1"}'

Since the answer includes the metrics of all services for the host, here is only a small excerpt as an example of what such an output could look like. As you can see here, the output can also include services that do not have any metrics:

{'result':
    {'CPU utilization':
        {'check_command': 'check_mk-kernel.util',
         'metrics':
            {'system': {'index': 3, 'name': 'system', 'title': 'System'},
             'user': {'index': 2, 'name': 'user', 'title': 'User'},
             'util': {'index': 0, 'name': 'util', 'title': 'CPU utilization'},
             'wait': {'index': 1, 'name': 'io_wait', 'title': 'I/O-wait'}
            }
        }
    }
    {'Mount options of /':
        {'check_command': 'check_mk-mounts',
         'metrics': {}
        }
    }
}

11.4. get_graph_recipes

With this command you get all of the necessary information for a concrete graph. Such a graph definition contains not only the metrics involved, but also their colours, units, titles, the resolution, etc. The request part of the command is very similar to that of the get_graph command. You do not need to specify a time period here, since it only applies to the general data. Here is an example for the CPU load service:

root@linux# curl "http://myserver/mysite/check_mk/webapi.py?action=get_graph_recipes&_username=automation&_secret=myautomationsecret" -d 'request={"specification":["template", {"service_description": "CPU load", "graph_index": 0, "host_name": "myhost123", "site": "mysite"}]}'

And the response to the query for this service could then look like this:

{'result': [{'consolidation_function': 'max',
             'explicit_vertical_range': (None, None),
             'horizontal_rules': [(20.0, '20.0', '#ffff00', u'Warning'),
                                  (40.0, '40.0', '#ff0000', u'Critical')],
             'metrics': [{'color': '#00d1ff',
                          'expression': ('rrd',
                                         'heute',
                                         u'heute',
                                         u'CPU load',
                                         'load1',
                                         None,
                                         1.0),
                          'line_type': 'area',
                          'title': u'CPU load average of last minute',
                          'unit': ''},
                         {'color': '#428399',
                          'expression': ('rrd',
                                         'heute',
                                         u'heute',
                                         u'CPU load',
                                         'load5',
                                         None,
                                         1.0),
                          'line_type': 'line',
                          'title': u'CPU load average of last 5 minutes',
                          'unit': ''},
                         {'color': '#2c5766',
                          'expression': ('rrd',
                                         'heute',
                                         u'heute',
                                         u'CPU load',
                                         'load15',
                                         None,
                                         1.0),
                          'line_type': 'line',
                          'title': u'CPU load average of last 15 minutes',
                          'unit': ''}],
             'omit_zero_metrics': False,
             'specification': ('template',
                               {u'graph_index': 0,
                                u'host_name': u'heute',
                                u'service_description': u'CPU load',
                                u'site': u'heute'}),
             'title': u'CPU Load - 4.0  CPU Cores',
             'unit': ''}],
 'result_code': 0}

12. Retrieval options and command overview

12.1. Commands

Command request_format output_format Required Optional

Host commands

get_host

-

python

host name

effective_attributes

add_host

python

-

host name, folder

attributes, nodes, create_folders

edit_host

python

-

host name

unset_attributes, attributes, nodes

delete_host

-

-

host name

-

delete_hosts

-

-

host names

-

get_all_hosts

-

python

-

effective_attributes

discover_services

-

-

host name

mode

Directory commands

get_folder

-

-

folder

effective_attributes

add_folder

-

-

folder, attributes

create_parent_folders

edit_folder

-

-

folder

attributes, configuration_hash

delete_folder

-

-

folder

configuration_hash

get_all_folder

-

-

-

effective_attributes

Group commands

add_contactgroup, add_hostgroup, add_servicegroup

-

-

group name, alias, customer*

nagvis_maps**

edit_contactgroup, edit_hostgroup, edit_servicegroup

-

-

group name, alias, customer*

nagvis_maps**

delete_contactgroup, delete_hostgroup, delete_servicegroup

-

-

group name

get_all_contactgroups, get_all_hostgroups, get_all_servicegroups

-

-

-

-

Group commands

add_users

-

-

users

-

edit_users

-

-

users

-

delete_users

-

-

users

-

get_all_users

-

-

-

-

Ruleset commands

get_ruleset

-

Python

ruleset_name

-

set_ruleset

Python

-

ruleset_name, ruleset

configuration_hash

get_ruleset_info

-

-

-

-

Host tag commands

get_hosttags

-

-

-

-

set_hosttags

-

-

tag_groups, aux_tags

configuration_hash

Site commands

get_site

-

Python

site_id

-

set_site

Python

-

site_config, site_id

configuration_hash

delete_site

-

-

site_id

configuration_hash

login_site

-

-

site_id, username, password

-

logout_site

-

-

site_id

-

Grafana commands

get_user_sites

-

-

-

-

get_host_names

-

-

-

site_id

get_metrics_of_host

-

-

hostname

site_id

get_graph_recipes

-

-

specification

-

Other commands

activate_changes

-

-

-

mode, sites, allow_foreign_changes, comment

bake_agents

-

-

-

-

get_graph

-

-

specification, data_range

-

* Only used with the CME Checkmk Enterprise Managed Services Edition

** Only for contact group commands

On this page