4 ms·

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

111 points by piterrro 3y ago

pmig 3y ago
Nice project, I really like the idea. Is it possible to create multiple log streams at once?
- piterrro 3y ago
  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?
  - pmig 3y ago
    Makes sense! I like the approach.
  - zokier 3y ago
    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
piterrro 3y ago
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/ https://demo.logdy.dev/ Latest release: https://github.com/logdyhq/logdy-core/releases https://github.com/logdyhq/logdy-core/releases
anirudhan 3y ago
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?
- piterrro 3y ago
  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 https://logdy.dev/docs/how-tos#how-to-tail-multiple-files [2] https://logdy.dev/docs/explanation/command-modes#read-soon https://logdy.dev/docs/explanation/command-modes#read-soon
zokier 3y ago
Have you considered getting logs from journal? That could make this useful also in ops context. License? Business model?
- piterrro 3y ago
  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.
  - zokier 3y ago
    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)
iddan 3y ago
I’ve been waiting for something like this to pop up for a long while! Do you consider integrating with VSCode?
- piterrro 3y ago
  That is my plan in the long term. I need to explore building VSCode extensions but that option is definitely on the table.
- liammclennan 3y ago
  In what way would this integrate with VS Code?
  - piterrro 3y ago
    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.
abusaidm 3y ago
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.
random_kris 3y ago
Had epiphany to build something similar not long ago https://github.com/grmkris/monocon https://github.com/grmkris/monocon Sadly my motivation did not last long. Nice project
yashafromrussia 3y ago
Something like this has been on my wishlist for a while now. I'll take it for a spin, thank you!
coxley 3y ago
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. :)
thayne 3y ago
There isn't any license file.
firecall 3y ago
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?
- veyh 3y ago
  If it's just files, lnav [1] is pretty good. [1] https://lnav.org/ https://lnav.org/
- pranay01 3y ago
  You can configure tools like Elastic or SigNoz[1] for this. https://github.com/signoz/signoz https://github.com/signoz/signoz
pugz 3y ago
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/ https://docs.docker.com/config/containers/logging/plugins/
- piterrro 3y ago
  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!
emmanueloga_ 3y ago
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 https://github.com/openobserve/openobserve 2: https://chromedevtools.github.io/devtools-protocol/ https://chromedevtools.github.io/devtools-protocol/
jspdown 3y ago
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/ https://lnav.org/
popalchemist 3y ago
How do you pronounce "Logdy"?
- piterrro 3y ago
  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"
  - popalchemist 3y ago
    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.

111 points by piterrro 3y ago

pmig 3y ago

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

piterrro 3y ago
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?
- pmig 3y ago
  Makes sense! I like the approach.
- zokier 3y ago
  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

piterrro 3y ago

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/ https://demo.logdy.dev/ Latest release: https://github.com/logdyhq/logdy-core/releases https://github.com/logdyhq/logdy-core/releases

anirudhan 3y ago

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?

piterrro 3y ago
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 https://logdy.dev/docs/how-tos#how-to-tail-multiple-files [2] https://logdy.dev/docs/explanation/command-modes#read-soon https://logdy.dev/docs/explanation/command-modes#read-soon

zokier 3y ago

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

piterrro 3y ago
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.
- zokier 3y ago
  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)

iddan 3y ago

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

piterrro 3y ago
That is my plan in the long term. I need to explore building VSCode extensions but that option is definitely on the table.
liammclennan 3y ago
In what way would this integrate with VS Code?
- piterrro 3y ago
  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.

abusaidm 3y ago

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.

random_kris 3y ago

Had epiphany to build something similar not long ago https://github.com/grmkris/monocon https://github.com/grmkris/monocon Sadly my motivation did not last long. Nice project

yashafromrussia 3y ago

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

coxley 3y ago

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. :)

thayne 3y ago

There isn't any license file.

firecall 3y ago

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?

veyh 3y ago
If it's just files, lnav [1] is pretty good. [1] https://lnav.org/ https://lnav.org/
pranay01 3y ago
You can configure tools like Elastic or SigNoz[1] for this. https://github.com/signoz/signoz https://github.com/signoz/signoz

pugz 3y ago

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/ https://docs.docker.com/config/containers/logging/plugins/

piterrro 3y ago
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!

emmanueloga_ 3y ago

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 https://github.com/openobserve/openobserve 2: https://chromedevtools.github.io/devtools-protocol/ https://chromedevtools.github.io/devtools-protocol/

jspdown 3y ago

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/ https://lnav.org/

popalchemist 3y ago

How do you pronounce "Logdy"?

piterrro 3y ago
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"
- popalchemist 3y ago
  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.