Show HN: Logdy.dev – web based log viewer UI for local development environments | Hacker News Reader

Show HN: Logdy.dev – web based log viewer UI for local development environments

logdy.dev

111 pointspiterrro29 comments

Author here: Logdy is a self-hosted, single binary, open source cli tool that catches stdout from a terminal and sends it to web browser UI. It's goal is to structure the logs and save time searching and browsing them.

This is an early version, I'm looking for feedback.

If you would like to try the tool without downloading it visit: https://demo.logdy.dev/ Latest release: https://github.com/logdyhq/logdy-core/releases

For local development, I cannot recommend lnav[1] enough. Discovering this tool was a game changer in my day to day life. Adding comments, filtering in/out, prettify and analyse distribution is hard to live without now.

I don't think a browser tool would fit in my workflow. I need to pipe the output to the tool.

[1] https://lnav.org/

This is a great idea for a project. You should also make it work as a Docker logging driver plugin[1] so that people can easily view their local Docker container logs through Logdy

[1]: https://docs.docker.com/config/containers/logging/plugins/

Interesting, I'll take a look at it. I was thinking specifically about Docker usage and right now you can do like this

$ logdy stdin 'docker logs --follow my_container_name'

I guess writing a logging driver plugin will enable better experience to the user. I'll investigate it, thanks for the nudge!

This looks neat. Getting a few examples on how it can connect to multiple sources like docker engine and k8s may make it a solid tool for developers that need to develop in complex infra setup. I have seen K9s fill this space with room for improvement.

Wouldn't make more sense to have the same observability stack on production and development? For instance, open-observe is also a single binary that provides UI for logs, metrics and traces, although every log producer would have to be properly configured and routing to it.

Another idea: maybe chrome dev-tools could be repurposed to display server logs instead of client logs, somehow [2].

1: https://github.com/openobserve/openobserve

2: https://chromedevtools.github.io/devtools-protocol/

Had epiphany to build something similar not long ago https://github.com/grmkris/monocon

Sadly my motivation did not last long. Nice project

As an aside, what are people's goto tools for remotely reading server side logs?

Is there anything free / open source that's decent and gives me a log dashboard?

If it's just files, lnav [1] is pretty good.

[1] https://lnav.org/

You can configure tools like Elastic or SigNoz[1] for this.

https://github.com/signoz/signoz

I’ve been waiting for something like this to pop up for a long while! Do you consider integrating with VSCode?

That is my plan in the long term. I need to explore building VSCode extensions but that option is definitely on the table.

In what way would this integrate with VS Code?

I'm not sure if that's possible but in the most simple way, just open a webrowser tab as a panel in VSCode so you don't have to switch between the editor and browser.

This project might solve the problem I have been having for a long time but falls short. My usecase is that I have a directory with log files in multiple subdirectories. I would like to explore these logs by pointing logdy at this directory. Is this possible somehow?

That depends on the constraints you have. Currently you can start a tail on multiple files if you don't need to distinguish the filenames in Logdy

- $ logdy stdin 'tail -f file1.log file2.log' this use case is described here [1].

Logdy currently works best with tailing, however exploring big files is not supported well as Logdy will stream the whole content if used like $ logdy stdin 'cat bigfile.log'. I'm planning to introduce another mode [2] that will work more like a 'less' command.

[1] https://logdy.dev/docs/how-tos#how-to-tail-multiple-files [2] https://logdy.dev/docs/explanation/command-modes#read-soon

Have you considered getting logs from journal? That could make this useful also in ops context.

License? Business model?

You can

$ logdy stdin 'journalctl -u service-name -f'

I would need more feedback on a specific use case. I started with forwarding development logs in mind, however during the process I quickly realized there might be more use cases when one would find useful forwarding logs to web UI, example: ops, data science, long-running scripts. I hope to get feedback from these angles as well.

Sure and journalctl even has `--output json` flag that I suppose would work here. But still I think native journal support would be just convenient, and would avoid needing this two layers of filtering (first journalctl and then logdy)

Love the idea, but the contrast is broken when `prefers-color-scheme: light`. Can't read headings or settings text.

Only tried the live demo page — so ignore this if it's fixed. :)

Something like this has been on my wishlist for a while now. I'll take it for a spin, thank you!

There isn't any license file.

Nice project, I really like the idea. Is it possible to create multiple log streams at once?

I'm working on it as we speak! My plan is to listen on multiple ports then attach the "origin" field to each log message with the port number it was produced with. This way you should be able to do:

$ logdy socket 8001,8002,8003

$ node app1.js | nc 8001;

$ node app2.js | nc 8002;

$ node app3.js | nc 8003;

Wdyt?

Makes sense! I like the approach.

Not sure if you want to go that route, but unix sockets allow you to use SO_PASSCRED to get the pid of the connected process, you could use that as natural "origin" without requiring many ports

How do you pronounce "Logdy"?

My initial idea for a name was "logd" but a few projects on github already take that name. Adding "y" doesn't change the pronunciation IMO so you can say "logdy" same as "logd"

I think you might want to rethink it. One of the cardinal sins of branding is making a word that does not have an immediately obvious pronunciation since it exponentially decreases the likelihood of being mentioned in conversation.

Reply on news.ycombinator.com