>

进级指南,质量测验

- 编辑:金沙国际平台登录 -

进级指南,质量测验

基于Python结合InfluxDB及Grafana图表实时采集Linux多主机性能数据

过去的一年中,关于 Docker 的话题从未断过,而如今,从尝试 Docker 到最终决定使用 Docker 的转化率依然在逐步升高,关于 Docker 的讨论更是有增无减。另一方面,大家的注意力也渐渐从 “Docker 是什么”转移到“实践 Docker”与“监控 Docker”上。

by:授客 QQ:1033553122

本文转自刘斌博文「如何选择 Docker 监控方案 」,文中刘斌从技术的角度深入解释了 Docker 监控的数据采集原理,介绍了现有开源的监控方案,以及能够对 Docker 进行监控功能的主流 SaaS 服务工具。

实现功能

斌哥是谁?

刘斌,拥有 10 多年编程经验,曾参与翻译过「第一本 Docker 书」、「GitHub 入门与实践」、「Web 应用安全权威指南」等多本技术书籍,主讲过「Docker入门与实践 」课程的 Cloud Insight 后台工程师。

测试环境

为什么监控,监控什么内容?

作为一名工程师,我们要对自己系统的运行状态了如指掌,有问题及时发现,而不是让用户先发现系统不能使用,打电话找客服,再反映到开发。这个过程很长,而且对工程师来说,是一件比较没面子的事情。

当领导问我们这个月的 MySQL 并发什么情况?slowsql 处于什么水平,平均响应时间超过 200ms 的占比有百分之多少的时候,回答不出来这个问题很尴尬。尽管你工作很辛苦,但是却没有拿得出来的成果。不能因为暂时没出问题就掉以轻心,换位想想,站在领导的角度,领导什么都不干,你提案,他签字,出了谁背锅?

监控目的

  1. 减少宕机时间

  2. 扩展和性能管理

  3. 资源计划

  4. 识别异常事件

  5. 故障排除、分析

为什么需要监控我们的服务?其中有一些显而易见的原因,比如需要监控工具来提醒服务故障,比如通过监控服务的负载来决定扩容或缩容。如果机器普遍负载不高,则可以考虑缩减一下机器规模,如果数据库连接经常维持在一个高位水平,则可以考虑一下是否可以进行拆库处理,优化一下架构。

环境搭建

Docker监控面临的挑战

  • Docker特点

    • 像host但不是host
    • 量大
    • 生命周期短 监控盲点(断层)
  • 微服务 集群

  • 全方位

    • Host(VM) + Services + Containers + Apps

容器为我们的开发和运维带来了更多的方向和可能性,我们也需要一种现代的监控方案来应对这种变化。

随着不可变基础设施概念的普及,云原生应用的兴起,云计算组件已经越来越像搭建玩具的积木块。很多基础设施生命周期变短,不光容器如此,云主机、VM也是。

在云计算出现之前,一台机器可能使用3、5年甚至更长都不需要重装,主机名也不会变,而现在,可能升级一个版本,就要重建一个云主机或重新启动一个容器。监控对象动态变化,而且非常频繁。即使全部实现自动化,也会在负载和复杂度方面带来不利影响。

监控还有助于进行内部统制,尤其是对安全比较敏感的行业,比如证券、银行等。比如服务器受到攻击时,我们需要分析事件,找到根本原因,识别类似攻击,发现未知的被攻击系统,甚至完成取证等工作。

集群的出现,使应用的拓扑结构也变得复杂,不同应用的指标和日志格式也不统一,再加上要考虑应对多租户的问题,这些都给监控带来了新挑战。

传统的监控内包括对主机、网络和应用的监控,但是Docker出现之后,容器这一层很容易被忽略,成为三不管地区,即监控的盲点。

有人说,容器不就是个普通的OS么?装个Zabbix的探针不就行了么?Docker host和Docker 容器都要装 Zabbix探针……其实问题很多。

除了容器内部看到的cpu内存情况不准之外,而且容器生命周期短,重启之后host名,ip地址都会变,所以最好在Docker host上安装Zabbix agent。

