寻找方便的可视化指标工具：Netdata、Prometheus、Telegraf

2 年 ago

清, 宇

3 minutes

制作应用程序和服务原型，并在服务器上进行环境配置和运行之后，有时候会想要全局俯瞰地了解“现在，这个服务器、中间件和应用程序处于什么样的状态”。

当然，可以使用top命令、dstat命令、cat /proc/~命令，或者通过journalctl命令查看日志等方式来查看。

是否有更加便捷地一目了然地查看整个指标的方法呢？

在这种情况下，最先想到的是属于所谓的监视工具的东西。
于是在谷歌上搜索『指标监视』、『服务器监视』等等，出现的都是一些“硬核”的东西。
这些工具在发布后肯定很重要，但在此之前所需的是更简便的多功能工具。

我想做的事情

サーバのリソース情報の可視化
ミドルウェア情報の可視化
作成したアプリケーションの各メトリクス

Apdex, レスポンスタイム、エラー率、GC …

環境構築自体もサクッとしたい

ハードウェアリソースはデフォルトで
ミドルウェアもデフォルト対応 or プラグイン導入で簡単に追加可能
アプリケーションのクライアントが豊富・登録も簡単

できれば、そのまま本番でも利用できればなお良い

通知系は不要

slack 通知くらいはあったらいいな、程度

真正的监控工具

在你开始方便地寻求之前，我简要列出一些所谓的严格监控工具，看看有哪些。

“软件即服务（SaaS）监控工具”

如果考虑监测指标，最近首先要考虑的可能是SaaS系统。

その他にも、CloudWatch, Stackdriver, Azure Monitor など各ベンダのモニタリングツール

总之，管理起来非常容易，一旦添加了代理就基本结束了。
但是，几乎没有可以无限制免费使用的选项，对于游戏级别的服务器来说可能并不适用。

经典监控工具 jù)

我也考虑了一些常见的工具。

Cacti

這些工具的資訊相當豐富，也相對穩定可靠，雖然有點老舊。但就這次的目的而言，

新技術・新ツールに対応していないものもある

也许还有其他什么东西，让我觉得是否还存在着。

最后的候选者

通过使用更广泛的搜索关键词，例如“度量监控”、“性能监控”和“资源监控”，筛选出以下看起来不错的选项。

Telegraf

● 普罗米修斯

一种擅长于收集基于动态服务导向架构的指标的监控工具。

https://prometheus.io/ 请参考此网站。
https://github.com/prometheus/prometheus请访问此github链接。

メトリクス名とそのラベル ( 属性のセット ) で識別されるデータを、時間方向に蓄積
ex. api_http_requests_total{method=”POST”, handler=”/messages”}

メトリクス名 : api_http_requests_total
ラベル : method=”POST”, handler=”/messages”

データタイプは、４種類

counter – インクリメンタルな数値

gauge – 普通の数値

histogram – bucket ( ラベルに対する範囲指定 ) 毎の発生回数 or 合計

summary – クライアントサイドによるストリーミング集計

独自のクエリ言語をもち、そのクエリ結果を視覚化できる

ラベルによるフィルター

sum や avg などの集計
論理演算子と算術演算子

Pull 型の収集 ( 詳細後述 )

静的な収集対象の指定
サービスディスカバリによる動的な収集対象の指定

独自のデータストアを内包し、外部ストレージに依拠しない
組み込みの Web UI で最低限の視覚化が可能

本格的ダッシュボードを求めるなら Grafana との統合も

バイナリでデプロイでき、外部依存がない

最初它的形象是作为容器监控工具而广泛采用，但现在已成为广泛应用于各种监控需求的工具。如果要引入一款专业的监控工具，我将首先考虑它作为第一候选。

构建的简易性

用一个二进制文件进行部署十分重要。

$ wget https://github.com/prometheus/prometheus/releases/download/v2.5.0/prometheus-2.5.0.linux-amd64.tar.gz
$ tar xvfz prometheus-2.5.0.linux-amd64.tar.gz
$ cd prometheus-2.5.0.linux-amd64
$ ./prometheus

收集指标

为了公开这个度量工具，我们称之为Exporter。

1. 服务器（硬件）指标

为了收集服务器资源指标，可以使用官方提供的node-exporter。
github.com/prometheus/node_exporter

以下是一个可能的中文翻译：基本的度量标准就足够了，只需部署二进制代码并将其服务化即可。如果使用 Docker，引入将更加轻松。

$ wget https://github.com/prometheus/node_exporter/releases/download/v0.17.0/node_exporter-0.17.0.linux-amd64.tar.gz
$ tar xvfz node_exporter-0.17.0.linux-amd64.tar.gz
$ cd node_exporter-0.17.0.linux-amd64
$ ./node_exporter

2. 中间件

第三方出口商 – 文档，还具备中间件的完善支持。

