精华内容
下载资源
问答
  • PROMETHEUS容器监控

    2021-02-02 16:49:13
    但是对容器监控显得力不从心。为解决监控容器的问题,引入了prometheus技术。prometheus号称是下一代监控。接下来的文章打算围绕prometheus做一个系列的介绍,顺便帮自己理清知识点。 一、简介  prometheus是由...

    我们知道zabbix在监控界占有不可撼动的地位,功能强大。但是对容器监控显得力不从心。为解决监控容器的问题,引入了prometheus技术。prometheus号称是下一代监控。接下来的文章打算围绕prometheus做一个系列的介绍,顺便帮自己理清知识点。


    一、简介

      prometheus是由谷歌研发的一款开源的监控软件,目前已经被云计算本地基金会托管,是继k8s托管的第二个项目。

    二、优势

      易于管理

      轻易获取服务内部状态

      高效灵活的查询语句

      支持本地和远程存储

      采用http协议,默认pull模式拉取数据,也可以通过中间网关push数据

      支持自动发现

      可扩展

      易集成

    三、prometheus运行流程

    prometheus根据配置定时去拉取各个节点的数据,默认使用的拉取方式是pull,也可以使用pushgateway提供的push方式获取各个监控节点的数据。将获取到的数据存入TSDB,一款时序型数据库。此时prometheus已经获取到了监控数据,可以使用内置的PromQL进行查询。它的报警功能使用Alertmanager提供,Alertmanager是prometheus的告警管理和发送报警的一个组件。prometheus原生的图标功能过于简单,可将prometheus数据接入grafana,由grafana进行统一管理。

    四、监控的目的

      google指出,监控分为白盒监控和黑盒监控之分。

      白盒监控:通过监控内部的运行状态及指标判断可能会发生的问题,从而做出预判或对其进行优化。

      黑盒监控:监控系统或服务,在发生异常时做出相应措施。

      监控的目的如下:

        1、根据历史监控数据,对为了做出预测

        2、发生异常时,即使报警,或做出相应措施

        3、根据监控报警及时定位问题根源

        4、通过可视化图表展示,便于直观获取信息

    五、常用概念

      prometheus采集到的监控数据均以metric(指标)形式保存在时序数据库中(TSDB)

      每一条时间序列由 metric 和 labels 组成,每条时间序列按照时间的先后顺序存储它的样本值。

      默认情况下各监控client向外暴露一个HTTP服务,prometheus会通过pull方式获取client的数据,数据格式如下:

    1

    2

    3

    4

    5

    6

    #  HELP node_cpu Seconds the cpus spent in each mode.

    #  TYPE node_cpu counter

    node_cpu{cpu="cpu0",mode="idle"}    362812.7890625

    #  HELP node_load1 1m   load    average.

    #  TYPE node_load1 gauge

    node_load1 3.0703125

      以#开头的表示注释信息,解释了每一个指标的监控目的和类型

      node_cpu表示监控指标的名称

      {}内的内容是标签,以键值对的方式记录 

      数字是这个指标监控的数据

      下图横坐标代表的是时间(时间戳的方式记录在TSDB中),纵坐标代表了各种不同的指标名称,坐标系中的黑点代表了各个指标在不同时间下的值。

      每一个横线 就是时间序列

      每个黑点就是样本(prometheus将样本以时间序列的方式保存在内存中,然后定时保存到硬盘上)

     

       指标(metric)的格式如下:

    1

    <metric  name>{<label  name>=<label  value>,  ...}

      指标名称反映的是监控了什么。

      标签反映的是样本的维度,可以理解成指标的细化。比如:

    1

    api_http_requests_total{method="POST",  handler="/messages"}

      指标是“api_http_requests_total”,含义是通过api请求的http总数。

      标签“method="POST"” "handler="/messages""代表了这些http请求中 POST 请求 并且 handler是/messages的数量

      上述指标等同于:

    1

    {__name__="api_http_requests_total",method="POST",  handler="/messages"}

      

      指标有四种类型

      1、Counter  只增不减  计数器

      2、Gauge  可增可减    仪表盘

      3、Histogram  直方图

      4、Summary  摘要型

    展开全文
  • Docker容器监控

    2019-12-19 19:28:42
    利用docker compose组合应用并利用scale可以快速对容器进行扩充,而docker compose启动的服务容器都在同一台宿主机上,对于一个宿主...容器监控方案选择 对于容器的监控方案可谓多种多样,除了docker本身自带的 dock...

    利用docker compose组合应用并利用scale可以快速对容器进行扩充,而docker compose启动的服务容器都在同一台宿主机上,对于一个宿主机上运行多个容器应用时,容器的运行情况,如:CPU使用率,内存使用率,网络状态,磁盘空间等一系列随时间变化的时序数据信息,都需要进行了解,因此监控是必须的。

    容器监控方案选择

    对于容器的监控方案可谓多种多样,除了docker本身自带的 docker stats 命令,还有Scout,Data Dog,Sysdig Cloud,Sensu Monitoring Framework,CAdvisor等都可以对容器进行监控。
    通过 docker stats 命令可以很方便的看到当前宿主机上所有容器的CPU,内存,以及网络流量等数据。但 docker stats 命令的缺点是只是统计当前宿主机的所有容器,为获取的数据是实时的,没有地方存储,也没有报警功能。

    img

    而Scout,Data Dog,Sysdig Cloud虽然都提供了教完善的服务,但是它们都是托管的服务且都是收费的,Sensu Monitoring Framework集成度较高,也免费,但是部署过于复杂,综合考虑选择CAdvisor做监控工具。

    CAdvisor出自Google,有点是开源产品,监控指标齐全,部署方便,而且有官方的docker镜像。缺点是集成度不高,默认只在本地保存2分钟数据。不过,可以加上InfluxDB存储数据,对接Grafana展示图表,比较便利搭建容器监控系统,数据收集和图表展示效果良好,对系统性能也几乎没什么影响。

    CAdvisor + InfluxDB + Grafana搭建容器监控系统

    CAdvisor

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

    InfluxDB

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

    InfluxDB主要功能:

    • 基于时间序列,支持与时间有关的相关函数
    • 可度量性,可以实时对大量数据进行计算
    • 基于事件,支持任意的事件数据

    InfluxDB主要特点:

    • 无结构
    • 可以是任意数量的列
    • 可拓展
    • 支持min,max等一系列的函数,方便统计
    • 原生的HTTP支持,内置HTTP API
    • 强大的类SQL语法

    Granfana

    Grafana是一个开源的数据监控分析可视化平台,支持多种数据源配置(如InfluxDB,MySQL,Elasticserach,OpenTSDB,Graphite等)和丰富的插件及模板功能,支持图表权限控制和报警。

    Grafana主要特点

    • 灵活丰富的图形化选项
    • 可以混合多种风格
    • 支持白天和夜间模式
    • 多数据源

    CAdvisor负责收集容器随时间变化的数据
    InfluxDB负责存储时序数据
    Grafana负责分析和展示时序数据

    安装部署

    部署InfluxDB服务

    启动InfluxDB的服务容器:

    docker run -d --name influxdb -p 8086:8086 \
    -v /data/influxdb:/var/lib/influxdb \
    --hostname influexdb \
    influxdb
    

    在容器中创建test数据库和root用户

    docker exec -it influxdb influx
    
    > CREATE DATABASE "test"
    > CREATE USER "root" WITH PASSWORD 'root' WITH ALL PRIVILEGES
    

    img

    部署CAdvisor

    启动CAdvisor的服务容器:

    docker run \
      --volume=/:/rootfs:ro \
      --volume=/var/run:/var/run:ro \
      --volume=/sys:/sys:ro \
      --volume=/var/lib/docker/:/var/lib/docker:ro \
      --volume=/dev/disk/:/dev/disk:ro \
      --publish=8080:8080 \
      --detach=true \
      --name=cadvisor \
      google/cadvisor:latest \
      -storage_driver=influxdb \
      -storage_driver_host=influxdb:8086 \
      -storage_driver_db=test \
      -storage_driver_user=root \
      -storage_driver_password=root 
    

    服务容器起来后可通过浏览器访问 http:///ip:8080

    img

    部署Grafana

    启动Grafana服务容器:

    docker run -d -p 3000:3000 \
    -v /data/grafana:/var/lib/grafana \
    --link=influxdb:influxdb \
    --name grafana grafana/grafana
    

    直接运行该命令后有可能会发现容器并没有启起来,通过 docker logs 命令会发现”mkdir: can’t create directory ‘/var/lib/grafana/plugins’: Permission denied“的错误,其实就是没有 数据卷对应的主机上 /data/grafana 的权限,可以在运行启动命令前先创建 /data/grafana 目录并给定权限777,或者通过”docker run --entrypoint “id” grafana/grafana“ 查看uid,gid,groups (默认为472),然后通过”chown -R 472:472 /data/grafana“修改权限。

    img

    Grafana正常启动后就可以 http://ip:3000 访问,出现以下的登录页面,初次访问需要修改密码,默认用户名密码为:admin/admin

    img

    Docker Compose集成部署

    准备docker-compose.yml文件

    version: '3.1'
    volumes:
      grafana_data: {}
    services:
      influxdb:
        image: influxdb
        restart: always
        environment:
          - PRE_CREATE_DB=cadvisor
        ports:
          - "8086:8086"
        expose:
          - "8090"
          - "8099"
        volumes:
          - ./data/influxdb:/data
      cadvisor:
        image: google/cadvisor
        links:
          - influxdb:influxdb-host
        command: -storage_driver=influxdb -storage_driver_db=cadvisor -storage_driver_host=influxdb-host: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
        restart: always
        links:
          - influxdb:influxdb-host
        ports:
          - "3000:3000"
        volumes:
          - grafana_data:/var/lib/data
        environment:
          - HTTP_USER=admin
          - HTTP_PASS=admin
          - INFLUXDB_HOST=influxdb-host
          - INFLUXDB_PORT=8086
          - INFLUXDB_NAME=cadvisor
          - INFLUXDB_USER=root
          - INFLUXDB_PASS=root
    

    在docker-compose.yml文件目录运行以下命令启动服务:

    docker-compose up -d
    

    -d指定在后台启动,初次启动可以不加可以在控制台查看启动日志,当然后台启动也可以通过“docker-compose logs”进行查看启动日志。

    服务正常启动后就可以 http://ip:3000 访问Granafa,在Home Dashboard页面点击添加data source

    img

    配置InfluxDB连接信息,当然在配置连接信息前需要进入InfluxDB容器创建相应的cadvisor数据库和用户root/root

    在容器中创建cadvisor数据库和root用户

    docker exec -it influxdb-contianer-id influx
    
    > CREATE DATABASE "cadvisor"
    > CREATE USER "root" WITH PASSWORD 'root' WITH ALL PRIVILEGES
    

    配置连接InfluxDB连接:

    img
    img

    数据源配好之后可以回到Home Dashboard添加添加dashboard图表展示监控信息,Grafana提供了丰富的图片模板对监控数据进行展示。

    添加dashboard:
    img
    img
    可选模板:
    img
    编辑图表:
    img
    配置监控cadvisor容器的内存使用情况的图表展示,配置好之后点击保存就可以了。
    img

    在这里插入图片描述

    展开全文
  • 所以今天我就和你分享关于容器监控的知识(原理及工具 cAdvisor)。 虽然传统的物理机和虚拟机监控已经有了比较成熟的监控方案,但是容器的监控面临着更大的挑战,因为容器的行为和本质与传统的虚拟机是不一样的,总...
  • 主要介绍了Docker容器监控及日志管理实现过程解析,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
  • 微服务:监控体系,容器监控

    千次阅读 2019-08-25 09:41:10
    微服务长什么样 微服务架构本质是带自身特点的面向服务的分布式架构模式。 微服务架构特征是有更细粒度服务边界,倡导独立开发、...以问题的形式来理解为什么需要监控体系,也是我们需要监控体系的理由 首先是...

    微服务长什么样

    微服务架构本质是带自身特点的面向服务的分布式架构模式

    微服务架构特征是有更细粒度服务边界,倡导独立开发、测试、部署、扩展等等,更细粒度带来的敏捷提升,以及分布式系统固有的复杂性。

     

    服务治理

     

    为什么需要监控?

    微服务是一个分布式的架构模式,它一直以来都会有一些自身的问题。

    • 以问题的形式来理解为什么需要监控体系,也是我们需要监控体系的理由

     

    首先是问题的定位。

    当系统发从单个节点扩张到很多节点的时候,如果系统的某个点出现问题,对于我们的运维和开发人员来说,这时的问题定位可能就会变成一个挑战。

    1. 分散在各个服务器上的日志如何处理
    2. 业务流程出现问题,如何快速的定位问题发生在哪个环节、哪个点

    数据支撑

    新的业务进来以后,系统能否支持,系统运行的状况又是怎样

    还有现在的一些电商要做促销活动,容量规划怎么做

    我们可以通过监控手段对系统进行衡量,或者做一个数据支撑。

    对服务的系统认知

    要理解分布式系统是怎样一个拓扑结构,如何部署,系统之间怎样通信,系统目前是怎样的性能状况,以及出了问题我们要怎么去发现它。

    1. 如何跟踪业务流的处理顺序和处理结果
    2. 如何实现事故的预警,如资源不足
    3. 如何分析系统的性能瓶颈

    这些都可能是分布式系统需要面对的问题。出现这些问题后,监控就是一个比较常用、有效率的一个手段。

    总的来说,监控主要解决的是感知系统的状况。

     要监控什么

     

    • 服务概览信息:如服务名称、服务部署所在机房、主机、服务包含的API、服务相关配置信息、服务负责人、开发人员、运维人员信息等
    • 服务性能指标:如响应实现、流量、成功、失败数、请求频率等
    • 服务拓扑关系:服务之间的调用关系
    • 服务调用链:服务的整个调用链监控
    • 服务版本信息:服务版本,客户端版本等
    • 服务治理状态:服务注册情况、服务状态、熔断等
    • 组件内部状态:活跃线程数、处理请求数等

    监控体系和内容

    监控体系从底到上分为:基础设施监控、系统层监控、应用层监控、业务层监控、端用户体验监控

    监控的内容分为五个部分:日志监控,Metrics监控(服务调用情况),调用链监控,告警系统和健康检查。

    日志监控,国内常用的就是ELK+KAFKA来实现。健康检查和Metrics,像spring boot会自带。

    Trace调用链监控

    调用链监控是用来追踪微服务之前依赖的路径和问题定位。例如阿里的鹰眼系统。主要原理就是子节点会记录父节点的id信息。

     

    下图是目前比较流行的调用链监控框架。

     

    基于容器的微服务监控

    对于微服务系统来说,相对比较复杂的是监控,容器编排,还有日志收集,容器编排目前有很好的实现,比如KubernetesSwarmMesos,等等,这些都解决了容器的编排问题,这里之所以提到容器编排,是因为微服务的落地比较好的实现方式就是运行在容器当中,多亏了这些开源组件的存在,很多微服务所要考虑的问题都被集成到这些平台中了。

    那么对于这种多说上千万个虚拟容器的大集群来说,监控到底怎么实现呢?

    基于容器的微服务监控大致可以分为,容器与宿主机的监控(基础监控),API监控,调用链监控以及应用本身的监控

     

    1. 容器与宿主机的监控

    基于容器的微服务监控和原始的监控是有很大区别的,因为服务的实例生存周期很短,分分钟可能就会有容器的生灭

    微服务的容器与宿主机的监控离不开CPU,内存,磁盘,网卡这些基础的性能指标。

    对于宿主机的监控来说,我们可以依然使用原始的监控方式,每个宿主机安装一个代理来采集服务器的性能指标,代理在采集性能指标的时候可以打上时间戳和相应的标签来区分不同性能指标的数据维度(metric),然后将监控数据汇总到时间序列数据库,里面的数据可以对接目前一些开源的组件来进行可视化的展示,也可以对接报警服务(结合报警服务的报警策略)进行报警。

    容器的监控自然就和宿主机不太一样了,我们不能说给每个容器镜像内部都集成一个监控代理(agent),这样的话侵入性太强, 不易于维护。目前有比较成熟的开源产品Prometheus,它有很多的Exporter可以用来采集监控数据,例如我们想采集Kubernetes上所有容器(pod)的性能指标的话,Promethus可以通过直接配置多个Kubernetes ApiServer的Endpoints来监控整个Kubernetes集群。

    2.API监控

    微服务对外暴露的api都是经过服务网关来访问的,那么我们可以在网关上对这些api进行流量的分析与监控,监控api的访问量,api的响应体状态码,当某些指标达到阀值时我们就可以进行报警,目前也有很多开源的产品可以使用,例如Kong,它可以安装很多功能性插件,其中就有dashboard插件,以及监控插件。

    3.调用链监控

    有了对整个微服务调用链的监控,我们就会有一种一览全局的感觉,对整个微服务集群的部署情况,以及运行情况了如指掌,可以很快的定位问题,协同开发人员进行性能调优,量化运维部门的价值。目前有谷歌的Google Dapper但是没有开源只有论文,ZipkinOpenTracing,这些都是根据谷歌的论文开发的开源产品都很不错。

    4.应用本身的监控

    微服务应用本身的监控的方式就比较多样了。这里我就说一下我自己基于Kubernetes实现的微服务应用级的监控插件,先上个图:

     

     

    在Kubernetes的master节点,也就是安装apiserver的那台服务器上运行一个监控插件,该插件可以通过一个kubernetes提供的官方客户端来访问apiserver,首先我们要告知插件要监控哪个namespace下的哪个service,然后,插件通过和apiserver进行交互获取某个service下所有Pods的实例,插件会并发访问所有pod提供的/metrics接口(Path可配),并给每个pod的返回数据(json格式,遵守一定的数据格式契约)打上pod_name的标签来标识每个pod返回的metrics,打上pod_name标签的同时也会打上service_name的标签用来区分具体是哪个service的监控数据。通过插件收集整理后的数据会上传到时间序列数据库中,后续就可以根据数据进行可视化分析以及展示(Granfana),同样若是结合开源监控PrometheusOWL也可以实现监控报警,只不过结合不同的监控需要返回它们所需要的监控数据格式罢了。

     

    参考链接:

    https://juejin.im/post/5add3b05f265da0b80705525
    https://blog.csdn.net/crave_shy/article/details/81334845

    展开全文
  • 主要介绍了python脚本监控docker容器的相关资料,需要的朋友可以参考下
  • 随着越来越多的线上服务docker化,对容器的监控、报警变得越来越重要,容器监控有多种形态,有些是开源的(如promethues),而另一些则是商业性质的(如Weave),有些是集成在云厂商一键部署的(Rancher、谷歌云),...
  • 所以今天我就和你分享关于容器监控的知识(原理及工具 cAdvisor)。 虽然传统的物理机和虚拟机监控已经有了比较成熟的监控方案,但是容器的监控面临着更大的挑战,因为容器的行为和本质与传统的虚拟机是不一样的,...

    生产环境中监控容器的运行状况十分重要,通过监控我们可以随时掌握容器的运行状态,做到线上隐患和问题早发现,早解决。所以今天我就和你分享关于容器监控的知识(原理及工具 cAdvisor)。

    虽然传统的物理机和虚拟机监控已经有了比较成熟的监控方案,但是容器的监控面临着更大的挑战,因为容器的行为和本质与传统的虚拟机是不一样的,总的来说,容器具有以下特性:

    • 容器是短期存活的,并且可以动态调度
    • 容器的本质是进程,而不是一个完整操作系统
    • 由于容器非常轻量,容器的创建和销毁也会比传统虚拟机更加频繁

     Docker 容器的监控方案有很多,除了 Docker 自带的docker stats命令,还有很多开源的解决方案,例如 sysdig、cAdvisor、Prometheus 等,都是非常优秀的监控工具。

    下面我们首先来看下,不借助任何外部工具,如何用 Docker 自带的docker stats命令实现容器的监控。

     

    使用 docker stats 命令


     使用 Docker 自带的docker stats命令可以很方便地看到主机上所有容器的 CPU、内存、网络 IO、磁盘 IO、PID 等资源的使用情况。下面我们可以具体操作看看。

     首先在主机上使用以下命令启动一个资源限制为 1 核 2G 的 nginx 容器:

    $ docker run --cpus=1 -m=2g --name=nginx  -d nginx
    

    容器启动后,可以使用docker stats命令查看容器的资源使用状态:

    $ docker stats nginx
    

    通过docker stats命令可以看到容器的运行状态如下:

    CONTAINER           CPU %               MEM USAGE / LIMIT   MEM %               NET I/O             BLOCK I/O           PIDS
    
    f742a467b6d8        0.00%               1.387 MiB / 2 GiB   0.07%               656 B / 656 B       0 B / 9.22 kB       2
    

    从容器的运行状态可以看出,docker stats命令确实可以获取并显示 Docker 容器运行状态。但是它的缺点也很明显,因为它只能获取本机数据,无法查看历史监控数据,没有可视化展示面板。

    因此,生产环境中我们通常使用另一种容器监控解决方案 cAdvisor。

     

    cAdvisor


    cAdvisor 是谷歌开源的一款通用的容器监控解决方案。cAdvisor 不仅可以采集机器上所有运行的容器信息,还提供了基础的查询界面和 HTTP 接口,更方便与外部系统结合。所以,cAdvisor很快成了容器指标监控最常用组件,并且 Kubernetes 也集成了 cAdvisor 作为容器监控指标的默认工具。

     

    cAdvisor 的安装与使用


    下面我们以 cAdvisor 0.37.0 版本为例,演示一下 cAdvisor 的安装与使用。

    cAdvisor 官方提供了 Docker 镜像,我们只需要拉取镜像并且启动镜像即可。

    由于 cAdvisor 镜像存放在谷歌的 gcr.io 镜像仓库中,国内无法访问到。这里我把打好的镜像放在了 Docker Hub。你可以使用 docker pull lagoudocker/cadvisor:v0.37.0 命令从 Docker Hub 拉取。

    首先使用以下命令启动 cAdvisor:

    $ docker run \
      --volume=/:/rootfs:ro \
      --volume=/var/run:/var/run:ro \
      --volume=/sys:/sys:ro \
      --volume=/var/lib/docker/:/var/lib/docker:ro \
      --volume=/dev/disk/:/dev/disk:ro \
      --publish=8080:8080 \
      --detach=true \
      --name=cadvisor \
      --privileged \
      --device=/dev/kmsg \
      lagoudocker/cadvisor:v0.37.0
    

     此时,cAdvisor 已经成功启动,我们可以通过访问 http://localhost:8080 访问到 cAdvisor 的 Web 界面。

                                                                                                                                               cAdvisor 首页

    cAdvisor 不仅可以监控容器的资源使用情况,还可以监控主机的资源使用情况。下面我们就先看下它是如何查看主机资源使用情况的。

     

    使用 cAdvisor 查看主机监控


     访问 http://localhost:8080/containers/ 地址,在首页可以看到主机的资源使用情况,包含 CPU、内存、文件系统、网络等资源,如下图所示。

     

    使用 cAdvisor 查看容器监控


    如果你想要查看主机上运行的容器资源使用情况,可以访问 http://localhost:8080/docker/,这个页面会列出 Docker 的基本信息和运行的容器情况,如下图所示。

                                                                                                                             图3 Docker 容器

    在上图中的 Subcontainers 下会列出当前主机上运行的所有容器,点击其中一个容器即可查看该容器的详细运行状态,如下图所示。

     总体来说,使用 cAdvisor 监控容器具有以下特点:

    • 可以同时采集物理机和容器的状态

    • 可以展示监控历史数据

    了解 Docker 的监控工具,你是否想问,这些监控数据是怎么来的呢?下面我就带你了解一下容器监控的原理。

     

    监控原理


    我们知道 Docker 是基于 Namespace、Cgroups 和联合文件系统实现的。其中 Cgroups 不仅可以用于容器资源的限制,还可以提供容器的资源使用率。无论何种监控方案的实现,底层数据都来源于 Cgroups。

    Cgroups 的工作目录为/sys/fs/cgroup/sys/fs/cgroup目录下包含了 Cgroups 的所有内容。Cgroups包含很多子系统,可以用来对不同的资源进行限制。例如对CPU、内存、PID、磁盘 IO等资源进行限制和监控。

    为了更详细的了解 Cgroups 的子系统,我们通过 ls -l 命令查看/sys/fs/cgroup文件夹,可以看到很多目录:

    $ sudo ls -l /sys/fs/cgroup/
    total 0
    
    dr-xr-xr-x 5 root root  0 Jul  9 19:32 blkio
    lrwxrwxrwx 1 root root 11 Jul  9 19:32 cpu -> cpu,cpuacct
    dr-xr-xr-x 5 root root  0 Jul  9 19:32 cpu,cpuacct
    lrwxrwxrwx 1 root root 11 Jul  9 19:32 cpuacct -> cpu,cpuacct
    dr-xr-xr-x 3 root root  0 Jul  9 19:32 cpuset
    dr-xr-xr-x 5 root root  0 Jul  9 19:32 devices
    dr-xr-xr-x 3 root root  0 Jul  9 19:32 freezer
    dr-xr-xr-x 3 root root  0 Jul  9 19:32 hugetlb
    dr-xr-xr-x 5 root root  0 Jul  9 19:32 memory
    lrwxrwxrwx 1 root root 16 Jul  9 19:32 net_cls -> net_cls,net_prio
    dr-xr-xr-x 3 root root  0 Jul  9 19:32 net_cls,net_prio
    lrwxrwxrwx 1 root root 16 Jul  9 19:32 net_prio -> net_cls,net_prio
    dr-xr-xr-x 3 root root  0 Jul  9 19:32 perf_event
    dr-xr-xr-x 5 root root  0 Jul  9 19:32 pids
    dr-xr-xr-x 5 root root  0 Jul  9 19:32 systemd
    

     这些目录代表了 Cgroups 的子系统,Docker 会在每一个 Cgroups 子系统下创建 docker 文件夹。这里如果你对 Cgroups 子系统不了解的话,不要着急,这里你只需要明白容器监控数据来源于 Cgroups 即可。

     

    监控系统是如何获取容器的内存限制的?


    下面我们以 memory 子系统(memory 子系统是Cgroups 众多子系统的一个,主要用来限制内存使用)为例,讲解一下监控组件是如何获取到容器的资源限制和使用状态的(即容器的内存限制)。

    我们首先在主机上使用以下命令启动一个资源限制为 1 核 2G 的 nginx 容器:

    $ docker run --name=nginx --cpus=1 -m=2g --name=nginx  -d nginx
    ## 这里输出的是容器 ID
    51041a74070e9260e82876974762b8c61c5ed0a51832d74fba6711175f89ede1
    

    注意:如果你已经创建过名称为 nginx 的容器,请先使用 docker  rm -f nginx 命令删除已经存在的 nginx 容器。

    容器启动后,我们通过命令行的输出可以得到容器的 ID,同时 Docker 会在/sys/fs/cgroup/memory/docker目录下以容器 ID 为名称创建对应的文件夹。

    下面我们查看一下/sys/fs/cgroup/memory/docker目录下的文件:

    $ sudo ls -l /sys/fs/cgroup/memory/docker
    total 0
    
    drwxr-xr-x 2 root root 0 Sep  2 15:12 51041a74070e9260e82876974762b8c61c5ed0a51832d74fba6711175f89ede1
    -rw-r--r-- 1 root root 0 Sep  2 14:57 cgroup.clone_children
    --w--w--w- 1 root root 0 Sep  2 14:57 cgroup.event_control
    -rw-r--r-- 1 root root 0 Sep  2 14:57 cgroup.procs
    -rw-r--r-- 1 root root 0 Sep  2 14:57 memory.failcnt
    --w------- 1 root root 0 Sep  2 14:57 memory.force_empty
    -rw-r--r-- 1 root root 0 Sep  2 14:57 memory.kmem.failcnt
    -rw-r--r-- 1 root root 0 Sep  2 14:57 memory.kmem.limit_in_bytes
    -rw-r--r-- 1 root root 0 Sep  2 14:57 memory.kmem.max_usage_in_bytes
    -r--r--r-- 1 root root 0 Sep  2 14:57 memory.kmem.slabinfo
    -rw-r--r-- 1 root root 0 Sep  2 14:57 memory.kmem.tcp.failcnt
    -rw-r--r-- 1 root root 0 Sep  2 14:57 memory.kmem.tcp.limit_in_bytes
    -rw-r--r-- 1 root root 0 Sep  2 14:57 memory.kmem.tcp.max_usage_in_bytes
    -r--r--r-- 1 root root 0 Sep  2 14:57 memory.kmem.tcp.usage_in_bytes
    -r--r--r-- 1 root root 0 Sep  2 14:57 memory.kmem.usage_in_bytes
    -rw-r--r-- 1 root root 0 Sep  2 14:57 memory.limit_in_bytes
    -rw-r--r-- 1 root root 0 Sep  2 14:57 memory.max_usage_in_bytes
    -rw-r--r-- 1 root root 0 Sep  2 14:57 memory.memsw.failcnt
    -rw-r--r-- 1 root root 0 Sep  2 14:57 memory.memsw.limit_in_bytes
    -rw-r--r-- 1 root root 0 Sep  2 14:57 memory.memsw.max_usage_in_bytes
    -r--r--r-- 1 root root 0 Sep  2 14:57 memory.memsw.usage_in_bytes
    -rw-r--r-- 1 root root 0 Sep  2 14:57 memory.move_charge_at_immigrate
    -r--r--r-- 1 root root 0 Sep  2 14:57 memory.numa_stat
    -rw-r--r-- 1 root root 0 Sep  2 14:57 memory.oom_control
    ---------- 1 root root 0 Sep  2 14:57 memory.pressure_level
    -rw-r--r-- 1 root root 0 Sep  2 14:57 memory.soft_limit_in_bytes
    -r--r--r-- 1 root root 0 Sep  2 14:57 memory.stat
    -rw-r--r-- 1 root root 0 Sep  2 14:57 memory.swappiness
    -r--r--r-- 1 root root 0 Sep  2 14:57 memory.usage_in_bytes
    -rw-r--r-- 1 root root 0 Sep  2 14:57 memory.use_hierarchy
    -rw-r--r-- 1 root root 0 Sep  2 14:57 notify_on_release
    -rw-r--r-- 1 root root 0 Sep  2 14:57 tasks

     可以看到 Docker 已经创建了以容器 ID 为名称的目录,我们再使用 ls 命令查看一下该目录的内容:

    $ sudo ls -l /sys/fs/cgroup/memory/docker/51041a74070e9260e82876974762b8c61c5ed0a51832d74fba6711175f89ede1
    
    total 0
    -rw-r--r-- 1 root root 0 Sep  2 15:21 cgroup.clone_children
    --w--w--w- 1 root root 0 Sep  2 15:13 cgroup.event_control
    -rw-r--r-- 1 root root 0 Sep  2 15:12 cgroup.procs
    -rw-r--r-- 1 root root 0 Sep  2 15:12 memory.failcnt
    --w------- 1 root root 0 Sep  2 15:21 memory.force_empty
    -rw-r--r-- 1 root root 0 Sep  2 15:21 memory.kmem.failcnt
    -rw-r--r-- 1 root root 0 Sep  2 15:12 memory.kmem.limit_in_bytes
    -rw-r--r-- 1 root root 0 Sep  2 15:21 memory.kmem.max_usage_in_bytes
    -r--r--r-- 1 root root 0 Sep  2 15:21 memory.kmem.slabinfo
    -rw-r--r-- 1 root root 0 Sep  2 15:21 memory.kmem.tcp.failcnt
    -rw-r--r-- 1 root root 0 Sep  2 15:21 memory.kmem.tcp.limit_in_bytes
    -rw-r--r-- 1 root root 0 Sep  2 15:21 memory.kmem.tcp.max_usage_in_bytes
    -r--r--r-- 1 root root 0 Sep  2 15:21 memory.kmem.tcp.usage_in_bytes
    -r--r--r-- 1 root root 0 Sep  2 15:21 memory.kmem.usage_in_bytes
    -rw-r--r-- 1 root root 0 Sep  2 15:12 memory.limit_in_bytes
    -rw-r--r-- 1 root root 0 Sep  2 15:12 memory.max_usage_in_bytes
    -rw-r--r-- 1 root root 0 Sep  2 15:21 memory.memsw.failcnt
    -rw-r--r-- 1 root root 0 Sep  2 15:12 memory.memsw.limit_in_bytes
    -rw-r--r-- 1 root root 0 Sep  2 15:21 memory.memsw.max_usage_in_bytes
    -r--r--r-- 1 root root 0 Sep  2 15:21 memory.memsw.usage_in_bytes
    -rw-r--r-- 1 root root 0 Sep  2 15:21 memory.move_charge_at_immigrate
    -r--r--r-- 1 root root 0 Sep  2 15:21 memory.numa_stat
    -rw-r--r-- 1 root root 0 Sep  2 15:13 memory.oom_control
    ---------- 1 root root 0 Sep  2 15:21 memory.pressure_level
    -rw-r--r-- 1 root root 0 Sep  2 15:21 memory.soft_limit_in_bytes
    -r--r--r-- 1 root root 0 Sep  2 15:21 memory.stat
    -rw-r--r-- 1 root root 0 Sep  2 15:21 memory.swappiness
    -r--r--r-- 1 root root 0 Sep  2 15:12 memory.usage_in_bytes
    -rw-r--r-- 1 root root 0 Sep  2 15:21 memory.use_hierarchy
    -rw-r--r-- 1 root root 0 Sep  2 15:21 notify_on_release
    -rw-r--r-- 1 root root 0 Sep  2 15:21 tasks

    由上可以看到,容器 ID 的目录下有很多文件,其中 memory.limit_in_bytes 文件代表该容器内存限制大小,单位为 byte,我们使用 cat 命令(cat 命令可以查看文件内容)查看一下文件内容:

    $ sudo cat /sys/fs/cgroup/memory/docker/51041a74070e9260e82876974762b8c61c5ed0a51832d74fba6711175f89ede1/memory.limit_in_bytes
    2147483648
    

    这里可以看到memory.limit_in_bytes 的值为2147483648,转换单位后正好为 2G,符合我们启动容器时的内存限制 2G。

    通过 memory 子系统的例子,我们可以知道监控组件通过读取 memory.limit_in_bytes 文件即可获取到容器内存的限制值。了解完容器的内存限制我们来了解一下容器的内存使用情况。

    $ sudo /sys/fs/cgroup/memory/docker/51041a74070e9260e82876974762b8c61c5ed0a51832d74fba6711175f89ede1/memory.usage_in_bytes
    4259840
    

    可以看到当前内存的使用大小为 4259840 byte,约为 4 M。了解了内存的监控。

     

    下面我们来了解下网络的监控数据来源


    网络的监控数据来源是从 /proc/{PID}/net/dev 目录下读取的,其中 PID 为容器在主机上的进程 ID。下面我们首先使用 docker inspect 命令查看一下上面启动的 nginx 容器的 PID,命令如下:

    $ docker inspect nginx |grep Pid
    
                "Pid": 27348,
    
                "PidMode": "",
    
                "PidsLimit": 0,
    

    可以看到容器的 PID 为 27348,使用 cat 命令查看一下 /proc/27348/net/dev 的内容

    $ sudo cat /proc/27348/net/dev
    Inter-|   Receive                                                |  Transmit
    face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
    
        lo:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
    
      eth0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
    

    /proc/27348/net/dev 文件记录了该容器里每一个网卡的流量接收和发送情况,以及错误数、丢包数等信息。可见容器的网络监控数据都是定时从这里读取并展示的。

    总结一下,容器的监控原理其实就是定时读取 Linux 主机上相关的文件并展示给用户。

     

    结语


    k8s后面使用metrics serve,cAdvisor 是提供底层数据的,metrics-server 底层数据来源是 cAdvisor

     cAdvisor 是提供监控数据的,Prometheus 是负责采集的数据的,这两个作用是不一样的,生产集群中一般都是 cAdvisor 配合 Prometheus 一起使用

    展开全文
  • docker容器监控的实现

    千次阅读 2019-09-14 14:44:00
    本文写于2015年,所有PAAS平台相关内容都已经在2015Q3完成,当时使用的docker版本为1.6.2,虽然docker新版本发布很快,但是...一、 docker容器有哪些指标需要监控容器CPU、内存、IO、网络、应用存活 ...
  • 目录 监控逻辑图 镜像准备 运行镜像文件 启动node-exporter ...docker pull google/cadvisor # 监控主机容器信息的镜像 docker pull prom/prometheus # 收集主机信息的镜像 docker pull grafana...
  • 一、介绍 描述:本人在docker容器中运行Tensorflow实验,为了统计Tensorflow训练过程中容器内部的资源使用情况,查阅不少资料。发现当下网上具体介绍docker容器内部资源统计的...容器监控的维度与监控命令 容器监...
  • 监控系统概述 cAdvisor (Container Advisor) :用于收集正在运行的容器资源使用和性能信息。https://github.com/google/cadvisor 为了解决docker stats的问题(存储、展示),谷歌开源的cadvisor诞生了,cadvisor...
  • 我们平时对宿主机中的容器进行监控只能执行docker自带的几个监控子命令:ps, top 和 stats,虽然是足够我们平常的容器监控。 但是对于普通的程序员来说,是不能这么随便或者是直接进入到生产的宿主机进行命令的执行...
  • Prometheus容器监控指标详解

    千次阅读 2019-08-16 21:30:49
    CPU使用率 ...注:container_cpu_usage_seconds_total得到的并不是容器的CPU使用率,待我们一层层分析。 第一步: http://10.4.**.***:31263/api/v1/query?query=container_cpu_usage_seconds_t...
  • 容器管理与容器监控-容器管理工具Rancher-Rancher安装什么是RancherRancher安装(1)下载Rancher 镜像(2)创建Rancher容器(3)浏览器访问(4)切换至中文界面 什么是Rancher ​ Rancher是一个开源的企业级全栈化...
  • 容器监控数据采集.pdf

    2021-10-11 10:42:52
    容器监控数据采集.pdf
  • Prometheus容器监控架构.docx
  • 模板下载地址https://grafana.com/grafana/dashboards,里面有很多模板下载 下载模板https://grafana.com/grafana/dashboards/11074 登录grafana,点击+,选择import ... ... 监控效果如下图 . ...
  • 受启发的容器监视Web UI。 获取间谍 要求 Python 2.7或更高版本 点子 安装 pip install -r requirements.txt 跑步 在运行容器的主机上: ./spyhop.py 然后将浏览器指向: localhost:5000 特征 列出主机上运行的...
  • 容器监控工具WeaveScope

    2020-02-26 15:00:17
    最近一段时间整了一些docker容器,弄了一些基于...这里就介绍下我最近用的容器监控工具WeaveScope。这个工具不仅可以 有基础性能的数据监控,同时还可以在线cli的操作,除了Docker外,这个工具还可以监控Kubernet...
  • openfalcon 容器监控

    2018-08-06 20:09:25
    [root@controller1 uploadCadviosrData]# ls cadvisor log nohup.out run test.txt uploadCadvisorData   cadvisor run uploadCadvisorData 主要组件有3个,原组件的cadvisor 的版本过低   ...
  • 目前Docker的使用越来越离不开对容器监控,阿里云最近上线了容器服务,不但提供了核心的容器和宿主机监控能力,而且支持集成 Cloud Insight 监控,下面会介绍如何集成。
  • dkrmon是一个简单的GUI,用于跨多个独立主机监视和管理Docker容器。 dkrmon由服务器和代理元素组成,它们被设计为可作为容器运行,从而使部署变得快速而容易。 安装 服务器 以下是服务器Docker Compose定义的示例: ...
  • prometheus docker 容器监控 k8s kubernetes 好东西 岗岗的
  • 容器管理与容器监控-Grafana-Grafana的使用-预警通知设置预警通知设置 预警通知设置 (1)选择菜单 alerting–> Notification channels (2)点击Add channel 按钮 (3)填写名称,选择类型为webhook ,填写钩子...
  • 容器监控之cadvisor介绍

    千次阅读 2020-08-05 09:17:52
    docker stats 对 cadvisor ... 由于 dokcer stats 有这些... cadvisor 不仅可以搜集一台机器上所有运行的容器信息还提供基础查询界面和 http 接口,方便 Prometheus 进行数据抓取。 正是因为 cadvisor 与 Prometheus
  • 解惑|你是否为容器监控操碎了心?

    千次阅读 2017-07-11 17:16:55
    本次分享邀请数人云运维总监庞铮,本文将从以下几个方面聊聊容器监控的相关思考: 容器监控面临问题-容器设计及运营复杂性的挑战; 容器的三种监控收集指标; 容器性能监控能力把控及报警调查。 容器监控的问题为...
  • docker容器监控(cAdvisor+InfluxDB+Grafana)

    千次阅读 2018-11-08 14:17:08
    对于一个物理机上运行多个容器应用时,容器的运行情况如:CPU使用率、内存使用率、网络状态、磁盘空间等信息,都是需要去了解的,因此监控是必须的。对于容器监控方案可谓多种多样,本身自带命令docker stats。 ...
  • cadvisor是一个谷歌开发的容器监控工具,它被内嵌到k8s中作为k8s的监控组件。默认情况下没有授权验证措施。攻击者可以直接未授权访问cAdvisor容器监控面板,获取相应Docker敏感信息。 开启cAdvisor的认证跟开启...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 154,889
精华内容 61,955
关键字:

容器监控