-
Notifications
You must be signed in to change notification settings - Fork 6
UseTraceHubConsole
TraceHubConsole.exe is a Windows console application that listens to TraceHub which will push trace messages to client programs.
While TraceHub MVC/Slim has its own Web UI to display trace messages in Web browsers, some people might prefer to see trace messages constantly scrolling up in a console window.
- .NET Framework 4.5 or above
- Fonlow.TraceHubConsole.exe
- Fonlow.TraceHub.Common.dll
- Essential.Diagnostics.dll
- Microsoft.AspNet.SignalR.Client.dll
- Newtonsoft.Json.dll
There are 2 ways to define the URL of TraceHub, defining in TraceHubConsole.exe.config, or inputting in command line.
<appSettings>
<add key="loggingHub" value="http://localhost:33628" />
<add key="loggingHub_Username" value="api" />
<add key="loggingHub_Password" value="Aaaaaa*8" />
</appSettings>
If these keys are missing in the config file, the program at startup will ask you to input in command line. For TraceHub Slim, the value of loggingHub_Username should be "anonymous".
You can inject respective trace listeners to the Console to persist traces in text files or a database or further process traces from distributed services.
If you have used ConsoleTraceListener of System.Diagnostics or ColoredConsoleTraceListener of Essential Diagnostics, you may prefer to view trace messages from various distributed services in a console window. In fact, current Trace Hub Console is utilizing ColoredConsoleTraceListener to display trace messages from Trace Hub.
Both Trace Hub web service and TraceHub Console do not persist trace messages, by design. If you want to persist trace messages, you may inject appropriate trace listeners. Among trace listeners listed in Essential Diagnostics, here's a list of candidates:
- RollingFileTraceListener
- RollingXmlTraceListener
- SqlDatabaseTraceListener
- BufferedEmailTraceListener
- EmailTraceListener
- ElasticSearchTraceListener
- AWS DynamoDB TraceListener
- DiagnosticMonitorTraceListener
- Your custom trace listeners
Please note, the traces were happening in the distributed services elsewhere, not within the running process of TraceHub Console, thus the information stored in the EventCache objects of the trace listeners is not of our concern, and we just want to display or persist messages received from Trace Hub.
If you happen to use some of the trace listeners of Essential.Diagnostics, you should define a very simple template, like this:
<add name="rollingFile" type="Essential.Diagnostics.RollingFileTraceListener, Essential.Diagnostics" template="{EventType}: {Message}" />
Most of the Template Parameters of the trace listener shouldn't be used, since they are of local process data of the Console. If you do want to get those data of the event sources of distributed services, you should apply these Template Parameters in the definition of the HubTraceListener injected in each service instance, so the information will be included in the trace messages being sent to Trace Hub.
By default, TraceHub Console re-formats the trace message from the original sources as:
DateTimeUTC [Origin] TraceMessageFromOrigin
A template of an Essential.Diagnostics trace listener like "{EventType}: {Message}"
will give you:
EventType: DateTimeUTC [Origin] TraceMessageFromOrigin
If you don't define a template, the default template for trace listeners of System.Diagnostics and Essential.Diagnostics could be:
{Source} {EventType}: {Id} : {Message}
, thus you will be getting formatted message as
Source EventType: Id: DateTimeUTC [Origin] TraceMessageFromOrigin
Because Trace Hub Console is a Windows console application, it can be running without a user logged on. So if you want to persist all the trace messages into text files or database, you may run the Console in a server machine, either a traditional machine/VM or managed service of the Cloud, and remove ColoredConsoleTraceListener from element sharedListeners. For good reliability, you may want to make the Console run in the same zone of Trace Hub. In short, TraceHub Console could run comfortably on client side and server side.
Source and EventType could be used for filtering.
The following variables should not be used in the template:
- DateTime. This is already included in the re-formatted message.
- ProcessId
- ThreadId
- Callstack
If you want ProcessId, ThreadId or Callstack, you should define respective variables in the template attribute of HubTraceListener attached to the origin service application.
It's Internet. It doesn't cooperate. At some point everything is going to go south on you.
By default, the SignalR connection object in the Console will retry up to 7 times to reconnect. If all retries failed, the connection object will be in the disconnected state permanently. The Console is smart enough to retry every 20 seconds with a new SignalR connection object.