Rtop – agentless sever monitoring tool built with Go

by kylequest • 11 years ago

154 56 11 years ago

andor2• 11 years ago

Interesting, but I'd rather let SSH handle the SSH connection. Just add a command to the parameters, e.g. to run top:

  ssh -t hostname top

i_have_to_speak2• 11 years ago

rtop collects a bunch of metrics and displays them. The equivalent would be to scp a script first then "ssh host /path/to/script" it.

thezilch• 11 years ago

Or...

    ssh host 'bash -s' < /path/to/local/script

philsnow3• 11 years ago

Yeah, ssh -t host [h]top is the existing default and rtop doesn't seem to bring anything more to the table. Maybe it's another one of those "I wanted to learn golang" projects, but there's nothing in the README.md about it.

I thought at first that this was going to be a thing where you could feed it a list of hostnames and it would go to all the hosts in parallel and show you aggregated metrics across them, like "what is the distribution of cpu load caused by my main app server" or "what is the distribution of free memory on these 20 machines" over the next N minutes while I change something", sort of a halfway point between opening a few windows with "ssh -t host1 top" "ssh -t host2 top" ... etc, and having full-blown centralized stats gathering like with e.g. datadog.

That would be a pretty sweet tool; I haven't heard of anything in this space yet.

i_have_to_speak2• 11 years ago

Have you seen OpsDash? http://www.opsdash.com/

Velox• 11 years ago

This isn't directed at this particular post, but more to HN in general. Why do I now constantly see "Tool XYZ (written in Go)" as though this is a hugely important aspect? I've never seen a "Tool ABC (written in Java)", so what's so great about Go? I know the features of the language help ensure "safe" development, but if someone was releasing software, I'd expect it to be relatively safe no matter what the language. So why is a tool being written in Go so important?

platz• 11 years ago

I agree, but maybe to shine light on what infrastructure and constraints will be required to support the tool in question?

proksoup• 11 years ago

Atom written in JavaScript makes atom more desirable to me as a JavaScript developer.

As a JavaScript developer I can get my head around Go programs. Java hurts my brain, I'm not sure why.

I like using programs I can get my head around.

kbaker• 11 years ago

Agreed in general... But, if you DO direct it to this particular post, you can see it is basically shelling out to get its parameters, or looking at /proc/, which you could just as easily do with bash + ssh. So the only benefit to using go for this is... the runtime overhead of the go libraries?

I think this project was maybe just posted way too early, it doesn't even provide 'top' - there is no breakdown of CPU by PID which is why top has its name... all the files are committed yesterday...

dkulchenko• 11 years ago

To me, "written in Go" is essentially shorthand for zero-dep, statically linked, single binary deployment.

This is a pretty big selling point for command-line utilities like rtop, as opposed to utilities written in Java/Python/Ruby/Node/etc. which require their respective runtime to be installed.

krat0sprakhar2• 11 years ago

This. Knowing that a command line / server side tool is written in Go conveys that it's very easy to install and dependency free.

ecnahc515• 11 years ago

Yep. It immediately tells me that I probably will have zero issues deploying it, compared to many of the python/ruby/node etc apps these days.

pjmlp2• 11 years ago

as opposed to utilities written in Java/Python/Ruby/Node/etc. which require their respective runtime to be installed.

In Java's case only by those that don't know what the Java eco-system offers.

There are plenty of commercial JVMs that offer AOT compilation, including static linking.

Plus as of Java 8, there is even a packager as part of the reference JDK.

lqdc133• 11 years ago

Isn't Python installed by default on most distros?

istvan__2• 11 years ago

It is as easy to achieve in so many languages (zero-dep, statically linked, single binary). I think this is part of the best practices more than the language itself.

fasteo2• 11 years ago

I would agree with this, but rtop is not meant to be installed on every server you want to monitor. The point is that it can remotely monitor any number of servers without previous agent installation. So, being written in go is kind of "useless" in this case, as you only need to install it in your C&C server, so to speak.

coolsunglasses• 11 years ago

Since the same is true of Haskell, can I add this tagline to everything made with Haskell without people complaining?

est2• 11 years ago

Me taking note: do not ever again distribute tools in source code in .tar.gz by default. Provide pre-compiled, copy & run binaries.

notduncansmith• 11 years ago

I don't think it's about Go itself (as if that makes the software better), but moreso that if you're a Go* developer, you may find the source of such a tool interesting - while Go seems particularly well-suited to writing system utils, perhaps there are parts of the codebase that seem like they may be difficult to implement in the language. Additionally, if the source is in a language one is familiar with, one may find that codebase leading to a deeper understanding of the tool itself.

* Go here being a proxy for any language. The same goes for Rust, Haskell, Javascript, etc - this trend certainly isn't unique to Go.

skybrian• 11 years ago

In the early days of Java, people did say "written in Java" and pure Java libraries were a thing since they're easier to ship as part of a Java app than wrappers of native libraries.

Java has never been very good for command-line tools, though, due to startup time.

sysk• 11 years ago

Some variant of this comment is also constantly being made in "X written in Y" threads and it's getting a bit annoying. (https://news.ycombinator.com/item?id=8907143, https://news.ycombinator.com/item?id=8751303, https://news.ycombinator.com/item?id=6160293, https://news.ycombinator.com/item?id=5436736, https://news.ycombinator.com/item?id=9061312, https://news.ycombinator.com/item?id=8163537, etc.)

