# Configuration
The following elements are necessary to configure the plugin:
MarkLogic API Rest access configuration
Configure the necessary parameters to guarantee that the plugin can connect with the API; this configuration section is imperative.
*Example*:
```
# MarkLogic NoSQL Server access configuration
ml_server = your.marklogic.server
ml_port = 8002
ml_user = admin
ml_pass = admin
ml_realm = public
use_ssl = 0
```
##
Information directory configuration
The plugin has two work modes:
As an agent plugin, it sends messages of completed operations to the standard output as modules. The data extracted from the API is sent to the Pandora FMS server using the method configured in the configuration file.
*Example of a transfer method configuration*:
```
# Pandora Server configuration
mode = tentacle
tentacle_ip = your.pandora.server
tentacle_port = 41121
tentacle_opts =
tentacle_client = /usr/bin/tentacle_client
local_folder = /var/spool/pandora/data_in
#tentacle_client = "C:\Program Files\pandora_agent\util\tentacle_client.exe"
temp = /tmp
```
Currently, the following transfer methods are accepted:
- Tentacle (remote).
- Local copy (running in server plugin mode).
As a server plugin, the data extracted is sent as an XML, as in agent plugin mode, but in this case the operation messages are displayed in the standard error output (STDERR) and they will return a numeric value referencing the status of the execution. This kind of execution may be launched from the Pandora FMS server or the system CRON.
**Generated agent configuration**
Agent name setup
The data extracted from the MarkLogic NoSQL installation is sent to Pandora FMS, classified as agents for each significant element found on the system.
- Forests
- Databases
- Servers (services)
- Hosts
To control, and be able to find these agents in your system, it’s possible to configure a common name as **header**.
```
# Agent name personalization
agent_name_header = ML_
```
Following this example, all agents generated by the plugin will have the name (agent\_name) formatted as: *ML\_<object type>\_<Name>*
Where the object type follows the following code:
- **F**: forest
- **DB**: database
- **S**: App servers (server)
- **H**: host
Server-type (S) agents can also be configured so the generated agents include the server type in its agent\_name (HTTP, Task, webDAV, XDBC or ODBC):
```
# Show server type (http, task, webDAV, xdbc, or odbc) in the agent name.
show_server_type_in_agentname = 1
```
The resulting agent name would be: *ML\_S\_<Name> \[<type>\]*
**Please note:** If this option is enabled, all pre-existing Server-type agents will stop receiving data from the plugin, and new agents will be generated, their server type being part of their agent\_name.
**Group setup**
The agent interval and the group to which the agent belongs can both be customized with this configuration:
```
# Agent configuration
agent_interval = 300
agent_group = MarkLogic
```
You can also configure the plugin to create a group for the agents in case it doesn’t already exist.
**Please note:** do not use group auto-creation if your Pandora FMS belongs to an environment with metaconsole. Editing or creating groups in nodes with metaconsole enabled can corrupt the integrity of the synchronization of groups of the combined set of nodes and metaconsole.
If your installation doesn’t have metaconsole, groups can be auto-configured with these elements:
```
# Create Group ~ Pandora FMS Console API
# DO NOT ENABLE IT IF THERE IS AN ACTIVE METACONSOLE IN YOUR ENVIRONMENT
autocreate_group = 1
# Pandora API configuration
api_url = http://your.pandora.server/pandora_console/include/api.php
api_user = admin
api_user_pass = pandora
api_pass = 1234
# Group definition (global name: agent_group)
group_icon = Servers
```
##
Modules configuration
The following module parameters for the modules generated by the plugin can be configured using the configuration file:
- Set module intervals
- List of tags to add to the modules
- Set the module group (classifier)
- Instructions for Critical situations
- Instructions for Warning Situations
- Assigned Alert Templates
```
# Module configuration
# Module interval
module_interval = 1
# Tags (comma separated)
# Ensure tags exists in your environment
module_tags = NoSQL
# Module group (default)
module_group =
# Warning instructions
#warning_instructions = Some text to guide team to solve a warning condition
# Critical instructions
#critical_instructions = Some text to guide team to solve a critical condition
# Define as many tokens as templates are needed to be applied
# global_alerts = critical condition
# global_alerts = warning condition
```
##
Monitoring customization
You can control the elements of your infrastructure to be monitored:
```
# Information filter
check_hosts = 1
check_databases = 1
check_forests = 1
check_servers = 1
And choose whether you want to monitor the App servers’ ports:
check_server_ports = 1
```
This option allows to monitor the connectivity of the App servers by creating a remote TCP module which checks the status of the ports.
You can also customize the level of detail (number of modules) generated by the plugin by enabling or disabling the detailed mode:
```
# Detailed information (generate extra modules)
show_detailed_hosts = 0
show_detailed_databases = 0
show_detailed_forests = 0
show_detailed_servers = 1
```
**Note**: It is recommended to enable the detailed information in the service entity modules.
You can configure item exceptions to avoid monitoring unwanted entities:
```
# Databases
# System databases: triggers, modules, security, schema
exlude_databases =
# Forests
# System forests: triggers, modules, security, schema
exlude_forests =
# Servers
exlude_servers =
```