Monitoring and Alerting

Applies to the MSP and organization portals.

What it is

Monitoring and alerting connects Solidlio to the systems that already watch your infrastructure — Zabbix and ConnectWise Automate — and turns what they see into work: alerts attached to the right client and the right device, and tickets raised only when your rules say so.

It does not replace your monitoring server. Zabbix keeps deciding what a problem is; Solidlio decides who owns it, whether it becomes a ticket, and when it stops.

Concepts

Alert ownership

An alert belongs to one organization. That organization is decided by the host that raised it, not by whose integration polled it. One Zabbix server can front fifty client companies; the group mappings on the integration and the monitoring links on each asset are what place each problem with the right customer.

An alert that cannot be placed — an unmapped host, or a problem with no host at all — goes to the MSP’s own organization for triage. It is never assigned to an arbitrary customer.

Alert identity

An alert is identified by (organization, source, external id). This matters because a Zabbix event id and an Automate alert id are only unique inside one monitoring server. Two customers running their own Zabbix will both eventually emit event 12345; they are two different alerts and Solidlio stores them as two different rows.

Alert states

The lifecycle is one-directional: ACTIVE → ACKNOWLEDGED → RESOLVED. Both hops are available from the alert detail page and from the MSP alert list. A suppressed alert is recorded so the history is honest, but never raises a ticket.

IGNORED sits outside that lifecycle. It is user-driven and sticky — the alert sync will not flip an ignored alert back to ACTIVE — and it is deliberately NOT written back to Zabbix or Automate, because ignoring is a decision about what this tenant wants to see, not a claim that the underlying problem is handled. Ignored alerts are excluded from the default list and from every headline count; ask for them by name (?status=IGNORED, or the Ignored filter) to see them, and Stop Ignoring returns an alert to whichever state its own timestamps say it was in.

Severity

Solidlio uses the Zabbix severity ladder end to end: INFO, WARNING, HIGH, CRITICAL, DISASTER. There is no LOW or MEDIUM — a UI offering them would be offering something the API rejects.

Severity maps to ticket priority when an alert raises a ticket:

Roles and permissions

