Fleet observability for VMware/vCenter and Proxmox VE estates plus standalone Linux hosts. opsview enumerates your hosts, probes each one over SSH, and reports state through a tabbed web UI with one-click OliveTin actions.
It is environment-agnostic: point it at one or more vCenters and/or Proxmox VE endpoints (and/or a list of physical servers), give it the hypervisor credentials and an SSH key for the fleet, and it builds an inventory and starts reporting. Everything that's site-specific — hypervisors, storage clusters, physical servers, credentials, host groups — is configured at runtime, not baked into the code.
For every Linux host known to a hypervisor (or added manually), it runs a set of probes:
- host_basics — uptime, OS, kernel, time skew
- disk — df usage, flag >85%
- mounts — findmnt + fstab + autofs; exports provided; active RW/RO verification of each live mount (mountpoint check, write+readback, hung-detection)
- services — systemd unit failures
- docker — container state, restart counts, image age
- apps — per-host process watchlist (a missing expected process = fail)
- ports — listening sockets
Results render in a tabbed web UI:
- Overview — color-coded status table, one row per host
- Topology · Infra — Cytoscape mount-relationship graph (provider → consumer); 4 layouts, vCenter/FS-type/health filters, PNG/JSON export; node color = probe status; OneFS/Isilon clusters render as distinct storage nodes
- Topology · Services — hand-curated app-flow diagram (
services.yaml); same color overlay - Analysis — mount health, redundancy, circular dependencies, orphans, and consolidation suggestions
- Run — OliveTin embedded; buttons to re-run all probes, just docker, just mounts, one host group, etc.
- Ops — parameterized host-affecting operations: create a network mount, expand a disk (hypervisor virtual-disk grow on vCenter or Proxmox + in-guest partition/LVM/FS extend); confirm step + audit log
- Broken — latest-run failures + drift from a blessed baseline
- Settings (admin only) — local users & groups with per-tab access control; a credential store (uploadable SSH keys + username/password credentials); manage vCenters, Proxmox VE endpoints, OneFS/Isilon clusters, and physical (non-hypervisor) servers
Access is gated by login. Local users belong to a group, and the group's
permissions decide which tabs they see — e.g. a readonly group with no Run
or Ops access. (AD integration is a future enhancement; local accounts for now.)
Hosts from a vCenter, a Proxmox VE endpoint, and a bare-metal server, side by side (the shots below come from the bundled demo dataset — see Quick start).
Topology · Infra — mount relationships drawn provider → consumer; node color is worst-of probe status, storage clusters render as distinct nodes:
Analysis — health, redundancy, circular dependencies, orphans, and
consolidation suggestions derived from the mounts probe across the fleet:
Broken — current failures/warnings plus drift from a blessed baseline:
Ops — parameterized, audited, host-affecting operations:
┌──────────────┐
you ───► │ nginx :80 │
└──┬────────┬──┘
/ │ │ /olivetin/
▼ ▼
┌─────────────┐ ┌──────────────────┐
│ Flask :5000 │ │ OliveTin :1337 │
│ static HTML │ │ button runner │
│ JSON API │ └──────┬───────────┘
└──────┬──────┘ │ shells out
│ ▼
│ ┌──────────────────────────┐
│ │ /opt/opsview/orchestrator│
│ │ cli.py run|triage|... │
│ └────────────┬─────────────┘
│ │ ssh (parallel fan-out)
▼ ▼
/var/lib/opsview/state ┌──────────────┐
<host>/<probe>/JSON │ fleet hosts │
read by Flask │ run probes, │
│ emit JSON │
└──────────────┘
- A Linux host to run opsview on (Ubuntu/Debian for the ansible role; any host with Python 3 for manual runs).
- Python 3.9+ on the opsview host and
python3on every target you probe. - An SSH key whose login user has passwordless
sudoon the targets (needed for the mount-verify and Ops features). - Optional, for automatic inventory: a read-only vCenter account and/or a Proxmox VE API token (
PVEAuditoris enough). Without either, add hosts manually in Settings.
A populated demo — the dataset shown in the screenshots above (vCenter + Proxmox + physical hosts, mixed statuses, populated Settings) — runs with one command:
./dev/run-demo.sh # Linux/macOS
.\dev\run-demo.ps1 # Windows PowerShell
# open http://127.0.0.1:5000 (login: admin / admin)Or use the docker-compose harness against the bare sample data:
cd dev/
docker compose up --build
# open http://localhost:5000See dev/README.md for details and a no-docker (Flask-direct) option.
- Provision a host (any VM or bare-metal box).
- Run the ansible role against it (see
roles/opsview/and RUNBOOK.md). It installs Python deps, OliveTin, nginx, the Flask service, and the hourly/daily systemd timers. - Log in to the web UI (default
admin/admin— change it immediately), then under Settings add your credentials, vCenters / storage clusters / physical servers, and tune host groups ininventory/groups.yaml.
The RUNBOOK walks through every phase: build, deploy, verify, rollback, and operating tips.
opsview/
├── README.md ← you are here
├── RUNBOOK.md ← phase-by-phase build/deploy/operate guide
├── roles/opsview/ ← ansible role: installs + configures the opsview host
├── orchestrator/ ← Python: enumerate, fan out, gather, triage
├── probes/ ← per-OS probe scripts (Linux)
├── inventory/ ← groups.yaml + cached vCenter enumeration
├── web/ ← Flask app + tabbed static UI
├── dev/ ← docker-compose + sample data for local testing
├── olivetin/ ← OliveTin actions catalog (docs)
└── services.yaml ← hand-curated service-flow graph
opsview reads its settings from environment variables (see .env.example)
and from settings.json managed through the Settings tab. Nothing about
your environment is hardcoded — host groups live in inventory/groups.yaml
(edit the example patterns to match your naming convention), and the curated
service flow lives in services.yaml.
Linux probes ship today. Windows (WinRM) probes are a planned addition — the runner and probe shapes are designed to extend to them.