$ wget https://github.com/wrouesnel/postgres_exporter/releases/download/v0.4.7/postgres_exporter_v0.4.7_linux-amd64.tar.gz
$ tar xvfz postgres_exporter_v0.4.7_linux-amd64.tar.gz
$ cd postgres_exporter_v0.4.7_linux-amd64
$ export DATA_SOURCE_NAME="postgresql://login:password@hostname:port/dbname"
$ ./postgres_exporter

此外，还存在一些具有针对 Prometheus 的度量指标公开端点的中间件。

果然容器和编排系统，分布式存储等很常见，真切地感受到它们在这些方面的应用。

3. 应用程序 xù)

添加应用程序指标公开的端点，最快的方法是将客户端库集成进去。
客户端库 – 文档

比如说，如果是 Go 语言的话，官方提供了客户端。

import (
    "net/http"
    "github.com/prometheus/client_golang/prometheus/promhttp"
)

func main() {
    http.Handle("/metrics", promhttp.Handler())
    http.ListenAndServe(":8080", nil)
}

此外，在等待 Prometheus 的 Pull 请求时，可以通过使用 PushGateway 来收集那些生命周期短暂的任务，这些任务在启动后就立即结束的情况。

乘机亦设置闹钟

Prometheus本身没有警报功能。
需要引入名为AlertManager的独立服务并进行协调。

● 网络数据

一种高速高效的实时监控工具，可以自动检测目标并自动收集指标数据，无需设置。

https://my-netdata.io/ – 我的Netdata是一个网站（或软件）。

https://github.com/netdata/netdata – Netdata在GitHub上的代码仓库。

デフォルトの保存期間は 1 時間
リアルタイム監視に特化

収集可能なメトリクスは自動で検出して全て収集
高速、高効率

CPU : コア 1 つの 1% まで
Memory : デフォルトで 25MB ( これで約1時間保存可能 )
Disc IO : なし

依存なし

バイナリ一つというわけではない

我一直以为它只是用于监控服务器性能的工具，但实际上它还支持各种应用程序和中间件的指标。每当我搭建服务器，我都会先安装它。

建構的便利性

只需一条指令即可完成安装。

