6 ms·

Show HN: Monitor in a Box – Instantly usable, open source monitoring

74 points by danfromberlin 10y ago

TjWallas 10y ago
Very interesting. As one of the sufferers who struggled many times with setting up icinga2 with distributed (and SSL-Encrypted) monitoring, this automation takes a way a lot of the hassle. I think it is one step in the right direction. Reminds me with: https://mailinabox.email/ https://mailinabox.email/
- 24gttghh 10y ago
  This is very interesting, thank you for sharing!
tlackemann 10y ago
Really nice setup, I'm glad to see Ansible being used to orchestrate the machines. I really do like that system for it's ease of use and low learning-curve.
zbjornson 10y ago
Wondering what the free version uses if it doesn't include graphite for dashboarding. It also feels way more invasive to have to install Ansible on all of my servers instead of just statsd plus a config file to point it at a host. (Edit: it's not required.) Nice to have a supported, pro-grade monitoring product that isn't priced per server, finally.
- danfromberlin 10y ago
  Hi zbjornson, regarding your question about "Wondering what the free version uses if it doesn't include graphite for dashboarding": the answer is that free version just includes the icingaweb dashboards and not those implemented with grafana. Also I'd like to clarify a possible misunderstanding: Monitor in a Box does not require that ansible be installed on all the servers. We only require that ansible be installed on the one machine that orchestrates the setup of Monitor in a Box.
  - zbjornson 10y ago
    Ah, thanks for clarifying, I misunderstood that part of your FAQ. Looking forward to trying it out.
    - danfromberlin 10y ago
      The free version doesn't provide any visualizations other than what you see in the icingaweb dashboards. The icinga demo (not grafana) should give you an idea of what I mean: https://solutions.stacktile.io/demo https://solutions.stacktile.io/demo In the spirit of shameless self-promotion, I invite you to clone our git repo and see for yourself! :-)
jeyoor 10y ago
I'm impressed with this project's messaging and support/feature pricing structure. I think trying to find more sustainable models for funding open-source software is interesting, and I don't recall seeing this exact approach used before (i.e. free version w/o LE or Graphana support). It'd be amazing if a percentage of each support contract gets donated back to upstream projects like icinga2, Graphana, and LE.
VA3FXP 10y ago
I would love to read more about your product/service/idea. But I can't. http://contrastrebellion.com/ http://contrastrebellion.com/ Being visually impaired just makes things worse. Your site doesn't work with FireFox 'Reader View', and that forces me to 'Toggle CSS' off which causes the icons and site-design to be FUBAR. You might have the best damn product in the world, but if I can't read about it on your own pages then it's no good to me. I only found out that you use Ansible from the comments on here from another poster. I really want to know about this now as I have migrated our entire datacenter to Ansible, and I really love it.
- danfromberlin 10y ago
  Hi VA4FXP, I'm sorry about that. We'll see what we can do to address this problem.
- 6DM 10y ago
  If anyone is looking for a tool to assist on this, the link leads to w3c, which has links directly to some free resources: https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html#visual-audio-contrast-contrast-resources-head https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-cont...
- unethical_ban 10y ago
  Is reader view an officially supported standard? I must say that if you can't read the #586772 on white, that's a pretty severe handicap that I imagine would require a screenreader. Let me postscript that I have sympathy for not having full ability to read on the internet, and I'm sure the world would be easier for many if screenreaders and high contrast were universal, but I also wonder whether and by how much design must suffer to accomodate all users.
  - trhway 10y ago
    >I must say that if you can't read the #586772 on white, that's a pretty severe handicap well, i have pretty much technically perfect (just very easily tired after almost 30 years looking into the screen) vision and while i can read it, i'd prefer to have it in higher contrast as i just physically feel how my eyes have to work harder for the glorious make benefit of design. After spending some time some years ago on accessibility related work, it became clear to me that while obviously the accessibility is the key for handicapped users, the thought-through accessibility (vs. just "get a screenreader") on a project frequently results in the improved design that is better (like in particular cleaner and simpler in appearance and interaction flow) for the regular non-handicapped users too.
kristopolous 10y ago
Is it just me or do these pitch pages always seem very light on what the software actually does... does it aggregate logs? LD tweaking maybe? Is it a kernel module? What is this technology?
- danfromberlin 10y ago
  Hi Kristopolous, In a nutshell, Monitor in a box is a system/application monitoring solution based on Ansible, Icinga 2 and Grafana. I would like to kindly point you to our demo to see what our software does. We've also made our code available at github, and I invite you to check out our README to get an idea of how to begin using. I hope that helps clarify what we're trying to do.
  - kristopolous 10y ago
    The github readme is far better. Have you ever been to the vendor floor of a Linux convention? It's like 30-40 "monitoring" and "devops" solutions with a web dashboard that in my mind are indistinguishable complex solutions to simple problems. I'm looking for simple solutions to complex problems...Thanks for responding
    - jamiesonbecker 10y ago
      > simple solutions to complex problems Too true. Messaging that is relevant to both technical people ("devops") and business (management, procurement, etc) is a hard problem to solve, though! There seems to be a marketing tendency to either gloss over the technical ideas behind a product, or make technical details front-and-center and leave anyone less than 100% technical searching for a product that they can grok. This is something we're struggling with right now: our basic messaging for Userify (ssh key management), which is actually a fairly simple and sane product, has gotten a bit out of hand as well: our support team is fielding frequent questions like, "what does each edition do." We've got to get on top of that and get some comparison matrices or something up. Applauding the OP for a nice, clean landing page that conveys most of the relevant details, but as you point out, the Github readme is far better. There's a lesson in there somewhere.
sagichmal 10y ago
Icinga? Really?
- danfromberlin 10y ago
  Hi sagichmal, To be precise, Monitor in a box is a solution built in-part on Icinga 2.
- packetslave 10y ago
  Yes, really. Feigned surprise adds nothing to a conversation. https://www.recurse.com/manual#sub-sec-social-rules https://www.recurse.com/manual#sub-sec-social-rules
