使用Zabbix和Prometheus监控基础设施即服务（IaaS）中的虚拟机和平台即服务（PaaS）中的服务

2 年 ago
韵, 科
5 minutes

这篇帖子是NTT通信Advent Calendar 2017的第22天。

我是NTT Resonant的@ktooriyama，负责撰写。

NTTレゾナント是NTT通信集团的子公司。我们为个人客户提供门户网站goo、NTT-X商店和gooSimseller等服务，并向企业客户推荐与网络相关的ICT解决方案。此外，我们还为开发人员提供远程测试套件（Remote TestKit）。

這篇文章是針對誰寫的？

    • クラウド環境の監視に興味がある方

 

    • ZabbixやPrometheusに興味がある方

 

    • ZabbixやNagiosを使っていてPrometheusがどう違うのか（何となく）知りたい方

 

    ZabbixのGUIがアレすぎてアレな感じになっている方

太长没时间读。

我很少有机会解释监视，所以我随心所欲地写了一篇长文。我懒得重新写，所以就直接发表了。

    • NTTレゾナントではOpenStackとCloud Foundryを使ったプライベートクラウドを運用しているよ

 

    • プライベートクラウド上で稼働するVMとサービスの監視に、ZabbixとPrometheusを利用しているよ

 

    • Zabbixをうまく使うと出たり消えたりするOpenStack上のVMを自動監視できるよ

 

    • Prometheus＋Grafanaを使うともっと変動しまくりなPaaS環境でも監視しやすいよ（けど課題もあるよ）

 

    （おまけ）ZabbixとGrafanaを組み合わせると既存環境をステキに見える化できるよ

首先

在NTT Resonant，我们利用OpenStack和Cloud Foundry来构建和运营私有的IaaS＆PaaS。目前，我们的OpenStack规模大约为400个计算节点，总共有3,300台虚拟机。Cloud Foundry从2017年7月开始提供服务，目前被用作goo服务等基础设施的基础。

我所属的团队负责开发和运营私有云，同时也提供基于IaaS的虚拟机和基于PaaS的服务的监控给内部使用。可以将其理解为内部版的监控即服务。

在本文中，我們將簡單解釋我們如何為內部提供監控，同時提出Zabbix和Prometheus的特點以及優缺點。

※这篇稿件是以NTT Tech Conference＃2的演讲内容为基础，重点关注监控的方面，但内容是独立的。

使用Zabbix自动监视Openstack上的虚拟机

我们在OpenStack上使用Zabbix进行虚拟机监控，并利用Zabbix的监控自动化机制。

在OpenStack平台上有3,300台虚拟机，这些是由各种团队负责构建的，用于提供goo服务等。而不是由我们云端团队直接构建的。由于无法自行更改虚拟机的配置，我们要求各服务负责人根据预设配置安装zabbix-agent。

在OpenStack上，虚拟机（VM）的数量会根据服务需求而增减。根据不同的VM角色，监控所需的中间件种类也会有所不同。还可能出现希望能够根据开发机和商用机不同，来修改警报通知严重程度的要求。

如果需要手动进行监控设置的话，针对多样且变动的超过3,000台虚拟机，不仅人工成本会大幅增加导致巨大亏损，工作人员的眼睛也会像死鱼一样无神。自动化是必要条件。

在实际中使用Zabbix进行自动监控

以下是Zabbix所需的功能。

    1. OpenStack虚拟机的自动发现和自动注册

 

    对每个虚拟机自动配置服务端要求的监控

每个都是通过以下方法来实施的。

    1. Zabbix的网络发现功能可以定期扫描OpenStack的全部租户IP地址范围，以探索虚拟机。

 

    1. 当服务开发人员将监视设置内容写入每个虚拟机的默认目录中的文件中时，Zabbix会读取该文件并应用所需的监视模板。

 

    例如，如果需要商业级别的Apache httpd监视设置，则在文件中写入apache_production，Zabbix会将相应的监视模板应用于该虚拟机。
zabbix_nwdiscovery1.PNG

除了其他办法，我们还通过这种方法自动控制着3,300台虚拟机的监控。

Zabbix好用吗？

我认为这很酷。

    • とにかく手堅く監視でき、安定稼働している

 

    • 自動化をサポートするしくみが整っている

 

    • 特定のホストだけアラート閾値を上書き変更する、といった柔軟な対応もできる

 

    自身が実行した処理のログを残しているので、何があったのか追いかけやすい

