for log event i have used every time await EventLogger.Log(DateTimeOffset.Now, Enum_EventType.Update, "Update Listing", Enum_LogType.Information, "Completed", listing.ID.ToString());

in my implementation in every call savechanges() in db is there any way to reduce this database call.

Then you may create a simple most used, overload or extension method for that. To simplify caller to EventLogger.LogInfo(EventType.Update, "Update Listing", "Completed", listing.ID.ToString());

You may introduce a mem-cache to save batches but I'd add such complexity only if you have a MEASURED requirement. Also ORM and DBE you're using may already have in-place effective optimizations.

"Do not use System.Web.HttpContext.Current directly" then for get ip address i need to pass parameter in log() method right? and pass this ip value from calling method

Yes or...not. You can pass it as parameter or inject a service to resolve it. Default implementation may access directly System.Web.HttpContext.Current (for both User and Request) but you open your code to testing. For testing purposes you may mock that interface to provide test values you need and then all this code will be testable in unit testing! Of course you will need some integration tests (at least to test the whole implementation and the concrete classes) but they're small, fast and easy to write.

can we add DateTimeOffset eventTriggeredOn in Log() method rather than every time pass from calling method is this right way?

"Right" depends on your use-case but yes, in general, I pick the timestamp directly in the Log() method. It's not a problem if you do not have 10,000 requests per second and time spent in processing is negligible (otherwise you may want to have a slightly more accurate timestamp, possibly related to when request has been accepted and not when log effectively will be written).

Think, for example, 5 requests received within 10 ms from the same client. Something went wrong (and you can easily see it from timestamps). If however 5 requests are completed in 10 ms it may be a server load issue (and user repeated the request because she didn't get any response for, let' say, 10 seconds). A VERY naive log inspector may help you to quickly build some analytic data.

hello!

hello

as created IHttpRequestInspector interface and implementation can i create for logger is it good way?

it's a step, yes.

Goal is to test logger code in unit testing, completely. If you have to deal with HTTP request then you can't (easily) test it in unit testing but in integration tests. They're slower and harder to write (but you still need them, of course, both to test the whole and to test your concrete IHttpRequestInspector implementation)

hi t3!

yes for same i also required unti test case

and for savechanges for log i have used await UnitOfWork.SaveChangesAsync(); that call my unit of work and save dbcontext it this good way to every log method call and call savechanges in database?

got your point

If not then I'd start with a simple implementation, it's something you can/should resolve elsewhere (introducing a memcache between ORM and database, for example) but there is really no need to make it more complex than needed