May I know if there is an existing separate log file for RESTCONF interface?
See the confd.conf(5) man page under /confdConfig/logs/webuiAccessLog/trafficLog
There is says:
Beware: Do not use this log in a production setting. This log is not enabled by default and is not rotated, i.e. use logrotate(8).
Is the warning only because the log isn’t rolled? If it’s rolled, is it safe to enable this in PROD?
@tspencer, you probably did something to enable a restconf log in production, so instead of asking, I suggest you share what you did (if anything).
I didn’t actually 
I was excited, however, to see that there is a log just for RESTCONF because this is something our customers would probably like to use. I was a bit concerned though about the warning, so I wanted to get that clarified.
The web server (Yaws) produce log entries for all HTTP(S) traffic, combining JSON-RPC and RESTCONF logging.
/confdConfig/logs/webuiAccessLog
<Host>.access - for each virtual host served by Yaws, a file <Host>.access will be
written that contains an access log in NCSA combined/XLF/ELF log format. (See
http://www.w3.org/TR/WD-logfile.html for more details on Extended Log File Format.)
/confdConfig/logs/webuiAccessLog/trafficLog
trace_<YYYYMMDD_hhmmss> - Trace files are written in this subdirectory, suffixed by
the creation date.
trace.<Pid>.traffic - this file contains the traffic trace if that is enabled,
where <Pid> is the (Erlang) process id handling the TCP connection.
/confdConfig/logs/webuiAccessLog/dir
All of the above files and subdirectories go into this the directory.
Not as simple as doing logrotate on a log file if you want to rotate those files and subdirectory files. I don’t have a good example of rotating all of that.
Perhaps someone on this forum can share their strategy for when deploying these logs in production?
1 Like
There will be performance penalties if you are logging all traffic. This is why it’s not recommended in production I think.
1 Like