Optimize: use Serilog instead

[Wi1l-B0t]

The previous logger is too simple.
So use Serilog instead of it.

[codecov]

Codecov Report

❌ Patch coverage is 44.71545% with 68 lines in your changes missing coverage. Please review.
✅ Project coverage is 47.42%. Comparing base (390a76b) to head (ec792d4).

Files with missing lines	Patch %	Lines
...DBFTPlugin/Consensus/ConsensusService.OnMessage.cs	42.10%	10 Missing and 12 partials ⚠️
plugins/DBFTPlugin/Consensus/ConsensusService.cs	36.36%	5 Missing and 9 partials ⚠️
plugins/OracleService/OracleService.cs	55.00%	4 Missing and 5 partials ⚠️
...ins/DBFTPlugin/Consensus/ConsensusService.Check.cs	54.54%	2 Missing and 3 partials ⚠️
...s/StateService/Verification/VerificationService.cs	0.00%	5 Missing ⚠️
...ins/OracleService/Protocols/OracleNeoFSProtocol.cs	0.00%	3 Missing ⚠️
plugins/RpcServer/RpcServerPlugin.cs	40.00%	0 Missing and 3 partials ⚠️
...s/StateService/Verification/VerificationContext.cs	0.00%	2 Missing ⚠️
...FTPlugin/Consensus/ConsensusContext.MakePayload.cs	0.00%	0 Missing and 1 partial ⚠️
plugins/DBFTPlugin/Consensus/ConsensusContext.cs	66.66%	1 Missing ⚠️
... and 3 more

Additional details and impacted files

@@              Coverage Diff              @@
##           master-n3    #1013      +/-   ##
=============================================
+ Coverage      43.73%   47.42%   +3.68%     
=============================================
  Files            274      274              
  Lines          15682    15631      -51     
  Branches        1959     2001      +42     
=============================================
+ Hits            6859     7413     +554     
+ Misses          8461     7754     -707     
- Partials         362      464     +102     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[shargon]

@superboyiii could you test it?

[superboyiii]

Even all active in config.json like:

  "ApplicationConfiguration": {
    "Logger": {
      "Path": "Logs",
      "ConsoleOutput": true,
      "Active": true
    },
    ...

No log shows in console although it's generated in ./Logs/Plugin_DBFTPlugin.

[superboyiii]

All console log is not working... Are we going to cancel console log but just keep local log?

[Wi1l-B0t]

All console log is not working... Are we going to cancel console log but just keep local log?

No console log.

Do we really need console log?

[shargon]

All console log is not working... Are we going to cancel console log but just keep local log?

We should be able to have both

[Wi1l-B0t]

All console log is not working... Are we going to cancel console log but just keep local log?

We should be able to have both

It can been done.
But it will make logging more complicated.

Maybe tail is OK.

[superboyiii]

It can been done. But it will make logging more complicated.

Maybe tail is OK.

Then you should remove console output related option in config. It's there but not working, making people confusing.

[superboyiii]

@Wi1l-B0t I'm very confusing why you think the old log is simple. I haven't seen any improvement in this PR but just turn to Serilog instead. Here’s no configuration visible support for Serilog sinks like JSON, Seq, or Elasticsearch. Console output is removed and no colorful Loglevel anymore. For ordinary users the perceived change in the logs is minimal—possibly even worse if console output has stopped working. Anyway, I'm not against switching to Serilog, it's good. But I need to see any
real improvement so we can say The previous logger is too simple.

[shargon]

Should be optional, just a bool in config

[Wi1l-B0t]

@Wi1l-B0t I'm very confusing why you think the old log is simple. I haven't seen any improvement in this PR but just turn to Serilog instead. Here’s no configuration visible support for Serilog sinks like JSON, Seq, or Elasticsearch. Console output is removed and no colorful Loglevel anymore. For ordinary users the perceived change in the logs is minimal—possibly even worse if console output has stopped working. Anyway, I'm not against switching to Serilog, it's good. But I need to see any real improvement so we can say The previous logger is too simple.

?
Why no improvement ?
The previous implementation opens file, close file each log, and creates log instance even if log is disabled.

This is a naive and inefficient way.

[Wi1l-B0t]

@Wi1l-B0t I'm very confusing why you think the old log is simple. I haven't seen any improvement in this PR but just turn to Serilog instead. Here’s no configuration visible support for Serilog sinks like JSON, Seq, or Elasticsearch. Console output is removed and no colorful Loglevel anymore. For ordinary users the perceived change in the logs is minimal—possibly even worse if console output has stopped working. Anyway, I'm not against switching to Serilog, it's good. But I need to see any real improvement so we can say The previous logger is too simple.

OK.

I will create an update to support the use of different sinks.

[Wi1l-B0t]

@Wi1l-B0t I'm very confusing why you think the old log is simple. I haven't seen any improvement in this PR but just turn to Serilog instead. Here’s no configuration visible support for Serilog sinks like JSON, Seq, or Elasticsearch. Console output is removed and no colorful Loglevel anymore. For ordinary users the perceived change in the logs is minimal—possibly even worse if console output has stopped working. Anyway, I'm not against switching to Serilog, it's good. But I need to see any real improvement so we can say The previous logger is too simple.

neo-project/neo#4513

[ajara87]

I don’t see value in keeping two logging systems. Having both would only duplicate configuration and increase maintenance while Serilog already provides structured logging and better extensibility