当然的，使用时也有一些困难的地方。

    • Web GUIのデザインが独特すぎて、必ず文句を言われる（俺が見たいグラフはどこにあるんだよぉぉぉ！）3

利用者に現在の監視設定をGUIで見せようとすると、監視設定を変更できる権限を渡さなければならない（手動で誤った設定変更をされると全体が破綻しかねないのでリスク有り）
複数セットを運用すると、それらの情報をまとめて監視・設定するための簡便な方法がない4

Zabbix自体が高負荷に陥るほど使い込んでいくと、安定させるための工夫が数多く必要になる5

尽管使用Zabbix会有一些小问题，但如果要可靠地监控服务器主机，我仍然认为Zabbix是一个强大的选择。

使用Prometheus自动监控在Cloud Foundry上的Web服务。

Cloud Foundry是一种PaaS服务。与传统的虚拟机监控完全不同，它需要对部署在其上的服务进行监视。Zabbix是一种出色的开源软件，具备可靠性和灵活性，但是否适用于Cloud Foundry呢？

根据结论，我们判断在Zabbix上监控Cloud Foundry上的服务并不现实，因此选择了采用Prometheus。

PaaS平台上服务的监控信息来源包括API和日志数据。

在Cloud Foundry中部署的服务实际上是作为包含应用程序代码的容器运行的。Cloud Foundry本身扮演容器编排器的角色，它会根据用户定义的容器数量进行保障。用户也可以轻松地设置将哪个URL映射到哪个容器的配置。

图示化了Cloud Foundry的运行概述如下。

cloudfoundry1.PNG

作为监视对象的指标，我们需要关注这些容器的CPU和内存状态。CPU和内存指标可以从Cloud Foundry API和Cloud Foundry所配备的日志输出模块Firehose6中获取。

需要通过某种手段了解服务的运行状态和健康状况，可以通过向服务URL发送HTTP请求/响应来监测。来自外部的流量到达每个服务的URL将由Cloud Foundry内置的软件负载均衡器”Gorouter”进行基于URL的L7路由处理。这些HTTP请求/响应的历史记录也可以通过Firehose获取大量的日志。

大致上的图解就是这样的形象。

cloudfoundry2.PNG

例如，您可以从API或firehose获取如下信息。

使用Cloud Foundry API可以方便地获取服务的定义和状态。（来自官方文档）

{
  "total_results": 3,
  "total_pages": 1,
  "prev_url": null,
  "next_url": null,
  "resources": [
    {
      "metadata": {
        "guid": "6064d98a-95e6-400b-bc03-be65e6d59622",
        "url": "/v2/apps/6064d98a-95e6-400b-bc03-be65e6d59622",
        "created_at": "2016-06-08T16:41:45Z",
        "updated_at": "2016-06-08T16:41:45Z"
      },
      "entity": {
        "name": "name-2443",
        "production": false,
        "space_guid": "9c5c8a91-a728-4608-9f5e-6c8026c3a2ac",
        "stack_guid": "f6c960cc-98ba-4fd1-b197-ecbf39108aa2",
        "buildpack": null,
        "detected_buildpack": null,
        "detected_buildpack_guid": null,
        "environment_json": null,
        "memory": 1024,
        "instances": 1,
        "disk_quota": 1024,
        "state": "STOPPED",
        "version": "f5696e0f-087d-49b0-9ad7-4756c49a6ba6",
        "command": null,
        "console": false,
        "debug": null,
        "staging_task_id": null,
        "package_state": "PENDING",
        "health_check_http_endpoint": "",
        "health_check_type": "port",
        "health_check_timeout": null,
        "staging_failed_reason": null,
        "staging_failed_description": null,
        "diego": false,
        "docker_image": null,
        "docker_credentials": {
          "username": null,
          "password": null
        },
        "package_updated_at": "2016-06-08T16:41:45Z",
        "detected_start_command": "",
        "enable_ssh": true,
        "ports": null,
        "space_url": "/v2/spaces/9c5c8a91-a728-4608-9f5e-6c8026c3a2ac",
        "stack_url": "/v2/stacks/f6c960cc-98ba-4fd1-b197-ecbf39108aa2",
        "routes_url": "/v2/apps/6064d98a-95e6-400b-bc03-be65e6d59622/routes",
        "events_url": "/v2/apps/6064d98a-95e6-400b-bc03-be65e6d59622/events",
        "service_bindings_url": "/v2/apps/6064d98a-95e6-400b-bc03-be65e6d59622/service_bindings",
        "route_mappings_url": "/v2/apps/6064d98a-95e6-400b-bc03-be65e6d59622/route_mappings"
      }
    },

    ...(snip)...

  ]
}

