Recently I implemented the logging target to the Windows Mailslots in our internal logging system.
All the applications and services register this target by default at program startup. The target itself tries to open named local mailslot and if succeeds then writes the log entry text prefixed with the process name and PID (to identify logs from different processes) like “MyProgram.exe:1234 20180421 19:51:08.357 INFO Some message” as binary Unicode buffer. TEncoding.UTF8.GetBytes() or whatever you prefer can be used for that.
Mailslots allow sending the messages of exact size and the receiver can obtain the information about the message count and their sizes. The work with mailslots is not a lot different from the work with usual files.
The logging targets (lets call them mailslot clients) do not create the mailslot. They only try to open it and send the log entries to it in case of success. There is a little to no overhead of this “NULL” logger until the mailslot server does not appear on the stage.
Once you create and start the application which creates the mailslot with hardcoded name (that is just assumption, that all clients know the common unique name of the local mailslot – “\\.\mailslot\YourUniqueNameForTheLoggingTarget“) the performance of the application is affected by a certain margin, but that can be acceptable in the cases when diagnosing problems is more important than 100% performance of the diagnosed application.
The implementation of this mechanism is really very compact. For the client (logging target) you just need to open the mailslot and if it exists then write the message in the format agreed between client and server. On the other side, in server application, you need some kind of main loop which after creating mailslot all the times checks for the new messages and then reads them from it (TTask or any other threaded approach can be used to implement that).
I found this approach for logging very simple to implement and with almost no overhead when there is no mailslot present. The performance with existing mailslot drops because of the overhead involved in the write operations to the mailslot file by handle.
This approach can be applied for performance non-critical application without problems. But if you need some similar mechanism with the best performance then go for Event Tracing for Windows where you can implement much more robust and advanced mechanism. The price of that obviously is the complexity.
With this in place you can get the diagnostic data from the production applications even if they were not configured to log to console, file or Windows Events. So you only get the logs when you need them and you will not need to restart the service application by losing the context of the problem. Keeping such a logger in a production can be helpful for tracking the issues when they appear.
Pascal Today 