Ledger is the reporting tool that sits on the end of Ascender's log stream. It accepts that stream from one or more Ascender servers, stores the host facts and the changes each playbook run made, and reports across both. Recording only the changes strips out the noise of every unchanged task, so what is left is what your automation actually did. It lives at ascender-ledger, Apache 2.0 like the rest of the platform.
Pointing Ascender at it
Ledger is a logging aggregator type of its own, beside logstash, splunk, loggly and sumologic, so wiring it up is the ordinary external logging configuration in Settings with ledger as the type. The Ascender installer deploys it alongside Ascender when LEDGER_INSTALL is true, which is how most people get it.
Trusting the server
Ledger ignores data from servers it has not been told to trust, so a newly pointed server sends nothing useful until you approve it, and pointing the wrong one at it costs nothing.
- A server appears under Admins, then Servers, the first time it sends data.
- Click the lock icon on that entry to trust it, and facts and changes populate live.
- Edit the entry to set that server's Ascender URL, which is what links a change back to its job.
What it records
Facts come from anything that writes to ansible_facts: the setup module behind gather_facts, the modules that register facts on their own such as several of the Windows ones, and set_fact. That last one is deliberate, so a playbook can build a custom fact specifically to report on it.
Changes are only changes. With Show Changes enabled on the job template and a module that supports it, lineinfile for instance, Ledger keeps the diff of exactly what changed. The search box searches that change data itself, so "which automated change touched /etc/sudoers" is a question you can put to it directly.
Running it
Ledger is three containers published under ghcr.io/ctrliq/ascender-ledger: ledger-web, the interface on nginx and PHP-FPM, ledger-parser, which receives and parses the incoming stream, and ledger-db, the MySQL database holding the facts and the changes. A standalone deployment is docker compose up -d from the repository, with credentials passed as Docker secrets rather than environment values.
One thing on the roadmap is a whitelist for restricting which modules contribute facts, since set_fact being allowed means a chatty playbook can fill the fact table with things nobody wants to report on. If you are running Ledger, what are you actually reporting on, and what is missing from the search?