如果每个容器都像OS那样监控,则metric数量将会非常巨大,而且这些数据很可能几分钟之后就无效率了(容器已经停止)。容器生命周期短暂,一旦容器结束运行,之前收集的数据将不再有任何意义。

主要的解决方式就是以App或者Service为单位进行监控(通过Tag等方式)。

使用前提

Docker 监控技术基础

  • docker stats

  • Remote API

  • 伪文件系统

我们可以通过 docker stats 命令或者Remote API以及Linux的伪文件系统来获取容器的性能指标。

使用API的话需要注意一下,那就是不要给Docker daemon带来性能负担。如果你一台主机有200个容器,如果非常频繁的采集系统性能可能会大量占据CPU时间。

最好的方式应该就是使用伪文件系统。如果你只是想通过shell来采集性能数据,则 docker stats 可能是最简单的方式了。

docker stats 命令

图片 1

该命令默认以流式方式输出,如果想打印出最新的数据并立即退出,可以使用 no-stream=true 参数。

  • 伪文件系统
  • CPU、内存、磁盘
  • 网络

文件位置大概在(跟系统有关,这是 Systemd 的例子):

图片 2

Docker各个版本对这三种方式的支持程度不同,取得metric的方式和详细程度也不同,其中网络metric是在1.6.1之后才能从伪文件系统得到。

Memory

内存的很多性能指标都来自于 memory.stat 文件:

图片 3

前面的不带total的指标,表示的是该cgroup中的process所使用的、不包括子cgroup在内的内存量,而total开头的指标则包含了这些进程使用的包括子cgroup数据。这里我们看到的数据都是一样的,由于这里并没有子cgroup。

两个比较重要的指标:

  • RSS: resident set size

进程的所有数据堆、栈和memory map等。rss可以进一步分类为active和inactive(activeanon and inactiveanon)。在内存不够需要swap一部分到磁盘的时候,会选择inactive 的rss进行swap 。

  • cache memory

缓存到内存中的硬盘文件的大小。比如你读写文件的时候,或者使用mapped file的时候,这个内存都会增加。这类内存也可以再细分为active和inactive的cache,即activefile和inactivefile。如果系统需要更多内存,则inactive的cache会被优先重用。

CPU

  • cpuacct.stat文件
  • docker.cpu.system
  • docker.cpu.user

但是比较遗憾,Docker 不会报告nice,idle和iowait等事件。

System也叫kernel时间,主要是系统调用所耗费的部分,而user则指自己程序的耗费CPU,如果User时间高,则需要好好检查下自己的程序是否有问题,可能需要进行优化。

Blkio

优先从CFQ(Completely Fair Queuing 完全公平的排队)拿数据,拿不到从这两个文件拿: · blkio.throttle.ioservicebytes,读写字节数 · blkio.throttle.io_serviced,读写次数

Throttle这个单纯可能有误导,实际这些都不是限制值,而是实际值。每个文件的第一个字段是 major:minor 这样格式的device ID。

网络数据

  • iptables
  • 伪文件系统
  • 网络设备接口
  • Virtual Ethernet

针网络的监控要精确到接口级别,即网卡级别。每个容器在host上都有一个对应的virtual Ethernet,我们可以从这个设备获得tx和rx信息。

不过找到容器在主机上对应的虚拟网卡比较麻烦。这时候可以在宿主机上通过 ip netns 命令从容器内部取得网络数据。

为了在容器所在网络命名空间中执行 ip netns 命令,我们首先需要找到这个容器进程的PID。

图片 4

或者:

图片 5

实际上Docker的实现也是从伪文件系统中读取网络metric的:

图片 6

以上,是不是意犹未尽呢? 下一部分,斌哥将为大家介绍: 《Docker 监控方案的实现》

超好用的监控软件 Cloud Insight 不仅能监控 Docker,还能对 Nagios 进行更好的可视化哦~

阅读更多技术文章,请访问 OneAPM 官方博客。
本文转自 OneAPM 官方博客

使用方法

运行程序

效果展示

实现功能

无需在被监控主机上安装代理,一键对Linux远程服务器不同主机执行性能监控、性能数据采集命令,并实时展示

支持跨堡垒机收集实时性能数据(注:定制化开发,非通用)

