Why does it have to be a custom network protocol when using syslog would not only suffice, but also allow for devices that don't run custom code (e.g., switches or routers) to be monitored?
Rtail – Terminal output to the browser using Unix pipes
11–20 of 35 posts
Re: Rtail – Terminal output to the browser using Unix pipes
#12Why does it have to be a custom network protocol when using syslog would not only suffice, but also allow for devices that don't run custom code (e.g., switches or routers) to be monitored?
Syslog is a little bit warty- if I didn't use it elsewhere[1], I wouldn't necessarily reach for it. It seems like it should also be fairly trivial to just use your OS' syslog as a shim, if you wanted this to be a syslog endpoint.
[1]: many more people should than do
Re: Rtail – Terminal output to the browser using Unix pipes
#13I am curious. What is the usecase of this?
ring ring ring
Hello?
The smoke tests are failing and Kibana isn't returning anything from the past 10 minutes
inaudible $ for i in grotty_old_server{1..10}; do ssh root@i "tail -f /var/log/froznob/goddamn-custom-logging-system" | rtail &; done
Are you still there?
Half of the servers are spewing the same stacktrace 200 times a second.
Re: Rtail – Terminal output to the browser using Unix pipes
#14I am curious. What is the usecase of this?
ring ring ring Hello? The smoke tests are failing and Kibana isn't returning anything from the past 10 minutes inaudible $ for i in grotty_old_server{1..10}; do ssh root@i "tail -f /var/log/froznob/goddamn-custom-logging-system" | rtail &; done Are you still there? Half of the servers are spewing the same stacktrace 200 times a second.
Hello and thanks for reporting! Do you mind opening an issue on github with the error you are presented?
Re: Rtail – Terminal output to the browser using Unix pipes
#15Why does it have to be a custom network protocol when using syslog would not only suffice, but also allow for devices that don't run custom code (e.g., switches or routers) to be monitored?
Syslog is a little bit warty- if I didn't use it elsewhere[1], I wouldn't necessarily reach for it. It seems like it should also be fairly trivial to just use your OS' syslog as a shim, if you wanted this to be a syslog endpoint. [1]: many more people should than do
Trivial, maybe. Not only does it add a single point of failure, though, as the logs get aggregated on the syslog host, the only “benefit” rtail retains is looking at the logs in a browser instead of tail(1).
Re: Rtail – Terminal output to the browser using Unix pipes
#16I am curious. What is the usecase of this?
I can start using this immediately for debugging the backend of a web application during development. For some kinds of debugging, it's preferable to log output to a file or tty instead of printing on the page during a request or stepping through a debugger. This is particularly true in frameworks where you might be trying to debug something that's happened after the rendering step. I would typically use standard deb…
It doesn't go to a browser (unless you use something like https://keymetrics.io/2015/06/10/pm2-ssh-expose-a-fully-capa...) but `less` is great for tailing logs, output, etc... and lets you search, filter, set marks.
> foreman start -c web=1,all_worker=3 > /tmp/x & less -r+F /tmp/x; kill -SIGINT %
I run this inside of screen so that I can decide not to wrap the lines.
Re: Rtail – Terminal output to the browser using Unix pipes
#17Earlier quoted context omitted.
Syslog is a little bit warty- if I didn't use it elsewhere[1], I wouldn't necessarily reach for it. It seems like it should also be fairly trivial to just use your OS' syslog as a shim, if you wanted this to be a syslog endpoint. [1]: many more people should than do
Trivial, maybe. Not only does it add a single point of failure, though, as the logs get aggregated on the syslog host, the only “benefit” rtail retains is looking at the logs in a browser instead of tail(1).
Not sure why syslogd as a single point of failure is worse than rtail-server being a single point of failure- there are some very, very stable & battle-tested syslogd implementations.
Additionally, it doesn't really seem like that's the case- as long as you were willing to reconfigure syslog on the hosts, you could do syslog -> rtail => rtail-server (-> is local, => is network), as rtail works via UDP.
Re: Rtail – Terminal output to the browser using Unix pipes
#18Earlier quoted context omitted.
I can start using this immediately for debugging the backend of a web application during development. For some kinds of debugging, it's preferable to log output to a file or tty instead of printing on the page during a request or stepping through a debugger. This is particularly true in frameworks where you might be trying to debug something that's happened after the rendering step. I would typically use standard deb…
It doesn't go to a browser (unless you use something like https://keymetrics.io/2015/06/10/pm2-ssh-expose-a-fully-capa... ) but `less` is great for tailing logs, output, etc... and lets you search, filter, set marks. > foreman start -c web=1,all_worker=3 > /tmp/x & less -r+F /tmp/x; kill -SIGINT % I run this inside of screen so that I can decide not to wrap the lines.
less is great, and I'm certainly comfortable using it (nice snippet btw!). Other devs on my team who are more web focused would probably find rtail easier to use.
We also have a Vagrant box for each project, and rtail would be trivial to add to the Vagrant template so that every development box has this running on a specific port without any setup or fiddling needed by each developer. At least that's the direction I'm thinking of going in right now, without having actually tried it out. :)
Re: Rtail – Terminal output to the browser using Unix pipes
#19What is the difference to using websocketd [1] to stream to a socket.io client?
Re: Rtail – Terminal output to the browser using Unix pipes
#20Wow! This is really cool! I would love to use this at my workplace. I had a small problem, though: it seems the clients don't keep very much data.
For example, I filtered based on an expression that matched about 1-2 lines per second. The lines appeared, but disappeared almost as quickly. I suspect there is some small client-side buffer that I'm overrunning almost instantly; the log stream I used produces about 500 lines per second. Is this too much for the tool? Can I tune it to work with that load?