Skip to content

Vesana library

The Vesana library is the catalog of device profiles that Vesana publishes — ready-made definitions for SNMP/SSH/agent checks per device type, verified against real hardware. Profiles in the library come only from Vesana; instances do not upload or share profiles or MIBs.

Questions, requests and feedback about profiles go through the public GitHub repository vesana-org/community. community.vesana.org no longer has a website or a login.

How access works

Your Vesana instance doesn't need to be publicly reachable itself. Every request to the library goes server-to-server through your own backend process; the frontend only talks to your own API. If the library is unreachable, the rest of the instance keeps working unaffected (see Without internet).

Signed profiles only

Every profile version in the library is signed by Vesana. The instance verifies the signature against built-in keys and installs only signed versions. An unsigned or altered version is not installed and nothing is written.

Profiles page: Installed and Available

Profiles has two tabs:

  • Installed — only the profiles present on this instance.
  • Available — library profiles that are not installed yet. Each profile has a preview with its checks and an Install button.

The host wizard and the check pickers show one list: installed profiles and library profiles together, your own profiles labeled Own. If you choose a library profile that is not installed yet, it is installed automatically.

Installing

Referenced monitoring scripts come along on install, without a separate consent prompt. After that, the profile lives locally on your instance. If its checks use MIBs, the install fetches them from the MIB library; a version of the same MIB you uploaded yourself always stays. If the MIB library can't be reached at that moment, the install continues without the MIBs and says so.

Detection rules (sysObjectID/sysDescr patterns for automatic profile matching) come along with the profile.

An installed profile remembers where it came from (profile and version in the library), so Vesana can tell whether a newer version is available.

Updates

Vesana keeps evolving the profiles — new checks, corrected OIDs, better thresholds, improved scripts and detection rules.

Automatic: installed library profiles that were not changed locally are updated by Vesana every hour in the background. New checks also reach the hosts that use the profile. Every automatic update is written to the diagnose log. To turn this off, use the switch "Update profiles automatically" under Admin → Updates (super admin only, default: on), see Updates.

Locally modified profiles are never overwritten silently. They show "Update available"; a super admin applies the update via the comparison dialog. Applying an update manually requires super admin — also when automatic updates are turned off.

The comparison dialog behind Update has two steps:

  1. Preview shows which checks are new, which existing ones the new version changes (field by field; passwords, communities and private keys only masked) and which are dropped. Renamed checks are recognised and renamed in place — history stays, no duplicate check generations.
  2. Apply with explicit choices:
    • New checks are added to the profile. The update never removes existing checks on its own.
    • Also add the new checks to connected hosts — preselected: hosts using the profile get the new checks attached. This runs in the background: the answer comes immediately, the profile shows “Applying to hosts: 120 of 500”, then the result. Restarting the instance midway does not cancel it — the run resumes and only creates what is still missing. If it cannot resume (profile deleted, account no longer active), the reason is shown on the profile and in the diagnose log. At most one run per profile; a further update before it finishes is rejected. Optional checks of the profile are not attached; the result names them, as well as checks that could not be created on a device (execution mode not possible there).
    • Improved existing checks — update them? — one choice per check, all changed checks are preselected. A selected check takes description, config, interval, thresholds, mode and info mode from the new version. Deselecting leaves the check unchanged. Per-host customizations (overrides) are always kept.
    • Type conflicts (same name, different check type) can be switched to the new type per check (history is kept), and old checks no longer included can be moved to the trash. Without that choice such checks stay unchanged.

Scripts come along. An update brings improved script bodies as long as the script is unchanged locally. Scripts you edited yourself are never overwritten. Improved detection rules come along too; rules you maintain yourself remain untouched. MIBs the profile newly needs come along as on install.

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.

No install and no update overwrites anything of your own: no host overrides, no scripts you adjusted, no detection rules you maintain, no MIBs you uploaded.

When a new version arrives

A new profile version first reaches instances with a tester license, and all other instances about two days later.

After the update period of the license has ended, no profile updates are applied, neither automatically nor manually. Installing remains possible.

Without internet

Every Vesana image contains a snapshot of the library. If the library is unreachable, the Available tab shows that snapshot ("Offline — library as of "), and installing works from it — with the same signature check. Updates need the online library.

Active/passive variants

Library profiles 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 file

Your own profiles stay on your instance. To move them between two instances, use a JSON bundle (export via the Export as file icon on the profile row, import via Import at the top of the profiles page; ZIP files with several bundles work too) or 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. An export only contains scripts the exporter is allowed to see; the rest is counted as omitted. For everyone except super admins the export also leaves out SNMP communities, passwords, private keys and script values declared as passwords. Detection rules from an imported file are only taken over by a super admin.

If a bundle file carries script code or custom commands, the importing user confirms their identity first (passkey, code or password) — this applies to every account.

On a file import, Vesana asks 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