Forums Read-only archive

Logging session / debug logs to stdout

14 posts · Brekeke SIP Server Forum

vinylmike Original post
1. Brekeke Product Name and Version:
3.14.7.4, Advanced

2. Java version:
openjdk-11-jdk

3. OS type and the version:
AWS ECS / docker - amzn2.x86_64

4. UA (phone), gateway or other hardware/software involved:
Freeswitch

5. Your problem:
Is there a way to configure Brekeke SIP Server to log to stdout instead of sip/WEB-INF/work/sv/log/2024? Specifically the SIP Session and Debug logs?

In an AWS ECS environment stdout / stderr gets logged/streamed to Cloudwatch.
Harold
Add lines below in [Configuration]->[Advanced] page.

Code: 

## For outputting Session Log in stdout.
file.log.session.plugin=com.brekeke.common.LoggingConsole

## For outputting Server Log in stdout.
file.log.plugin=com.brekeke.common.LoggingConsole
vinylmike
Thank you for the response. I have tried those settings and do see the log data is no longer being written to disk, but I also do not see anything in stdout.

Any thoughts?


Thanks,
Mike
Harold
Also add this line in [Configuration]->[Advanced] page.

Code: 

sv.enable.consoleout=true
vinylmike
Hi Harold,

Unfortunately that didn't help.

I've got the following in [Configuration]->[Advanced]:

Code: 

file.log.plugin=com.brekeke.common.LoggingConsole
file.log.session.plugin=com.brekeke.common.LoggingConsole
sv.enable.consoleout=true
Any other thoughts?

Thanks,
Mike
Harold
I confirmed that the settings above writes logs for stdout in Linux.

So I can see logs from the command below.
cat /proc/<pid>/fd/1
Harold
Did you enable following logging Categories in [Diagnostics]->[Debug Logs] page?

SIP Session, Registrar
vinylmike
Hi Harold,

Thanks for the reply. Yes, SIP Session is checked in [Diagnostics]->[Debug Logs]. We're not using registration. Here's what I've discovered -

If I run a ps -ef on the Brekeke SIP Server process, it will yield something like this:

root 9564 8979 1 16:34 ? [truncated]
9564 is the PID
8979 is the PPID

If I "echo test >> /proc/8979/fd/1", I can see the entry using docker logs <container>, as well as in Cloudwatch. However, Brekeke is using PID, /proc/9564/fd/1, and those don't appear in Cloudwatch nor docker logs.

From the Tomcat point of view I've insured that it is configured to only log using ConsoleHandler.

Any thoughts on this?

Regards,
Mike
Harold
If you run the ps command, there are several java processes, not only SIP Server.

You can check the SIP Server's PID at [PID] filed in [Status]->[SIP Server] page.
vinylmike
Hi Harold,

Yes, you're correct, I see the other java processes. The problem as I see it is that the Brekeke stream is not being outputted to the main process of the container (PID 1 inside the container). Docker only captures the stdout and stderr of the main process.

Thanks,
Mike
Harold
If you use Linux as a host OS to run Docker, you can get a PID of a process running inside a Docker container.

With this PID, can you access to SIP Server's STDOUT?
vinylmike
Hi Harold,

Yes, I can get the PIDs -

Code: 