Every monitoring mutation floors at organization administrator. The hierarchy is platform administrator > MSP administrator > MSP technician > organization administrator > power user > CUSTOMER`, so MSP technicians clear the floor and organization power users do not.

The two reads that stay open to everyone are the ones that describe the caller’s own machines — “your file server is down” is exactly what an end customer should be able to see, and it is what the customer portal renders.

Power users see monitoring in their navigation and can read the alerts; the action buttons are hidden from them rather than shown and refused. On the asset detail’s Monitoring tab the per-machine switches degrade to plain “On”/“Off” text for the same reason.

What each portal sees

An MSP can narrow to one client with ?organizationId=. An id outside the visible set is refused with 403, never silently ignored.

Walkthroughs

Connect Zabbix

1. Go to Integrations → Zabbix (/msp/integrations/zabbix or /org/integrations/zabbix).
2. Solidlio detects the server version on connect and caches it.
3. Save. The connection is tested before it is stored.
4. Open the Hosts tab to confirm Solidlio can see your inventory.
5. Under Group mappings, map each Zabbix host group to the client organization that owns it. Without at least one mapping, alert sync logs “No group mappings configured” and imports nothing.
6. Under Sync, enable host sync and alert sync and set their intervals. Alert sync defaults to every 5 minutes, host sync to every 60.

Solidlio speaks Zabbix 6.0 through 7.x. It sends an Authorization: Bearer header on 6.4 and later, and falls back to the legacy body property on older servers — the auth body property was removed entirely in 7.2.

Connect ConnectWise Automate

1. Go to Integrations → ConnectWise Automate.
2. Enter the server URL, your Automate username and password, and a two-factor passcode if your instance requires one. The Partner ClientId comes from Solidlio’s server configuration; you do not supply it.
3. Save. Solidlio exchanges the credentials for an AccessToken and stores the connection encrypted.
4. Run Discover to pull the client companies and groups from Automate, then map each one to a Solidlio organization.
5. Under Sync settings, choose what to sync (computers, software, services, drives, patches, groups) and at what cadence.

Automate alert ingestion runs on the interval set as Alert sync interval in Settings → Monitoring, default 5 minutes.

Set the alert policy

Settings → Monitoring (/msp/settings/monitoring or /org/settings/monitoring).

On the MSP portal, pick the client you are configuring from the selector at the top; “My organization” configures the MSP’s own.

Press Save policy. Press Sync now to pull immediately rather than waiting for the next scheduled run.

Link a host to an asset

Alerts name a device only if the host that raised them is linked to a Solidlio asset. Host sync does this automatically; you do it by hand when a machine was created in Solidlio first, or when the matcher declined to guess.

1. Settings → Monitoring → Monitored hosts.
2. Find the host. If it already resolves to an asset, the asset name is shown with an Unlink button.
3. Otherwise pick an asset from the selector and press Link.

The automatic matcher tries, in order: an existing integration mapping, an existing monitoring row for the same external id, serial number, MAC address, then hostname. It only ever matches inside one organization, and it abandons a strategy that finds more than one candidate rather than guessing — a duplicate asset a human can merge is less damaging than two machines merged into one. Placeholder serials (Default string, To be filled by O.E.M., and fifteen others) are ignored.

Work an alert

1. Monitoring shows the current picture; Monitoring → Alerts is the full list. On the MSP portal each row names the client that raised it, and you can filter by client, severity and status.
2. Open an alert. The detail page shows the message, the asset, the linked ticket, and who acknowledged it.
3. Acknowledge — records who and when, and acknowledges the problem in Zabbix or Automate as well.
4. Create Ticket — raises a ticket under the alert’s organization (not yours, if you are the MSP), tagged auto-generated, monitoring and the source name, with the asset attached. An alert can carry only one ticket; a second attempt is refused.
5. Resolve — closes it in Solidlio and in the source system.

Mute a noisy machine

A machine that is known-bad and already being dealt with should stop generating tickets without losing its monitoring link — unlinking it only lasts until the next host sync.

Open the asset (/msp/assets/{id} or /org/assets/{id}), go to Monitoring, and turn off Alerting on the row for the source you want quiet. The same tab shows, per source: the live status, what the last sync recorded, when it last checked, and how many alerts are currently active.

• Alerting off — the machine’s alerts are still recorded and still visible; they simply stop raising tickets.
• Monitoring off — additionally stops live status polling (the row reports “Monitoring off” rather than probing) and excludes the machine from maintenance-window suppression sync.

Both switches floor at organization administrator, so a technician or power user sees the state as plain text rather than an operable control.

Suppress alerts for a planned outage

1. Create a maintenance window under Changes → Maintenance (/msp/changes/maintenance or /org/changes/maintenance) with Suppress alerts on, and add the affected assets.
2. When the window activates, Solidlio pushes a matching maintenance period into Zabbix (with data collection off) and acknowledges the open Automate alerts on those computers.
3. Independently, any alert imported for one of those assets while the window is open is stored SUPPRESSED and raises no ticket. This is the part that covers ConnectWise Automate, which has no maintenance-window API of its own.

Configuration reference

Alert policy (MonitoringConfig)

Per-machine switches (AssetMonitoring)

Where connections live

Solidlio holds monitoring settings in two places, and they answer different questions:

• Connections live on the Integration Hub (Integration + ZabbixConfig). This is what the Zabbix and Automate pages write.
• Alert policy lives on MonitoringConfig, edited at Settings → Monitoring.

Plan tiers

Monitoring carries no plan gate. No tier unlocks or restricts Zabbix, ConnectWise Automate, alert ingestion, alert-to-ticket rules, host linking or maintenance suppression. Reads and writes are governed by role and tenancy only.

Troubleshooting

Limits and known behaviour

• Alert lists are capped at 100 rows per request (default 50). The monitoring dashboard requests 50 and the alerts list 100, and both filter in the browser — beyond 100 alerts, use the source, status, severity and organizationId filters to narrow the query rather than scrolling.
• IGNORED is unused. The status exists in the model and renders a badge, but nothing writes it.
• Ticket auto-creation is off by default, including for organizations that connect through the Integration Hub and never open the settings page.
• ConnectWise Automate has no maintenance-window API. Solidlio acknowledges the open alerts on the affected computers when a window activates, and suppresses newly imported alerts tenant-side. It cannot stop Automate from generating them.
• Automate maintenance is not “un-done”. Clearing the window is a no-op; alerts fired after it ends flow normally.
• Maintenance suppression needs a linked asset. An alert from a host with no monitoring link cannot be matched to a maintenance window.
• Deduplication is per problem, per machine. It matches on organization, source, alert title and asset. Two different checks on the same box are two tickets, by design.
• Auto-resolve never re-opens. A ticket already RESOLVED or CLOSED is left alone when its alert clears again.
• Zabbix problem.get returns no host details. Solidlio reads host identity from the event’s own fields; a Zabbix problem with no host is attributed to the MSP’s own organization.
• Live device actions are Automate-only. Reboot, shutdown and script execution exist for ConnectWise Automate; Zabbix hosts can only be enabled or disabled.
• There is no bulk acknowledge. Alerts are acknowledged one at a time.
• Nothing arrives faster than the configured sync interval.