amir20 / dozzle

Realtime log viewer for docker containers.
https://dozzle.dev/
MIT License
5.7k stars 287 forks source link

Suppress ANSI color escape sequence from logs #3147

Closed meta3ark closed 1 month ago

meta3ark commented 1 month ago

πŸ” Check for existing issues

How is Dozzle deployed?

Standalone Deployment

πŸ“¦ Dozzle version

8.0.6

βœ… Command used to run Dozzle

dozzle: container_name: in-dozzle image: amir20/dozzle:latest restart: unless-stopped volumes:

πŸ› Describe the bug / provide steps to reproduce it

?1h= ansi escape sequence strings occasionally appear in log entries.

Only appears to happen on unix deployment. Dotnet Serilog works as expected on console, Docker Desktop for Windows.

πŸ’» Environment

Client: Docker Engine - Community Version: 27.0.3 Context: default Debug Mode: false Plugins: buildx: Docker Buildx (Docker Inc.) Version: v0.15.1 Path: /usr/libexec/docker/cli-plugins/docker-buildx compose: Docker Compose (Docker Inc.) Version: v2.28.1 Path: /usr/libexec/docker/cli-plugins/docker-compose

Server: Containers: 24 Running: 23 Paused: 0 Stopped: 1 Images: 24 Server Version: 27.0.3 Storage Driver: overlay2 Backing Filesystem: extfs Supports d_type: true Using metacopy: false Native Overlay Diff: true userxattr: false Logging Driver: json-file Cgroup Driver: systemd Cgroup Version: 2 Plugins: Volume: local Network: bridge host ipvlan macvlan null overlay Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog Swarm: inactive Runtimes: runc io.containerd.runc.v2 Default Runtime: runc Init Binary: docker-init containerd version: ae71819c4f5e67bb4d5ae76a6b735f29cc25774e runc version: v1.1.13-0-g58aa920 init version: de40ad0 Security Options: apparmor seccomp Profile: builtin cgroupns Kernel Version: 6.1.0-22-amd64 Operating System: Debian GNU/Linux 12 (bookworm) OSType: linux Architecture: x86_64 CPUs: 4 Total Memory: 7.421GiB Name: REDACTED ID: 531b0ca4-76c6-4575-afc1-9fff9a7dd479 Docker Root Dir: /var/lib/docker Debug Mode: false Experimental: false Insecure Registries: 127.0.0.0/8 Live Restore Enabled: false

πŸ“Έ If applicable, add screenshots to help explain your bug

dozzle

πŸ“œ If applicable, attach your Dozzle logs. You many need to enable debug mode. See https://dozzle.dev/guide/debugging.

No response

amir20 commented 1 month ago

I have never seen this. Dozzle doesn't have 1h variable any where.

If someone else sees this then maybe I can debug.

Could you create a compose file to reproduce?

meta3ark commented 1 month ago

debian server terminal -> docker logs container_name prints colored logs as expected.

I've attached raws logs from docker logs container_name > dozzle.txt

dozzle.txt

It's a very minor problem so if it was something quick to fix then worth reporting.

amir20 commented 1 month ago

That might help reproduce it. Can you also show a screenshot of docker logs so I know what it is supposed to look like?

meta3ark commented 1 month ago

dozzle2

amir20 commented 1 month ago

Ah wait, you hid the time stamps! So Wed 17:04:45.315 is from your own logs?

amir20 commented 1 month ago

My initial finding is that \033[?1h\033=\033 is not valid ANSI color. It seems like this is not related to Dozzle. I use https://www.npmjs.com/package/ansi-to-html to convert to HTML and that string doesn't work.

How are you generating these colors? Dozzle processes it correctly so probably not related to something I can fix.

amir20 commented 1 month ago

So I did a little test in javascript:

import ansiHTML from "ansi-html";

import Convert from "ansi-to-html";

const text =
  "\x1b[?1h\x1b=\x1b[?1h\x1b=Wed 17:03:45.313\x1b[0m \x1b[0m\x1b[36;1mINF\x1b[0m (\x1b[0m30\x1b[0m) [\x1b[0m_redacted_\x1b[0m] \x1b[0m_redacted_: *\x1b[0m\x1b[35m8\x1b[0m ~\x1b[0m\x1b[>";

console.log(ansiHTML(text));

const convert = new Convert();

console.log(convert.toHtml(text));

Which outputs:

Wed 17:03:45.313<span style="font-weight:normal;opacity:1;color:#fff;background:#000;"> </span>INF<span style="font-weight:normal;opacity:1;color:#fff;background:#000;"> (</span>30<span style="font-weight:normal;opacity:1;color:#fff;background:#000;">) [</span>_redacted_<span style="font-weight:normal;opacity:1;color:#fff;background:#000;">] </span>_redacted_: *<span style="font-weight:normal;opacity:1;color:#fff;background:#000;"><span style="color:#ff00ff;">8</span> ~</span>

=?1h=Wed 17:03:45.313 <span style="color:#0AA"><b>INF</b></span> (30) [_redacted_] _redacted_: *<span style="color:#A0A">8</span> ~>

So looks like ansi-html works better. But it produces a lot more HTML too.

I'll wait until you tell me how you are producing these colors. If it's something standard, then I think it's worth changing.

meta3ark commented 1 month ago

Ah wait, you hid the time stamps! So Wed 17:04:45.315 is from your own logs?

the first screenshot is from dozzle. the second is from debian server terminal. Hiding dozzle timestamps makes no difference.

meta3ark commented 1 month ago

I'm using the Serilog console sink. Serilog is pretty much the de facto standard logging package for modern dotnet (c#).

https://github.com/serilog/serilog-sinks-console#themes using the simple "sixteen" theme

I did wonder if it was serilog. Certain log messages trigger the issue consistently, but other very similar messages do not. And other messages are formatted correctly sometimes and not others. I wrote a serilog based consolidation log service (docker hosted) that takes individual service log messages and stores them in mongo and prints them to the console (docker log). A bad individual service log message is formatted correctly when re-logged in the consolidation log service console and dozzle.

It's entirely your call whether you switch converter. Thanks for your time investigating this πŸ‘

amir20 commented 1 month ago

Thanks @meta3ark. I misspoke. The other NPM module has issues with it too. I don't think I'll spend too much time on this because it is the first time I am seeing it and I don't think that many other people are impacted. Dozzle handles the logs correctly, the coloring is a different issue. A while back, I had stripped colors all together. But a few people complained. So I brought it back. Seems like if colors were stripped this wouldn't be a problem. You can test this by using the copy feature to copy the text.

For now, I am not going to do anything as this is pretty complicated and I don't have much time to figure out how to go about fixing it.

If more people see this issue, I can come back to it.

meta3ark commented 1 month ago

@amir20 just a final note.

I turned off colorizing of logs. Spurious "[?1h" continued to be printed. Bit of digging suggests they are terminal cursor position codes (1h equals top left). Which led me to https://github.com/moby/moby/issues/30137.

And finally removing "tty: true" from my docker service compose file. Escape codes are gone but so is the color.

Don't think you can do anything as there are many ansi escape codes.

amir20 commented 1 month ago

That makes sense why I couldn't find those characters in ansi colors.