v0.7.0 — findings, category extraction, and a Vates support package.
Since the last update, log collection has been through a few fixes and gained three new pieces built on top of it.
Findings, from two sources. A new Findings page reads the XO API (messages, alarms, tasks, missing patches, backup/restore runs) and also scans a collected bundle for storage failures, multipath issues, XAPI exceptions, HA fencing, OOM kills and clock skew — six log-based rules in total now. When both reports describe the same incident (matched by condition and, if both are timestamped, within an hour of each other) each finding gets a small "confirmed by" badge instead of showing up as two unrelated entries.
[image: 1789142072836-screenshot_20260911_115408.png]
Individual log categories, pulled out of a bundle already on disk instead of downloading again — XAPI, storage, audit, security, kernel, HA, xenstore, RRD, network, system. Tick categories on the Collect form before collecting, or against an already-stored bundle afterwards.
[image: 1789142141211-screenshot_20260911_114713.png]
A Vates support package. One .tgz — redacted bundle, findings (MD + JSON), redaction report, inventory, and a manifest of what's inside and what was masked — instead of downloading each piece separately.
[image: 1789142174831-screenshot_20260911_114827.png]
Dashboard status panels now show findings severity, how many redaction rules are off, storage used, and recent job activity at a glance.
[image: 1789142371892-screenshot_20260911_115754.png]
Known issue — still unsolved
The truncated-download-behind-a-reverse-proxy bug from the last post is not fixed. logs.tgz has no Content-Length (XCP-ng builds it on the fly), and on my own Nginx Proxy Manager deployment the proxy's connection to XO intermittently closes before the last chunk arrives. Two things tried, neither fixed it:
proxy_buffering off / proxy_set_header Connection "" — reduced how often it happened, didn't eliminate it. Identical config, run twice back to back, produced one good download and one truncated at the same offset as before.
Suppressing httpx's Accept-Encoding: gzip, deflate header (it was asking the proxy to transport-encode an already-gzipped file) — same result, only reduced frequency, not shipped since it doesn't actually fix anything.
proxy_http_version 1.1; broke the proxy outright when I tried it, for a reason I don't understand — so that's not the next thing to try either.
What XCP Pulse now does about it: reads the archive in streaming order and keeps whatever it read before the stream broke, rather than losing the whole analysis to the last few missing bytes, and says on the report when it ended early. If a collection tells you the bundle ended early, the honest advice is to retry it — not that it's fixed. Documented in docs/installation.md in case someone with more insight into the Nginx/httpx side of this has a fix.
Also fixed since v0.6.0
The restricted-account warning on the Collect page was showing on every connection, including admin ones — wrong template condition, not a real permission check. Fixed.
The default collection no longer downloads the XAPI audit trail unless you ask for it — xen-bugtool already includes it in the bundle, so it was 770 MiB of duplicate data on every run. Default collection is now the bundle only, ~870 MB / ~3 minutes.
XO's /messages and similar routes were being limited from the oldest end, not the newest — a pool with a lot of history could return findings from a month ago and miss everything recent. Now filtered by time window server-side instead.
https://github.com/acebmxer/xcp_pulse
