配置Docker Telegraf输入插件

作者：Anais Dotis-Georgiou / 产品，用例，开发者
2018年10月22日

导航到

幸运的是，使用InfluxDB监控容器出奇地简单。然而，从容器数据中提取价值并不容易。理解如何管理和分配容器资源绝非易事，DevOps对我来说仍然相当神秘。当我开始在本地上监控一些容器时，我的理解不足问题变得尤为突出。在这篇博客文章中，我将分享我更好地理解容器监控的旅程。

但首先，让我向您展示

  1. 我是如何在Docker容器中配置反向代理和nginx服务器以提供静态HTML的
  2. 我是如何使用Telegraf和InfluxDB本地监控这些容器的
  3. 这个练习引发的所有问题

如何在Docker容器中配置反向代理和nginx服务器以提供静态HTML

我决定在我的本地机器上监控容器。我非常喜欢这个教程，并推荐任何新Docker用户观看。首先，我创建了两个镜像。第一个是一个nginx镜像，用于提供静态HTML页面。第二个是一个nginx反向代理镜像，它使用内置的DNS解析器以轮询方式将请求转发到所有的静态应用容器。为了构建这两个镜像，我创建了一个“app”目录和一个“proxy”目录。在我的“app”目录中，我创建了一个dockerfile（一个包含构建docker镜像所需所有命令的文件）以及我的静态HTML。dockerfile看起来像这样

FROM nginx:alpine
COPY static.html /usr/share/nginx/html

它包含docker构建nginx容器（具体来说，是alpine版本）的指令。Static.html被复制到nginx的默认静态HTML文件目录，以便它能够提供网站服务。由于我只想看看使用InfluxDB监控容器是什么样子，我的HTML页面就是一个痛苦无聊的“Hello World”页面

<html>
<header><title>Monitoring Docker with InfluxDB</title></header>
<body>
Hello world
</body>
</html>

为了构建nginx静态应用镜像，我使用命令docker build -t "app" . -p 9000:80。这个命令构建了镜像并使用名称“app”标记它。它还将本地主机的端口9000映射到端口80。

在我的proxy目录中，我也有一个dockerfile，其中包含这个镜像构建的指令。它看起来像这样

FROM nginx:alpine

COPY proxy.conf /etc/nginx/conf.d/

在这里，我将我的代理配置文件复制到nginx的默认配置目录中。Proxy.conf包含指定代理应该监听哪个端口接收请求以及DNS解析器应该如何行为的指令

server {

    listen 80;

    resolver 127.0.0.11 valid=5s;
    set $app_address http://app;
    location / {
        proxy_pass $app_address;
    }

}

具体来说，proxy.conf告诉代理服务器在本地主机的端口80上监听任何传入请求。我还包含了内置DNS解析器的IP地址（127.0.0.11），这样代理就知道要将请求转发到何处。这个DNS解析器包含所有运行的应用容器的IP地址。它将选择一个IP地址，然后在对剩余容器的轮询DNS负载均衡中执行操作。通过设置valid=5s，我们告诉代理将缓存时间设置为5秒。这样，代理将更快地发现对DNS服务器的任何更改。这对我很重要，因为我希望能够在添加几个容器后立即看到InfluxDB实例中的变化。如果我没有更改valid变量的参数，它将默认为5分钟。

在生产环境中，较长的缓存时间是有意义的，因为它有助于最小化DNS解析器的负载。然而，我没有那种时间/耐心。更不用说，我还需要启动很多“应用”容器来观察较小的valid变量的负面影响。由于这个项目的目标不是试图对DNS服务器进行压力测试，也不是让我的资源达到最大，因此5秒的缓存时间效果很好（信不信由你，我有时会尽量不破坏东西）。最后，将proxy_pass设置为变量$app_address，迫使代理尝试发现该$app_address变量包含的信息。为此，它必须每次都在DNS解析器中查找，以确保地址更新。

配置拼图的最后一块是docker-compose.yml和docker-telegraf.conf。docker-compose.yml包括

---
version: '2'

services:
    app:
        build: app

    proxy:
        build: proxy
        ports:
         - "80:80"

这个yml仅仅指定将运行两个服务：应用和代理。它还包含相对路径和构建指令。

我是如何使用Telegraf和InfluxDB本地监控这些容器的

Telegraf是InfluxData的开源指标和事件收集代理。它是插件驱动的，因此我需要包含一个配置文件，其中包含适当的输入和输出插件，以便从我的Docker容器中收集指标。我正在使用Docker输入插件和默认的InfluxDB输出插件。为了生成我的配置文件，docker-telegraf.conf，我在项目目录中运行telegraf --input-filter docker --output-filter influxdb config > docker_telegraf.conf。我将这些容器指标发送到默认的“telegraf”数据库。但是，您可以通过更改配置文件中的第95行来创建一个名为您选择的数据库

