Bosun是由Stack Exchange的优秀人员开发的监视和警报系统，然后为我们其他人开源。 它是用Go编写的，这意味着它的监视代理可以在Go可以删除二进制文件的任何地方运行……几乎在任何地方。 那么，它的作用到底是什么？与New Relic ， CloudWatch ， Nagios ， Splunk Cloud ， Server Density以及其他监视工具等相比， 它又如何呢？

什么是波桑？

最简单的说，Bosun是一个用于从许多不同来源接收测量值，对其进行组织，对其进行跟踪并根据随时间的变化允许触发的系统。

系统使用Go 语言编写的称为scollector的代理将这些度量标准发送到接收主机。 度量标准仅受收集器可以发送的内容限制，而不受Bosun本身的任何限制。 这意味着有足够的机会扩展可用数据。 已经有许多外部收集器，通过您自己的shell脚本编写自定义收集器并不是特别复杂。

毫无疑问，这种设置和结构已经非常具有吸引力。 它是免费的，几乎可以在任何地方部署，代理是无需编译的嵌入式二进制文件，并且可以进行高度自定义 。 那是一个可靠的公式。

除非我们缩小范围，否则这也使本文的范围非常开放。 考虑到这一点，在本概述和比较中，我们将重点关注即用型功能。

盒子里装了什么？

可以直接在scollector中监视Windows，Mac和Linux上的CPU，磁盘，网络，内存和进程。 从那里开始，它添加了一些其他特定于操作系统的功能，例如Windows上的.NET进程，AppDomains，Active Directory和SQL Server或Linux上的Yum。 还内置了VMWare，icmp（ping），snmp以及AWS的EC2和ELB监视器。仅举几例，其中包括对Apache，Cassandra，Chef，CloudFlare，Elasticsearch，HAProxy，Puppet和Redis的其他支持。 这些当然可以扩展。

如何使用？

首先，我们将设置一个服务器，以从可能正在使用的各种远程监视器接收信息。 该服务器还将充当我们的虚拟主机，以查看，跟踪和提醒这些值。 接下来，我们将设置一个远程代理，将有关另一台计算机的信息发送回我们的主监视服务器。 最后，我们将研究如何设置警报，可以跟踪的一些高级指标，以及如何收集代理可能不知道的自定义信息。

1.设置服务器以收集信息

首先，您需要设置Bosun Monitor服务器/容器以接收和汇总信息。

你可以用水手长的码头工人建立快速尝试了这一点，尽管堆栈交易所本身说，他们没有在生产中使用此设置。 他们没有说你不应该，只是他们没有。 目前，我倾向于同意这一建议，因为在几天的过程中，我将监视器从Docker容器运行到监视三到四台服务器，并在一段时间后出现了挂起的监视服务器的情况。 不过，Bosun GitHub存储库中确实有代码可以在监控器关闭的情况下中继数据 。 有关详细的生产设置， 请查看此博客文章 。

要运行Docker版本进行尝试，只需启动可公开访问的服务器/ VM，确保已安装Docker ，然后…

docker run -d -p 4242:4242 -p 8070:8070 stackexchange/bosun

这将在8080端口及其所有依赖项（包括OpenTSDB和HBase）上安装监听该端口的监视器。

在这里，您可以获取虚拟机的IP地址，然后打开浏览器到IP：8070，以查看基本的Web界面，包括其从右侧接收信息的主机。 当前，它应该仅从自身收集信息，但是您可以翻阅指标以了解可以从系统获得的粒度级别和详细信息。 您可能需要等待几分钟，以收集足够的信息来显示。

我发现我需要一个1GB的VM才能使Docker映像正常运行，但是要在一台计算机上同时运行监视器，HBase和OpenTSDB。 在生产设置中，您可能只是查看将数据存储在外部OpenTSDB主机中的监视器本身，就像您在其他任何生产数据库设置中所期望的那样。

2.设置客户端以发送信息

现在，您已经设置了监视服务器，请跳至另一台计算机/ VM来设置收集器。 收集器是可移植的Go二进制文件。 为您的机器下载正确的机器，然后调出控制台并运行…

scollector -h <BOSUN MONITOR IP>:8070

就是这样。 代理将立即开始收集并发送该主机可以使用的所有现成信息。

3.创建一个警报

我不会重复Bosun自己的警报创建快速入门 ，它提供了一个很好的示例，说明了如何在不同指标上设置警报。 警报归结为选择度量标准和主机，使用表达式监视度量标准，在该度量标准上创建规则以触发警报，然后发送警报。

