sameeralam3127.linux_vitals · Ansible Galaxy collection

Your Linux fleet has a pulse. Now you can see it.

LinuxVitals is an agentless Ansible collection that scans, opt-in self-heals, and reports on your Linux servers — with per-distro reboot and kernel detection, a baseline → postcheck comparison built for real maintenance windows, and one self-contained HTML dashboard at the end of it.

See the live dashboard View source

$ ansible-galaxy collection install sameeralam3127.linux_vitals

1.2.0 latest release

4 distros tested every push

MIT open source

3 roles scan · heal · report

Verified on every push against real systemd containers

✓ Ubuntu 24.04 ✓ Rocky Linux 9 ✓ Fedora 42 ✓ openSUSE Leap 15

What it does

Deep OS posture, not just uptime pings

Six things LinuxVitals does out of the box, across RHEL, Fedora, Ubuntu, and SUSE.

Read-only scan

Kernel & bootloader validation, boot-partition health, SELinux/AppArmor, failed logins, journal errors, memory pressure. Nothing is changed unless you opt in.

vitals_scan

Opt-in self-healing

One restart attempt per enabled, failed systemd service — and the report says whether it worked. Disabled by default (linux_vitals_heal_enabled: false); nothing changes unless you flip the switch.

vitals_heal

Baseline → postcheck comparison

Snapshot before a maintenance window, snapshot after — correlated by a maintenance id. Status changes, RAM deltas, kernel changes, and new/resolved findings, computed for you.

vitals_report

Self-contained dashboard

One HTML file. No CDN, no build step, no server. Search, sort, filter, and expandable host rows — opens in any browser, forever, offline.

dashboard.html.j2

Multi-channel notifications

Slack, email, and generic webhook — configurable independently, with secrets resolved from inventory, group_vars, or a local .env file.

vitals_report

Tested on four distributions

Every push boots a real systemd container per family and runs the whole pipeline end to end — discovery, healing, and reporting — not just a lint pass.

molecule

Not a mockup

This is the actual dashboard

Real template, sample fleet data. Search a hostname, click a column to sort, expand a row for the full picture — including a live before/after maintenance comparison.

reports / linux_vitals_report.html Open full screen ↗

Health-score ring & KPI row Improved / Regressed filters Per-host expandable detail Light & dark themes

Distro-aware by design

Every family answers "do I need a reboot?" differently

So LinuxVitals asks each one in its own language, reports which source produced the answer, and never reads a broken check as "all clear" — an unusable tool falls back to a kernel comparison and says so.

Family	Primary check	Reported as	Packages
Debian / Ubuntu	`/run/reboot-required`	`reboot-required-file`	apt
RHEL / Rocky / Alma	`needs-restarting -r`	`needs-restarting`	dnf
Fedora	`dnf needs-restarting`	`dnf-needs-restarting`	dnf5
openSUSE / SLES	`zypper needs-rebooting`	`zypper-needs-rebooting`	zypper
No usable check	running vs. latest installed kernel	`kernel-comparison`	—

The same care goes into the bootloader: GRUB via grubby, grubenv, BLS drop-in entries and systemd-boot are all resolved, so a host with the newest kernel installed but an older one set to boot gets flagged before it reboots into a surprise. Read the detection docs ↗

The workflow

Built around real maintenance windows

Three playbooks, one shared maintenance id.

01 / Before

Capture a baseline

Run …linux_vitals.baseline with a linux_vitals_maintenance_id before your window opens. Full posture, snapshotted per host.

02 / During

Do your maintenance

Patch, reboot, reconfigure — however you normally do it. LinuxVitals stays out of the way; it only observes and, if you've enabled it, self-heals.

03 / After

Run postcheck, get the diff

Run …linux_vitals.postcheck with the same id. The dashboard shows exactly what changed — per host, per finding.

Get started

Point it at an inventory, get a dashboard

No agents, no daemons, no database — just SSH and Ansible. Python 3.10+ and Ansible Core 2.16+ on the control node.

terminal

# install the collection
ansible-galaxy collection install sameeralam3127.linux_vitals

# and its runtime dependency
ansible-galaxy collection install community.general

requirements.yml

collections:
  - name: sameeralam3127.linux_vitals
    version: ">=1.2.0"
  - name: community.general

terminal

# one-shot health check across the fleet
ansible-playbook -i inventory.ini sameeralam3127.linux_vitals.healthcheck

# before a maintenance window
ansible-playbook -i inventory.ini sameeralam3127.linux_vitals.baseline \
  -e linux_vitals_maintenance_id=2026-08-patch

# after it, for the before/after diff
ansible-playbook -i inventory.ini sameeralam3127.linux_vitals.postcheck \
  -e linux_vitals_maintenance_id=2026-08-patch

Command builder

Build the exact command, from the real variables

Every option below is generated from the collection's own meta/argument_specs.yml — all 51 variables across the four roles, with their real defaults. Change what you need; only what differs from a default ends up in the output.

Playbook

Inventory

Report paths and the .env lookup resolve from this file's directory, not from the playbook's.

Forks

Ansible's default is 5. Raising this is the cheapest fleet-scale win; match it to control-node cores and to what your bastion tolerates.

become (privilege escalation)

Needed to read /var/log/btmp, the journal, and grub.cfg. Without it those checks degrade quietly. Set it in the inventory rather than with --become, which would also try to escalate on the control node during reporting.

--check (dry run)

Roadmap

Pulled live from the open issues on GitHub. Nothing here is a commitment or a shipping date — track progress and weigh in.

Exploring

See what's actually going on across your fleet

Install it, point it at an inventory, and open one HTML file.

Get it from Ansible Galaxy Read the docs