Logging session / debug logs to stdout

[vinylmike]

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: Select all

## 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: Select all

sv.enable.consoleout=true

[vinylmike]

Hi Harold,

Unfortunately that didn't help.

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

Code: Select all

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: Select all

$ 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: Select all

$ 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: Select all

[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.