Comments (14)
It's really only ruby for historical reasons, and to simplify installation and updating--gem update riemann-dash is a heck of a lot easier than mucking around with tarballs. If you want to take a stab at a Clojure variant and can get the memory profile in the same ballpark, and figure out a good technique for packaging it on various *nix flavors, be my guest.
chillitom [email protected] wrote:
I was wondering if anyone had considered converting riemann-dash to a pure clojure application to remove the ruby dependency, seems like ruby/rails is barely required as it is only serving files and allowing simple config load/save.
If you thought it'd be useful/desirable then I could have a stab at it.
—
Reply to this email directly or view it on GitHub.
from riemann-dash.
Wanted to revive this discussion, as cljs has been growing and many companies are now using it. This would allow code reuse, as well as low memory footprint after clj has been compiled to js.
Ideally, you then write a .clj config file, which generates the necessary pages
Thoughts?
from riemann-dash.
I think you would be hard-pressed to get the memory profile for a Clojure variant close to the Ruby version.
What about a version in Go? Go has fantastic HTTP and WebSocket support, can be compiled and distributed to multiple nix environments, has a low memory footprint, and is fast.
from riemann-dash.
To clarify--riemann-dash does no websockets handling; its whole purpose in life is to serve up some static files and store a chunk of JSON config in the filesystem. No real constraints on performance or library support there, so I suggest only taking the time to rewrite it if it makes installing, upgrading, or maintaining riemann-dash significantly simpler for users.
from riemann-dash.
@kingsbury, I went through the dash source a few days ago and thought that was the case as I saw no WS-related code.
Perhaps the README should be changed to reflect the fact that ws* (I presumse) originates from the riemann server and not the dash server?
from riemann-dash.
@aphyr Regarding the ruby argument, for someone who doesn't use Ruby (anymore) in production it is not as trivial as gem update
. I actually had to install extra gcc packages for Nokogiri dependencies and I had to upgrade the default ruby version from 1.8 to 1.9 as well. And then I had another problem with eventmachine dependencies of Thin that I "solved" by removing it from the gemspec.
For what the dashboard code is, static html plus js, and a config update API endpoint the above is pretty complex. I think I would prefer the config endpoint to be removed or optional, and just have a bundle of static assets that can be served by any webserver from any language. Ruby could be used to generate those bundles (like with Middleman), but wouldn't be a requirement on the server. These static assets could be bundled as a release on Github. And why not serve this static html with the normal Riemann server?
What do you guys think?
from riemann-dash.
Huh. I honestly don't hear many complaints about the installation process, (pretty painless on a stock Debian or Ubuntu box, in my experience) but if you'd like to take over riemann-dash's server and packaging responsibilities you'd be more than welcome to do so. That might take the form of a total rewrite, or of just tuning the dependencies somewhat.
I strongly advocate against embedding it in Riemann proper; Riemann's server is already a very large and complex project, and I'm fighting hard to keep its role simple and well-defined.
from riemann-dash.
I should also mention that 1.8 has been scheduled for EOL for some time now; haven't run anything less than 1.9.1 on a server in 3 years. apt-get install ruby1.9 build-essentials should basically handle the deps on debian, and IIRC it was pretty similar on centos.
from riemann-dash.
Yeah having worked with Ruby for many years I know 1.8 is a long time no go. The point though is that I had to deal with this upgrade issue anyway since it is still the default (on my Centos). Luckily I did have Ruby experience while other people might feel it is too much effort. Should we really care about Ruby specifics whereas this app is (currently) just static html?
from riemann-dash.
I think we should do the simplest thing possible for the most people. That might just mean writing 4 lines of docs showing how to install it on centos, instead of re-writing the app from scratch.
from riemann-dash.
(Missed your previous comment)
I understand the complexities of the server and of maintaining these package. And to be clear, I really appreciated Riemann even though I've only used small parts of it. I just wanted to point out a different light on the matter than e.g. rewriting it to a Clojure or Go app.
When I become more familiar with Riemann I maybe have better thoughts on this.
Regarding the simplest thing possible, I couldn't agree more :-)
from riemann-dash.
For what it is worth, here are my notes on what I did to get things working https://gist.github.com/jeroenvandijk/283791297a56aa43a66c
from riemann-dash.
+1
from riemann-dash.
Another 2 years later... :) I'm looking at Riemann again. I'll consider doing something with a dashboard at some point I think. In the meanwhile I found these links of other people trying:
There are some useful pieces in there I believe.
from riemann-dash.
Related Issues (20)
- [question] sample query for dashboard HOT 4
- Theme and Custom views support. Would you be interested in this addition? HOT 1
- Add "Undo" operation to riemann-dash HOT 2
- "expired" events appearing from nowhere HOT 2
- Dashboard showing socker error, HOT 7
- The HOT 2
- The "spec" link in the help is dead
- toolbar height is to small HOT 6
- Request for enhancement: ability to specify riemann host, port, connection type as HTTP GET parameters
- fix incorrect (404) link to spec in help text HOT 1
- Edit on mac os x does not work HOT 1
- How to start with the dashboard? HOT 2
- `setup_storage_backend': Unknown backend
- Problems using riemann-dash with secure websockets wss HOT 4
- save dashboard error
- Ruby Sass has reached end-of-life and should no longer be used
- Provide support for the latest version of gem thin. HOT 1
- Graphs going backward in time... sometimes HOT 1
- Key bindings not working on OS X HOT 2
- Rack::CommonLogging is enabled even when RACK_ENV is set to production
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from riemann-dash.