cadvisor

Docker监控——Cadvisor+InfluxDB+Grafana搭建过程

不羁岁月 提交于 2020-04-18 00:36:58
Docker监控——Cadvisor+InfluxDB+Grafana搭建过程 1)、InfluxDB安装与配置: InfluxDB的0.8.8或是0.9.6版本,安装都是通过rpm直接安装,区别只是 数据库的“表”不一样 而已,所以会 影响到Grafana过滤数据 ,这些不是重点,重点是 Grafana数据的清理 。 (1)、InfluxDB安装: wget https://repos.influxdata.com/centos/6/x86_64/stable/influxdb-0.9.6-1.x86_64.rpm rpm -vih influxdb-0.9.6-1.x86_64.rpm vi /etc/influxdb/influxdb.conf hostname = "192.168.16.234" /etc/init.d/influxdb start Web页面: http://192.168.16.234:8083/ (2)、InfluxDB配置: 此步,需要配置 提供Cadvisor写入数据 的 InfluxDB库 ,和 提供grafana访问 的 用户名和密码 InfluxDB可以通过 web界面 或是 influx命令行 ,进行操作。 数据库: cadvisor 用户名: root 密码: root [root @localhost ]# influx >

K8S 监控告警原生演进

旧街凉风 提交于 2020-04-10 16:24:06
公司在虚拟机时代已有一套完善而强大的监控告警系统:agent 支持采集丰富的监控指标、监控日志的错误字段和进程存活并发送告警,后端提供强大的聚合方式和灵活的告警配置,前端具备强大的可视化能力。在如此优秀的监控告警系统映衬下,一切开源的方案都显得如此苍白无力,所以毫无疑问将该 agent 稍微改造即塞到胖容器中。该方案很好的适配已有的监控告警体系,但是不利于 agent 的升级维护,也不符合原生的玩法,所以对监控进行一些改造,本文主要谈谈相关经验,即 K8S 如何在原生玩法下对接已有的监控告警系统。 指标 首先讨论 PaaS 平台需要采集哪些指标,这些指标可以分为容器指标和宿主机指标两个层面。无论是宿主机还是容器,如下是常用的监控指标: CPU:usr, sys, iowait, irq, softirq, load GPU:显卡使用量,显存使用量 内存:主要为内存的真实使用 网络:网卡出入带宽,网卡出入包速率,丢包率等 磁盘:读写 iops,读写带宽,ioutil,磁盘使用率等 上下文切换数 容器监控指标 CAdvisor 内置于 Kubelet 中,默认采集该节点所有容器的一些监控指标。其中容器的 cpu 通过容器中 /sys/fs/cgroup/cpu 相关文件所得,内存指标通过容器中 /sys/fs/cgroup/memory/ 相关文件获取,磁盘指标源自 /sys/fs

Kubernetes Node全解

南笙酒味 提交于 2020-04-06 20:56:18
今晚20:30,Kubernetes Master Class在线培训第四期《企业如何构建CI/CD流水线》即将开播,点击链接: http://live.vhall.com/729465809 即可免费预约注册! 介 绍 Kubernetes在GitHub上拥有超过48,000颗星,超过75,000个commit,拥有以Google为代表的科技巨头公司为主要贡献者。可以说,Kubernetes已迅速掌管了容器生态系统,成为容器编排平台的真正领导者。 Kubernetes提供了诸如部署的滚动和回滚、容器健康检查、自动容器恢复、基于指标的容器自动扩展、服务负载均衡、服务发现(适用于微服务架构)等强大功能。在本文中,我们将讨论Kubernetes重要的基本概念、master节点架构,并重点关注节点组件。 理解Kubernetes及其抽象 Kubernetes是一个开源的编排引擎,用于自动部署、扩展、管理和提供托管容器化应用程序的基础架构。在基础架构级别,Kubernetes集群由一组物理或虚拟机组成,每个机器都以特定角色运行。 Master机器就像是所有业务的大脑,负责编排所有运行在节点机器上的容器。每个节点都配有一个容器运行时。节点接收来自master的指令,然后执行操作来创建pod、删除pod或调整网络规则。 Master组件负责管理Kubernetes集群。它们管理pod的生命周期