在这里，您开始看到Bosun的长处，即表达 。 表达式是一种自己的语言，基本上是映射/减少聚合调用，包括平均值，更改计数，标准差（非常有用），中位数等。快速入门中的一个简单示例显示了可读性……

avg(q("sum:rate{counter,,1}:os.cpu{host=your-system-here}", "1h", ""))

我们可以看到，对于“ your-system-here”的指定主机名“ host”，它正在查询“ os.cpu”指标的过去一小时“ 1h”结果的平均“ avg”。

规则也很清楚……

alert cpu.is.too.high {template = test$metric = q("sum:rate{counter,,1}:os.cpu{host=your-system-here}", "1h", "")$avgcpu = avg($metric)crit = $avgcpu > 80warn = $avgcpu > 60
}

该值超过60％时将触发警告，超过80％时将触发严重状态。 警报将使用模板“ test”，该模板使用Bosun自己的模板语言 ，并可根据您的需要进行自定义。

template test {subject = {{.Last.Status}}: {{.Alert.Name}} on {{.Group.host}}body = `<p>Alert: {{.Alert.Name}} triggered on {{.Group.host}}<hr><p><strong>Computation</strong><table>{{range .Computations}}<tr><td><a href="{{$.Expr .Text}}">{{.Text}}</a></td><td>{{.Value}}</td></tr>{{end}}</table><hr>{{ .Graph .Alert.Vars.metric }}<hr><p><strong>Relevant Tags</strong><table>{{range $k, $v := .Group}}<tr><td>{{$k}}</td><td>{{$v}}</td></tr>{{end}}</table>`
}

为了发送这些警报，Bosun需要SMTP服务器。 当前，这是发送警报的唯一方法，尽管来自提供商（Sendgrid，Mailgun，Cloudmailin等）的许多传入邮件处理系统可以使将这些电子邮件定向到http端点相当容易，以触发其他操作。 在这种情况下，您可以设置模板以发送JSON或XML数据。

4.跟踪高级指标

Bosun提供了许多高级用法示例 ，这些示例涵盖了处理以下内容：

• 每个HAProxy前端上的跟踪会话：

$current_sessions = max(q("sum:haproxy.frontend.scur{host=*,pxname=*,tier=*}", "5m", ""))
$session_limit = max(q("sum:haproxy.frontend.slim{host=*,pxname=*,tier=*}", "5m", ""))
$q = ($current_sessions / $session_limit) * 100

• 关于预测的未来磁盘空间的警报：

$days_to_zero = (forecastlr(q("avg:6h-avg:os.disk.fs.percent_free{$filter}", "7d", ""), 0) / 60 / 60 / 24)

• 使用宏避免重复使用警报定义：

macro host_based {
warnNotification = lookup("host_base_contact", "main_contact")
critNotification = lookup("host_base_contact", "main_contact")
warnNotification = lookup("host_base_contact", "chat_contact")
critNotification = lookup("host_base_contact", "chat_contact")
}

• 设置偏离规范的警报，而不必对警报阈值进行硬编码：

$history = band($metric, $duration, $period, $lookback)
$past_dev = dev($history)
$past_median = percentile($history, .5)
$current_median = percentile(q($metric, $duration, ""), .5)
$diff = $current_median - $past_median
warn = $current_median > ($past_median + $past_dev*2) && abs($diff) > 10 && $hit_percent > 1

• 有条件的警报。 当您在某些情况下希望收到警报时，可以这样做，例如在邮件队列很高时不发送使用Swap的警报。

$mail_q = nv(max(q("sum:exim.mailq_count{host=*}", "2h", "") > 5000), 1)
$metric = "sum:rate{counter,,1}:linux.mem.pswp{host=*,direction=in}"
$q = (median(q($metric, "2h", "")) > 1) && ! $mail_q

5.使用外部收集器跟踪自己的指标

Scollector还可以发送从几乎任何类型的脚本收集的信息，以由Bosun Monitor进行汇总，监视和操作。 这些脚本称为外部收集器 。 可以以两种简单格式之一收集此数据：简单数据输出和JSON数据。

简单的数据输出格式

就像这样使用标准输出流：

// metric timestamp value tag-key=tag-value tag-key=tag-value tag-key=tag-value
twitter.tweet_count 1441406996 0 query=stackoverflow-down
twitter.follower_count 1441406996 1337 account=stackoverflow

您会注意到该指标未指定度量单位； 就Bosun而言，这只是一个数字。 以后可以将它们添加到图形或表达式中。

