Server logging

[kination]

Hello,
I'm testing indradb server internally, but it seems there are no log appearing in server for certain action.

• I've tried ping command, and there were no log appearing in server. It only shows grpc address.

$ ./target/release/indradb-server
grpc://127.0.0.1:27615

Are there any option to make log visible, or is it not prepared?

[ysimonson]

There's no logs at the moment, definitely makes sense to add.

[kination]

@ysimonson about logging,

• In ping, seems this is just checking proto server connection goes well, and not checking actual server runs well or not. Will it be okay? https://github.com/indradb/indradb/blob/master/proto/src/server.rs#L196
• About logging, do you have some common format having in mind?

[ysimonson]

Yeah that’s right regarding ping.

for logging, the level should be the lowest possible (I think that’s TRACE?) And maybe just the function name and stringified input argument? That should be fine except in the case of bulk insert where the argument could be too large, in which case ellipses will do. Eg bulk_insert(…)

[kination]

@ysimonson how do you think of format like following? #298

[ysimonson]

That works!

[kination]

@ysimonson hello, this is some example logs...

[2023-06-04T03:07:38Z INFO  indradb_server] Server listening at grpc://127.0.0.1:27615
[2023-06-04T03:07:44Z INFO  indradb_proto::server] Call 'create_vertex'
[2023-06-04T03:07:44Z INFO  indradb::memory::datastore] Create vertex : Vertex { id: 0e09060e-0e0b-0b03-0c01-020c06020904, t: Identifier(0x14471f520 : "test") }
...

I'm not quite sure in this part because I don't have professional experience in GraphDB. So feel free to suggest.
I think

• error: cases which can break data, or force stopping db server
• warn: cases which can cause unexpected action
• info: main informations caused by user action (such as CRUD, server running information, ...)
• debug&trace: detail running information

and

for logging, the level should be the lowest possible (I think that’s TRACE?)

=> I think such data in example above, will be okay to setup as info, cause these API call history can be used to trace server running history. How do you think?

[ysimonson]

Yeah INFO for the highest level function works fine.

I’m a little hesitant to add logging to the IndraDB library though, as that’d be somewhat prescriptive and I’m not sure if there’s enough consensus on the log crate to justify that.

if the IndraDB server log includes both the function name and it’s arguments, that may well cover most logging needs.

[kination]

@ysimonson okay, understood. Than could you think of good way to make things go on?

What I was thinking is,

• Show running information, to help admin check service is working well
• Show error information, to display the detail of exception cases
• Show debug log to show verbose data

It will be better to hold this work until you get some detail plan 👍

[ysimonson]

How about to start, we just log the gRPC calls? That might be adequate, and in any case further use will reveal if there are additional logging needs.

[kination]

@ysimonson got it. I'll make simple draft soon 🆗