你可以使用Cloud Foundry Firehose Gorouter日志（HttpStartStop）来获取HTTP响应代码和响应时间。

origin:"gorouter" eventType:HttpStartStop timestamp:1490342338243712080 deployment:"cf" job:"router" index:"da47a061-5a18-4903-8478-38127fdec412" ip:"172.x.z.32" httpStartStop:<startTimestamp:1490342338182399930 stopTimestamp:1490342338243675973 requestId:<low:14213839074033669409 high:10169310528741837688 > peerType:Server method:GET uri:"http://www.example.com/" remoteAddress:"172.x.y.107:53698" userAgent:"curl/7.35.0" statusCode:200 contentLength:13941 applicationId:<low:13783871512652741491 high:10240381973283636141 > instanceId:"b9a20c63-b5f8-427b-7440-fcc71febabfd" forwarded:"172.x.y.107" >

在Zabbix上监控PaaS服务…无法实现。

使用API和日志获取的监控数据，我们能够通过Zabbix监控Cloud Foundry上的服务吗？

Zabbix的理念是以“监控主机”为单位设置监控目标。被监控的主机应该具有一个或多个IP地址，并且假设Zabbix代理正在运行。指标和警报将记录和判断针对“监控主机”。换句话说，为了在Zabbix中进行监控，需要将API和日志数据转换为Zabbix可处理的“监控主机”和“监控主机的指标”格式。

此外，服务和URL的映射以及容器数量等都在不断变化。这种变化比在OpenStack上的虚拟机更为剧烈。必须利用API和日志来跟踪这种变化。

这些功能理论上可以通过使用Zabbix的低级别发现（LLD）功能来实现。LLD功能可以从以JSON表示的信息中自动注册监视项和监视主机。这篇文章等可作为可理解的解释参考。

通过应用LLD，可以根据API或日志的解析结果自动添加监控主机，设置监控项和警报。例如，对于容器指标，可以考虑以下流程。

    1. 准备一个脚本，用于适当解析API和日志，并将Cloud Foundry上的1个容器解释为Zabbix可以接受的JSON格式，作为”监控主机”输出。

 

    1. 使用Zabbix的LLD定期运行该脚本。

 

    1. 当脚本运行时，每个容器都被添加为（虚拟的）”监控主机”。（这些是虚拟的监控主机，因为容器上没有运行zabbix-agent，且不直接从容器中抽取指标）

 

    1. 将解析API和日志以获取自身容器的CPU和内存值的脚本设置为”监控主机”的监控项。

 

    1. 通过在”监控主机”的”应用程序”字段中写入容器所属的Cloud Foundry上的服务名称，可以了解哪个服务包含哪个”监控主机（即容器）”。

 

    等等？？

这个人在说什么呢。

暂且用图解来说明吧。

zabbix_lld1.PNG

这家伙到底在说什么呢。

如果我们有足够的动力和决心，也许可以实现，但这会很辛苦。
例如，考虑到Cloud Foundry的负载，直接访问大量正在运行的容器来收集指标是不明智的，因此需要一些策略，如尽量批量获取API响应并缓存，然后从缓存中读取。
还有其他的……

    • Cloud Foundryにおけるそれぞれの要素（Org, Spaceなど）を、Zabbix上の何の要素に対応するように監視を設定すれば良いでしょうか。

 

    • Firehoseのログを適切にパースする…って簡単に書いていますが、そもそもどうするのがよいでしょうか。FirehoseからのログをfluentdでカウントしてZabbixに送信する、ELKで溜め込んでから検索してメトリクス化する……方法はいくつかありそうです。

 

    URLとコンテナのマッピング情報は、どうやってZabbixの画面上に反映させればわかりやすいでしょうか。

思考无极限。看起来是LLD的要求很严格呢。嗯，这是个完美的计划呢～ 只要忽略了不可能的一面呦～