Dewie3• 11 years ago

I know the features of the language help ensure "safe" development,

Safe development? What does that mean?

dang• 11 years ago

I think it's just that the audience is full of programmers who are always curious about how stuff is implemented.

Pretty sure there have been plenty of posts saying "written in Java", though of course fashionable languages get more of this.

iand• 11 years ago

In the early days of Java, there were tons of articles titled XXX written in Java. Just go look at some early Slashdot or JavaWorld.

tomblomfield• 11 years ago

Typo in the title - sever/server

sigmonsays• 11 years ago

You're incorrectly setting up the source tree which makes it difficult to "go get".

why have a makefile and not just allow "go get github.com/rapidloop/rtop" to function?

politician• 11 years ago

`go get` seems to be increasingly considered harmful -- for example, by its poor dependency versioning practices which promotes non-reproducible builds. See Dave Cheney's `gb` project for an alternative. [1]

As a fellow gopher, I've decided to consider support for `go get` a non-goal in my projects for similar reasons.

[1] https://walledcity.com/supermighty/building-go-projects-with...

lstamour• 11 years ago

"go get" on its own isn't to blame -- the culture folks behind Go are trying to promote is that dependencies are intrinsically part of your code and thus you have to maintain them. I'm not going to say that version pinning harms this, but the lack of it is no reason to throw away good conventions around imports mapping to URLs, etc.

For a set of alternative package managers that are perhaps more in the "spirit of go get", see https://github.com/golang/go/wiki/PackageManagementTools

lsc2• 11 years ago

the agentless/agentful security question is an important one. I mean, all existing snmpd implementations suck, right? but the idea is that if you run snmpd (or another agent) on your monitored servers, if an attacker takes over your monitoring server, they still have to find an exploit in snmpd or whatever agent you use; whereas in an agentless setup like this, if your attacker gains access to your monitoring server, said attacker has a (hopefully non-root) shell on all the monitored boxes.

On the other hand, installing this agentless setup is going to be dramatically easier, and this is way less likely to accidentally blow up the box being monitored, say, than snmpd.

(clearly, with snmpd and other agents, you want to make it so that only the monitoring server can see those services, either through tunnels or what have your. Leaving a snmpd port open to the general internet is crazy.)

philsnow3• 11 years ago

whereas in an agentless setup like this, if your attacker gains access to your monitoring server, said attacker has a (hopefully non-root) shell on all the monitored boxes.

I think the idea with rtop in particular is not to have it running headless ever, but you'd only use it interactively. There would not be a "monitoring server", at least not running rtop.

If you wanted to use it this way, note that rtop currently sshes around places and then execs a bunch of local commands. That gives me both the heebies and the jeebies. I'd much rather deploy an rtop-server compiled binary and restrict the ssh key that rtop uses to connect with something like "command=/usr/bin/rtop-server" in the .ssh/authorized_keys file for the local user that will accept rtop-initiated ssh connections.

lsc2• 11 years ago

I think the idea with rtop in particular is not to have it running headless ever, but you'd only use it interactively. There would not be a "monitoring server", at least not running rtop.

Aah. I misunderstood. I've not figured out how to run a cluster without giving myself through one of my workstations or a jump box or something ssh access to all of them, so I'm generally okay with a program that automates some of that SSHing I do, like ansible; far more comfortable than I am with a box that is running some monitoring web frontend having any kind of access to my backend servers. (I usually try to give that box read-only access to the storage that another server which queries the agents writes to.)

To be clear, I'm not super comfortable with this situation, but I don't see any way around of having my own login everywhere, or of making it so that if I do have my own login everywhere, my logging in from a compromised machine is not a game over.

(as an aside, you and I mean different things by headless; usually when i say 'headless' - i mean 'the video port is disabled or unused' - all the servers I use are managed via serial console, and I would call them 'headless' - I think my usage is more standard than yours, but I could be wrong.)

If you wanted to use it this way, note that rtop currently sshes around places and then execs a bunch of local commands. That gives me both the heebies and the jeebies. I'd much rather deploy an rtop-server compiled binary and restrict the ssh key that rtop uses to connect with something like "command=/usr/bin/rtop-server" in the .ssh/authorized_keys file for the local user that will accept rtop-initiated ssh connections.

Yeah, that is what I meant by "some sort of agent." - I personally make rather extensive use of the forced-command bit in ssh.

fasteo2• 11 years ago

This is fairly close to Ansible (agentless) and Salt stack (optionally agentless)

Or am I missing something ?

[1] http://www.ansible.com/home

[2] http://saltstack.com/

detaro2• 11 years ago

This does seem to really only be for monitoring, vs ansible and salt aiming at managing and changing system configuration.

embro• 11 years ago

I really like the fact that you can monitor remote servers!

Not sure if you consider feature requests but I would love to be able to monitor ZFS as well with it.

sengork• 11 years ago

Instead of depending on a running agent, SSH based remote monitors depend on the consistency of the SSH configuration across the fleet of machines. This is sometimes non-trivial configuration find in heterogeneous environments (usernames, authentication, permissions, sshd_config...).

regularfry• 11 years ago

It looks like a perfect match for an ansible-managed fleet, though.

Rtop – agentless sever monitoring tool built with Go

Related Stories