Monitor Configuration
The Monitor configuration file controls the probe identity, connectivity, scheduling behavior, browser automation settings, auto-thresholding, and vault integration.
monitor.json from a few guided questions.
Service Configuration (monitor.json)
This file must be in the same directory as the executable.
Full Example
{
"name": "probe-paris-01",
"port": "8051",
"webserver": "192.168.1.100:8050",
"integratorEndPoint": "192.168.1.100:8052",
"location": "Paris, France",
"description": "Production monitoring probe - Paris DC",
"logLevel": "info",
"concurrencyLimit": "100",
"dataRetention": "336",
"backupInterval": "24",
"nbDaysBackup": "336",
"maxBackups": "5",
"maxSize": "10",
"maxAge": "28",
"logCompress": "true",
"chromeBinPath": "C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe",
"firefoxBinPath": "",
"edgeBinPath": "",
"chromeVersion": "",
"firefoxVersion": "",
"edgeVersion": "",
"autoThreshold": "true",
"autoThresholdRange": "24",
"autoThreshCri": "8",
"autoThreshMaj": "6",
"autoThreshMin": "4",
"autoThreshTimeout": "10",
"autoTransThreshold": "false",
"vaultType": "",
"hashiCorpVaultUrl": "",
"hashiCorpVaultToken": "",
"azureKVUrl": "",
"cyberarkConjurUrl": ""
}
Settings Reference
Identity & Network
| Field | Type | Description | Default | Required |
|---|---|---|---|---|
name |
string | Unique probe identifier. Must be unique across all probes | - | Yes |
port |
string | TCP port for the Monitor REST API | "8051" |
No |
webserver |
string | Webserver IP:port for self-registration | - | Yes |
integratorEndPoint |
string | Integrator IP:port for data forwarding. Leave empty to skip | "" |
No |
location |
string | Geographic or logical location label (displayed in UI) | "" |
No |
description |
string | Free-text description of this probe | "" |
No |
Data Management
| Field | Type | Description | Default |
|---|---|---|---|
concurrencyLimit |
string | Maximum concurrent monitor executions (semaphore limit) | "100" |
dataRetention |
string | Hours to retain monitoring data in the embedded key-value store | "336" (14 days) |
purgeStatusChangeDataNb |
string | Max status-change records to keep per monitor | "250" |
backupInterval |
string | Hours between automatic KV store backups | "24" |
nbDaysBackup |
string | Hours to keep backup files | "336" |
Logging
| Field | Type | Description | Default |
|---|---|---|---|
logLevel |
string | Log verbosity: debug, info, warn, error |
"info" |
maxBackups |
string | Number of rotated log files to keep | "5" |
maxSize |
string | Maximum log file size in MB | "10" |
maxAge |
string | Maximum log file age in days | "28" |
logCompress |
string | Compress rotated log files: "true" or "false" |
"true" |
Browser Configuration
Required for Web UI / EUM monitors that use Selenium WebDriver:
| Field | Type | Description |
|---|---|---|
chromeBinPath |
string | Full path to the Chrome executable. If empty, auto-detected |
firefoxBinPath |
string | Full path to the Firefox executable |
edgeBinPath |
string | Full path to the Microsoft Edge executable |
chromeVersion |
string | Chrome version string. If empty, auto-detected from the binary |
firefoxVersion |
string | Firefox version string |
edgeVersion |
string | Edge version string |
Auto-Thresholding
Automatically calculate performance thresholds based on historical data using standard deviation analysis:
| Field | Type | Description | Default |
|---|---|---|---|
autoThreshold |
string | Enable auto-thresholding for monitors | "true" |
autoThresholdRange |
string | Hours of historical data to analyze: 24, 168, 336, 672 or 1344 (1d / 7d / 14d / 28d / 56d) |
"24" |
autoThreshCri |
string | Standard deviation multiplier for Critical threshold | "8" |
autoThreshMaj |
string | Standard deviation multiplier for Major threshold | "6" |
autoThreshMin |
string | Standard deviation multiplier for Minor threshold | "4" |
autoThreshTimeout |
string | Standard deviation multiplier for the execution timeout value (timeout = mean + mult * stddev) |
"10" |
autoTransThreshold |
string | Enable auto-thresholding for individual transaction steps | "false" |
How it works: A nightly job (02:00) collects the last N hours of performance data (autoThresholdRange), calculates the mean and standard deviation, then sets thresholds as:
Timeout = mean + (autoThreshTimeout * stddev) // hard execution cap
Critical = mean + (autoThreshCri * stddev)
Major = mean + (autoThreshMaj * stddev)
Minor = mean + (autoThreshMin * stddev)
Notes:
- Only successful executions are included in the mean/stddev — failures and timeouts are excluded so a bad period does not poison the baseline.
- Only enabled monitors (
state = on) are updated. autoTransThresholdruns the same computation per transaction step (02:05).- Ping monitors additionally get jitter thresholds (
jitterThreshCri/Maj/Min) computed from jitter mean + stddev with the same multipliers.
mean + k*stddev assumes a roughly normal distribution. When the baseline window is very stable the stddev is near zero, so the timeout sits just above the mean and normal daytime variance can trip a false outage. Mitigations: use a longer window (168+ hours) so seasonality is captured, and raise autoThreshTimeout so the hard cap keeps clear headroom above the soft Critical threshold.
Percentile method (robust, recommended for noisy latency)
Set thresholdMethod to "percentile" to derive thresholds from the empirical latency distribution instead of mean+stddev. Latency is right-skewed, so percentiles match SLO semantics and resist outliers. The timeout is a high percentile times a safety factor, clamped to an absolute floor, which removes the near-zero-spread false-outage trap above.
| Field | Type | Description | Default |
|---|---|---|---|
thresholdMethod |
string | "sigma" (legacy mean+stddev) or "percentile" |
"sigma" |
autoThreshMinPct |
string | Percentile (0-100) for the Minor threshold | "95" |
autoThreshMajPct |
string | Percentile for the Major threshold | "98" |
autoThreshCriPct |
string | Percentile for the Critical threshold | "99" |
autoThreshTimeoutPct |
string | Percentile used as the timeout base | "99.9" |
autoThreshTimeoutFactor |
string | Multiplier applied to the timeout percentile | "2" |
autoThreshTimeoutFloor |
string | Absolute floor (ms) for the computed timeout | "1000" |
autoThreshMinSamples |
string | Minimum successful samples; below this the baseline is left unchanged (per step for transactions) | "200" |
The method applies to all monitor types — url, api, tcp, udp, ping, nslookup, db, snmp, wmi, sys and EUM transaction steps (exec). For EUM the per-step Minor/Major thresholds use autoThreshMinPct / autoThreshCriPct; steps below autoThreshMinSamples fall back to the legacy max×coefficient model.
Alert debounce (status-change flap suppression)
| Field | Type | Description | Default |
|---|---|---|---|
debounceStatusChange |
string | When "true", a status-change notification fires only after the new status has held notifyAfter+1 consecutive runs |
"false" |
On-failure alerts are already debounced by the per-monitor notifyAfter / notifyFor settings (alert only after N consecutive breaches). debounceStatusChange extends the same consecutive-run guard to status-change notifications, so a single transient sample (e.g. a one-off timeout) no longer pages on the way out and back. Reuses the monitor’s existing notifyAfter as the depth.
Vault Integration
For retrieving secrets (passwords, API keys, TOTP seeds) from external vaults at runtime:
| Field | Type | Description |
|---|---|---|
vaultType |
string | Vault provider: "hashicorp", "azure", or "cyberark". Empty to disable |
hashiCorpVaultUrl |
string | HashiCorp Vault server URL |
hashiCorpVaultToken |
string | HashiCorp Vault access token |
azureKVUrl |
string | Azure Key Vault URL |
cyberarkConjurUrl |
string | CyberArk Conjur server URL |
For how vault credentials and TOTP secrets reach EUM scenarios at runtime (VAULT_USERNAME_<urlTitle>, VAULT_PASSWORD_<urlTitle>, TOTP_SECRET_<urlTitle>), see the EUM Monitor page. For the end-to-end setup workflow, see Secret vaults.
Per-Monitor Settings
Each individual monitor has its own settings, configured via the Web UI or API. These are stored in the embedded key-value store, not in the JSON file.
Pattern Groups (URL & API)
URL and API monitors evaluate the response body with one or more pattern groups. Each group extracts a single value with its own regexp and grades it against its own thresholds. The monitor status is the most severe of every group status and the response-time status.
A single group can be configured through the legacy fields above (the primary group). Additional groups are stored in the patterns field as a JSON array; when it is set, it fully describes the evaluation (the primary group is its first entry).
Content match vs. value extraction
The primary pattern (pattern / patternUrl) works in two modes, chosen automatically by whether the regexp contains a capture group:
- Content match — no
(capture group). A plain presence check: the response body must contain the pattern (substring or regexp). If it does not, the monitor fails (ERROR). No operator or thresholds apply; response-time thresholds still grade the timing. - Value extraction — one
(capture group). The captured text is graded against the operator and Minor/Major/Critical thresholds below. This is what a pattern group is.
Additional rows in the patterns array are always value-extraction groups. (A content-match primary combined with extra value groups is not re-checked in multi-group mode — keep the primary as a content match or a value group.)
Fields per group
| Key | Description |
|---|---|
name |
Group name — used as the history bucket and chart panel title |
pattern |
Regexp with exactly one (capture group) extracting the value |
matchIndex |
Which occurrence of the pattern to read: 1 = first, 2 = second, … Use it to reach element N of a repeated field or JSON array |
comp |
Comparison operator (table below) |
min / maj / cri |
Minor / Major / Critical threshold values — a blank tier is skipped and does not contribute to the status |
enabled |
"false" keeps the group in the config but excludes it from evaluation; omitted/any other value = enabled |
datetimeFmt / datetimeTz |
Optional, only for the datetime older than operator |
Comparison operators
| Operator | Captured value is flagged when it… |
|---|---|
number > / number < / number == |
is greater than / less than / equal to the tier value (numeric) |
string == / string != |
equals / does not equal the tier value |
string contains / string not contains |
contains / does not contain the tier value |
datetime older than |
parses as a datetime whose age exceeds the tier value (a duration such as 30s, 4m, 1h); datetimeFmt / datetimeTz control parsing |
For every tier, the most severe matching tier wins; blank tiers are ignored, so a group can, for example, define only a Critical threshold.
patterns example
[
{ "name": "length", "pattern": "\"length\"\\s*:\\s*(\\d+)", "matchIndex": "1",
"comp": "number >", "min": "1000", "maj": "1500", "cri": "2000" },
{ "name": "fact", "pattern": "\"fact\":(.*)", "matchIndex": "1",
"comp": "string contains", "min": "cats", "maj": "", "cri": "" },
{ "name": "updated", "pattern": "\"updated\":\"([^\"]*)\"", "matchIndex": "1",
"comp": "datetime older than", "min": "", "maj": "1h", "cri": "24h" }
]
Per-group captured values are stored under STATUS_PATTERN/<monitor>/<group> for history charts; groups removed or renamed are swept from the store on the next monitor save.
patterns. In the Web UI, the Pattern groups grid on a URL or API monitor builds it for you. Run Test against the live endpoint, then Suggest pattern groups to auto-fill name / regexp / match index / operator from the actual response — leaving only the thresholds to set. See Monitor operations → Pattern groups.