3.1.log store general info
LogStore is responsible for storing logs generated by your applications. It's the log store implementation which decides whether DiagnosticsCastle may be deployed on multiple servers or should be run as a single-instance. Log stores using ElasticSearch, MySql or SQL Server support concurrent access from multiple Diagnostics Castle instances.
Each log store additionally implements an instance of the configuration manager and the users manager. It is convenient as once you switch to a specific log store you may use it also to save the application configuration data and user accounts information. Though, you are not forced to do so - you may use MySql log store to store user account information and Elastic Search for the application configuration and the log records.
If you can't find a log store that suits your needs you may implement your own one (and maybe share it in the future :)). Diagnostics Castle talks with a log store through the ILogStore interface and it's the interface you need to implement in your log store class.
Each log store should have its custom implementation of the ConfigurationSection which will contain its internal settings. For example log store based on Lucene.NET needs a path to the index. Example configuration for the Lucene.NET log store might then look as follows:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="luceneNetLogStore" type="LowLevelDesign.Diagnostics.LogStore.LuceneNet.LuceneNetConfigSection, LowLevelDesign.Diagnostics.LogStore.LuceneNet" />
</configSections>
<luceneNetLogStore indexPath="d:/data/lucene/llddiag" logEnabled="true" logPath="d:/logs/llddiag/lucene.log" />
<appSettings>
<add key="diag:logstore" value="LowLevelDesign.Diagnostics.LogStore.LuceneNet.LuceneNetLogStore, LowLevelDesign.Diagnostics.LogStore.LuceneNet"/>
</appSettings>
...
</configuration>It's up to the log store implementer how the log store will save the incoming log records. What's important is that the AddLogRecord method should return quickly. If feasible implement also AddLogRecords method which saves a batch of log records events in the log store. Design the log store underlying storage in a way that it will query the log records in a timely fashion applying all necessary filters (more in the next paragraph).
There are two methods to query log information.
-
GetApplicationStatuses- used to retrieve current statuses of all the applications -
FilterLogs- used to retrieve logs generated by a given application (ApplicationPath,FromUtcandToUtcparameters must be provided)
Logs maintenance is extremely important - keeping logs for too long time will consume disk space and slow down the log viewers. Diagnostics Castle IS NOT an application to store archived logs, but rather to inform you about the current status of your applications with some recent log records to review (few weeks at maximum).
1. Diagnostics Kit architecture
1.1. Overview
1.2. Installation and updates
1.3. Configuration
1.4. Authentication and authorization
1.5. Miscellaneous
2. Logs collection
2.1. Overview
2.2. Description of the Log Record fields
2.3. Collecting logs from ASP.NET applications
2.4. Collecting logs from ASP.NET MVC applications
2.5. Collecting logs from ASP.NET WebAPI applications
2.6. Collecting logs from Owin applications
2.7. Collecting logs from logging libraries (System.Diagnostics, NLog, log4net)
3. Logs storage
3.1. Overview
3.2. MySql log store
3.3. ElasticSearch log store
3.4. Sql Server log store
4. System and services monitoring (Musketeer)
4.1. Overview
5. Fiddler plugin for testing web servers (Bishop)
5.1 Overview