Closed meta3ark closed 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?
debian server terminal -> docker logs container_name prints colored logs as expected.
I've attached raws logs from docker logs container_name > dozzle.txt
It's a very minor problem so if it was something quick to fix then worth reporting.
That might help reproduce it. Can you also show a screenshot of docker logs
so I know what it is supposed to look like?
Ah wait, you hid the time stamps! So Wed 17:04:45.315 is from your own logs?
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.
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.
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.
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 π
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.
@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.
That makes sense why I couldn't find those characters in ansi colors.
π 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
π If applicable, attach your Dozzle logs. You many need to enable debug mode. See https://dozzle.dev/guide/debugging.
No response