Generate, Email, and Schedule PDF Reports
Produce, email, and schedule PDF reports of your PostgreSQL workload. Keep them as long-term snapshots without paying the storage cost of extended metric retention, and use two reports as a before/aft
Datasentinel can export the dashboards you already use as PDF reports: same graphs, same tables, same tag and time-window scope, packaged as a single file you can download, email, or schedule on a recurring basis. The feature is available from every dashboard and through the Reporting API, so the same operations work from the UI or from a script.
This guide focuses on why reports are worth using as a routine practice, then walks through generating, emailing, and scheduling them, and finishes with concrete comparison recipes.
Reports inherit the filters and time window of the screen you launch them from, unless you are creating a scheduled report (which uses its own window). See Reporting for the full feature reference.
Why PDF reports change the storage math
Datasentinel stores metrics in InfluxDB on the platform host. The default sizing assumes 14 days of retention, and the recommended disk size scales with both the number of monitored instances and the retention period. Extending retention from 14 days to a year is a 26× increase in time, which means a roughly 26× increase in metric storage (the actual factor depends on activity volume, but the trend is linear).
PDF reports break that trade-off. A weekly Full Report is at most a few megabytes, and a year of weekly snapshots is therefore a handful of dozens of files: trivial to keep on a wiki, a SharePoint folder, an S3 bucket, or attached to a ticket.
Extend metric retention
Every sample, queryable at full resolution.
Storage scales linearly with retention and instance count. Backups, dispatcher load, and platform sizing all grow with it.
Archive PDF reports
A snapshot of the period: dashboards, top-N tables, plans, summaries.
A few MB per report, independent of how many instances you monitor. Lives outside the platform, so it survives upgrades, restores, and platform decommissions.
Reports are not a replacement for live dashboards or for the Workload API (which returns raw metrics in JSON or CSV). They are a way to preserve the analytical view of a workload long after the underlying samples have been rolled off.
Why PDF reports unlock comparison
Once two reports of the same shape exist, comparing them is a tab-switching exercise that anyone can do, regardless of whether they have a Datasentinel account.
Three patterns come up most often:
Before / after a change: generate a Full Report for the week preceding a migration, an index addition, or a PostgreSQL upgrade, then a second one for the week after. The pair tells you whether the change actually moved the needle.
Week-over-week or month-over-month: a recurring scheduled report gives you a stack of identically-shaped PDFs. Drift in top queries, table sizes, or system metrics jumps out.
Same window, two scopes: generate one report filtered on
application=Aand one onapplication=Bfor the same time range. Side-by-side reveals which workload is heavier, where the wait events differ, which queries dominate each side.
Reports always carry their time window, tag filters, and database scope in the header. This is what makes them unambiguous to compare: there is no doubt about which slice of data each PDF reflects.
Before you start
SMTP configured
Mandatory for the Email and Scheduled email modes. Not needed for one-off downloads. See SMTP configuration.
A tagging strategy
Reports are scoped through tag filters. A consistent tagging scheme makes per-application, per-environment, or per-cluster reports trivial. See Organize Content using Tags.
Access token (API only)
For Reporting API calls. Tokens are valid 24 h. See Automate with the API.
What you can report on
Datasentinel ships one Full Report that bundles every section, plus seven individual reports for users who want one specific angle:
Full
full-report
All sections below in a single PDF. The default choice for an archive snapshot.
Session History
session-history-report
Active Session History samples, grouped by wait-event type and an optional secondary tag dimension.
Top Queries
top-queries-report
The most resource-intensive queries for the window, ranked by the dimension you pick (total time, calls, blocks read/written, WAL bytes, etc.).
Top Tables
table-report
Heaviest tables and indexes with their access patterns and sizes.
Instance
instance-report
Per-cluster metrics: connections, transactions, WAL, replication, configuration.
Server
server-report
Host-level metrics (CPU, memory, I/O, network) when collected.
Query
query-report
Deep-dive on one specific query identified by its query_md5_id.
Data Size
data-size-report
Table and index sizes, useful for capacity-planning archives.
Generate a report
Every dashboard exposes a reporting icon in the top-right toolbar.
Open the dashboard you want a report for, set the filters and time window you need, and click the reporting icon.
Pick the report type. From a generic page (such as Home) you can choose any of the eight types; from a specific dashboard (such as Session History) only the matching type is available.
Optionally restrict to a single database (default: All).
Choose the delivery mode in the dialog:
Download: the PDF generates and downloads to your browser immediately.
Email: enter recipients and an optional subject, then send. Requires SMTP.
Scheduled email: covered in the next section.
The filters and time window from the current screen are carried into the report, so the PDF reflects exactly what you were looking at.
The same operation as a one-liner. Each report type has its own endpoint under /ds-api/activity/; the body shape is the same for all of them: a time window, optional tag filters, optional database, plus type-specific knobs (such as the by ranking dimension for Top Queries).
To email the report directly instead of downloading it, add three fields:
Swap full-report for any of the seven individual endpoints to scope the output. The full list lives in the Reporting API reference.
Schedule recurring reports
A scheduled report is the cheapest way to build a long-term archive. It runs unattended on a cadence you choose and lands in the recipients' inbox each time.
Configure SMTP first
Email and scheduled email both go through SMTP. If you haven't set this up yet, follow SMTP configuration and run a Test e-mail to confirm delivery.
Create the scheduled report
From any dashboard, open the reporting dialog and pick Scheduled email. Configure:
Frequency: daily or weekly.
Day and hour the report should run.
Recipients and optional subject.
The activity time range the report should cover (this is the rolling window each scheduled run will recompute against).
The report actually starts 3 minutes after the scheduled time so the most recent samples are included in the run.
Manage and audit
The Reporting screen lists every scheduled job. You can change properties, delete a job, and open any entry to view its execution history (status and duration of every past run).
An administrator sees every scheduled report across all users. A non-administrator can only see and manage their own.
Comparison recipes
Before / after a change
Use a Full Report bracketing the change. Same scope, same window length, two adjacent time ranges.
Open both PDFs side by side. Top Queries, wait events, I/O metrics, and table activity should all shift in the expected direction if the change worked.
Week-over-week digest
Schedule a weekly Full Report and archive the inbox. After three months you have a 13-PDF time series; after a year you have 52. Each PDF is self-describing (header carries window + filters), so the archive can outlive the platform that produced it.
Two scopes at the same time
When two applications share a platform, generate the same report twice with different tag filters to compare workloads directly.
The same recipe works for primary vs replica, production vs staging, or any two slices that share a tag dimension.
Best practices
Pick the Full Report for archives, the per-section reports for sharing: one PDF is easier to file; a single section is easier to read with one stakeholder.
Standardize the window: pick a cadence (weekly or monthly) and keep it. Comparable archives are the ones that share the same window length and tag scope.
Name files predictably: when scripting via API, write filenames like
<scope>-<from>_<to>-<type>.pdfso an archive of hundreds remains scannable.Don't pair reports with extended retention by reflex: in most cases, 14 days of live metrics plus a year of weekly PDFs is cheaper and more useful than 90 days of live metrics on their own.
Where to go next
Conclusion
PDF reports turn Datasentinel into a system of record, not just a live dashboard. They cost almost nothing to store, they outlive the metrics they were generated from, and they make comparisons (before/after, week-over-week, scope-against-scope) a matter of opening two files. Use them as the routine alternative to extending metric retention, and as the standard artefact for any change you want to evidence.
Last updated