bosun_与Bosun一起监控

羊舌承

2023-12-01

bosun

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

什么是波桑？

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

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

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

除非我们缩小范围，否则这也使本文的范围不受限制。考虑到这一点，在本概述和比较中，我们将专注于即用型功能。

盒子里装了什么？

与收集器紧密相连的是，它能够监视Windows，Mac和Linux上的cpu，磁盘，网络，内存和进程。从那里开始，它添加了更多特定于OS的功能，例如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 > 80
    warn = $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 Admin解决方案，而考虑使用Bosun的DevOps解决方案。

Splunk云

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

服务器密度

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

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

至于定价，它比云计算产品更具可比性，而我提到的其他付费企业却没有。

结论

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

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