Acumatica writes several kinds of logs by default — IIS logs, the application trace log accessible through the Trace screen (SM205020), Windows Event Log entries for unhandled exceptions, and SQL Server's own error and slow-query logs. None of these are aggregated anywhere by default; on a self-hosted deployment each lives on its own server, in its own format, and finding a correlated picture of what happened during an incident means opening several tools by hand. Log aggregation is the discipline of shipping all of it somewhere queryable in one place before you need it.
What actually needs to leave the server
Not every log is worth centralizing. IIS access logs and the Acumatica trace log (which captures PXException details, including the stack trace and the screen/action that triggered it) are the highest-value sources for diagnosing user-reported issues. SQL Server's error log matters for infrastructure-level problems. Windows Event Log application entries catch things that crash before Acumatica's own trace logging engages. Verbose debug-level tracing, if enabled, generates enormous volume and is usually better left local, toggled on only during active investigation of a specific issue.
C:\inetpub\logs\LogFiles\W3SVC1\*.log -> IIS access logs
C:\Acumatica\\App_Data\Trace\*.log -> PXTrace / exception log
Windows Event Log (Application channel) -> unhandled exceptions, IIS crashes
SQL Server error log -> deadlocks, timeouts, corruption warnings
Custom PXTrace.WriteInformation calls -> business-logic-level breadcrumbs A standard log-shipping agent does the heavy lifting
Because these are all just files on a Windows server, the shipping mechanism doesn't need to be Acumatica-specific — Filebeat, the OpenTelemetry Collector's filelog receiver, or Azure Monitor Agent (if you're already on Azure infrastructure) can all tail these paths and forward to whatever store you've standardized on: an ELK/OpenSearch stack, Azure Log Analytics, Datadog, or similar. The Acumatica-specific work is entirely in configuring the right file paths and, ideally, parsing the trace log's structure so exception messages and stack traces land as structured fields rather than one opaque blob of text per entry.
A single user action in Acumatica can touch IIS, the trace log, and SQL Server within the same second, and timestamp alone won't reliably tell you which log lines belong together under load. If your aggregation stack supports it, extract and index the Acumatica session ID or a correlation ID from the trace log entries so you can pivot from "user reports an error at 2:14pm" to every related log line across all three sources in one query, not three separate manual searches.
Retention driven by what you'll actually need later
Trace and error logs are useful for maybe two to four weeks of active debugging; audit-relevant logs (who logged in, what was changed on a financial record) may need to be retained far longer for compliance reasons, but that's a different concern from operational log aggregation and is better served by Acumatica's built-in audit trail feature than by parsing trace logs after the fact. Set a shorter hot-retention window for operational logs in your aggregation tool and let cost drive that number — a slow query from six months ago is rarely still actionable.
Alert on rate-of-change, not raw error counts
Once logs are centralized, the temptation is to alert on any exception appearing in the trace log — which produces so much noise from routine validation errors (a user typing an invalid value) that the alert channel gets muted within a week. A more durable signal is the rate of a specific exception type spiking above its normal baseline, or a brand-new exception type appearing that's never been seen before; both are far better indicators of an actual regression than "an exception happened."
Why this matters at 6pm on a Friday
The value of aggregation shows up specifically during an incident, when a user reports "the system is slow" or "I got an error saving an invoice" with no other detail. Without centralized logs, diagnosing that means remoting into the app server, then the SQL server, then correlating timestamps by hand. With aggregation already in place, the same investigation is one query filtered by time window and, if you've indexed it, by user or session — minutes instead of the better part of an evening.
Wrapping up
Log aggregation for Acumatica is unglamorous plumbing — a shipping agent pointed at IIS, trace, event log, and SQL Server error log paths, landing in whatever aggregation tool your team already runs. The return on that plumbing is entirely realized during incidents, which is exactly the wrong time to be setting it up for the first time.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.