Docker容器监控，使用CAdvisor+InfluxDB+Granfana实现docker容器监控

Posted 2023-04-12 秃了也弱了。

文章目录

• 一、概述
• • 1、CAdvisor监控收集+InfluxDB存储数据+Granfana展示图表
• 二、使用compose容器编排部署
• • 1、创建目录
  • 2、新建docker-compose.yml
  • 3、启动docker-compose文件
  • 4、访问一下
  • 5、配置grafana数据源
  • • （1）配置数据源
    • （2）配置图形化界面
    • （3）查看效果

一、概述

通过docker stats命令可以很方便的看到当前宿主机上所有容器的CPU,内存以及网络流量等数据，一般情况是够用了，但是docker stats统计结果只能是当前宿主机的全部容器，数据资料是实时的，没有地方存储、没有健康指标过线预警等功能。

1、CAdvisor监控收集+InfluxDB存储数据+Granfana展示图表

CAdivisor是一个容器资源监控工具，包括容器的内存、CPU、网络IO、磁盘IO等监控，同时提供了一个WEB页面用于查看容器的实时运行状态。CAdvisor默认存储2分钟的数据，而且只是针对单物理机。不过CAdvisor提供了很多数据集成接口，支持InfluxDB、Redis、Kafka、Elasticsearch等集成，可以加上对应配置将监控数据发往这些数据库存储起来。

CAdivisor功能主要有两点：展示Host和容器两个层次的监控数据；展示历史变化数据。

InfluxDB是用Go语言编写的一个开源分布式时序、事件和指标数据库，无需外部依赖。CAdivisor默认只在本地保存最近2分钟的数据，为了持久化存储数据和统一收集展示监控数据，需要将数据存储到InfluxDB中。InfluxDB是一个时序数据库，专门用于存储时序相关数据，很适合存储CAdvisor的数据。而且，CAdvisor本身已经提供了InfluxDB的集成方法，启动容器时指定配置即可。

InfluxDB主要功能：基于时间序列，支持与时间有关的相关函数（如最大、最小、求和等）；可度量性，你可以实时对大量数据进行计算；基于事件，它支持任意的事件数据。

Granfana是一个开源的数据监控分析可视化平台，支持多种数据源配置（支持的数据源包括InfluxDB、mysql、Elasticsearch、OpenTSDB、Graphite等）和丰富的插件及模板功能，支持图表权限控制和报警。

Granfana主要特性：灵活丰富的图形化选项；可以混合多种风格；支持白天和夜间模式；多个数据源。

二、使用compose容器编排部署

docker-compose容器编排使用详解+示例

1、创建目录

mkdir cig

2、新建docker-compose.yml

version: '3.1'
volumes:
  grafana_data: 
services:
 influxdb:
  image: tutum/influxdb:0.9
  restart: always
  environment:
    - PRE_CREATE_DB=cadvisor
  ports:
    - "8083:8083"
    - "8086:8086"
  volumes:
    - ./data/influxdb:/data
 cadvisor:
  image: google/cadvisor
  links:
    - influxdb:influxsrv
  command: -storage_driver=influxdb -storage_driver_db=cadvisor -storage_driver_host=influxsrv:8086
  restart: always
  ports:
    - "8080:8080"
  volumes:
    - /:/rootfs:ro
    - /var/run:/var/run:rw
    - /sys:/sys:ro
    - /var/lib/docker/:/var/lib/docker:ro
 grafana:
  user: "104"
  image: grafana/grafana
  user: "104"
  restart: always
  links:
    - influxdb:influxsrv
  ports:
    - "3000:3000"
  volumes:
    - grafana_data:/var/lib/grafana
  environment:
    - HTTP_USER=admin
    - HTTP_PASS=admin
    - INFLUXDB_HOST=influxsrv
    - INFLUXDB_PORT=8086
    - INFLUXDB_NAME=cadvisor
    - INFLUXDB_USER=root
    - INFLUXDB_PASS=root

