The solution is a bit of a mystery but if you really have /System/Library/CoreServices/Notification Center.app with the space and not /System/Library/CoreServices/NotificationCenter.app you may have to reinstall the OS or restore that entire directory from backup (or another similar Mac OS install).
As to the load on the computer due to the logging - it should be harmless or at worst a minor slowdown. I have Macs with thousands of messages a minute and can barely measure their load running Activity Monitor even when I have several windows up tailing the logs, grepping for patterns to filter out noise like you mention.
You can assure yourself the system is not loaded with the following command:
iostat 15
You can run with the notifications running and the error messages and without and watch for long term problems in terms of CPU usage and disk IO. Airs and other SSD based Macs generally have plenty of horsepower to deal with thousands of messages a second let alone per minute and the system logging infrastructure scales very well, uses little RAM and is miserly with CPU and disk access.
Now, as far as hunting down the culprit - it's going to be a bit of sleuthing unless someone has already slayed this bug by noticing why the space got added in that directory for the app.
I would probably edit the plist file for that process to set the respawn to be 100 or 300 or 600 until you have a handle on the error (and if you don't want to see so many messages). Also, when you have unloaded (or removed) the job from launchd
control, you could manually run the program from the terminal to see if it output any errors on startup that might help you.
launchctl unload /System/Library/LaunchAgents/com.apple.notificationcenterui.plist
/System/Library/CoreServices/NotificationCenter.app/Contents/MacOS/NotificationCenter
You can quit the app by pressing control+c - If it's a permission error, you could test that by running the process as root:
sudo /System/Library/CoreServices/NotificationCenter.app/Contents/MacOS/NotificationCenter
Time Machine is designed around ease of use, rather than utility. It does not backup everything on the hard drive, typically not including files that are not necessary to recover from a failure. Log files seem to fit this category.
The first option is to see if you can remove the exclusion using tmutil, which is the commandline version of Time Machine.
tmutil removeexclusion "/var/log/apache2"
Typically, this command is used for exclusions the user has created, but its worth a try.
The other option is to use something like chron and bash (or Automator) to simply compress the log files into an archive (zip file) and place the archive in your documents folder. I would suggest that you perhaps name your archive file with the date, so Time Machine does not assume they are duplicate or simply newer versions of the same file.
Best Answer
While I suspect that this is not what you want to do, you could always do something like schedule a maintenance task to run to limit the size of the file.
Something like this in a shell script that you schedule:
Or if you want to keep a history of the contents, something like this:
If you want to get fancy, you could:
and then only rename the file if > 10K. As usual it all depends on how much effort you want to put into it, and whether or not you want a history of this file.
And as you said....this doesn't actually resolve the root cause.