k8s中部署prometheus常用exporter

ε祈祈猫儿з 提交于 2020-04-06 14:59:21
部署kube-state-metrics, kube-state-metrics用来获取k8s集群所有资源的状态: 准备镜像: [root@hdss7-200 ~]# docker pull quay.io/coreos/kube-state-metrics:v1.5.0 v1.5.0: Pulling from coreos/kube-state-metrics cd784148e348: Pull complete f622528a393e: Pull complete Digest: sha256:b7a3143bd1eb7130759c9259073b9f239d0eeda09f5210f1cd31f1a530599ea1 Status: Downloaded newer image for quay.io/coreos/kube-state-metrics:v1.5.0 quay.io/coreos/kube-state-metrics:v1.5.0 [root@hdss7-200 ~]# docker images|grep kube-state-metrics quay.io/coreos/kube-state-metrics v1.5.0 91599517197a 15 months ago 31.8MB [root@hdss7-200 ~]# docker tag

Elasticsearch+Fluentd+Kafka搭建日志系统

爱⌒轻易说出口 提交于 2020-02-28 05:10:10
前言 由于logstash内存占用较大,灵活性相对没那么好,ELK正在被EFK逐步替代.其中本文所讲的EFK是Elasticsearch+Fluentd+Kfka,实际上K应该是Kibana用于日志的展示,这一块不做演示,本文只讲述数据的采集流程. 前提 docker docker-compose apache kafka服务 架构 数据采集流程 数据的产生使用cadvisor采集容器的监控数据并将数据传输到Kafka. 数据的传输链路是这样: Cadvisor->Kafka->Fluentd->elasticsearch 每一个服务都可以横向扩展,添加服务到日志系统中. 配置文件 docker-compose.yml version: "3.7" services: elasticsearch: image: elasticsearch:7.5.1 environment: - discovery.type=single-node #使用单机模式启动 ports: - 9200:9200 cadvisor: image: google/cadvisor command: -storage_driver=kafka -storage_driver_kafka_broker_list=192.168.1.60:9092(kafka服务IP:PORT) -storage_driver

部署docker swarm集群监控

依然范特西╮ 提交于 2020-02-27 08:44:09
前提 Docker 前言 现在Docker Swarm已经彻底输给了K8S,但是现在K8S依然很复杂,上手难度较Docker Swarm高,如果是小规模团队且需要容器编排的话,使用Docker Swarm还是适合的。 目前Docker Swarm有一个问题一直没有解决,如果业务需要知道用户的请求IP,则Docker Swarm满足不了要求。目前部署在Docker Swarm内的服务,无法获取到用户的请求IP。 具体可以看看这个ISSUE-> Unable to retrieve user's IP address in docker swarm mode 整体思路 思路整体来说是使用Influxdb+Grafana+cadvisor,其中 cadvisor 负责数据的收集,每一台节点都部署一个cadvisor服务,Influxdb负责数据的存储,Grafana负责数据的可视化。 演示环境 主机 IP master(manager) 192.168.1.60 node1(worker) 192.168.1.61 node2(worker) 192.168.1.62 我这里是将master节点当作监控数据存储以及可视化服务的节点作为演示,一般是拿一个worker节点做这样的工作。 初始化Docker Swarm 在master机器上初始化集群,运行 docker swarm init

部署docker swarm集群监控

