mORMot Open Source

jaclas

Member

Registered: 2014-09-12

Posts: 215

Separate log for services

I use the event EchoCustom to log server behavior. However, I would like that every REST service had its own, separate log (separate event EchoCustom). How to do it correctly? Do I have to create an instance TSynLogFamily in each REST service?

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,669

Website

Re: Separate log for services

You would need a separated TSynLog class for each REST service...
So it is not obvious, nor fully tested yet...

jaclas

Member

Registered: 2014-09-12

Posts: 215

Re: Separate log for services

I guess I don't understand completely :-)
Event EchoCustom is in a class TSynLogFamily, so I had only one event? How to distinguish from which the service is an log entry in the event?

...and how create TSynLog in my REST service when I can't call constructor...

    /// intialize for a TSynLog class instance
    // - WARNING: not to be called directly! Use Enter or Add class function instead
    constructor Create(aFamily: TSynLogFamily=nil);

Please some example.

Last edited by jaclas (2017-02-28 13:47:28)

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,669

Website

Re: Separate log for services

It is not feasible like that.

Depending on the class/family options, you may have several TSynLog instances per family...
I suspect you could use your stand-alone TSynLog instance, but it is not tested, nor used on our side.

The log viewer makes it easy to identify several log threads, and browse huge content with needed granularity.
Currently, we rely on a single low-level log file, and use SOA-level logs in a SQLite3 database to have information about a given service.
See https://synopse.info/files/html/Synopse … #TITLE_443

We found out that the benefit of having separated log files make it more difficult to identify concurrent issues.
So the high-level logs are at SOA level in a SQlite3 database - very easy to browse and query using any SQL SELECT statement needed.
And the low-level logs are still there, but only for debugging / audit.