App definition and data modelling

This section describes how to structure your monitor inventory with tags, and how to group monitors into applications with their own health rules, SLA targets, notifications and dependency views.

The data model

Mugnsoft uses a simple, three-level model:

• Monitors are the atomic unit: each check (a browser script, a URL probe, a ping, an SNMP device…) produces a status and performance data.
• Tags are free-form labels attached to monitors. They are the glue of the platform: reports, downtimes, user visibility and application membership are all resolved through tags.
• Applications group monitors (via tags) and/or other applications into a business-level object with its own aggregated status, SLA history and notifications.

Recommended tag scheme

Tags are the foundation of everything else, so agree on a naming convention before creating monitors at scale. A scheme that works well in practice:

• one tag per business service (crm, webshop, intranet),
• one tag per environment (prod, uat, dev),
• one tag per owning team (team-infra, team-app),
• optional tags per tier (frontend, backend, db).

A monitor can carry several tags; every scoping feature (apps, reports, downtimes, user visibility) computes its monitor list as all monitors carrying at least one of the selected tags, plus any explicitly selected monitors.

Defining an application

Applications are managed from the App page. Users in the ADMIN group can create, edit or delete applications; USER-group users can manage the applications matching their tags.

An application is defined by:

• Display name, description, state (on/off) and an optional logo image (uploaded after saving; shown on the app tile and in the dependency views).
• Membership — at least one of:
  • tags: every monitor of any type carrying one of these tags becomes a member,
  • applications: one or more existing apps become children of this app (see Nested applications).
• Business rule, weights, SLA targets and notifications, described below.

Business rule: how the app status is computed

The business rule (bRule) decides how the member statuses roll up into one application status:

Disabled members are excluded from the computation.

Per-type weights

With the weighted rule, each monitor type (API, DB, discovery, exec, nslookup, ping, SNMP device, WMI device, system, TCP, UDP, URL) has a configurable integer weight (default 1). Give a higher weight to the types that really define user-facing availability — for example, weight browser scripts and URLs above pings — so a failed ping cannot outrank a failed transaction.

SLA targets and history

Each application carries three monthly SLA targets (uptime percentages):

• Minor (default 99), Major (default 95), Critical (default 90).

The webserver computes a monthly SLA history (up to 24 months) from the application’s status-change timeline: uptime percentage, cumulated outage duration and outage count per month, graded against the three targets.

SLA exclusions — a list of date/time windows with a reason (for example an agreed maintenance) — are subtracted from the outage time before the uptime percentage is computed. Changing the exclusion list invalidates and rebuilds the affected months.

Notifications and remediation

Applications have the same alerting options as monitors, applied to the aggregated app status:

• email, Slack, Teams and PagerDuty notifications, each independently triggered on failure and/or on status change,
• a notify threshold (notifyStatus: critical/major/minor) and a notify after counter to suppress flapping,
• optional remediation scripts executed on failure and/or on status change, with a configurable timeout.

Nested applications

An application may contain other applications instead of (or in addition to) tags. Child app statuses are aggregated by the parent’s business rule, which lets you model hierarchies such as:

Digital workplace (parent app)
├── Mail (app: tags mail-prod)
├── Intranet (app: tags intranet-prod)
└── Video conferencing (app: tags visio-prod)

Nesting is resolved recursively everywhere applications are used — including downtime scoping, where selecting a parent app puts all monitors of its descendants in maintenance.

Dependency views

Two visualizations render the app model:

• Application dependency map — an interactive 2D graph of the applications, their child apps and member monitors, colored by current status. Use it to spot which member drags an application down.
• 3D plane (App 3D) — a 3D scene where each application is a tile laid out on a plane, useful as a NOC/wallboard view. The layout is per user: drag tiles to arrange them, save the layout and the camera position, and optionally upload a custom background. Layout, camera and background can be reset at any time.

Importing applications in bulk

Applications can be created via import/export operations with the app monitor type. The CSV line format is:

app;displayName;description;state (on|off);applications;tags;businessRule (worst|best|highestPercentage|weighted);WeightApi;WeightDb;WeightDiscovery;WeightExec;WeightNslookup;WeightPing;WeightSnmpdevice;WeightWmidevice;WeightSys;WeightTcp;WeightUdp;WeightUrl;threshCri;threshMaj;threshMin;notifyStatus;notifyAfter;emailOnF;emailOnSC;emailR;slackOnF;slackOnSC;slackChan;slackTok;teamsOnF;teamsOnSC;teamsWH;pdOnF;pdOnSC;pdAPI;ScriptOnF;ScriptOnSC;ScriptAction;ScriptActionT;image

Either applications or tags is required; businessRule defaults to worst.

Modelling guidance

• One application per business service, named as the business names it — applications are what appear on reports and wallboards.
• Membership through tags, not monitor lists: new monitors tagged consistently join the right applications automatically.
• Use nesting sparingly — two levels (service → macro-service) cover most organizations; deeper trees make status roll-ups hard to reason about.
• Pick worst unless you have a reason not to: it is the most conservative rule. Move to weighted only once weights are agreed with the service owner.
• Set SLA targets to the contractual values and record maintenance windows as SLA exclusions rather than deleting history.

See also

• Monitor operations — creating the monitors and tags applications are built from
• Report operations — application reports and per-tag reporting
• Downtime operations — putting whole applications in maintenance
• Import/export operations — bulk-creating applications from CSV

Translations

• fr: Definition d'applications et modelisation des donnees