Skip to content

Community hub

The community hub (community.vesana.org) is the central distribution channel for device profiles — ready-made definitions for SNMP/SSH/agent checks per device type, curated and verified against real hardware. Instead of building every profile yourself, you search the hub and import whatever fits your environment.

How access works

Your Vesana instance doesn't need to be publicly reachable itself — every hub request goes server-to-server through your own backend process. The frontend only ever talks to your own API, which in turn contacts the hub. If the hub is unreachable, the UI shows that cleanly (no crash, just "community unreachable") — the rest of the instance keeps working unaffected.

Browsing profiles

/profiles → Browse community:

  • Full-text search + filter by category/vendor
  • Each result shows whether it's compatible with your Vesana version and whether it's already imported
  • The detail view shows all profile checks before you import

Importing

During import, Vesana asks whether referenced monitoring scripts should come along too (see "Scripts travel along" below). After that, the profile lives locally on your instance — editable like any profile you create yourself, independent of the hub.

An imported profile remembers where it came from (source ID and the version it was imported at), so Vesana can later tell whether a newer version is available in the hub.

Updates: preview, then apply

The hub keeps evolving profiles — new checks, corrected OIDs, better thresholds, improved scripts and detection rules. For every imported profile Vesana checks whether the hub has a newer version (/profiles → Community updates); one button updates all community profiles at once.

An update is never applied silently. The flow has two steps:

  1. Preview shows a diff: which checks are new, which existing ones the new version changes (field by field), which are dropped. Renamed checks are recognised and renamed in place — history stays, no duplicate check generations. Type conflicts (same name, different check type) are flagged and can be healed with one click; old checks no longer included can optionally go to the trash.
  2. Apply with explicit choices:
    • Add new checks to the profile — default.
    • Update connected devices — preselected: hosts already using the profile get the new checks attached. Without it the improvement only lands in the profile and the devices stay on the old state. The result also names the checks that could not be created on a device (for instance because that execution mode is not available there).
    • Optional + selectable individually: lift existing checks of the same name to the hub state (config, interval, thresholds). Off by default — your local changes to a check stay untouched until you explicitly select it for refresh.

Scripts come along. A profile update brings improved script bodies as long as the script is unchanged locally. Scripts you edited yourself stay and are reported separately in the result ("kept local"). "Update" also fetches improved detection rules; rules you adjusted yourself remain untouched.

Inherited values stay inherited. A host check only records what you really changed on it — everything else follows the profile and therefore every update. The six background telemetry checks (system overview, network, security, inventory, lifecycle, hardware) never appear in a bundle or an update dialog.

The import never overwrites your own changes unasked. You decide per check whether the hub state replaces your local version.

Active/passive variants

Profiles from the hub can contain checks in several modes — passive (via the collector), active (via the active collector), or agent, depending on what makes sense for the check type. When you apply a profile to a host, the host's actual mode decides: agent checks are only created on agent-managed hosts, passive/active SNMP and network checks need an assigned collector or run through the active collector. Checks that don't fit are never silently skipped — they're reported back as skipped_checks in the response.

Profile export/import as a bundle

Independent of the hub, you can also move profiles directly between two instances — as a JSON bundle (download via /profiles → Export) or through the API (GET /profiles/{id}/export, POST /profiles/import).

Referenced monitoring scripts travel along. A profile whose checks refer to a custom SSH/agent script only works after import on another instance if the script exists there too — otherwise the check config points at nothing and the check silently never produces a result (no data, no error). That's why the bundle carries referenced scripts as their own field; on import they're created as global, reusable scripts (idempotent — importing the same scripts twice doesn't create duplicates).

Creating global scripts is a super-admin matter (they are delivered to every tenant). If a tenant admin imports a bundle file, the profile still arrives; the bundled scripts are skipped and counted, and the affected checks stay without a script. The regular route through the hub — import and "update profile" — is unaffected: there the server fetches the bundle from the configured hub itself, and script improvements keep reaching every instance. An export only contains scripts the exporter is allowed to see; the rest is counted as omitted.

Vesana explicitly asks during import whether the scripts should come along — if you choose "without scripts", a note points out that script-dependent checks will stay without a result until you add the scripts manually.

Details on the profile UI itself (clone, threshold edit, reset for builtins): Edit profiles.

Next