支持docker容器(因为程序实现是从docker容器内部获取性能数据,所以目前仅支持 CPU,内存,I/O)

使用前提

可以用Xshell等工具远程连接Linux主机

Linux主机支持sar命令

dokcer容器内部挂载了docker容器自身的cgroup系统

注:目前不支持嵌套cgroup下子cgroup的性能数据监控

测试环境

Win7 64位

Python 3.4.0

CentOS 6 64位(内核版本2.6.32-642.el6.x86_64)

influxdb-1.5.2.x86_64.rpm

网盘下载地址:

grafana-5.1.2-1.x86_64.rpm

下载地址:

下载地址:

influxdb-5.0.0-py2.py3-none-any.whl

下载地址:

下载地址:

paramiko 1.15.2

下载地址:

cryptography-1.0-cp34-none-win_amd64.whl

(如果paramiko可以正常安装完,则不需要安装该类库)

下载地址:

安装好后,找到nt.py(本例中路径为:

Libsite-packagespycrypto-2.6.1-py3.4-win-amd64.eggCryptoRandomOSRNGnt.py),修改

import winrandom

from Crypto.Random.OSRNG import winrandom

如下

#import winrandom

from Crypto.Random.OSRNG import winrandom

以解决ImportError: No module named 'winrandom'错误

说明:具体文件路径可能还得根据实际报错情况来确定,如下

............

"D:Program Filespython33libsite-packagesCryptoRandomOSRNGnt.py", line 28, in <module>

import winrandom

ImportError: No module named 'winrandom'

VS2010

因操作系统而异,可能需要安装VS2010,以解决包依赖问题

图片 7

环境搭建

参考CentOS下结合InfluxDB及Grafananux图表实时展示JMeter相关性能数据

使用方法

influxDB主机配置

monitorconfinfluxDB.conf

[INFLUXDB]

influxdb_host = 10.203.25.106

influxdb_port = 8086

主机登录信息配置

(用于远程ssh登录)

monitorconfhost_config.conf

[10.203.36.1]

host = 10.203.36.1

username = xxxx

password = xxxx

port = 22

remark = 鉴权微服务

[10.203.36.33]

host = 10.203.36.33

username = xxxx

password = xxxx

port = 22

remark = 发货微服务

[10.202.27.5]

host = 10.202.27.5

username = xxxx

password = xxxx

port = 22

remark = 堡垒机

[10.202.27.6]

host = 10.202.27.6

username = xxxx

password = xxxx

port = 22

remark = 堡垒机

说明:

[需要监控的Linux服务器IP]

host = 需要监控的Linux服务器IP

username = 远程登录用户名

password = 用户密码

port = 22

remark = 补充说明

堡垒机-目标机配置

bastion_host_config.conf

[10.202.27.5]

ip1 = 10.203.33.18

ip2 = 10.203.33.19

ip3 = 10.203.33.20

[10.202.27.6]

ip4 = 10.203.33.21

ip5 = 10.203.32.49

ip6 = 10.203.33.4

说明:

[堡垒机ip]

自定义名称 = 需要通过堡垒机访问的目标ip

注意:不同堡垒机节点下的目标ip不能重复

堡垒机连接目标机,账号密码,登录用户选取等信息配置

monitorconfaccount.conf

[ACCOUNT]

user_id = 01367522

pwd = xxx

login_user_choice = 1

dokcer容器cpu, cpuacct,memory,blkio系统路径配置

[CGROUPPATH]

cpu_path=/sys/fs/cgroup/cpu

cpuacct_path=/sys/fs/cgroup/cpuacct

memory_path=/sys/fs/cgroup/memory

blkio_path=/sys/fs/cgroup/blkio/

#cpu_path=/cgroup/cpu/docker/docker/$CONTAINERID

#cpuacct_path=/cgroup/cpuacct/docker/docker/$CONTAINERID

#memory_path=/cgroup/memory/docker/docker/$CONTAINERID

#blkio_path=/cgroup/blkio/docker/docker/$CONTAINERID

#cpu_path=/cgroup/cpu/docker/d74ac2610ed325498767bc708197148d414bf6a7719f15c013dc2b6460690dd8

