Home > Back-end >  Bad Practice to log everything to the Event Viewer?
Bad Practice to log everything to the Event Viewer?

Time:02-24

I searched this and couldn't find an answer. How many entries can the event viewer hold?

I am trying to log the origination of a rest request as I have multiple applications that call a single api. I want to log all of these requests in the event viewer using Serilog.

In production I will be able to pull these stats in Splunk.

Is this bad practice to log millions of entries to the Event Viewer? We literally can have up to 2million calls perday from different sources to this Net WebAPi.

I wanted to go the db route to log this information but my db admin said no way. There is no way to pull this from files so that is out of the equation.

Log.Logger = new LoggerConfiguration()
    .WriteTo.EventLog("Sample App", manageEventSource: true)
    .CreateLogger();

Log.Information("Hello, Windows Event Log!");

Log.CloseAndFlush();


private void CallApi()
{
 Log.Information("Request originated from "   System.Environment.MachineName);
 //Call Web Api below
}

CodePudding user response:

I discourage my customers from passing Splunk logs through the Windows event viewer. That's primarily because context often is lost. That's not to mention the extra overhead MS adds to each event, which Splunk will have to store or remove (extra $ or time).

Events typically come in to Splunk as wineventlog:application, which is fine, but what if you have multiple applications? You (probably) don't want them all processed the same way so they should be ingested in a way that preserves the original information.

Better ways to send data to Splunk:

  1. Write the logs to a file and have a Splunk Universal Forwarder (agent) monitor the file.
  2. Write the logs directly to Splunk using Splunk's HTTP Event Collector (HEC) service.
  • Related