4 ms·

Hubble - a terminal dashboard

124 points by jaymedavis 14y ago

josegonzalez 14y ago
Is it possible to have the dashboard auto-update itself instead of posting to it?
- jcla1 14y ago
  From looking at the code, it should be quite easy to extend Hubble to make requests to a server. As far as I can tell, all you need to do is write a function that will call a server/resource and then call board.set/.draw. And then wrap that in a setInterval...
  - jaymedavis 14y ago
    Yep, you got it. Having a way to auto fetch something is a very soon thing. I also want to be able to have some sort of regex fetcher that can fetch and webpage and regex scrape a value (if not using an api, etc)
keyle 14y ago
That's great! But you know that begs for sparklines... https://github.com/holman/spark https://github.com/holman/spark
- jonaldomo 14y ago
  +1 for sparklines, autorefresh would be cool too
  - hakaaaaak 14y ago
    Why not just do it like top; by itself it would autorefresh or you could -n 1 and just see it once?
- jaymedavis 14y ago
  OH HELLS YEAH. This looks awesome! Thanks!
gingerlime 14y ago
Looks very cool. I really like the way it looks and the idea of having a text-based dashboard. Similar to the other comments, would be nice to be able to add some `fetcher` plugins, that know how to pull data from external resources (Graphite, Google Analytics etc), preprocess it, and then push it to the dashboard. If you go down that route however, then the question is why run a server in the first place? It kinda goes against the essence of a command-line tool, which should be lightweight, quick and can run (almost) anywhere. I'm not trying to discourage you, but am thinking whether instead of server-based architecture, this might be better off as a client with different 'plugins' for different types of data (e.g. a sysinfo plugin that gets memory and cpu, a graphite plugin to fetch data from your graphite server, an SQL plugin etc) (disclaimer: I wrote Giraffe, a graphite dashboard, so perhaps I'm suffering from tunnel-vision based on the graphite architecture).
- jaymedavis 14y ago
  Fetching is definitely something I want to do, but it's more of an 'also supports' thing. I want it to be able to get data in all sorts of ways. :)
icio 14y ago
Hubble looks really nice. There are times when I'm wanting to monitor particular aspects of how an application is running that this would be particularly interesting. There's been a few mentions of having hubble do the requesting itself, but I don't think that should distract from arbitrary systems being able to post to hubble. That said, being able to have hubble handle your polling for local tasks would be particularly interesting: a kind of `watch` dashboard. With that in mind, perhaps opening up a `watch` like interface to hubble would work well: hubble watch -n3600 --title "Bootstrap contributors" "curl -s https://api.github.com/repos/twitter/bootstrap/contributors | jsawk -a 'return this.length'"
deleted 14y ago
[deleted]

124 points by jaymedavis 14y ago

josegonzalez 14y ago

Is it possible to have the dashboard auto-update itself instead of posting to it?

jcla1 14y ago
From looking at the code, it should be quite easy to extend Hubble to make requests to a server. As far as I can tell, all you need to do is write a function that will call a server/resource and then call board.set/.draw. And then wrap that in a setInterval...
- jaymedavis 14y ago
  Yep, you got it. Having a way to auto fetch something is a very soon thing. I also want to be able to have some sort of regex fetcher that can fetch and webpage and regex scrape a value (if not using an api, etc)

keyle 14y ago

That's great! But you know that begs for sparklines... https://github.com/holman/spark https://github.com/holman/spark

jonaldomo 14y ago
+1 for sparklines, autorefresh would be cool too
- hakaaaaak 14y ago
  Why not just do it like top; by itself it would autorefresh or you could -n 1 and just see it once?
jaymedavis 14y ago
OH HELLS YEAH. This looks awesome! Thanks!

gingerlime 14y ago

Looks very cool. I really like the way it looks and the idea of having a text-based dashboard. Similar to the other comments, would be nice to be able to add some `fetcher` plugins, that know how to pull data from external resources (Graphite, Google Analytics etc), preprocess it, and then push it to the dashboard. If you go down that route however, then the question is why run a server in the first place? It kinda goes against the essence of a command-line tool, which should be lightweight, quick and can run (almost) anywhere. I'm not trying to discourage you, but am thinking whether instead of server-based architecture, this might be better off as a client with different 'plugins' for different types of data (e.g. a sysinfo plugin that gets memory and cpu, a graphite plugin to fetch data from your graphite server, an SQL plugin etc) (disclaimer: I wrote Giraffe, a graphite dashboard, so perhaps I'm suffering from tunnel-vision based on the graphite architecture).

jaymedavis 14y ago
Fetching is definitely something I want to do, but it's more of an 'also supports' thing. I want it to be able to get data in all sorts of ways. :)

icio 14y ago

Hubble looks really nice. There are times when I'm wanting to monitor particular aspects of how an application is running that this would be particularly interesting. There's been a few mentions of having hubble do the requesting itself, but I don't think that should distract from arbitrary systems being able to post to hubble. That said, being able to have hubble handle your polling for local tasks would be particularly interesting: a kind of `watch` dashboard. With that in mind, perhaps opening up a `watch` like interface to hubble would work well: hubble watch -n3600 --title "Bootstrap contributors" "curl -s https://api.github.com/repos/twitter/bootstrap/contributors | jsawk -a 'return this.length'"

deleted 14y ago

[deleted]