Logging

Server-side logging is pretty important for any type of software, and web applications are not an exception. Whether to implement logging or not is not really a decision – implement logging. The decision is where to send these logs and hot to consume them.

Here are some logging targets to consider:

• A database. Logging to a database has many advantages

  • You can retrieve the logs from anywhere, without access to the production machine.

  • It’s easy to aggregate logs when you have multiple servers.

  • There’s no chance the logs will be deleted from a local machine.

  • You can easily search and extract statistics from the logs. This is especially useful if you’re using Structured Logging.

  There’s a myriad of choices for a database to store your logs. We can categorize them as follows:

  • Relational Databases are always an option. They’re easy to set up, can be queried with SQL and most engineers are already familiar with them.

  • NoSQL Databases like CouchDB. These are perfect for structured logs that are stored in JSON format.

  • Time-series Databases like InfluxDB are optimized to store time-based events. This means your logging performance will be better and your logs will take less storage space. This is a good choice for intense high-load logging.

  • Searchable Solutions like Logstash + Elastic Search + Kibana (The "Elastic Stack") provide a full service for your logs. They will store, index, add search capabilities and even visualize your logs data. They work best with structured logging.

• Error/Performance monitoring tools can also act as logging targets. This is very beneficial since they can display errors alongside log messages that were in the same Http request context. A few choices are elmah.io, AWS Cloudwatch and Azure Application Insights.

• Logging to File is still a good logging target. It doesn’t have to be exclusive, you can log both to file and a database for example.

Once you have logging in place, I suggest doing a test run on retrieving them or searching them. It’s going to be a shame to wait until you have a bug in production only to find out that you have some kind of problem in your logging.

https://www.stevejgordon.co.uk/high-performance-logging-in-net-core?utm_source=csharpdigest&utm_medium=email&utm_campaign=featured