
Rtop – agentless sever monitoring tool built with Go - kylequest
http://www.rtop-monitor.org/
======
andor
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

~~~
philsnow
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_speak
Have you seen OpsDash? [http://www.opsdash.com/](http://www.opsdash.com/)

~~~
finnn
>Self Hosted

>Invite

Wtf is this? Why would self hosted shit need invites?

~~~
reitanqild
FYI, your language and lack of thought invites downvotes.

Self Hosted for example doesn't necessarily also mean Open Source or Free.

~~~
finnn
That's true. I should have been more clear: If it's not using any of their
resources for me to run it (which is what I assume "self hosted" means), what
purpose is served by the invite only system? While the other commenters
mentioned support and stuff which kind of makes sense, it feels to me like
their definition of self hosted is different from my definition.

~~~
detaro
What differences do you see?

~~~
finnn
Well self-hosted to me implies that they don't have anything on their end that
has to run per-instance, which is the usual reason to do invite only betas.

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

~~~
philsnow
> 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.

~~~
lsc
>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.

------
sigmonsays
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
`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...](https://walledcity.com/supermighty/building-go-projects-with-gb)

~~~
lstamour
"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](https://github.com/golang/go/wiki/PackageManagementTools)

------
sengork
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
It looks like a perfect match for an ansible-managed fleet, though.

------
tomblomfield
Typo in the title - sever/server

------
embro
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.

------
Velox
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?

~~~
dkulchenko
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.

~~~
pjmlp
> 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.

~~~
axaxs
I'm curious to know more about these. Are any free? Are any open source? These
aren't rhetorical questions, there's a ton of Java stuff I'd want to test it
with.

I tried robovm, it actually worked nicely but apparently only does 32 bit.
Also, the simple reference HelloWorld was nearly 10MB, the build process took
20 seconds, and running it took 15x longer than a comparable one in Go. I
don't mean to knock it, what it does is amazing, but it's not a viable
replacement for simple static command line tools.

~~~
pjmlp
> Are any free? Are any open source?

No, most of those that produce good quality code are commercial, hence why I
stated that on my comment.

Some of most well known,

[http://www.excelsiorjet.com/](http://www.excelsiorjet.com/)

[http://www.atego.com/products/atego-
perc/](http://www.atego.com/products/atego-perc/)

[https://www.aicas.com/cms/en/JamaicaVM](https://www.aicas.com/cms/en/JamaicaVM)

[http://www-03.ibm.com/software/products/en/real-
time](http://www-03.ibm.com/software/products/en/real-time)

[https://www.codenameone.com/](https://www.codenameone.com/)

Oracle Research has SubstrateVM as part of Graal, but it is still
experimental.

[https://wiki.openjdk.java.net/display/Graal/Publications+and...](https://wiki.openjdk.java.net/display/Graal/Publications+and+Presentations)

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

Or am I missing something ?

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

[2] [http://saltstack.com/](http://saltstack.com/)

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