#cpuacct_path=/cgroup/cpuacct/docker/d74ac2610ed325498767bc708197148d414bf6a7719f15c013dc2b6460690dd8

#memory_path=/cgroup/memory/docker/d74ac2610ed325498767bc708197148d414bf6a7719f15c013dc2b6460690dd8

#blkio_path=/cgroup/blkio/docker/d74ac2610ed325498767bc708197148d414bf6a7719f15c013dc2b6460690dd8

说明:

系统路径支持简单的参数化,目前仅支持容器ID(大写的$CONTAINERID),如上

一次仅支持一组配置

配置单台目标机器上不要采集的性能指标维度

monitorconfhost_filter.conf

[HOSTFILTER]

10.203.36.1= onecpu,disk

#10.203.36.33=

10.203.36.4=

[HOSTFILTER]

待监控目标ip = 指标维度1, 指标维度2, 维度之间用逗号分隔

维度说明:

onecpu不采集单个cpu的性能数据信息

queue不采集系统负载队列长度和负载均值性能数据信息

proc不采集任务创建和系统上下文切换信息

mem 不采集内存性能数据信息

swap 不采集swap交换统计信息

swapspace 不采集swap空间使用率信息

deviotps 不采集磁盘设备I/O性能数据信息

netdev 不采集网络设备的性能数据信息

enetdev 不采集网络设备的出错数据信息

disk 不采集单个磁盘的性能数据信息

paging 不采集分页信息

如果不需要过滤,可不配置,或者如上 设置ip等于空,或者用 #注释

待监控主机配置

monitorconftarget_host_for_monitor.conf

# #代表注释

10.203.36.1

10.203.36.33

# 堡垒机

10.202.27.5

# 需要通过堡垒机访问的目标ip

ip1 = 10.203.33.18

注意:

1、每一行代表需要监控的ip

如果ip不需要通过堡垒机访问,那么这个ip必须在monitorconfhost_config.conf有对应的配置才会被监控,不想监控则注释;

如果ip需要通过堡垒机访问,那么这个ip必须在 monitorconfbastion_host_config.conf 下有对应的配置,且这里必须配置对应堡垒机IP,才会被监控

运行程序

数据收集:

python main.py

或者

python main.py 2 20

python main.py 2 10+45+10

python main.py 2 ’10 + 45 + 10’

python main.py 2 20 onecpu netdev enetdev diskpaging

python main.py 采集频率 采集时间 不监控维度

说明:为了方便,采集时间可以写成加减运算表达式,省去“心算”,方便算术能力不好的人,比如我~~

如果需要设置不监控维度(每个维度之间用逗号相隔,目前仅支持以下维度),则一定要“显示”的指定采集频率和采集时间

onecpu不采集单个cpu的性能数据信息

queue不采集系统负载队列长度和负载均值性能数据信息

proc不采集任务创建和系统上下文切换信息

mem 不采集内存性能数据信息

swap 不采集swap交换统计信息

swapspace 不采集swap空间使用率信息

deviotps 不采集磁盘设备I/O性能数据信息

netdev 不采集网络设备的性能数据信息

enetdev 不采集网络设备的出错数据信息

disk 不采集单个磁盘的性能数据信息

paging 不采集分页信息

注意:

1、这里的维度过滤是针对所有待监控目标机的,针对单台机器的过滤项是在这个基础上做的进一步过滤

2、如果逻辑CPU个数,磁盘设备,网卡设备过多的情况下,如果不过滤对应指标,可能会因为采集的数据量过大,解析耗时加长,无法及时显示所要的数据(特别是CPU,单台机器有几十个逻辑CPU的情况下,延迟会很严重)。

实践测试记录:公司服务器,1秒钟采集一次,采集1个小时,统一加过滤项,如下方式运行

python main.py 1 3600 onecpu netdev enetdev paging

44台机器同时采集(总的会开启88个线程),可以做到实时显示

3、docker容器监控,不支持维度过滤,即IO,CPU,内存要么监控,要么不监控

数据清理:

python dropDB.py

根据提示,可删除单个数据库,或者一次性删除所有数据库的数据

效果展示

图片 8

图片 9

下载地址:

本文由编程发布,转载请注明来源:进级指南,质量测验