$ sudo docker top 4139f011f70a
UID                 PID                 PPID                C                   STIME               TTY                 TIME                CMD
root                7017                6944                0                   09:15               ?                   00:00:57            /usr/bin/java -Djava.util.logging.config.file=/usr/share/tomcat9/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djdk.tls.ephemeralDHKeySize=2048 -Djava.protocol.handler.pkgs=org.apache.catalina.webresources -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Dhttp.proxyHost=proxy -Dhttp.proxyPort=3128 -Dignore.endorsed.dirs= -classpath /usr/share/tomcat9/bin/bootstrap.jar:/usr/share/tomcat9/bin/tomcat-juli.jar -Dcatalina.base=/usr/share/tomcat9 -Dcatalina.home=/usr/share/tomcat9 -Djava.io.tmpdir=/usr/share/tomcat9/temp org.apache.catalina.startup.Bootstrap start
root                7200                7017                0                   09:15               ?                   00:00:46            /usr/lib/jvm/java-11-openjdk-amd64/bin/java -Duser.dir=/usr/share/tomcat9/webapps/sip/WEB-INF/work/sv -Dhsqldb.reconfig_logging=false -Xrs -classpath /usr/share/tomcat9/webapps/sip/WEB-INF/classes:/usr/share/tomcat9/webapps/sip/WEB-INF/lib/ondoutil.jar:/usr/share/tomcat9/webapps/sip/WEB-INF/lib/ondooss.jar:/usr/share/tomcat9/webapps/sip/WEB-INF/lib/hsqldb.jar:/usr/lib/jvm/java-11-openjdk-amd64/lib/tools.jar:/usr/share/tomcat9/bin/bootstrap.jar:/usr/share/tomcat9/bin/tomcat-juli.jar:null org.hsqldb.server.Server --props db_r.properties
root                29702               7017                3                   17:51               ?                   00:00:03            /usr/lib/jvm/java-11-openjdk-amd64/bin/java -Xrs -Dfile.encoding=UTF-8 -classpath /usr/share/tomcat9/webapps/sip/WEB-INF/classes:/usr/lib/jvm/java-11-openjdk-amd64/lib/tools.jar:/usr/share/tomcat9/bin/bootstrap.jar:/usr/share/tomcat9/bin/tomcat-juli.jar:/usr/share/tomcat9/common/classes:/usr/share/tomcat9/lib/tomcat-api.jar:/usr/share/tomcat9/lib/catalina-ha.jar:/usr/share/tomcat9/lib/annotations-api.jar:/usr/share/tomcat9/lib/tomcat-util-scan.jar:/usr/share/tomcat9/lib/tomcat-coyote.jar:/usr/share/tomcat9/lib/servlet-api.jar:/usr/share/tomcat9/lib/tomcat-i18n-es.jar:/usr/share/tomcat9/lib/el-api.jar:/usr/share/tomcat9/lib/catalina-tribes.jar:/usr/share/tomcat9/lib/tomcat-dbcp.jar:/usr/share/tomcat9/lib/jaspic-api.jar:/usr/share/tomcat9/lib/jasper-el.jar:/usr/share/tomcat9/lib/jsp-api.jar:/usr/share/tomcat9/lib/catalina-ant.jar:/usr/share/tomcat9/lib/tomcat-i18n-ru.jar:/usr/share/tomcat9/lib/catalina-storeconfig.jar:/usr/share/tomcat9/lib/tomcat-i18n-ja.jar:/usr/share/tomcat9/lib/jasper.jar:/usr/share/tomcat9/lib/tomcat-jni.jar:/usr/share/tomcat9/lib/tomcat-websocket.jar:/usr/share/tomcat9/lib/catalina.jar:/usr/share/tomcat9/lib/tomcat-i18n-fr.jar:/usr/share/tomcat9/lib/tomcat-util.jar:/usr/share/tomcat9/lib/tomcat-jdbc.jar:/usr/share/tomcat9/lib/websocket-api.jar:/usr/share/tomcat9/webapps/sip/WEB-INF/lib/javax.mail.jar:/usr/share/tomcat9/webapps/sip/WEB-INF/lib/activation.jar:/usr/share/tomcat9/webapps/sip/WEB-INF/lib/ondoutil.jar:/usr/share/tomcat9/webapps/sip/WEB-INF/lib/hsqldb.jar:/usr/share/tomcat9/webapps/sip/WEB-INF/lib/br10.jar:/usr/share/tomcat9/webapps/sip/WEB-INF/lib/smtp.jar:/usr/share/tomcat9/webapps/sip/WEB-INF/lib/remoteweb-agent.jar:/usr/share/tomcat9/webapps/sip/WEB-INF/lib/log4j-core-2.18.0.jar:/usr/share/tomcat9/webapps/sip/WEB-INF/lib/pop3.jar:/usr/share/tomcat9/webapps/sip/WEB-INF/lib/br11.jar:/usr/share/tomcat9/webapps/sip/WEB-INF/lib/mailapi.jar:/usr/share/tomcat9/webapps/sip/WEB-INF/lib/ondooss.jar:/usr/share/tomcat9/webapps/sip/WEB-INF/lib/log4j-core.jar:/usr/share/tomcat9/webapps/sip/WEB-INF/lib/radiusplugin.jar:/usr/share/tomcat9/webapps/sip/WEB-INF/lib/TFplugin.jar:/usr/share/tomcat9/webapps/sip/WEB-INF/lib/jradiusclient.jar:/usr/share/tomcat9/webapps/sip/WEB-INF/lib/ondosip.jar:/usr/share/tomcat9/webapps/sip/WEB-INF/lib/log4j-api-2.18.0.jar:/usr/share/tomcat9/webapps/sip/WEB-INF/lib/json_simple-1.1.jar:/usr/share/tomcat9/webapps/sip/WEB-INF/lib/log4j.jar:/usr/share/tomcat9/webapps/sip/WEB-INF/lib/commons-lang3-3.1.jar:null -Xmx256m com.brekeke.ondo.sv -f /usr/share/tomcat9/webapps/sip/WEB-INF/work/sv/sv_r.properties -d /usr/share/tomcat9/webapps/sip/WEB-INF/work/sv -product Brekeke SIP Server -e 5 -l 15
Brekeke logs to 29702 and, from while on the Linux host, if I cat 29702, I can see the Brekeke log stream.

The issue is that the contents streaming to 29702 (/proc/29702/fd/1) do not get sent to Cloudwatch, because 29702 is not the main process of the container, 7017 is (/proc/7017/fd/1) and Docker only captures the stdout and stderr of the main process.

So for example, if I run the following:

Code: 

$ echo "test to main process id" >> /proc/7017/fd/1
$ echo "test to process id brekeke is streaming to" >> /proc/29702/fd/1
and then look at Cloudwatch, I see only the message sent to the main process id, 7017 (/proc/7017/fd/1)

Code: 

[2024-02-23T12:59:03-05:00] (brekeke-sip-server) test to main process id
Hopefully that all makes sense.

Thanks,
Mike
vinylmike
I ended up with a sidecar approach, using fluentd. This appears to not be a Brekeke SIP Server issue and more with how docker/Cloudwatch work.

Thanks for your help.
Harold
Thank you for the update.