A recent question in the Exchange TechNet Forum asked about Performance Monitor (PerfMon) data collector sets that appear in the \Microsoft\Exchange Server \V15\Logging\Diagnostics\DailyPerformanceLogs folder, where you’ll find files named ExchangeDiagnosticsDailyPerformanceLog_MMDDHHMM.blg. Another folder (\Microsoft\Exchange Server\V15\Logging\Diagnostics\PerformanceLogsToBeProcessed) holds a slightly different PerfMon data collector set, the content of which is gathered and then merged into the daily performance log on a regular basis by the Microsoft Exchange Diagnostics service.
The question expressed a concern that Exchange generates these files automatically and takes up disk space for no obvious reason. In fact, the files are used by Exchange’s Managed Availability framework (which runs as the Microsoft Exchange Health Management service) to track the health of system components, so they serve a useful purpose. The measurement side of Managed Availability works by sending out probes to measure the health of different parts of Exchange. Some probes use RPCs to measure resposiveness, others look at PerfMon data to decide whether things are progressing as they should. Literally hundreds of different measurements are taken to assess the health of every protocol used by Exchange on a server, including OWA, EWS, ECP, and ActiveSync. Depending on the activity of your system, the data collector sets could take up anything from a few hundred megabytes to tens of gigabytes. Of course, even an apparently inactive Exchange 2013 server is busy under the hood because Managed Availability probes are being constantly dispatched and assessed to measure system health, all of which takes some system resources.
Managed Availability is new to Exchange 2013 and some parts of it are not yet well documented. It’s the nature of things that time is required to fully document the inner workings of technology and I’m sure that Microsoft will get around to documenting all of the various parts of the system in due course. For now, we occasionally have mysteries to solve, such as why these data collector sets exist.
The PerfMon data collector sets are not the only diagnostics files that “steal” disk space on an Exchange 2013 server. If you browse through the folders under the V15\Logging root, you’ll find many places where Exchange captures information about activities such as the Calendar Repair Assistant, Mailbox Assistants, Mailbox Replication service, Migration service, OAB generation, and so on. In most cases the data is captured in CSV format and is not of very much interest to normal human beings. But in the case of tricky support problems, you might be asked to provide different log files to Microsoft Support to help track down the root cause of an issue.
In most cases, you can leave the log files alone and let Exchange take care of them. After all, disks are so large these days that using even a hundred gigabytes to store different log files isn’t going to be an issue, unless of course you’re running with low capacity disks for some reason as in the case where you have small system volumes for virtual servers. In this case, you might want to consider clearing out the log files on a regular basis and perhaps follow the advice offered on another TechNet post that suggests using a one-line PowerShell command to track down and delete log files older than 14 days.
And if you’re in the mood to clean up, you can save a gigabyte or so of space by clearing out the PerfMon counter load file backups that are found in the \V15\Logging\lodctr_backups folder. I don’t quite know why Microsoft leaves these in place after a successful installation on a server because the files really serve no useful purpose and my practice is to remove them soon after a successful update. You might want to add this to your post-update installation task list. The same issue exists on Exchange 2010 servers.
Not so long ago it would have been a scandal if several gigabytes of valuable disk was occupied by log files. I guess disk is now so bountiful and cheap that we don’t really concern ourselves so much about this issue anymore… Or maybe you do?
Follow Tony @12Knocksinna