不想你离开。 提交于 2020-02-12 02:04:22
前提 Docker 前言 现在Docker Swarm已经彻底输给了K8S,但是现在K8S依然很复杂,上手难度较Docker Swarm高,如果是小规模团队且需要容器编排的话,使用Docker Swarm还是适合的。 目前Docker Swarm有一个问题一直没有解决,如果业务需要知道用户的请求IP,则Docker Swarm满足不了要求。目前部署在Docker Swarm内的服务,无法获取到用户的请求IP。 具体可以看看这个ISSUE-> Unable to retrieve user's IP address in docker swarm mode 整体思路 思路整体来说是使用Influxdb Grafana cadvisor,其中cadvisor负责数据的收集,每一台节点都部署一个cadvisor服务,Influxdb负责数据的存储,Grafana负责数据的可视化。 演示环境 主机 IP master(manager) 192.168.1.60 node1(worker) 192.168.1.61 node2(worker) 192.168.1.62 我这里是将master节点当作监控数据存储以及可视化服务的节点作为演示,一般是拿一个worker节点做这样的工作。 初始化Docker Swarm 在master机器上初始化集群,运行 docker swarm init -

docker监控: cAdvisor

与世无争的帅哥 提交于 2020-02-06 16:32:01
docker监控: cAdvisor 什么是 cAdvisor? cAdvisor 是 Google 开源的一款用于展示和分析容器运行状态的可视化工具,通过在主机上运行 cAdvisor 用户可以轻松的获取到当前主机上容器的运行统计信息,并以图表的形式向用户展示. 使用 cAdvisor 想运行在这个很简单,只需要执行如下命令即可 docker run \ --volume=/:/rootfs:ro \ --volume=/var/run:/var/run:rw \ --volume=/sys:/sys:ro \ --volume=/var/lib/docker/:/var/lib/docker:ro \ --publish=8080:8080 \ --detach=true \ --name=cadvisor \ google/cadvisor:latest 我们通过访问 http://localhost:8080 就可以查看当前主机上容器的运行状态, 使用技巧 cAdvisor 是一个简单易用的工具,相比于使用 docker status 命令相比,我们不需要登录到服务器上即可以以可视化图表的形式查看主机上所有容器的运行状态. 但是如果我们有多个容器宿主机的话,我们不可能登录到每台机器的 web 界面去查看,这样未免太傻了点,cAdvisor 早已经想到这一点

InfluxDB+cAdvisor+Grafana容器管理

强颜欢笑 提交于 2020-02-06 15:24:52
InfluxDB InfluxDB是一个分布式时间序列数据库。cAdvisor仅仅显示实时信息,但是不存储监视数据。因此,需要提供实时数据库用于存储cAdvisor组件所提供的监控信息,以便显示除实时信息之外的时序数据。 1.InfluxDB的安装 下载镜像 docker pull tutum/influxdb 创建容器 docker run -di \ -p 8083:8083 \ -p 8086:8086 \ --expose 8099 \ --expose 8099 \ --name influxsrv \ tutum/influxdb 上面,8083端口是web访问端口,8086是数据写入端口。 安装好,浏览器访问192.xxx.xx.xxx:8083 2.使用influxDB 通过query templates下拉选项可以快速使用命令语句。 创建数据库 CREATE DATABASE "cadvisor" 查看所有数据库 SHOW DATABASES 创建用户 CREATE USER "zhangsan" WITH PASSWORD 'password' WITH ALL PRIVILEGES 查看用户 SHOW USERS 用户授权 grant all privileges on cadvisor to zhangsan grant write on cadvisor

cAdvisor prometheus integration returns container_cpu_load_average_10s as 0

耗尽温柔 提交于 2020-01-04 14:12:24
问题 I have configured Prometheus to scrape metrics from cAdvisor. However, the metric "container_cpu_load_average_10s" only returns 0. I am able to see the CPU metrics under the cAdvisor web UI correctly but Prometheus receives only 0. It is working fine for other metrics like "container_cpu_system_seconds_total". Could someone point if I am missing something here? Prometheus version: 2.1.0 Prometheus config: scrape_configs: - job_name: cadvisor scrape_interval: 5s metrics_path: /metrics scheme: