<p>Currently using Zabbix monitoring a virtual environment. Anything like Zabbix written in Go? My deal breaker is that it must support robust alerting like Zabbix does. Already looked at OpsDash but was hoping there are other alternatives. A big bonus if the alerts can exported either in CSV, JSON, or even XML.</p>
<hr/>**评论：**<br/><br/>gogroob: <pre><p>Prometheus</p></pre>bbrazil: <pre><p>I'm one of the Prometheus developers and it should support what you need. The alertmanager's generic webhook can send out alert notifications to any HTTP endpoint in JSON.</p>
<p>I did a <a href="http://www.robustperception.io/audio-alerting-with-prometheus/">demo</a> of this a month back.</p></pre>lobster_johnson: <pre><p>We're using Prometheus.</p>
<p>It's well-designed, completely solid despite not being 1.0, fast, doesn't use much memory, has decent I/O performance, has good APIs, has decent (if basic) integration with Grafana, and is super easy to get set up.</p>
<p>Prometheus is a time series database as its core. It's similar to Zabbix (which we also used, way back, and very quickly tired of) in that its data model is based on a database of collected metrics that are monitored for trigger expressions. Unlike Zabbix, Prometheus does not have a management UI to modify its configuration; rather, it uses a rather simple YAML configuration file. It's also much simpler than Zabbix. It doesn't care about the topology of your data center; its data model is completely metric-oriented.</p>
<p>The alerting system is simple, but functional. The core keeps track of pre-defined trigger expressions, which it can then emit to an external alerting system. We're using Prometheus' own <code>alertmanager</code>; it supports email, PagerDuty, Slack and other mechanisms. The Github repo will warn you that the alert manager is not production-ready, but we've been using it for a year or so with no hiccups whatsoever.</p>
<p>The binary also contains a (very!) rudimentary web UI that can be used to inspect the state of the system and perform queries. Although it supports adding custom templates, it's not very good, and it's better to hook it up to something like Grafana. There's also PromDash, which I haven't tried out.</p></pre>gbrayut: <pre><p>Might want to check out <a href="http://Bosun.org" rel="nofollow">http://Bosun.org</a> which is written in go and backed by Opentsdb, graphite, or influxdb. It is not quite as mature as Prometheus but has a very powerful "alert IDE" experience.</p>
<p>Check out my boss's presentation at Monitorama or his fundamentals video playlist at <a href="http://bosun.org/resources" rel="nofollow">http://bosun.org/resources</a> for more details.</p></pre>frankwiles: <pre><p>Consul.io has some simple, but neat monitoring abilities. </p></pre>lobster_johnson: <pre><p>Consul is a service discovery system, not a monitoring system.</p></pre>frankwiles: <pre><p>It's both <a href="https://www.consul.io/intro/getting-started/checks.html" rel="nofollow">https://www.consul.io/intro/getting-started/checks.html</a></p></pre>lobster_johnson: <pre><p>It's not. Consul's health checks exist to route requests to backends that are healthy (and, conversely, not route anything to backends that are down). It's not a general-purpose monitoring system.</p></pre>bbrazil: <pre><p>The problem with "monitoring" is that is has very different meanings depending on who you're talking to.</p>
<p>One meaning is "supervisor", that it when such a check fails it'll restart the process. Consul does not provide this.</p>
<p>Another meaning is "metrics". It is possible to pull the health data out and track it over time, but that's not part of Consul itself.</p>
<p>What consul does have is an on-machine healthcheck for use in loadbalancing - in this case via service discovery. This is a handy way to avoid talking to servers that you can be pretty sure won't work, but you <a href="http://www.robustperception.io/healthchecking-is-not-transitive/" rel="nofollow">still need to send healthchecks from your clients to catch all the potential failure modes</a>.</p></pre>dacort: <pre><p>Take a look at Inspeqtor: <a href="http://contribsys.com/inspeqtor/" rel="nofollow">http://contribsys.com/inspeqtor/</a></p></pre>dAnjou: <pre><p>Why does it need to be written in Go? How is the programming language a tool is written in relevant for the job it's doing?</p></pre>TheMerovius: <pre><p>"Written in go" ⇒ "single static binary with reasonable performance". "Written in C" ⇒ "Probable security hole if it has network access". "Written in ruby" ⇒ "Probably some dependency problems when updating, better get used to rvm". "Written in Java/Skala/Clojure/…" ⇒ "Make sure you ship a JVM and have enough memory". "Written in perl" ⇒ "Dear god, hopefully it does everything I want it to perfectly because I will never fix that mess".</p>
<p>The language a software is written in is <em>hugely</em> important, especially if it's open source (because that more or less implies that you probably want to be able to change it).</p></pre>dAnjou: <pre><blockquote>
<p>"Written in go" ⇒ "<strong>single static binary</strong> with reasonable performance".</p>
</blockquote>
<p>Which you will have to compile yourself unless you're telling me that you're trusting some random people's builds. But let's assume you're not crazy and you're building it yourself. Well, then suddenly you'll be in the dependency mess that you're taunting Ruby with. Or is Go somehow immune to that?</p>
<blockquote>
<p>"Written in C" ⇒ "Probable security hole if it has network access".</p>
</blockquote>
<p>Of course Go has like 0 flaws! And it has magic built-in that prevents every developer from shooting themselves in the foot.</p>
<blockquote>
<p>"Written in ruby" ⇒ "Probably some dependency problems when updating, better get used to rvm".</p>
</blockquote>
<p>Not sure if you knew that but people in the Go community are desperately trying to come up with a dependency management solution that doesn't suck more those of other languages. Don't know if they got there yet or if they just went back to vendoring it all.</p>
<blockquote>
<p>"Written in Java/Skala/Clojure/…" ⇒ "Make sure you ship a JVM and have enough memory".</p>
</blockquote>
<p>You're kidding right? The JVM is one <code>apt-get install</code> away and hardware is usually the least of your problems.</p>
<blockquote>
<p>"Written in perl" ⇒ "Dear god, hopefully it does everything I want it to perfectly because I will never fix that mess".</p>
</blockquote>
<p>I guess I can agree with that one at least ... no, seriously, do you really think people will dive into the code of even only a moderately sized project just to debug a misbehaviour that they're observing? They either live with it and maybe wait for it to be fixed upstream or they switch products.</p></pre>TheMerovius: <pre><p>You grossly misunderstood my comment. It's purpose wasn't primarily to bash on other languages, but to illustrate how hugely important the language choice can be.</p>
<p>But if you rather want to discuss the particular points I made:</p>
<blockquote>
<p>Which you will have to compile yourself unless you're telling me that you're trusting some random people's builds. </p>
</blockquote>
<p>I do indeed trust the developers builds (which I install from signed binary packages of my distribution). I don't use Gentoo and I don't live in the 90s. If I trust their code I can trust their binary just as well. No one audits all code they are installing beforehand. That's crazy talk.</p>
<blockquote>
<p>Of course Go has like 0 flaws!</p>
</blockquote>
<p>Never claimed that. You are putting words in my mouth.</p>
<blockquote>
<p>And it has magic built-in that prevents every developer from shooting themselves in the foot.</p>
</blockquote>
<p>It is mostly memory safe. Which C clearly isn't. If you think, that software written in C isn't a <em>huge</em> security risk, you have been living under a rock for at least 30 years. You <em>can</em> write secure C. It's just that nobody does (which, again, should be completely obvious by watching the security space).</p>
<blockquote>
<p>Not sure if you knew that but people in the Go community are desperately trying to come up with a dependency management solution that doesn't suck more those of other languages.</p>
</blockquote>
<p>You worry about build-time. I worry about run-time. If I install a go program it will run in 10 years just as well, probably longer. I can put it on network storage and every computer in my fleet can just use it. If I install a ruby program, it breaks. On every effing update.</p>
<blockquote>
<p>You're kidding right? The JVM is one apt-get install away and hardware is usually the least of your problems.</p>
</blockquote>
<p>But for large deployments it makes a serious difference.</p>
<blockquote>
<p>no, seriously, do you really think people will dive into the code of even only a moderately sized project just to debug a misbehaviour that they're observing?</p>
</blockquote>
<p>Yes. That's just common fucking sense. Why else would you run open source anyway? I work at a company where all third-party open source code is part of the repository and if something breaks in it, you fix it and include the fix in your commit. You then try to get your fix upstream. But <em>of course</em> people are fixing bugs and issues in their open source software, that's literally what it's made for.</p></pre>dAnjou: <pre><blockquote>
<p>You grossly misunderstood my comment. <strong>It's purpose wasn't primarily to bash on other languages</strong>, but to illustrate how hugely important the language choice can be.</p>
</blockquote>
<p>But it certainly sounded like that.</p>
<blockquote>
<p>I do indeed trust the developers builds (which I install from signed binary packages of my distribution).</p>
</blockquote>
<p>Usually a package maintainer is building it then. And depending on your distribution that's not necessarily a developer of this project. But do you only use Go projects that made it into your preferred distro?</p>
<blockquote>
<blockquote>
<p>Of course Go has like 0 flaws!</p>
</blockquote>
<p>Never claimed that. You are putting words in my mouth.</p>
</blockquote>
<p>I was being sarcastic. As for your other point, Go is very very young, that alone makes it immature. And with its growing popularity it's attracting a lot of people including those who don't really know what they're doing but still release software that is then used by other software and so on. Go is <strong>not</strong> more or less of a security risk than any other language.</p>
<blockquote>
<p>If I install a go program it will run in 10 years just as well, probably longer. [...] If I install a ruby program, it breaks. On every effing update.</p>
</blockquote>
<p>I admit the deployment of a Go program is almost a no-brainer (btw. I like Go very much myself for that reason). But lumping every Ruby program together like it's inherently the most shittiest thing in the world is just not fair to say (btw. I really really dislike Ruby for various reasons).</p>
<blockquote>
<p>Yes. That's just common fucking sense. Why else would you run open source anyway? [...]</p>
</blockquote>
<p>Using open source software and working on it (aka contributing) are two very different things. And I doubt that the majority of situations is like in your company. It's really cool that you're doing it like that, especially that you're given or taking time to do that! I appreciate it.</p></pre>TheMerovius: <pre><blockquote>
<p>Go is not more or less of a security risk than any other language.</p>
</blockquote>
<p>It is <em>much</em> less of a security risk than C/C++ (so is <em>any</em> other memory safe language of course). Claiming otherwise is ignoring reality. There are classes of security bugs that are language independent. C/C++ have their own class and it's probably the majority of the exploits out there <em>by far</em> (I don't want to claim numbers, but the margin should be enormous).</p>
<p>Again, to reiterate: If you think, that software written in C isn't a <em>huge</em> security risk, you have been living under a rock for at least 30 years.</p></pre>TheMerovius: <pre><p>Btw:</p>
<blockquote>
<p>But let's assume you're not crazy and you're building it yourself.</p>
<p>The JVM is one <code>apt-get install</code> away</p>
</blockquote>
<p>Seriously?</p></pre>dAnjou: <pre><p>Trusting a random person's build is different from trusting a package that's gone through an established process of reviewing it by people that are actually known by the community surrounding it (i.e. not everyone can become a package maintainer and put their stuff in Debian).</p></pre>