## The target database for metrics; will be created as needed.
 database = "<database of your wildest imagination>"

我保留了Docker输入的默认路径和数据库配置设置，如文档中所述。具体来说，我的配置中的输入部分如下

[[inputs.docker]]
  ## Docker Endpoint
  ##   To use TCP, set endpoint = "tcp://[ip]:[port]"
  ##   To use environment variables (ie, docker-machine), set endpoint = "ENV"
  endpoint = "unix:///var/run/docker.sock"

  ## Set to true to collect Swarm metrics(desired_replicas, running_replicas)
  gather_services = false

  ## Only collect metrics for these containers, collect all if empty
  container_names = []

  ## Containers to include and exclude. Globs accepted.
  ## Note that an empty array for both will include all containers
  container_name_include = []
  container_name_exclude = []

  ## Container states to include and exclude. Globs accepted.
  ## When empty only containers in the "running" state will be captured.
  # container_state_include = []
  # container_state_exclude = []

  ## Timeout for docker list, info, and stats commands
  timeout = "5s"

  ## Whether to report for each container per-device blkio (8:0, 8:1...) and
  ## network (eth0, eth1, ...) stats or not
  perdevice = true
  ## Whether to report for each container total blkio and network stats or not
  total = false
  ## Which environment variables should we use as a tag
  ##tag_env = ["JAVA_HOME", "HEAP_SIZE"]

  ## docker labels to include and exclude as tags.  Globs accepted.
  ## Note that an empty array for both will include all labels as tags
  docker_label_include = []
  docker_label_exclude = []

  ## Optional TLS Config
  # tls_ca = "/etc/telegraf/ca.pem"
  # tls_cert = "/etc/telegraf/cert.pem"
  # tls_key = "/etc/telegraf/key.pem"
  ## Use TLS but skip chain & host verification
  # insecure_skip_verify = false

接下来，我想检查代理是否工作。我可以调整运行的应用容器数量，以确保代理工作正常。我使用docker-compose up --scale app=3启动3个应用容器。接下来，我访问https://127.0.0.1。刷新几次后，我看到以下输出

太好了！代理正在成功工作。请求正在被引导到每个容器。

这个代理测试还将使我能够看到Telegraf是否成功地从我的容器中收集指标。我访问https://127.0.0.1:8888来打开Chronograf，InfluxData的开源数据可视化和警报管理平台。在默认的名为“telegraf”的数据库中，我现在可以看到所有的docker指标。我运行以下查询…

…以监控容器总数和运行中的容器数。我得到以下预期的结果

哇哇哇！Telegraf正在将容器指标发送到InfluxDB。我的配置是成功的。我可以直接收集以下指标

  • 使用的文件描述符数量
  • CPU数量
  • 容器数量
  • 运行中的容器数量
  • 停止的容器数量
  • 暂停的容器数量
  • 镜像数量
  • goroutine数量
  • 监听器事件数量
  • 总内存

但还有更多可供我使用。如果我将docker配置为使用devicemapper存储驱动程序，则可以获得大约5倍的指标。如果配置了HEALTHCHECK，则可以报告容器的健康状况，或者可以监控整个Docker Swarm。那是很多指标。

所有由此练习引发的疑问

我想提出一些棘手的问题，领导一次成功的数据调查，并找出技术责任人。然而，当我看到所有可用的指标时，我开始感到不知所措。我不知道如何处理它们。我意识到我对DevOps监控、测试和警报一无所知。我想提出深入的问题，但首先，我必须找到这些基本问题的答案。

  1. Docker默认如何分配资源？
  2. 我能将一定量的GHz分配给一个进程吗？（剧透：哈哈...不能）
  3. 如何在本地实际监控Docker？
  4. 最重要的10个指标是什么？这是一个相关的问题吗？这些问题中有任何好的吗？
  5. 监控Docker容器与监控Kubernetes相比如何？
  6. Docker Swarm与Kubernetes相比如何？
  7. DevOps工程师运行什么类型的测试来确定容器资源的阈值？
  8. DevOps测试过程是什么样的？
  9. 在什么情况下DevOps工程师决定自动化扩展？
  10. 我如何使用InfluxDB在容器内监控我的应用程序？

我希望这篇博客能帮助你开始监控你的Docker容器。我知道它帮助我找出了我的知识盲点。我期待着尝试回答这些问题，并分享我更好地理解容器监控的探索之旅。如果您发现任何内容令人困惑，或者随时向我寻求帮助。您可以访问InfluxData的社区网站或向我们发推文@InfluxDB。最后，我为您提供一个大脑放松的时刻。

<figcaption>我为您的观看乐趣制作的一幅变色龙插图</figcaption>