Add LOG_STDOUT support

[mhmdksh]

This is meant to lessen the development burden to support Elastic Logging natively by the application or any direct centralized logging solution

Take into consideration the below:

• Logs are written to STDOUT & STDERR instead of a file
• This should be optional (We are only using this on demand, and specific use case, ex: Kubernetes for centralised logging)
• The application should not crash in case there is no .log file and this option is enabled (We should not create a volume in k8s to hold the .log file just for the application to start successfully)

Check this for reference: https://github.com/Giveth/impact-graph/commit/0f06e0a134e93e8c5ab3d63087d970776325e1ab

[aminlatifi]

This is meant to lessen the development burden to support Elastic Logging natively by the application or any direct centralized logging solution

Take into consideration the below:

• Logs are written to STDOUT & STDERR instead of a file
• This should be optional (We are only using this on demand, and specific use case, ex: Kubernetes for centralised logging)
• The application should not crash in case there is no .log file and this option is enabled (We should not create a volume in k8s to hold the .log file just for the application to start successfully)

Check this for reference: Giveth/impact-graph@0f06e0a

Thanks @mhmdksh, Though, the modification by https://github.com/Giveth/impact-graph/commit/0f06e0a134e93e8c5ab3d63087d970776325e1ab doesn't stop writing files to a directory! You mean we must disable it too?

[mhmdksh]

Hey @aminlatifi

So this is the point that I was not sure about. But after reviewing it for a little bit I guess we can leave it as it is. (I mean no change to logging to a .log file is required)

Instead, I should modify the docker attached volumes in the kubernetes deployment in order for it not to make mapping a log file necessary. And see how it goes.

So I assume we can proceed forward with the other STDOUT & STDERR logging option normally.