$ bash <(curl -Ss https://my-netdata.io/kickstart.sh)

收集指標

Netdata文档-监控了什么

请注意，所有指标都以每秒的间隔进行收集，并默认存储在内部的循环数据库中，存储时间为1小时（收集周期和存储容量可以进行设置更改）。

这是一个用于查看实时指标的工具。

1. 服务器（硬件）指标

只需安装即可自动收集服务器指标。

大部分都是通过称为内部插件的集成插件来进行收集的。

cgroups.plugin – Netdata Documentation

有些设备和网络相关的指标是由称为外部插件的独立插件提供的。

SNMP Data Collector – Node modules – Netdata Documentation

2. 中间件

令人惊讶的是，中间件的度量标准即使没有设置，也能自动判断收集对象。
如果只监视已支持的中间件，使用现有插件，那么确实可以无需设置即可使用。

如果要监控PostgreSQL，它会自动处理，不需要你做任何操作。

添加新的中间件

如果没有相应的插件，该怎么办？

中间件收集主要是由称为外部插件的独立插件提供的。其中，python.d.plugin、node.d.plugin和charts.d.plugin有些特殊。它们本身是Netdata的插件，但也具有自身的插件机制。这降低了插件引入的门槛，因为可以使用熟悉的语言编写扩展。

要增加目标中间件，最快的方法似乎是创建 python.d.plugin 或 node.d.plugin 的子插件。
如果模仿实际插件的话，可能会意外地很容易实现。

中间件在讨论中。

此外，与其他指标收集工具相比，以下列出了一些缺失模块，其中大部分已经通过提出问题和讨论进行了解决，并且似乎还有积极意愿进一步添加应用程序和中间件的支持。
https://github.com/netdata/netdata/issues/4574

举例来说，JMX兼容性在过去的一年中一直是一个热议的话题。

3. 应用程序

1, 在 1, 2 之前，零配置确实能够很好地应对，但是当要将其集成到自己的应用程序中时，需要花费一些工夫。
Netdata 具有与 StatsD 和 API 兼容的服务器功能，作为内部插件存在，因此通常会使用它。

“统计数据守护进程”

StatsD是一个中继服务器，它负责汇总和收集来自应用程序的指标，并将其发送至Graphite（等时序数据库）。

接続不可時でもクライアント側にエラー対策が不要

データタイプは、4 種類

counting – 回数 ( StatsD 上で rate 計算 )

timing – 経過時間 ( StatsD 上で Uppser/lower bound, mean, percentile, count を計算 )

gauge – 統計処理されない数値

set – キーに渡されたユニークな値の発生頻度

クライアントライブラリが豊富

様々な言語に対応

アプリケーションメトリクス収集のプラットフォームとしては非常にポピュラー

Datadog では StatsD 互換の agent を提供
NewRelic では NerRelic agent をバックエンド化する npm パッケージを提供
実際にポピュラーなのは、実装ではなくプロトコル？
その割に日本語のまとまった情報がとても少ない

比如说，在使用Go语言时，有几个客户端库可以选择，但是这次我们将使用这个。

import (
    "net/http"
    "time"
    "fmt"
    "runtime"

    statsd "github.com/smira/go-statsd"
)

func main() {
    client := statsd.NewClient("localhost:8125",
      statsd.MaxPacketSize(1400),
      statsd.MetricPrefix("app.web."))
    defer client.Close()

    http.HandleFunc("/hello", func(res http.ResponseWriter, req *http.Request) {
      start := time.Now()
      client.Incr("requests.http", 1)  // count

      client.SetAdd("requests.user", user.Id)  // set
      // ...

      fmt.Fprint(res, "Hello")
      client.PrecisionTiming("requests.route.api.latency", time.Since(start)) // timing
    })

    client.Gauge("goroutine.count", runtime.NumGoroutine())  // gauge

    http.ListenAndServe(":8080", nil)
}

可以这样写。

网络连接问题

与Prometheus不同，它采用推送式收集，因此每个应用程序都需要知道连接目标。

StatsD使用UDP作为通信协议，这样就不需要处理连接不可的错误，所以不必担心对方是否存在。但是，如果无法连接，则无法收集指标，这就没有意义了。最终，应用程序还是需要根据上下文来更改连接目标的机制。

顺便提一下闹钟

也内置了闹钟功能。由于主要是实时监视，所以在异常情况下发出警报是合理的。

● 电讯台

作为 TICK stack 中的重要组成部分，它是基于插件的经典监控工具。

请参考以下中文译文：

https://www.influxdata.com/time-series-platform/telegraf/

https://github.com/influxdata/telegraf

Inflaxdata が提供する TICK stack の一角

Telegraf – メトリクス収集

InfluxDB – 時系列DB

Chronograf – 可視化

Kapacitor – Stream processing
とはいえ、InfluxDB 以外へもアウトプットできる

でも、通常は InfluxDB を使うと思う

プラグインベース
メモリフットプリント小さい
バイナリでデプロイでき、外部依存がない

因为InfluxDB作为时序数据库非常有吸引力，所以我了解和使用了Telegraf。
尽管对于这次的用途来说它可能有点过大了，但我还是想试着构建一次，看看使用感受如何。

选择了结果

理想情况下，在开发阶段使用Netdata，随着项目的严肃性逐渐增加，开始使用Prometheus。其实，我认为只选择其中一个更好。

要实现这一目标，

将应用程序与Prometheus兼容，并添加一个能够读取Prometheus Exporter格式的插件以兼容Netdata。

有两个选项。

1. 将应用程序适配至StatsD的模式。

何か特別なものを作る必要はない

欠点

Prometheus のクライアントライブラリが持つ機能が使えない

ライブラリがデフォルトで必要そうなメトリクスをあらかじめ収集してくれるものが多い
全体的に、StatsD より Prometheus の方がクライアントライブラリの質が高い ( 印象 )

Prometheus 特有のデータ (属性) が使えない可能性

Summary や Histgram データは対応できない
Label は、DogStatsD 形式で送った Tag を変換することで対応できる

此外，尤其是官方并不太建议的感觉。

我们建议这仅作为一个中间解决方案，并建议长期切换到本地的Prometheus仪表化。

如果已经在运行StatsD，那么请将其用作后端。然而，不建议仅因为有此Exporter就将StatsD的客户端库添加到应用程序中，请使用Prometheus的客户端库。

2. 此应用程序支持 Prometheus 的模式。

Prometheus のクライアントライブラリが使える
Prometheus の機能がフルに使える

欠点

Netdata のプラグインを作成する必要がある

開発段階だけ利用するという意味では、デプロイや長期運用は深く考えなくて良さそう

总体来说，好像后者更好。
所以，我打算尝试第二种方针。

个人感受

说到DevOps，我总是太过关注分支策略、持续集成、部署、基础设施即代码、容器、编排和日志聚合等方面，但我意识到监控作为另一个重要要素，也需要更多关注。
我觉得Prometheus和Netdata有很好地连接开发和运维的能力，所以我想要充分利用它们。
另外，我喜欢InfluxDB，所以也想要更仔细地研究Telegraf。

希望你能在Twelve-Factor App的第13点中增加有关指标监控的政策。

后记

※ 本文仅为个人观点，不代表所属组织观点。

我想做的事情

真正的监控工具

“软件即服务（SaaS）监控工具”

经典监控工具 ​​ ​jù)

最后的候选者

● 普罗米修斯

构建的简易性

收集指标

1. 服务器（硬件）指标

2. 中间件

3. 应用程序 xù)

乘机亦设置闹钟

● 网络数据

建構的便利性

收集指標

1. 服务器（硬件）指标

2. 中间件

添加新的中间件

中间件在讨论中。

3. 应用程序

“统计数据守护进程”

网络连接问题

顺便提一下闹钟

● 电讯台

选择了结果

1. 将应用程序适配至StatsD的模式。

2. 此应用程序支持 Prometheus 的模式。

个人感受

后记

经典监控工具 jù)