要追加或删除监视主机等所有操作，为什么不使用Zabbix API呢？通过API，您可以完全控制各种操作，随心所欲。然而，实现这个目标所需的开发成本可能不低。运行后的维护也可能会很麻烦。我不认为这也是一个好方法。

由于Zabbix遵循“监视对象应稳定存在于一个主机上”的理念，当监视对象不符合该条件时，会引发不便。

被选择的是Prometheus。

我们知道 Zabbix 无法胜任。那么，作为备受关注的云原生环境监控开源软件，Prometheus 如何呢？

阿波罗与Zabbix有很大的不同。例如，在其官方网站的解释中提到了Instant vector和Range vector等词汇。等等，别离开。“向量”之类的词突然出现让人感到不太妙，但是如果理解了就不会那么可怕……也许。

被巨怪控制的监视

Prometheus服务器从名为Exporter的监视代理程序中获取值并存储。这与zabbix-agent类似，但与Zabbix不同的是，Exporter的实现因监视对象而异。您也可以自己编写Exporter。

在Cloud Foundry的情况下，您可以使用Cloud Foundry Prometheus Exporter（cf_exporter）将API的执行结果转换为适用于Prometheus的形式并返回，还可以使用Cloud Foundry Firehose Exporter（firehose_exporter）将来自Firehose的日志同样转换并返回，还可以使用Firehose-to-syslog（firehose-to-syslog）+ grok_exporter等。

每个出口商的指标以类似多维向量的形式传递给 Prometheus。例如，从 Cloud Foundry Firehose Exporter 获取每个容器的 CPU 使用率，返回的指标将如下所示，每个容器占一行。

ElementValuefirehose_container_metric_cpu_percentage{
application_id=”92bbd8f8-35ad-4228-8478-561ce123459a”,
bosh_job_ip=”172.x.y.128″,
bosh_job_name=”cell”,
instance=”firehose_exporter:9186″,
instance_index=”5″,
job=”firehose”}0.6165940472169581firehose_container_metric_cpu_percentage{
application_id=”92bbd8f8-35ad-4228-8478-561ce123459a”,
bosh_job_ip=”172.x.y.129″,
bosh_job_name=”cell”,
instance=”firehose_exporter:9186″,
instance_index=”6″,
job=”firehose”}20.408200363712947firehose_container_metric_cpu_percentage{
application_id=”92bbd8f8-35ad-4228-8478-561ce123459a”,
bosh_job_ip=”172.x.y.130″,
bosh_job_name=”cell”,
instance=”firehose_exporter:9186″,
instance_index=”7″,
job=”firehose”}0.4638560322248198

在这里，application_id表示所属服务的容器，instance_index表示扩展的第几个容器，bosh_job_ip表示容器运行的虚拟机的IP地址。它们被称为标签和标签值。右侧的值是指标的实际值。

阅读后，我们可以得知这3个容器都是同一个服务容器，标识为92bbd8f8-35ad-4228-8478-561ce123459a。每个容器的CPU利用率大约为0.6％，20.4％和0.5％。如果容器数量增加，那么instance_index为”8″的指标行也会增加一行，并自动获取。当服务增多时会出现不同的application_id指标。

换句话说，通过使用标签和标签值以多维向量的方式表示度量指标，明确地表达了“该度量指标代表什么”的含义，易于理解。由于所有的度量指标都是以不同的标签和标签值保存的，因此它们是扁平且无模式的，无需担心“监控主机”的问题。相比于Zabbix的LLD，这种方式可以更清晰地跟踪环境的变化。

在Prometheus的图形界面上，您可以查看积累的度量数据。例如，您可以检索出instance_index=”5″的容器的CPU利用率如下：

Prometheus_metrics1.PNG

这些对于度量的查询被称为 PromQL。您可以使用正则表达式对 labelvalue 和度量名称进行搜索，正如最初所述的“类似多维向量”的表达方式，您可以像向量一样将度量相加或相乘，以创建新的度量。这个功能是 Prometheus 的关键。

例如，如果要表达“在3分钟内，400系列HTML响应代码的访问比例已超过10%”，可以使用以下PromQL表示。

(sum(rate(cf_application_response_time_sec_bucket{host_domain=“hoge.goo.ne.jp",http_status=~"^4..$",le="+Inf"}[3m])) by (organization_name, space_name, host_domain) / sum(rate(cf_application_response_time_sec_bucket{host_domain=“hoge.goo.ne.jp",le="+Inf"}[3m])) by (organization_name, space_name, host_domain) ) * 100 > 10

