8 ms·

Rtop – agentless sever monitoring tool built with Go

154 points by kylequest 11y ago

andor 11y 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_speak 11y 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 11y ago
    Or... ssh host 'bash -s' < /path/to/local/script
- philsnow 11y 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_speak 11y ago
    Have you seen OpsDash? http://www.opsdash.com/ http://www.opsdash.com/
    - finnn 11y ago
      >Self Hosted >Invite Wtf is this? Why would self hosted shit need invites?
      - andor 11y ago
        They probably want to talk to potential customers and learn about their requirements.
      - Sanddancer 11y ago
        It's in beta, so I imagine they want to be able to manage to support load as they tweak various bits and pieces of the system before having it go live.
      - reitanqild 11y ago
        FYI, your language and lack of thought invites downvotes. Self Hosted for example doesn't necessarily also mean Open Source or Free.
        finnn 11y ago
        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 11y ago
        What differences do you see?
        finnn 11y ago
        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.
Velox 11y 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 11y ago
  I agree, but maybe to shine light on what infrastructure and constraints will be required to support the tool in question?
- proksoup 11y 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 11y 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 11y 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.
  - ecnahc515 11y ago
tomblomfield 11y ago
Typo in the title - sever/server
sigmonsays 11y 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 11y 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-gb https://walledcity.com/supermighty/building-go-projects-with...
  - lstamour 11y 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 https://github.com/golang/go/wiki/PackageManagementTools
lsc 11y 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.)
- philsnow 11y 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.
  - lsc 11y 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.
fasteo 11y ago
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 11y ago
  This does seem to really only be for monitoring, vs ansible and salt aiming at managing and changing system configuration.
embro 11y 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 11y 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 11y ago
  It looks like a perfect match for an ansible-managed fleet, though.

154 points by kylequest 11y ago

andor 11y 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_speak 11y 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 11y ago
  Or... ssh host 'bash -s' < /path/to/local/script
philsnow 11y 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_speak 11y ago
  Have you seen OpsDash? http://www.opsdash.com/ http://www.opsdash.com/
  - finnn 11y ago
    >Self Hosted >Invite Wtf is this? Why would self hosted shit need invites?
    - andor 11y ago
      They probably want to talk to potential customers and learn about their requirements.
    - Sanddancer 11y ago
      It's in beta, so I imagine they want to be able to manage to support load as they tweak various bits and pieces of the system before having it go live.
    - reitanqild 11y ago
      FYI, your language and lack of thought invites downvotes. Self Hosted for example doesn't necessarily also mean Open Source or Free.
      - finnn 11y ago
        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 11y ago
        What differences do you see?
        finnn 11y ago
        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.

Velox 11y 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 11y ago
I agree, but maybe to shine light on what infrastructure and constraints will be required to support the tool in question?
proksoup 11y 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 11y 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 11y 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.
- ecnahc515 11y ago

tomblomfield 11y ago

Typo in the title - sever/server

sigmonsays 11y 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 11y 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-gb https://walledcity.com/supermighty/building-go-projects-with...
- lstamour 11y 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 https://github.com/golang/go/wiki/PackageManagementTools

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

philsnow 11y 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.
- lsc 11y 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.

fasteo 11y ago

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 11y ago
This does seem to really only be for monitoring, vs ansible and salt aiming at managing and changing system configuration.

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