3、启动docker-compose文件

# 启动
docker-compose up -d

# 查看是否启动成功
[root@localhost cig]# docker ps
CONTAINER ID   IMAGE                COMMAND                  CREATED          STATUS          PORTS                                                                                  NAMES
744345aa2dda   google/cadvisor      "/usr/bin/cadvisor -…"   36 seconds ago   Up 35 seconds   0.0.0.0:8080->8080/tcp, :::8080->8080/tcp                                              cig_cadvisor_1
de1b9e3cfbb8   grafana/grafana      "/run.sh"                36 seconds ago   Up 35 seconds   0.0.0.0:3000->3000/tcp, :::3000->3000/tcp                                              cig_grafana_1
4611eb3dda87   tutum/influxdb:0.9   "/run.sh"                36 seconds ago   Up 35 seconds   0.0.0.0:8083->8083/tcp, :::8083->8083/tcp, 0.0.0.0:8086->8086/tcp, :::8086->8086/tcp   cig_influxdb_1

4、访问一下

浏览cAdvisor收集服务，http://ip:8080/
第一次访问慢，请稍等，cadvisor也有基础的图形展现功能，这里主要用它来作数据采集

浏览influxdb存储服务，http://ip:8083/

浏览grafana展现服务，http://ip:3000
默认帐户密码（admin/admin），第一次登录会提示修改密码

5、配置grafana数据源

（1）配置数据源

出现绿色对钩说明配置成功

（2）配置图形化界面

（3）查看效果

可以随心所欲地设置要展示的信息啦！

使用 cAdvisor 和 Prometheus 监控未命名容器

【中文标题】使用 cAdvisor 和 Prometheus 监控未命名容器

【英文标题】：Monitoring unnamed containers with cAdvisor and Prometheus

【发布时间】：2021-09-10 16:16:12

【问题描述】：

我有一个运行 Docker 容器化应用程序的实验主机。 cAdvisor 和 Prometheus 容器也在运行。

应用生成容器以运行与一组命名空间（可能是数千个命名空间）中的一个相关的作业，并使用 uuid 命名容器。 cAdvisor 可以选择这些，我可以看到每个容器在 prometheus 中的指标使用情况。这些容器的运行时间从几秒钟到大约一个小时不等。

我需要能够将命名空间 ID（来自容器中的 API 调用）与 prometheus 中的指标相关联，因为容器名称对于运行来说是唯一的，我需要命名空间 ID。

This doc 说不要使用很多不同的标签，因为它会生成很多单独的时间序列，但添加 kv 似乎是最方便的方法。

This doc 表示将 pushgateway 用于服务级别的批处理作业，并且由于我的容器与命名空间相关而不是与整个服务相关，因此使用它似乎不正确。

我每天可能有 5-10 个容器在不同的容器名称下运行，这些容器名称对应于应用程序中的相同命名空间，我需要一个跨越所有 5-10 个的时间序列。

进行这种关联的最佳方法是什么？ 如何从容器内部向 prometheus 发送一些任意数据？

【参考方案1】：

如果您需要通过某些特征来区分一组相同的指标，那么除了使用标签之外没有其他合理的方法。当标签过多或标签值过多时，就会出现标签和存储问题。请允许我向您展示此示例中的问题：

http_requestscode="200",client="8.8.8.8",uri="/hello"

只有三个标签，但每个标签都可以产生大量不同的时间序列。每个响应代码、客户端地址和访问 URL 的唯一组合一个。我想，您的命名空间 ID 具有有限且少量的可能值，因此不会造成任何伤害。独特的容器名称（cAdvisor 将它们公开为标签）甚至可能比命名空间 ID 产生更大的影响。

还有一种使用relabel_config 重写、添加或删除标签的方法。但是，如果您决定重写，该解决方案有点难以掌握并且很容易在腿部射击。如果可能的命名空间数量很少，我建议继续添加新标签。

【讨论】：

谢谢。我发现将自定义指标发布到推送网关是最好的。