shadowdao
119d376029
Build and deploy / deploy (push) Successful in 24s
Verified every page against the live admin panel on whp01 (read-only). Five existing articles rewritten; one new article added; customer-facing backups article updated to match server reality. Article changes - overview: super admin = the root user only (no UI to add another); WHMCS portal route doesn't apply for admin; accurate sidebar map of every admin-only section; customer backups don't cover server config (multiple locations, not just /etc — full-server backup is the right safety net). - server-settings: walked all six tabs (System / Services / Mail / DNS / Network & SSL / Security); clarified that host Apache + PHP-FPM serve the WHP control panel, not customer sites; that MySQL runs as a container so host MySQL config is client-facing; that custom container needs are met by publishing a custom Docker image (linked to repo.anhonesthost.net/cloud-hosting-platform/ for examples). - coraza-waf: real Firing rules / CRS catalog / Activity tabs; global WAF mode pill (off/detect/enforce); per-rule + per-host overrides; Ask AI link; security.db source-of-truth + SIGHUP reload note. - site-monitoring: split into the three actual admin pages — AI Monitor dashboard, Issues, Ignore Rules — with stat tiles + health-check timeline + ignore-rule AND-semantics. - user-management: account types corrected to full / domain_dns / mail_dns (verified in web-files/pages/user-management.php:26); system users are protected against deletion (verified is_protected_user in web-files/libs/usermgmt.php:697); delegated users are admin-editable (not read-only); suspension page is served by haproxy's 503 errorfile (verified in haproxy-manager-base/haproxy_tarpit_config.txt:31) so troubleshooting points at haproxy reload / container logs. - new admin/backups: customer-data backups vs full-server backups; auto-backups only run with a default target; how to add global vs per-customer targets; how to fire on-demand backups for any user; troubleshooting around missing targets / failed test / disk pressure. - how-to/backups (customer): aside about default-target requirement; new section explaining what full-server backups cover vs customer backups (managed plans + VDS covered by AnHonestHost; elsewhere is the server operator's responsibility). New components / tooling - admin-signin partial: 'sign in directly at :8443 as root'. - Head.astro override + medium-zoom: click-to-zoom lightbox on every article image; auto-reattaches after Starlight client navigation. - capture-admin.ts: read-only Playwright capture for admin docs with multi-pass redaction (server hostnames, mail server, customer domains, customer usernames in table cells, IPs except RFC1918 and public resolvers, password/key/token/secret/api input values, plus LiteLLM URLs, model names, JWT/sk-prefix API keys, root → admin).
114 lines
5.3 KiB
Plaintext
114 lines
5.3 KiB
Plaintext
---
|
|
title: AI Monitor, Issues & Ignore Rules
|
|
description: The three admin pages that drive the Site Monitoring add-on — AI Monitor dashboard, Issues, and Ignore Rules.
|
|
sidebar:
|
|
order: 4
|
|
---
|
|
|
|
import { Aside } from '@astrojs/starlight/components';
|
|
import SuperAdmin from '~/content/partials/super-admin-callout.mdx';
|
|
import AdminSignIn from '~/content/partials/admin-signin.mdx';
|
|
import Support from '~/content/partials/support-link.mdx';
|
|
|
|
<SuperAdmin />
|
|
|
|
[Site Monitoring](/whp/add-ons/monitoring/) is the customer-facing alerting add-on. The admin side exposes three pages — together they let you tune what gets monitored, what surfaces as a customer-visible issue, and what gets suppressed.
|
|
|
|
## Sign in as super admin
|
|
|
|
<AdminSignIn />
|
|
|
|
## AI Monitor (admin dashboard)
|
|
|
|
Sidebar → **AI Monitor → Dashboard**. The operational heartbeat of the whole monitoring pipeline.
|
|
|
|
|
|
|
|
Panels:
|
|
|
|
- **AI Log Monitor Status** — overall on/off plus three sub-statuses:
|
|
- **Minute-cadence poll** — the cron that scans logs every minute.
|
|
- **Health API** — the internal API that exposes per-container health.
|
|
- **HAProxy stats** — the proxy stats feed used for error-rate tracking.
|
|
- **Stat tiles** — Last Run, Errors Tracked, Remediations, API Calls Today (with a rate-limit denominator).
|
|
- **Health Check Timeline (last 7d)** — every state transition (`cpu`, `swap`, `haproxy`, etc.) with its severity and an **AI Diagnosis** explanation.
|
|
|
|
Use this page to confirm the pipeline is healthy and to drill into recent state changes. The AI Diagnosis text gives a plain-language summary of *why* a transition happened — useful for context before you act.
|
|
|
|
## Issues
|
|
|
|
Sidebar → **AI Monitor → Issues**. The customer-visible findings, server-wide.
|
|
|
|
|
|
|
|
Four stat tiles at the top:
|
|
|
|
- **Critical** — open critical-severity issues.
|
|
- **Warning** — open warning-severity issues.
|
|
- **Auto-resolved (review)** — issues the monitor closed on its own that may still need a human glance.
|
|
- **Active suppressions** — issues currently muted by an Ignore Rule.
|
|
|
|
Filter row: Scope (All / specific user), Status (Open / Closed / All), Severity, Source, Signature prefix.
|
|
|
|
Bulk actions: **Mark Fixed**, **Ignore**, **Delete**.
|
|
|
|
Each row has its own quick-actions: **Fix** (close it) and **Ignore** (create an ignore rule from this row's match criteria).
|
|
|
|
## Ignore Rules
|
|
|
|
Sidebar → **AI Monitor → Ignore Rules**. Match criteria that prevent matching findings from becoming customer-visible issues.
|
|
|
|
|
|
|
|
Each rule has these fields:
|
|
|
|
- **Scope** — `user` (just one customer) or `global` (every customer).
|
|
- **Target** — the user or domain the rule applies to.
|
|
- **Match** — a comma-separated set of `field=value` predicates (e.g. `cat=degraded & title~"Beaver Builder cache files missing"`). Match fields combine with **AND** semantics — every predicate must match.
|
|
- **Reason** — a short note for future-you explaining why the rule exists.
|
|
- **Hits / Last hit** — how often the rule has matched, and when.
|
|
- **Enabled** — toggle without deleting.
|
|
|
|
<Aside type="tip">
|
|
Prefer **per-user** ignores over global. Global rules silence the finding for everyone on the server.
|
|
</Aside>
|
|
|
|
## Common tasks
|
|
|
|
### Mute a known-noisy finding for one customer
|
|
|
|
1. Open **Issues**, find the row.
|
|
2. Click the row's **Ignore** action — that pre-fills an Ignore Rule with the matching criteria scoped to that user.
|
|
3. Add a **Reason** so future-you (or someone else on the team) understands why it exists.
|
|
4. Save. Future matching findings will be suppressed; the **Active suppressions** tile will tick up.
|
|
|
|
### Investigate an "Auto-resolved (review)" issue
|
|
|
|
These are issues where the underlying signal recovered before a human looked at them. Open the row to see the AI Diagnosis and the original detection. If the resolution looks legitimate, click **Mark Fixed**; if you're suspicious, leave it open and add a comment for context.
|
|
|
|
### Tune brute-force detection
|
|
|
|
Brute-force rules live in **Coraza Rules** (rule families CRS-913 / 921 / 942 / 949) rather than AI Monitor. AI Monitor surfaces the *effects* (error spikes) once a brute-force pattern fires, but the matching itself is in the WAF — see [Coraza WAF rules](/whp/admin/coraza-waf/).
|
|
|
|
## Routing alerts
|
|
|
|
Customer email alerts are sent via the SMTP relay configured on **Server Settings → Mail → Outbound Email (SMTP)**. Toggle **Enable Outbound Email** off there if you need to silence outbound notifications for a maintenance window.
|
|
|
|
## Troubleshooting
|
|
|
|
**Pipeline shows "stale" — Last Run more than a few minutes ago.** Check the cron's container on **Server Settings → Services → Docker Container Management**. The monitor poll is `whp-monitor-poll`.
|
|
|
|
**Issues appearing for a known noisy site.** Add an Ignore Rule scoped to that user.
|
|
|
|
**No customer alerts arriving.** Confirm Outbound Email is enabled and the SMTP relay is reachable from the server.
|
|
|
|
## Related
|
|
|
|
- [Site Monitoring add-on](/whp/add-ons/monitoring/) — the customer-facing side.
|
|
- [Coraza WAF rules](/whp/admin/coraza-waf/) — request-level firewall.
|
|
- [Server settings & services](/whp/admin/server-settings/) — SMTP relay config for outbound alerts.
|
|
|
|
## Still stuck?
|
|
|
|
<Support />
|