等一下，不要走。

只能避免不去记住PromQL这一点，所以请在这方面努力。总的来说，这只是一个熟悉的过程。如果在图形界面上尝试不断实验查询，你就会掌握窍门。

如果要将Prometheus的度量指标作为图形化展示，使用Grafana已经成为事实上的标准。只要将Prometheus指定为数据源，就可以绘制出漂亮的图形。当然，需要正确理解PromQL查询语言，并掌握Grafana的工作原理。

在Prometheus中，需要根据监测目标使用相应的Exporter。通过Exporter的输出指标，即使环境发生变化，也可以简单地收集指标。

在实际中使用Prometheus进行自动监控

因此，我们决定在Cloud Foundry上使用Prometheus进行服务监控。我们使用Grafana进行图形绘制。

我想要实现的目标如下所示。

    以图表形式展示HTTP响应情况和与URL映射的容器状态。自动更新URL与容器的映射关系，以及容器的扩展、服务的添加和删除。

实现方法如下所示。

    1. 使用Prometheus从cf_exporter、firehose_exporter、firehose-to-syslog+grok_exporter收集指标（假设每个Exporter都与Cloud Foundry正确连接）。

 

    1. 在Grafana上对收集的值进行处理和绘制。

 

    如果Cloud Foundry端进行了设置更改，相应指标的标签值将变化，因此需要快速将其反映在屏幕上。

你有没有解释的打算啊，你这家伙。

……为了避免这篇文章变得更长，我忽略了详细说明实现方法，但具体来说，我们将利用PromQL和Grafana的模板功能。总之，希望您能大致理解这比使用Zabbix更简单地解决问题。是可行的。明白了吗？

结果变成这样。上半部分是针对服务URL的HTTP响应统计，下半部分是映射到URL的容器的CPU/内存/磁盘统计信息。由于可以在一个屏幕上查看服务和资源的运行情况，所以情况更容易一目了然。如果要在Zabbix中创建这样的界面，就需要使用屏幕功能，但并不像Grafana那样简单。

Grafana1.png

如果要使用Prometheus监控VM会怎么样？

“虽然从Zabbix的角度来看，Prometheus似乎更加灵活，但那只是在监控API和日志的情况下。假设我们在同一个平台上，比如OpenStack上监控虚拟机，Prometheus和Zabbix会有什么样的结果呢？”

因为可能会有人产生这样的疑问，所以我会写下在Prometheus中监视大量虚拟机会发生什么。虽然我从未尝试过。

如果监视VM或物理服务器，通常会使用Node exporter。Node exporter需要在要监视的服务器上运行，而Prometheus需要从每个Node exporter获取值。在这方面，它与Zabbix代理完全相同。

在Zabbix中，我们使用网络发现工具来探索虚拟机（VM）。而在Prometheus中，可以利用Service Discovery功能。

服务发现是指Prometheus可以通过IP地址和端口号来检测到某个Exporter（Target）正在运行的信息。它正式支持Kubernetes、Consul、DNS和AWS EC2，并且只需要编写配置文件，Prometheus就能够了解目标的位置。对于OpenStack Nova API等，它目前还处于测试阶段的支持。有关具体示例，请参考官方网站。

即使未被支持，您仍然可以编写YAML或JSON文件并将其读入Prometheus，以便使用服务发现功能。因为在文件更新的瞬间，目标会被添加或删除，所以它能够迅速适应环境变动。如果您自己编写一个不断生成YAML或JSON文件的脚本，就可以轻松实现目标的自动更新。

因此，即使在监控大量虚拟机的情况下，使用Prometheus进行设置也不会耗费巨大的工作量。如果是在支持Kubernetes等环境下，相比Zabbix来说会更容易。

在Zabbix中，根据方法的使用，似乎能够以同样的速度跟进虚拟机的添加和删除，但可能会带来一些麻烦或者导致视野变得模糊。11

Prometheus很酷吗？

我觉得很酷。

正确来说，只有与Grafana结合使用，才能实现图形化的“可视化”。仅使用Prometheus无法正常绘制图形，因此毫无用处。

如果没有合适的现有出口商，就需要自己制作，但原理并不太复杂，所以只需在监视脚本的基础上稍加努力就可以解决。