JSON数据格式

通过这种格式，您可以在指标中包括其他数据，这些数据只是opentsdb.DataPoint或metadata.Metasend结构的序列化实例。

{"metric":"exceptional.exceptions.count","timestamp":1438788720,"value":5,"tags":{"application":"Careers","machine":"ny-web03","source":"NY_Status"}}
{"metric":"exceptional.exceptions.count","timestamp":1438788720,"value":0,"tags":{"application":"AdServer","machine":"ny-web03","source":"NY_Status"}}

它如何比较？

现在，我们有了一个监视服务器，该服务器可以接收所需的任何指标，以简单的格式从我们选择的任何位置收集这些指标，让我们对这些指标中的任何一种使用减少工具，并允许我们从一个自定义模板到我们选择的任何地方。 它是免费的，除了它所在的服务器的价格。 这是一个非常可靠的产品。

以下是与其他产品比较的一般概述。

新遗物

尽管New Relic确实包含一些服务器监视功能，但它仍然依靠应用程序监视功能。

构建了应用程序监视器以将其集成到正在运行的应用程序中，以便它可以收集和报告堆栈级别信息，识别瓶颈并向您发出问题的警报。 这是一个高度复杂的系统，价格从每主机每月免费到149美元不等，甚至更高。 不管您在何处托管应用程序，它都能提供宝贵的信息，因此通常可以赚钱。

博盛当然不会取代它。 但是，如果您想编写应用程序级别收集器以Bosun可以使用它的方式输出数据，那么您仍然不太可能拥有New Relic数据附带的应用程序跟踪级别详细信息。 New Relic是一项出色的服务，难以理解。 它也是可扩展的 。

Bosun在New Relic上的优势在于，您可以使用无限的主机来确定自己的数据保留，其警报系统具有更大的可定制性和灵活性，并且New Relic的兼容性也不会成为监视系统的限制。 我认识的许多人最终都关闭了New Relic的警报，特别是有关寻呼机集成的警报，因为它们往往是虚假警报，自我解决或预期的行为，而没有任何手段告知New Relic。

CloudWatch

CloudWatch根据我们正在谈论的AWS资源类型，对AWS跟踪的现有指标提供监视和警报。

警报系统相当灵活，尽管不如Bosun灵活。 因此，CloudWatch提供了一个很好的系统来监视AWS资源，但除此之外没有其他功能。 如果要跟踪AWS尚未跟踪的内容，则无法使用CloudWatch进行。 如果您使用的是AWS，则CloudWatch是您的监视基础架构的一部分，而不是全部。

纳吉奥斯

Nagios是监视系统的综合祖父。 它监视一切，已经进行了多年，并且围绕它具有相当全面的插件和解决方案网络 。 从UI定制到监视器的所有内容。 它具有几乎所有内容的开源和商业解决方案。

只是看着它就令人生畏，而这正是Bosun与它进行比较的地方。 Bosun比Nagios简单得多。 那是设计的一部分，而缺乏年龄的一部分。 如果要在一个简单的水平上比较这两个工具，我将考虑使用Nagios IT管理员解决方案，而考虑使用Bosun的DevOps解决方案。

Splunk云

有Splunk的人会爱Splunk。 Splunk是一个非常全面的解决方案，价格昂贵。 我知道在IT世界中，很多人都坚信Splunk必须提供作为监视解决方案的所有内容，但是，价格标签使我无法有机会对它进行全面评估。 因此，我无法提供太多的比较。

服务器密度

在“服务即服务”的世界中，服务器密度可能是与Bosun的最佳对比。 作为主机，它将消耗几乎所有东西，包括Nagios数据。

您可以为代理编写自己的插件。 可以从各种不同的云提供商中引入指标，因此没有与之相关的监视锁定。 他们的Web界面带有完整的指标图片，可以随时了解服务器的运行情况。 甚至还有iPhone和Android应用程序。 它还可以基于您可能传入的各种指标提供可自定义的警报 。

至于价格 ，与我提到的其他付费公司相比，它与云产品更具可比性。

结论

Bosun是开源监视空间中的绝佳选择，并且还有很大的增长空间。 随着生态系统的扩展，它必将成为越来越好的选择。 目前，监视器的稳定性似乎是一个已知的问题，但是一旦简化了生产监视器的设置，我希望它会开始引起人们的广泛关注。

翻译自: https://www.javacodegeeks.com/2015/10/monitoring-with-bosun.html