dozzie 10y ago
Honestly, fixing Icinga's broken architecture (shared with Nagios, Shinken, Zenoss, and Zabbix) with a bunch of shell and Ansible scripts doesn't seem like very robust solution. And install instructions from README on GitHub looks like one big let's not, with half a dozen of modernish tools that obscure what's actually happening (basically, `apt-get install icinga2' and putting some config files in place).
- danfromberlin 10y ago
  Hi dozzie [edit: typo], I can entirely sympathize with your comment here, but I'd like to try to quickly present a contrary perspective: Indeed there are architectural trade-offs made by every monitoring system, and icinga2 makes some that we also have found to be frustrating: one such example that comes to mind for me personally is that icinga aims to maintain backwards compatibility with its historically-derived nagios configuration file syntax which is difficult to understand and hard to parse in an automated fashion. On the other hand, there are exampls of architectural choices that I believe icinga gets right: It implements an approach to secure and authenticated metrics collection that virtually every other monitoring system leaves as an "exercise" for the user. It provides checks and alerts and notification thershholds by default, which many other monitoring systems don't. We build monitor in a box to attempt to highlight one particular approach to using icinga 2 which we find works for us. We attempt to be systematic and through in our approach, aiming for a reproducible, Ansible based implementation that emphasizes modularity and code reuse. We invite everyone to try out our open source offering to decide for his or her self whether the benfits of running icinga 2 in this fashion outweigh the drawbacks.
  - dozzie 10y ago
    > Hi dozie, It's two "z" there. > [...] icinga aims to maintain backwards compatibility with its historically-derived nagios configuration file syntax which is difficult to understand and hard to parse in an automated fashion. Parsing Icinga/Nagios configuration file is easy, even if you count object templates (register=0 and use foo) and use handcrafted parser instead of generated one. The syntax is not a complicated one. I don't know what problems have you encountered. > On the other hand, there are exampls of architectural choices that I believe icinga gets right: It implements an approach to secure and authenticated metrics collection that virtually every other monitoring system leaves as an "exercise" for the user. Oh, this is more or less easy task if your monitoring system has some secret (e.g. X.509 certificate) exchanged with the monitored hosts, and can be bolted on pretty much any monitoring system with some stunnel-fu (which proves that it's nothing on the architecture side of the system). It's sharing that secret in a robust and automatic way that is quite difficult. I doubt Icinga does anything better than the rest of the crowd. > It provides checks and alerts and notification thershholds by default, which many other monitoring systems don't. Once you have an established flow of monitoring messages, then thresholds, alerts, and notification become simple stream processing and consumption. Sure, Icinga and others give you this simple processing in the package, and some systems give you a few more queries than others (e.g. originally Nagios only processed what I call "state", while Cacti only processed metrics, and Zabbix processes both). But this processing rarely is complex. And none of them give you an ability to process the data stream itself. And then there is this almost universally shared requirement that you need to define all the instances of hosts and services beforehand, only differing how the template system is implemented in a given monitoring system. You can't just start collecting data about servers as they get installed and about services and resources as they emerge and disappear. No, you need to tell the monitoring system that it should expect data from this host and this service (collectd, Graphite, and InfluxDB got it right here). It is useful sometimes for monitoring system to expect some data to show up (and possibly alert that it's missing), only sometimes, not all the time. Usually other data can easily cover the scenario where something silently goes down, and there's still this "stream processing" thing I mentioned that can just monitor that some data stopped being received.
randomsofr 10y ago
I'm so stupid, can someone ELI5 what this is for?
DougN7 10y ago
As someone from the Windows world, I'm always surprised to read things like: "That said, the more specific you customize your monitoring, the more detailed an understanding of these components you will need." This sounds as bad as what I've heard about Nagios. Why does it have to be so complicated?

74 points by danfromberlin 10y ago

Very interesting. As one of the sufferers who struggled many times with setting up icinga2 with distributed (and SSL-Encrypted) monitoring, this automation takes a way a lot of the hassle. I think it is one step in the right direction. Reminds me with: https://mailinabox.email/ https://mailinabox.email/

24gttghh 10y ago
This is very interesting, thank you for sharing!

tlackemann 10y ago

Really nice setup, I'm glad to see Ansible being used to orchestrate the machines. I really do like that system for it's ease of use and low learning-curve.

zbjornson 10y ago

Wondering what the free version uses if it doesn't include graphite for dashboarding. It also feels way more invasive to have to install Ansible on all of my servers instead of just statsd plus a config file to point it at a host. (Edit: it's not required.) Nice to have a supported, pro-grade monitoring product that isn't priced per server, finally.

danfromberlin 10y ago
Hi zbjornson, regarding your question about "Wondering what the free version uses if it doesn't include graphite for dashboarding": the answer is that free version just includes the icingaweb dashboards and not those implemented with grafana. Also I'd like to clarify a possible misunderstanding: Monitor in a Box does not require that ansible be installed on all the servers. We only require that ansible be installed on the one machine that orchestrates the setup of Monitor in a Box.
- zbjornson 10y ago
  Ah, thanks for clarifying, I misunderstood that part of your FAQ. Looking forward to trying it out.
  - danfromberlin 10y ago
    The free version doesn't provide any visualizations other than what you see in the icingaweb dashboards. The icinga demo (not grafana) should give you an idea of what I mean: https://solutions.stacktile.io/demo https://solutions.stacktile.io/demo In the spirit of shameless self-promotion, I invite you to clone our git repo and see for yourself! :-)

jeyoor 10y ago

I'm impressed with this project's messaging and support/feature pricing structure. I think trying to find more sustainable models for funding open-source software is interesting, and I don't recall seeing this exact approach used before (i.e. free version w/o LE or Graphana support). It'd be amazing if a percentage of each support contract gets donated back to upstream projects like icinga2, Graphana, and LE.

VA3FXP 10y ago

I would love to read more about your product/service/idea. But I can't. http://contrastrebellion.com/ http://contrastrebellion.com/ Being visually impaired just makes things worse. Your site doesn't work with FireFox 'Reader View', and that forces me to 'Toggle CSS' off which causes the icons and site-design to be FUBAR. You might have the best damn product in the world, but if I can't read about it on your own pages then it's no good to me. I only found out that you use Ansible from the comments on here from another poster. I really want to know about this now as I have migrated our entire datacenter to Ansible, and I really love it.

danfromberlin 10y ago
Hi VA4FXP, I'm sorry about that. We'll see what we can do to address this problem.
6DM 10y ago
If anyone is looking for a tool to assist on this, the link leads to w3c, which has links directly to some free resources: https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html#visual-audio-contrast-contrast-resources-head https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-cont...
unethical_ban 10y ago
Is reader view an officially supported standard? I must say that if you can't read the #586772 on white, that's a pretty severe handicap that I imagine would require a screenreader. Let me postscript that I have sympathy for not having full ability to read on the internet, and I'm sure the world would be easier for many if screenreaders and high contrast were universal, but I also wonder whether and by how much design must suffer to accomodate all users.
- trhway 10y ago
  >I must say that if you can't read the #586772 on white, that's a pretty severe handicap well, i have pretty much technically perfect (just very easily tired after almost 30 years looking into the screen) vision and while i can read it, i'd prefer to have it in higher contrast as i just physically feel how my eyes have to work harder for the glorious make benefit of design. After spending some time some years ago on accessibility related work, it became clear to me that while obviously the accessibility is the key for handicapped users, the thought-through accessibility (vs. just "get a screenreader") on a project frequently results in the improved design that is better (like in particular cleaner and simpler in appearance and interaction flow) for the regular non-handicapped users too.

kristopolous 10y ago

Is it just me or do these pitch pages always seem very light on what the software actually does... does it aggregate logs? LD tweaking maybe? Is it a kernel module? What is this technology?

danfromberlin 10y ago
Hi Kristopolous, In a nutshell, Monitor in a box is a system/application monitoring solution based on Ansible, Icinga 2 and Grafana. I would like to kindly point you to our demo to see what our software does. We've also made our code available at github, and I invite you to check out our README to get an idea of how to begin using. I hope that helps clarify what we're trying to do.
- kristopolous 10y ago
  The github readme is far better. Have you ever been to the vendor floor of a Linux convention? It's like 30-40 "monitoring" and "devops" solutions with a web dashboard that in my mind are indistinguishable complex solutions to simple problems. I'm looking for simple solutions to complex problems...Thanks for responding
  - jamiesonbecker 10y ago
    > simple solutions to complex problems Too true. Messaging that is relevant to both technical people ("devops") and business (management, procurement, etc) is a hard problem to solve, though! There seems to be a marketing tendency to either gloss over the technical ideas behind a product, or make technical details front-and-center and leave anyone less than 100% technical searching for a product that they can grok. This is something we're struggling with right now: our basic messaging for Userify (ssh key management), which is actually a fairly simple and sane product, has gotten a bit out of hand as well: our support team is fielding frequent questions like, "what does each edition do." We've got to get on top of that and get some comparison matrices or something up. Applauding the OP for a nice, clean landing page that conveys most of the relevant details, but as you point out, the Github readme is far better. There's a lesson in there somewhere.

sagichmal 10y ago

Icinga? Really?

danfromberlin 10y ago
Hi sagichmal, To be precise, Monitor in a box is a solution built in-part on Icinga 2.
packetslave 10y ago
Yes, really. Feigned surprise adds nothing to a conversation. https://www.recurse.com/manual#sub-sec-social-rules https://www.recurse.com/manual#sub-sec-social-rules

dozzie 10y ago

Honestly, fixing Icinga's broken architecture (shared with Nagios, Shinken, Zenoss, and Zabbix) with a bunch of shell and Ansible scripts doesn't seem like very robust solution. And install instructions from README on GitHub looks like one big let's not, with half a dozen of modernish tools that obscure what's actually happening (basically, `apt-get install icinga2' and putting some config files in place).

danfromberlin 10y ago
Hi dozzie [edit: typo], I can entirely sympathize with your comment here, but I'd like to try to quickly present a contrary perspective: Indeed there are architectural trade-offs made by every monitoring system, and icinga2 makes some that we also have found to be frustrating: one such example that comes to mind for me personally is that icinga aims to maintain backwards compatibility with its historically-derived nagios configuration file syntax which is difficult to understand and hard to parse in an automated fashion. On the other hand, there are exampls of architectural choices that I believe icinga gets right: It implements an approach to secure and authenticated metrics collection that virtually every other monitoring system leaves as an "exercise" for the user. It provides checks and alerts and notification thershholds by default, which many other monitoring systems don't. We build monitor in a box to attempt to highlight one particular approach to using icinga 2 which we find works for us. We attempt to be systematic and through in our approach, aiming for a reproducible, Ansible based implementation that emphasizes modularity and code reuse. We invite everyone to try out our open source offering to decide for his or her self whether the benfits of running icinga 2 in this fashion outweigh the drawbacks.
- dozzie 10y ago
  > Hi dozie, It's two "z" there. > [...] icinga aims to maintain backwards compatibility with its historically-derived nagios configuration file syntax which is difficult to understand and hard to parse in an automated fashion. Parsing Icinga/Nagios configuration file is easy, even if you count object templates (register=0 and use foo) and use handcrafted parser instead of generated one. The syntax is not a complicated one. I don't know what problems have you encountered. > On the other hand, there are exampls of architectural choices that I believe icinga gets right: It implements an approach to secure and authenticated metrics collection that virtually every other monitoring system leaves as an "exercise" for the user. Oh, this is more or less easy task if your monitoring system has some secret (e.g. X.509 certificate) exchanged with the monitored hosts, and can be bolted on pretty much any monitoring system with some stunnel-fu (which proves that it's nothing on the architecture side of the system). It's sharing that secret in a robust and automatic way that is quite difficult. I doubt Icinga does anything better than the rest of the crowd. > It provides checks and alerts and notification thershholds by default, which many other monitoring systems don't. Once you have an established flow of monitoring messages, then thresholds, alerts, and notification become simple stream processing and consumption. Sure, Icinga and others give you this simple processing in the package, and some systems give you a few more queries than others (e.g. originally Nagios only processed what I call "state", while Cacti only processed metrics, and Zabbix processes both). But this processing rarely is complex. And none of them give you an ability to process the data stream itself. And then there is this almost universally shared requirement that you need to define all the instances of hosts and services beforehand, only differing how the template system is implemented in a given monitoring system. You can't just start collecting data about servers as they get installed and about services and resources as they emerge and disappear. No, you need to tell the monitoring system that it should expect data from this host and this service (collectd, Graphite, and InfluxDB got it right here). It is useful sometimes for monitoring system to expect some data to show up (and possibly alert that it's missing), only sometimes, not all the time. Usually other data can easily cover the scenario where something silently goes down, and there's still this "stream processing" thing I mentioned that can just monitor that some data stopped being received.

randomsofr 10y ago

I'm so stupid, can someone ELI5 what this is for?

DougN7 10y ago

As someone from the Windows world, I'm always surprised to read things like: "That said, the more specific you customize your monitoring, the more detailed an understanding of these components you will need." This sounds as bad as what I've heard about Nagios. Why does it have to be so complicated?