整体来看，这是一个非常出色的开源软件项目。然而，如果有人问我是否想要完全将OpenStack虚拟机监控替换为Prometheus，我并不急于立即进行替换。我将在下一节中给出理由。

尝试在商业环境中使用Zabbix和Prometheus。

我将总结一下在使用Zabbix数年和Prometheus半年左右后的感受。

手的稳固性和安心感

我觉得总体来说，Zabbix更可靠和放心。毕竟，它是被企业领域所广泛使用的开源软件。然而，如果只是监控我们团队的工作范围，那么Prometheus+Grafana似乎更能灵活适应，所以如果是我现在，我会选择在小规模监控中使用Prometheus。

由于Zabbix仅有一种zabbix-agent，因此很少会因为agent的问题而影响使用。而Prometheus则通过适应每个监控对象的Exporter来简化了我们的工作，但这也意味着Exporter的实现方法千差万别。因此，在大规模环境中使用时可能需要进行自己的验证工作。

当Exporter出现异常行为时，调试变得麻烦。当Exporter或其周围出现异常时，如果Exporter能够自动退出或输出错误信息，我们可以进行相应的处理，但这并非总是如此。在构建Cloud Foundry监控系统时，我遇到了Exporter仍然存活但度量值不再更新的情况。此外，也有一些Exporter需要定期重新启动，以防止保留不必要的度量指标。我们应该意识到每个Exporter都有其特殊之处。

此外，Prometheus的通知机制AlertManager的运作方式有些复杂。Zabbix能够记录自身执行的操作，但AlertManager却无法提供详细信息。很难确定故障是否被检测到并发送了警报通知。而且在12个监控实例时，其行为有时也有些可疑。使用上仍有些让人感到不安的地方。

如果在Prometheus提供第三方监控时考虑到这些因素，当被问到“安全可靠吗？”我很难点头。我没有考虑立即将OpenStack VM的监控从Zabbix迁移到Prometheus。

数据库的冗长化和数据备份容易性

由于Zabbix的数据存储在MySQL中，如果了解如何使用MySQL的人，就不会为备份方法感到困惑。如果不需要保存监控日志数据，则只需备份监控配置表即可减少所需时间和数据量。在构建数据库冗余时，也不会有困扰。

对于 Prometheus 来说，所有的配置都存储在文本文件中，只需要进行版本库管理即可。然而，备份时间序列数据并不容易，至少在1.x版本中如此。为了实现监控冗余，我们需要考虑不同的备份方法。

从2.x版本开始，时间序列数据的存储方式得到了改进，实现了超快速备份的功能。虽然我还没有试过，但如果现在开始使用的话，毫无疑问应该选择2.x系列。

由于Prometheus本身没有数据库冗余的概念，所以需要采取一些措施来保证其能够抵御单点故障，比如使用Act/Act模式在多台服务器上运行，或者将其部署在类似于Kubernetes的编排器上，实现自动恢复。不过，令人困扰的是，负责通知的AlertManager的高可用性目前仍处于开发阶段。

对环境变化的适应性

Zabbix虽然非常努力，但与Prometheus的追踪性相比，显然不占优势。

Prometheus能够即时添加或删除目标非常出色。即使目标数量有所增减，度量指标的变化也只是随之增加或减少，无需考虑复杂的事情，这一点也值得赞赏。

然而，Prometheus基本上不能做到没有Exporter。这取决于每个Exporter输出什么样的指标。理解每个Exporter的指标非常重要。相反，可以说”如果自己制作Exporter，基本上可以做任何事情”。另外，虽然我没有使用过类似于script-exporter的工具，但我非常开放。

建立多个配置集时的操作

当您建立多个Zabbix实例时，您将需要查看和操作每个仪表板。虽然也有像Hatohol这样的解决方案可以汇总显示多个实例的信息，但您仍需要支付学习和运维成本。这取决于您是否愿意付出这些成本来实现我们是否真正需要这么做的讨论。

尽管我还没有尝试过，但是Prometheus通过使用联邦技术可以将多个集合的信息整合到一个集合中。例如，为每个OpenStack租户提供一个Prometheus集合，将所有租户的信息汇集到一个Prometheus中，从而全面监控整个环境的情况。尽管配置会相对复杂一些，但是由于原生支持联邦功能，这样做是可行的。

如果能够简单地构建一个可以全面确认的监控系统，那将是很棒的。

GUI的易理解性和易用性

请理解。

（赠品）用于Grafana的Zabbix插件

我想要把Zabbix现有的数据以易于理解的形式绘制成图表，但是目前没有找到合适的方法，感到困扰。

如果您正在使用Zabbix和Grafana，我有一个好消息要告诉您。通过使用Grafana的Zabbix插件（grafana-zabbix），您可以将Zabbix数据库中的指标值呈现为非常美观的图形。

特别值得注意的是，使用直接的DB连接，可以在Grafana上直接连接到Zabbix DB，并且图表绘制非常流畅。此外，就算是旧版本的Zabbix 2.2也可以进行图表化。13

试一试，从OpenStack上的所有虚拟机中只绘制出磁盘读取速度最高的前10个虚拟机，结果如下。这个图表非常简单易画。

VMDiskReadTop10.png

而且，还可以轻松处理以下这些情况。真是太方便了，简直让人感到兴奋！

    • あるホストグループに所属するホストの特定のグラフだけを重ねて描画したい

 

    ホスト名や監視アイテムを正規表現でマッチさせて描画したい　などなど

然而，在正式环境的Zabbix上无谓地连接grafana-zabbix是不推荐的。与在Zabbix GUI上执行常规操作相比，可能会发送非常重的SQL查询到Zabbix。最好使用备份数据或参考待机的数据库，或者进行一些其他的改进。

最终

普罗米修斯虽然使用的时间还不久，但他的潜力之高令人惊叹。虽然还存在一些不确定因素，但随着发展逐渐稳定，所以在创建下一个OpenStack环境时，我想考虑使用普罗米修斯。

Zabbix是一种可靠的选择，当涉及传统的监控范围时。然而，如果要监控像云原生服务那样变化频繁的目标，就需要考虑它能支持到什么程度。对于无法适用于”监控主机”概念的情况，需要特别注意。

Zabbix和Prometheus都是很出色的监控开源软件。让我们理解它们的优势和局限，好好使用它们吧。

与其在各个服务中分散建立监控系统和业务流程，不如集中建立统一的监控业务流程，这样成本上更具优势，同时也更有利于内部控制。 ↩

但是光是安装zabbix-agent是行不通的，所以通过使用Puppet可以轻松地进行安装。 ↩

熟能生巧。 ↩

可以使用像Hatohol这样的工具。但是，是否值得所有相关人员去学习它呢？ ↩

抗负载的问题确实有很多。我认为任何监控OSS都需要一些改进才能进行大规模使用… ↩

与Twitter的Firehose和Amazon Kinesis Firehose类似，它是由与消防水龙带相关联的概念命名的。 ↩

作为日志记录度量指标有点不太合理，但就是这么回事。 ↩

我认为在Zabbix的自动化机制中，LLD是一个非常强大的功能，差不多可以称之为终极武器，但同时也是一把具有双刃刀特质的魔剑。它的灵活性太高，如果不加思考地激烈使用，接任者就无法进行维护了。在GUI上很容易与网络发现混淆，这也让初学者感到困扰。 ↩

在Grafana中，使用模板化和管理仪表板等方面可能会遇到各种困难。熟能生巧。 ↩

还有一种叫做自动注册的功能。在这种情况下，zabbix-server不是通过探测zabbix-agent来确定其存在，而是zabbix-agent自己通知zabbix-server自己的存在。由于一些行为不符合我们的需求，所以我们没有采用它。 ↩

在Zabbix的自动注册机制中，虽然可以通过zabbix-agent进行快速添加，但是需要在agent端配置告诉它server的位置。还有删除的时机也是令人困扰的。使用Zabbix API通过脚本控制添加和删除似乎更好。如果你想做到那一步的话。 ↩

通过Alertmanager将所有警报通知同时发送到用于记录的系统中，可以积累通知日志，但不支持本地化有点困难。 ↩

Zabbix API中实现了获取趋势（指标的历史数据）的功能是在Zabbix 2.4版本及以后。这个功能在通过API向外部系统提供指标时几乎是必需的。在Zabbix 2.2中，您可以通过应用补丁来使用该功能。但是，在使用Zabbix plugin for Grafana的情况下，由于直接连接到MySQL，实际上不需要从API获取趋势数据。太好了。 ↩

✖
广告
将在 10 秒后关闭
bannerAds