标签 监控 下的文章

从系统管理员接手服务器和主机管理以来,像应用监控这样的工具就成了他们的好帮手。其中比较有名的有 NagiosZabbixIcinga 和 Centreon。以上这些是重量级的监控工具,让一个新手管理员来设置,并使用其中的高级特性是有些困难的。

本文将向你介绍 Ganglia,它是一个易于扩展的监控系统。使用它可以实时查看 Linux 服务器和集群(图形化展示)中的各项性能指标。

Ganglia 能够让你以集群(按服务器组)和网格(按地理位置)的方式更好地组织服务器。

这样,我们可以创建一个包含所有远程主机的网格,然后将那些机器按照其它标准分组成小的集合。

此外, Ganglia 的 web 页面对移动设备进行过优化,也允许你导出 csv.json 格式的数据。

我们的测试环境包括一个安装 Ganglia 的主节点服务器 CentOS 7 (IP 地址 192.168.0.29),和一个作为被监控端的 Ubuntu 14.04 主机(192.168.0.32)。我们将通过 Ganglia 的 Web 页面来监控这台 Ubuntu 主机。

下面的例子可以给大家提供参考,CentOS7 作为主节点,Ubuntu 作为被监控对象。

安装和配置 Ganglia

请遵循以下步骤,在主节点服务器安装监控工具。

1、 启用 EPEL 仓库 ,然后安装 Ganglia 和相关工具:

# yum update && yum install epel-release
# yum install ganglia rrdtool ganglia-gmetad ganglia-gmond ganglia-web

在上面这步随 Ganglia 将安装一些应用,它们的功能如下:

  • rrdtool,Round-Robin 数据库,它是一个储存并图形化显示随着时间变化的数据的工具;
  • ganglia-gmetad 一个守护进程,用来收集被监控主机的数据。被监控主机与主节点主机都要安装 Ganglia-gmond(监控守护进程本身);
  • ganglia-web 提供 Web 前端,用于显示监控系统的历史数据和图形。 2、 使用 Apache 提供的基本认证功能,为 Ganglia Web 界面(/usr/share/ganglia)配置身份认证。

如果你想了解更多高级安全机制,请参阅 Apache 文档的 授权与认证部分。

为完成这个目标,我们需要创建一个用户名并设定一个密码,以访问被 Apache 保护的资源。在本例中,我们先来创建一个叫 adminganglia 的用户名,然后给它分配一个密码,它将被储存在 /etc/httpd/auth.basic(可以随意选择另一个目录 和/或 文件名, 只要 Apache 对此有读取权限就可以。)

# htpasswd -c /etc/httpd/auth.basic adminganglia

给 adminganglia 输入两次密码完成密码设置。

3、 修改配置文件 /etc/httpd/conf.d/ganglia.conf

Alias /ganglia /usr/share/ganglia
<Location /ganglia>
AuthType basic
AuthName "Ganglia web UI"
AuthBasicProvider file
AuthUserFile "/etc/httpd/auth.basic"
Require user adminganglia
</Location>

4、 编辑 /etc/ganglia/gmetad.conf

首先,使用 gridname 指令来为网格设置一个描述性名称。

gridname "Home office"

然后,使用 data_source 指令,后面跟集群名(服务器组)、轮询时间间隔(秒)、主节点主机和被监控节点的 IP 地址:

data_source "Labs" 60 192.168.0.29:8649 # 主节点
data_source "Labs" 60 192.168.0.32 # 被监控节点

5、 编辑 /etc/ganglia/gmond.conf

a) 确保集群的配置类似下面。

cluster {
name = "Labs" # gmetad.conf 中的  data_source 指令的名字
owner = "unspecified"
latlong = "unspecified"
url = "unspecified"
}

b) 在 udp_send_chanel 中,注释掉 mcast_join

udp_send_channel   {
# mcast_join = 239.2.11.71
host = localhost
port = 8649
ttl = 1
}

c) 在 udp_recv_channel 中,注释掉 mcast_joinbind 部分:

udp_recv_channel {
# mcast_join = 239.2.11.71 ## comment out
port = 8649
# bind = 239.2.11.71 ## comment out
}

保存并退出。

6、打开 8649/udp 端口,使用 SELinux 确保 php 脚本(通过 Apache 运行)能够连接到网络:

# firewall-cmd --add-port=8649/udp
# firewall-cmd --add-port=8649/udp --permanent
# setsebool -P httpd_can_network_connect 1

7、重启 Apache、gmetad、gmond,并确保它们启用了“开机启动”。

# systemctl restart httpd gmetad gmond
# systemctl enable httpd gmetad httpd

至此,我们现在能够打开 Ganglia 的 Web 页面 http://192.168.0.29/ganglia 并用步骤 2 中设置的凭证登录。

Gangila Web Interface

Gangila Web 页面

8、 在 Ubuntu 主机上,只需安装 Ganglia-monitor,等同于 CentOS 上的 ganglia-gmond:

$ sudo aptitude update && aptitude install ganglia-monitor

9、 编辑被监控主机的 /etc/ganglia/gmond.conf 文件。与主节点主机上是相同的文件,除了被注释掉的 cluster, udp_send_channeludp_recv_channel 这里不应被注释:

cluster {
name = "Labs" # The name in the data_source directive in gmetad.conf
owner = "unspecified"
latlong = "unspecified"
url = "unspecified"
}
udp_send_channel   {
mcast_join = 239.2.11.71
host = localhost
port = 8649
ttl = 1
}
udp_recv_channel {
mcast_join = 239.2.11.71 ## comment out
port = 8649
bind = 239.2.11.71 ## comment out
}

之后重启服务。

$ sudo service ganglia-monitor restart

10、 刷新页面,你将在 Home office grid / Labs cluster 中看到两台主机的各种统计及图形化的展示(用下拉菜单选择集群,本例中为 Labs):

Ganglia Home Office Grid Report

Ganglia 中 Home office 网格报告

使用菜单按钮(如上指出的),你可以获取到每台服务器和集群的信息。还可以使用 对比主机Compare Hosts选项卡来比较集群中所有服务器的状态。

可以使用正则表达式选择一组服务器,立刻就可以看到它们性能的对比:

Ganglia Host Server Information

Ganglia 服务器信息

我最喜欢的一个特点是对移动端有友好的总结界面,可以通过 Mobile 选项来访问。选择你感兴趣的集群,然后选中一个主机。

Ganglia Mobile Friendly Summary View

Ganglia 移动端总结截图

总结

本篇文章向大家介绍了 Ganglia,它是一个功能强大、扩展性很好的监控工具,主要用来监控集群和网格。它可以随意安装,便捷的组合各种功能(你甚至可以尝试一下官方网站提供的 Demo)。

此时,你可能会发现许多知名的 IT 或非 IT 的企业在使用 Ganglia。除了我们在文章中提及的之外,还有很多理由这样做,其中易用性,统计的图形化(在名字旁附上脸部照片更清晰,不是吗)可能是最重要的原因。

但是请不要拘泥于本篇文章,尝试一下自己去做。如果你有任何问题,欢迎给我留言。


via: http://www.tecmint.com/install-configure-ganglia-monitoring-centos-linux/

作者:Gabriel Cánepa 译者:ivo-wang 校对:jasminepeng

本文由 LCTT 组织编译,Linux中国 荣誉推出

我们对微服务的需求可以归纳为一个词:速度。这种更快提供功能完善且可靠的软件的需求,彻底改变了软件开发模式。毫无疑问,这个改变对软件管理,包括系统监控的方式,都产生了影响。在这篇文章里,我们将重点关注放在有效地监控产品环境中的微服务所需做出的主要改变。我们将为这一新的软件架构拟定 5 条指导性原则来调整你的监控方法。

监控是微服务控制系统的关键部分,你的软件越复杂,那么你就越难了解其性能及问题排障。鉴于软件交付发生的巨大改变,监控系统同样需要进行彻底的改造,以便在微服务环境下表现更好。下面我们将介绍监控微服务的 5 条原则,如下:

  1. 监控容器及其里面的东西。
  2. 在服务性能上做监控,而不是容器性能。
  3. 监控弹性和多地部署的服务。
  4. 监控 API。
  5. 将您的监控映射到您的组织结构。

利用这 5 条原则,你可以在向微服务前进的道路上,建立更有效的对微服务的监控。这些原则,可以让你应对随着微服务而来的技术变化和组织变化。

微服务监控的原则

1、监控容器及其里面的东西

容器因构建微服务而凸显其重要性,容器的速度、可移植性和隔离特性让开发者很容易就爱上了微服务模型。容器的好处已经写的够多了,毋庸赘述。

容器对于其外围的系统来说就像是黑盒子。这对于开发来说大有裨益,从开发环境到生产环境,甚至从开发者的笔记本到云端,为它们带来高度的可移植性。但是当运行起来后,监控和解决服务问题时,这个黑盒子让常规的方法难以奏效了,我们会想:容器里到底在运行着什么?程序和代码运行性能如何?它有什么重要的输出指标吗?从 DevOps 的视角,你需要对容器有更深的了解而不是仅仅知道有一些容器的存在。

非容器环境下衡量的典型做法,是让一个代理程序运行在主机或者虚机上的用户空间里,但这并不适用于容器。因为容器的优点是小,将各种进程分离开来,并尽可能的减少依赖关系。

而且,从规模上看,成千上万的监测代理,对即使是一个中等大小的部署都是一个昂贵的资源浪费和管理的噩梦。对于容器有两个潜在的解决方案:1)要求你的开发人员直接监控他们的代码,或者2)利用一个通用的内核级的检测方法来查看主机上的所有应用程序和容器活动。这里我们不会深入说明,但每一种方法都有其优点和缺点。

2、 利用业务流程系统提醒服务性能

理解容器容器中的运行数据并不容易,一个单一容器相比组成一个功能或服务的容器聚合,测量复杂度要低得多。

这特别适用于应用程序级别的信息,比如哪个请求拥有最短响应时间,或者哪些 URL 遇到最多的错误,但它同样也适用于架构级别的监测,比如哪个服务的容器使用 CPU 资源超过了事先分配的资源数。

越来越多的软件部署需要一个 编排系统 orchestration system ,将应用程序的逻辑规划转化到物理的容器中。常见的编排系统包括 Kubernetes、Mesosphere DC/OS 和 Docker Swarm。团队可以用一个编排系统来(1)定义微服务(2)理解部署的每个服务的当前状态。你可以认为编排系统甚至比容器还重要。容器是短暂的,只有满足你的服务需求才会存在。

DevOps 团队应该将告警重点放到运行特征上,以尽可能贴近监控服务的体验。如果应用受到了影响,这些告警是评估事态的第一道防线。但是获得这些告警并不容易,除非你的监控系统是基于原生于容器的。

原生容器 Container-native 解决方案利用 编排元数据 orchestration metadata 来动态聚合容器和应用程序数据,并按每个服务计算监控度量。根据您的编排工具,您可能想在不同层次进行深入检测。比如,在 Kubernetes 里,你通常有 Namespace、ReplicaSet、Pod 和一些其他容器。聚合这些不同的层,对排除逻辑故障是很有必要的,与构成服务的容器的物理部署无关。

3、 监控 弹性 Elastic 多地部署 Multi-Location 的服务

弹性服务不是一个新概念,但是它在原生容器环境中的变化速度比在虚拟环境中快的多。迅速的变化会严重影响检测系统的正常运行。

监测传统的系统经常需要根据软件部署,手动调整检查指标。这种调整可以是具体的,如定义要捕获的单个指标,或基于应用程序在一个特定的容器中的操作配置要收集的数据。在小规模上(比如几十个容器)我们可以接受,但是再大规模就难以承受了。微服务的集中监控必须能够自由的随弹性服务而增长和缩减,无需人工干预。

比如,如果 DevOps 团队必须手动定义容器包含哪个服务需要监控,他们毫无疑问会失手,因为 Kubernetes 或者 Mesos 每天都会定期创建新的容器。同样,如果代码发布并置于生产环境时要求运维团队安装一个 定制的状态端点 custom stats endpoint ,也给开发者从 Docker 仓库获取基础镜像带来更多的挑战。

在生产环境中,建立面向跨越多个数据中心或多个云的复杂部署的监控,比如,如果你的服务跨越私有数据中心和 AWS,那么亚马逊的 AWS CloudWatch 就很难做到这一点。这就要求我们建立一个跨不同地域的监控系统,并可在动态的原生容器环境下运行。

4、 监控 API

在微服务环境中,API 接口是通用的。本质上,它们是将服务暴露给其它团队的唯一组件。事实上,API 的响应和一致性可以看作是“内部 SLA”,即使还没有定义一个正式的 SLA(服务等级协议)。

因此,API 接口的监控也是必要的。API 监控可以有不同的形式,但是很显然它绝对不是简单的二进制上下检查。例如,了解像时间函数这样的最常使用的 端点 endpoint 是有价值的。这使得团队可以看到服务使用的变化,无论是由于设计变更或用户的改变。

你也可以记录服务最缓慢的端点,这些可能揭示出重大的问题,或者至少指向需要在系统中做优化的区域。

最后,跟踪系统服务响应的能力是另一个很重要的能力,它主要是开发者使用,也能帮助你了解整体用户体验,同时将信息基于底层和应用程序视角分成两大部分。

5、 将您的监控映射到您的组织结构

这篇文章着重在微服务和监控上,像其他科技文章一样,这是因为很多人都关注此层面。

对于那些熟悉 康威定律 Conway’s law 的人来说,系统的设计是基于开发团队的组织结构。创造更快,更敏捷的软件的压力推动了团队去思考重新调整他们的开发组织和管理它的规则。

所以,如果他们想从这个新的软件架构(微服务)上获益,他们的团队必须将微服务映射到团队自身中。也就是说,他们需要更小的更松散耦合的团队,可以选择自己的方向只要能够满足整个需求即可。在每一个团队中,对于开发语言的使用,bug 的提交甚至工作职责都会有更大的控制能力。

DevOps 团队对此可以启用一个监控平台:让每一个微服务团队可以有自己的警报,度量指标,和控制面板,同时也要给出整体系统的视图。

总结

让微服务流行起来的是快捷。开发组织要想更快的为客户提供更多的功能,然后微服务技术就来了,架构转向微服务并且容器的流行让快捷开发成为可能,所有相关的进程理所当然的搭上了这辆火车。

最后,基本的监控原则需要适应伴随微服务而来的技术和结构。越早认识到这种转变的开发团队,能更早更容易的适应微服务这一新的架构。


via: http://thenewstack.io/five-principles-monitoring-microservices/

作者:Apurva DaveLoris Degioanni 译者:jiajia9linuxer 校对:jasminepeng

本文由 LCTT 原创编译,Linux中国 荣誉推出

Grafana 是一个有着丰富指标的开源控制面板。在可视化大规模测量数据的时候是非常有用的。根据不同的指标数据,它提供了一个强大、优雅的来创建、分享和浏览数据的方式。

它提供了丰富多样、灵活的图形选项。此外,针对 数据源 Data Source ,它支持许多不同的存储后端。每个数据源都有针对特定数据源的特性和功能所定制的查询编辑器。Grafana 提供了对下述数据源的正式支持:Graphite、InfluxDB、OpenTSDB、 Prometheus、Elasticsearch 和 Cloudwatch。

每个数据源的查询语言和能力显然是不同的,你可以将来自多个数据源的数据混合到一个单一的仪表盘上,但每个 面板 Panel 被绑定到属于一个特定 组织 Organization 的特定数据源上。它支持验证登录和基于角色的访问控制方案。它是作为一个独立软件部署,使用 Go 和 JavaScript 编写的。

在这篇文章,我将讲解如何在 Ubuntu 16.04 上安装 Grafana 并使用这个软件配置 Docker 监控。

先决条件

  • 安装好 Docker 的服务器

安装 Grafana

我们可以在 Docker 中构建我们的 Grafana。 有一个官方提供的 Grafana Docker 镜像。请运行下述命令来构建Grafana 容器。

root@ubuntu:~# docker run -i -p 3000:3000 grafana/grafana

Unable to find image 'grafana/grafana:latest' locally
latest: Pulling from grafana/grafana
5c90d4a2d1a8: Pull complete
b1a9a0b6158e: Pull complete
acb23b0d58de: Pull complete
Digest: sha256:34ca2f9c7986cb2d115eea373083f7150a2b9b753210546d14477e2276074ae1
Status: Downloaded newer image for grafana/grafana:latest
t=2016-07-27T15:20:19+0000 lvl=info msg="Starting Grafana" logger=main version=3.1.0 commit=v3.1.0 compiled=2016-07-12T06:42:28+0000
t=2016-07-27T15:20:19+0000 lvl=info msg="Config loaded from" logger=settings file=/usr/share/grafana/conf/defaults.ini
t=2016-07-27T15:20:19+0000 lvl=info msg="Config loaded from" logger=settings file=/etc/grafana/grafana.ini
t=2016-07-27T15:20:19+0000 lvl=info msg="Config overriden from command line" logger=settings arg="default.paths.data=/var/lib/grafana"
t=2016-07-27T15:20:19+0000 lvl=info msg="Config overriden from command line" logger=settings arg="default.paths.logs=/var/log/grafana"
t=2016-07-27T15:20:19+0000 lvl=info msg="Config overriden from command line" logger=settings arg="default.paths.plugins=/var/lib/grafana/plugins"
t=2016-07-27T15:20:19+0000 lvl=info msg="Path Home" logger=settings path=/usr/share/grafana
t=2016-07-27T15:20:19+0000 lvl=info msg="Path Data" logger=settings path=/var/lib/grafana
t=2016-07-27T15:20:19+0000 lvl=info msg="Path Logs" logger=settings path=/var/log/grafana
t=2016-07-27T15:20:19+0000 lvl=info msg="Path Plugins" logger=settings path=/var/lib/grafana/plugins
t=2016-07-27T15:20:19+0000 lvl=info msg="Initializing DB" logger=sqlstore dbtype=sqlite3

t=2016-07-27T15:20:20+0000 lvl=info msg="Executing migration" logger=migrator id="create playlist table v2"
t=2016-07-27T15:20:20+0000 lvl=info msg="Executing migration" logger=migrator id="create playlist item table v2"
t=2016-07-27T15:20:20+0000 lvl=info msg="Executing migration" logger=migrator id="drop preferences table v2"
t=2016-07-27T15:20:20+0000 lvl=info msg="Executing migration" logger=migrator id="drop preferences table v3"
t=2016-07-27T15:20:20+0000 lvl=info msg="Executing migration" logger=migrator id="create preferences table v3"
t=2016-07-27T15:20:20+0000 lvl=info msg="Created default admin user: [admin]"
t=2016-07-27T15:20:20+0000 lvl=info msg="Starting plugin search" logger=plugins
t=2016-07-27T15:20:20+0000 lvl=info msg="Server Listening" logger=server address=0.0.0.0:3000 protocol=http subUrl=

我们可以通过运行此命令确认 Grafana 容器的工作状态 docker ps -a 或通过这个URL访问 http://Docker IP:3000

所有的 Grafana 配置设置都使用环境变量定义,在使用容器技术时这个是非常有用的。Grafana 配置文件路径为 /etc/grafana/grafana.ini

理解配置项

Grafana 可以在它的 ini 配置文件中指定几个配置选项,或可以使用前面提到的环境变量来指定。

配置文件位置

通常配置文件路径:

  • 默认配置文件路径 : $WORKING_DIR/conf/defaults.ini
  • 自定义配置文件路径 : $WORKING_DIR/conf/custom.ini

PS:当你使用 deb、rpm 或 docker 镜像安装 Grafana 时,你的配置文件在 /etc/grafana/grafana.ini

理解配置变量

现在我们看一些配置文件中的变量:

  • instance_name:这是 Grafana 服务器实例的名字。默认值从 ${HOSTNAME} 获取,其值是环境变量HOSTNAME,如果该变量为空或不存在,Grafana 将会尝试使用系统调用来获取机器名。
  • [paths]:这些路径通常都是在 init.d 脚本或 systemd service 文件中通过命令行指定。

    • data:这个是 Grafana 存储 sqlite3 数据库(如果使用)、基于文件的会话(如果使用),和其他数据的路径。
    • logs:这个是 Grafana 存储日志的路径。
  • [server]

    • http_addr:应用监听的 IP 地址,如果为空,则监听所有的接口。
    • http_port:应用监听的端口,默认是 3000,你可以使用下面的命令将你的 80 端口重定向到 3000 端口:$iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3000
    • root_url : 这个 URL 用于从浏览器访问 Grafana 。
    • cert_file : 证书文件的路径(如果协议是 HTTPS)。
    • cert_key : 证书密钥文件的路径(如果协议是 HTTPS)。
  • [database]:Grafana 使用数据库来存储用户和仪表盘以及其他信息,默认配置为使用内嵌在 Grafana 主二进制文件中的 SQLite3。

    • type:你可以根据你的需求选择 MySQL、Postgres、SQLite3。
    • path:仅用于选择 SQLite3 数据库时,这个是数据库所存储的路径。
    • host:仅适用 MySQL 或者 Postgres。它包括 IP 地址或主机名以及端口。例如,Grafana 和 MySQL 运行在同一台主机上设置如: host = 127.0.0.1:3306
    • name:Grafana 数据库的名称,把它设置为 Grafana 或其它名称。
    • user:数据库用户(不适用于 SQLite3)。
    • password:数据库用户密码(不适用于 SQLite3)。
    • ssl_mode:对于 Postgres,使用 disablerequire,或 verify-full 等值。对于 MySQL,使用 truefalse,或 skip-verify
    • ca_cert_path:(只适用于 MySQL)CA 证书文件路径,在多数 Linux 系统中,证书可以在 /etc/ssl/certs 找到。
    • client_key_path:(只适用于 MySQL)客户端密钥的路径,只在服务端需要用户端验证时使用。
    • client_cert_path:(只适用于 MySQL)客户端证书的路径,只在服务端需要用户端验证时使用。
    • server_cert_name:(只适用于 MySQL)MySQL 服务端使用的证书的通用名称字段。如果 ssl_mode 设置为 skip-verify 时可以不设置。
  • [security]

    • admin_user:这个是 Grafana 默认的管理员用户的用户名,默认设置为 admin。
    • admin_password:这个是 Grafana 默认的管理员用户的密码,在第一次运行时设置,默认为 admin。
    • login_remember_days:保持登录/记住我的持续天数。
    • secret_key:用于保持登录/记住我的 cookies 的签名。

设置监控的重要组件

我们可以使用下面的组件来创建我们的 Docker 监控系统。

  • cAdvisor:它被称为 Container Advisor。它给用户提供了一个资源利用和性能特征的解读。它会收集、聚合、处理、导出运行中的容器的信息。你可以通过这个文档了解更多。
  • InfluxDB:这是一个包含了时间序列、度量和分析数据库。我们使用这个数据源来设置我们的监控。cAdvisor 只展示实时信息,并不保存这些度量信息。Influx Db 帮助保存 cAdvisor 提供的监控数据,以展示非某一时段的数据。
  • Grafana Dashboard:它可以帮助我们在视觉上整合所有的信息。这个强大的仪表盘使我们能够针对 InfluxDB 数据存储进行查询并将他们放在一个布局合理好看的图表中。

Docker 监控的安装

我们需要一步一步的在我们的 Docker 系统中安装以下每一个组件:

安装 InfluxDB

我们可以使用这个命令来拉取 InfluxDB 镜像,并部署了 influxDB 容器。

root@ubuntu:~# docker run -d -p 8083:8083 -p 8086:8086 --expose 8090 --expose 8099 -e PRE_CREATE_DB=cadvisor --name influxsrv tutum/influxdb:0.8.8
Unable to find image 'tutum/influxdb:0.8.8' locally
0.8.8: Pulling from tutum/influxdb
a3ed95caeb02: Already exists
23efb549476f: Already exists
aa2f8df21433: Already exists
ef072d3c9b41: Already exists
c9f371853f28: Already exists
a248b0871c3c: Already exists
749db6d368d0: Already exists
7d7c7d923e63: Pull complete
e47cc7808961: Pull complete
1743b6eeb23f: Pull complete
Digest: sha256:8494b31289b4dbc1d5b444e344ab1dda3e18b07f80517c3f9aae7d18133c0c42
Status: Downloaded newer image for tutum/influxdb:0.8.8
d3b6f7789e0d1d01fa4e0aacdb636c221421107d1df96808ecbe8e241ceb1823

    -p 8083:8083 : user interface, log in with username-admin, pass-admin
    -p 8086:8086 : interaction with other application
    --name influxsrv : container have name influxsrv, use to cAdvisor link it.

你可以测试 InfluxDB 是否安装好,通过访问这个 URL http://你的 IP 地址:8083,用户名和密码都是 ”root“。

InfluxDB Administration 2016-08-01 14-10-08

我们可以在这个界面上创建我们所需的数据库。

createDB influx

安装 cAdvisor

我们的下一个步骤是安装 cAdvisor 容器,并将其链接到 InfluxDB 容器。你可以使用此命令来创建它。

root@ubuntu:~# 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 --link influxsrv:influxsrv --name=cadvisor google/cadvisor:latest -storage_driver_db=cadvisor -storage_driver_host=influxsrv:8086
Unable to find image 'google/cadvisor:latest' locally
latest: Pulling from google/cadvisor
09d0220f4043: Pull complete
151807d34af9: Pull complete
14cd28dce332: Pull complete
Digest: sha256:8364c7ab7f56a087b757a304f9376c3527c8c60c848f82b66dd728980222bd2f
Status: Downloaded newer image for google/cadvisor:latest
3bfdf7fdc83872485acb06666a686719983a1172ac49895cd2a260deb1cdde29
root@ubuntu:~#

    --publish=8080:8080 : user interface
    --link=influxsrv:influxsrv: link to container influxsrv
    -storage_driver=influxdb: set the storage driver as InfluxDB
    Specify what InfluxDB instance to push data to:
    -storage_driver_host=influxsrv:8086: The ip:port of the database. Default is ‘localhost:8086’
    -storage_driver_db=cadvisor: database name. Uses db ‘cadvisor’ by default

你可以通过访问这个地址来测试安装 cAdvisor 是否正常 http://你的 IP 地址:8080。 这将为你的 Docker 主机和容器提供统计信息。

cAdvisor - Docker Containers 2016-08-01 14-24-18

安装 Grafana 控制面板

最后,我们需要安装 Grafana 仪表板并连接到 InfluxDB,你可以执行下面的命令来设置它。

root@ubuntu:~# docker run -d -p 3000:3000 -e INFLUXDB_HOST=localhost -e INFLUXDB_PORT=8086 -e INFLUXDB_NAME=cadvisor -e INFLUXDB_USER=root -e INFLUXDB_PASS=root --link influxsrv:influxsrv --name grafana grafana/grafana
f3b7598529202b110e4e6b998dca6b6e60e8608d75dcfe0d2b09ae408f43684a

现在我们可以登录 Grafana 来配置数据源. 访问 http://你的 IP 地址:3000http://你的 IP 地址(如果你在前面做了端口映射的话):

  • 用户名 - admin
  • 密码 - admin

一旦我们安装好了 Grafana,我们可以连接 InfluxDB。登录到仪表盘并且点击面板左上方角落的 Grafana 图标(那个火球)。点击 数据源 Data Sources 来配置。

addingdatabsource

现在你可以添加新的 图形 Graph 到我们默认的数据源 InfluxDB。

panelgraph

我们可以通过在 测量 Metric 页面编辑和调整我们的查询以调整我们的图形。

Grafana - Grafana Dashboard 2016-08-01 14-53-40

Grafana - Grafana Dashboard

关于 Docker 监控,你可用从此了解更多信息。 感谢你的阅读。我希望你可以留下有价值的建议和评论。希望你有个美好的一天。


via: http://linoxide.com/linux-how-to/monitor-docker-containers-grafana-ubuntu/

作者:Saheetha Shameer 译者:Bestony 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

如果你正在运行 Swarm 模式的集群,或者只运行单台 Docker,你都会有下面的疑问:

我如何才能监控到它们都在干些什么?

这个问题的答案是“很不容易”。

你需要监控下面的参数:

  1. 容器的数量和状态。
  2. 一台容器是否已经移到另一个节点了,如果是,那是在什么时候,移动到哪个节点?
  3. 给定节点上运行着的容器数量。
  4. 一段时间内的通信峰值。
  5. 孤儿卷和网络(LCTT 译注:孤儿卷就是当你删除容器时忘记删除它的卷,这个卷就不会再被使用,但会一直占用资源)。
  6. 可用磁盘空间、可用 inode 数。
  7. 容器数量与连接在 docker0docker_gwbridge 上的虚拟网卡数量不一致(LCTT 译注:当 docker 启动时,它会在宿主机器上创建一个名为 docker0 的虚拟网络接口)。
  8. 开启和关闭 Swarm 节点。
  9. 收集并集中处理日志。

本文的目标是介绍 Elasticsearch + Kibana + cAdvisor 的用法,使用它们来收集 Docker 容器的参数,分析数据并产生可视化报表。

阅读本文后你可以发现有一个监控仪表盘能够部分解决上述列出的问题。但如果只是使用 cAdvisor,有些参数就无法显示出来,比如 Swarm 模式的节点。

如果你有一些 cAdvisor 或其他工具无法解决的特殊需求,我建议你开发自己的数据收集器和数据处理器(比如 Beats),请注意我不会演示如何使用 Elasticsearch 来集中收集 Docker 容器的日志。

“你要如何才能监控到 Swarm 模式集群里面发生了什么事情?要做到这点很不容易。” —— @fntlnz

我们为什么要监控容器?

想象一下这个经典场景:你在管理一台或多台虚拟机,你把 tmux 工具用得很溜,用各种 session 事先设定好了所有基础的东西,包括监控。然后生产环境出问题了,你使用 tophtopiotopjnettop 各种 top 来排查,然后你准备好修复故障。

现在重新想象一下你有 3 个节点,包含 50 台容器,你需要在一个地方查看整洁的历史数据,这样你知道问题出在哪个地方,而不是把你的生命浪费在那些字符界面来赌你可以找到问题点。

什么是 Elastic Stack ?

Elastic Stack 就一个工具集,包括以下工具:

  • Elasticsearch
  • Kibana
  • Logstash
  • Beats

我们会使用其中一部分工具,比如使用 Elasticsearch 来分析基于 JSON 格式的文本,以及使用 Kibana 来可视化数据并产生报表。

另一个重要的工具是 Beats,但在本文中我们还是把精力放在容器上,官方的 Beats 工具不支持 Docker,所以我们选择原生兼容 Elasticsearch 的 cAdvisor。

cAdvisor 工具负责收集、整合正在运行的容器数据,并导出报表。在本文中,这些报表被到入到 Elasticsearch 中。

cAdvisor 有两个比较酷的特性:

  • 它不只局限于 Docker 容器。
  • 它有自己的 Web 服务器,可以简单地显示当前节点的可视化报表。

设置测试集群,或搭建自己的基础架构

和我以前的文章一样,我习惯提供一个简单的脚本,让读者不用花很多时间就能部署好和我一样的测试环境。你可以使用以下(非生产环境使用的)脚本来搭建一个 Swarm 模式的集群,其中一个容器运行着 Elasticsearch。

如果你有充足的时间和经验,你可以 搭建自己的基础架构 Bring Your Own Infrastructure,BYOI

如果要继续阅读本文,你需要:

  • 运行 Docker 进程的一个或多个节点(docker 版本号大于等于 1.12)。
  • 至少有一个独立运行的 Elasticsearch 节点(版本号 2.4.X)。

重申一下,此 Elasticsearch 集群环境不能放在生产环境中使用。生产环境也不推荐使用单节点集群,所以如果你计划安装一个生产环境,请参考 Elastic 指南

对喜欢尝鲜的用户的友情提示

我就是一个喜欢尝鲜的人(当然我也已经在生产环境中使用了最新的 alpha 版本),但是在本文中,我不会使用最新的 Elasticsearch 5.0.0 alpha 版本,我还不是很清楚这个版本的功能,所以我不想成为那个引导你们出错的关键。

所以本文中涉及的 Elasticsearch 版本为最新稳定版 2.4.0。

测试集群部署脚本

前面已经说过,我提供这个脚本给你们,让你们不必费神去部署 Swarm 集群和 Elasticsearch,当然你也可以跳过这一步,用你自己的 Swarm 模式引擎和你自己的 Elasticserch 节点。

执行这段脚本之前,你需要:

创建集群的脚本

现在万事俱备,你可以把下面的代码拷到 create-cluster.sh 文件中:

#!/usr/bin/env bash
#
# Create a Swarm Mode cluster with a single master and a configurable number of workers

workers=${WORKERS:-"worker1 worker2"}

#######################################
# Creates a machine on Digital Ocean
# Globals:
#   DO_ACCESS_TOKEN The token needed to access DigitalOcean's API
# Arguments:
#   $1 the actual name to give to the machine
#######################################
create_machine() {
  docker-machine create \
    -d digitalocean \
    --digitalocean-access-token=$DO_ACCESS_TOKEN \
    --digitalocean-size 2gb \
    $1
}

#######################################
# Executes a command on the specified machine
# Arguments:
#   $1     The machine on which to run the command
#   $2..$n The command to execute on that machine
#######################################
machine_do() {
  docker-machine ssh $@
}

main() {

  if [ -z "$DO_ACCESS_TOKEN" ]; then
    echo "Please export a DigitalOcean Access token: https://cloud.digitalocean.com/settings/api/tokens/new"
    echo "export DO_ACCESS_TOKEN=<yourtokenhere>"
    exit 1
  fi

  if [ -z "$WORKERS" ]; then
    echo "You haven't provided your workers by setting the \$WORKERS environment variable, using the default ones: $workers"
  fi

  # Create the first and only master
  echo "Creating the master"

  create_machine master1

  master_ip=$(docker-machine ip master1)

  # Initialize the swarm mode on it
  echo "Initializing the swarm mode"
  machine_do master1 docker swarm init --advertise-addr $master_ip

  # Obtain the token to allow workers to join
  worker_tkn=$(machine_do master1 docker swarm join-token -q worker)
  echo "Worker token: ${worker_tkn}"

  # Create and join the workers
  for worker in $workers; do
    echo "Creating worker ${worker}"
    create_machine $worker
    machine_do $worker docker swarm join --token $worker_tkn $master_ip:2377
  done
}

main $@

赋予它可执行权限:

chmod +x create-cluster.sh

创建集群

如文件名所示,我们可以用它来创建集群。默认情况下这个脚本会创建一个 master 和两个 worker,如果你想修改 worker 个数,可以设置环境变量 WORKERS。

现在就来创建集群吧。

./create-cluster.sh

你可以出去喝杯咖啡,因为这需要花点时间。

最后集群部署好了。

现在为了验证 Swarm 模式集群已经正常运行,我们可以通过 ssh 登录进 master:

docker-machine ssh master1

然后列出集群的节点:

docker node ls
ID                           HOSTNAME  STATUS  AVAILABILITY  MANAGER STATUS
26fi3wiqr8lsidkjy69k031w2 *  master1   Ready   Active        Leader
dyluxpq8sztj7kmwlzs51u4id    worker2   Ready   Active
epglndegvixag0jztarn2lte8    worker1   Ready   Active

安装 Elasticsearch 和 Kibana

注意,从现在开始所有的命令都运行在主节点 master1 上。

在生产环境中,你可能会把 Elasticsearch 和 Kibana 安装在一个单独的、大小合适的实例集合中。但是在我们的实验中,我们还是把它们和 Swarm 模式集群安装在一起。

为了将 Elasticsearch 和 cAdvisor 连通,我们需要创建一个自定义的网络,因为我们使用了集群,并且容器可能会分布在不同的节点上,我们需要使用 overlay 网络(LCTT 译注:overlay 网络是指在不改变现有网络基础设施的前提下,通过某种约定通信协议,把二层报文封装在 IP 报文之上的新的数据格式,是目前最主流的容器跨节点数据传输和路由方案)。

也许你会问,“为什么还要网络?我们不是可以用 link 吗?” 请考虑一下,自从引入用户定义网络后,link 机制就已经过时了。

以下内容摘自 Docker 文档

在 Docker network 特性出来以前,你可以使用 Docker link 特性实现容器互相发现、安全通信。而在 network 特性出来以后,你还可以使用 link,但是当容器处于默认桥接网络或用户自定义网络时,它们的表现是不一样的。

现在创建 overlay 网络,名称为 monitoring:

docker network create monitoring -d overlay

Elasticsearch 容器

docker service create --network=monitoring \
  --mount type=volume,target=/usr/share/elasticsearch/data \
  --constraint node.hostname==worker1 \
  --name elasticsearch elasticsearch:2.4.0

注意 Elasticsearch 容器被限定在 worker1 节点,这是因为它运行时需要依赖 worker1 节点上挂载的卷。

Kibana 容器

docker service create --network=monitoring --name kibana -e ELASTICSEARCH_URL="http://elasticsearch:9200" -p 5601:5601 kibana:4.6.0

如你所见,我们启动这两个容器时,都让它们加入 monitoring 网络,这样一来它们可以通过名称(如 Kibana)被相同网络的其他服务访问。

现在,通过 routing mesh 机制,我们可以使用浏览器访问服务器的 IP 地址来查看 Kibana 报表界面。

获取 master1 实例的公共 IP 地址:

docker-machine ip master1

打开浏览器输入地址:http://[master1 的 ip 地址]:5601/status

所有项目都应该是绿色:

让我们接下来开始收集数据!

收集容器的运行数据

收集数据之前,我们需要创建一个服务,以全局模式运行 cAdvisor,为每个有效节点设置一个定时任务。

这个服务与 Elasticsearch 处于相同的网络,以便于 cAdvisor 可以推送数据给 Elasticsearch。

docker service create --network=monitoring --mode global --name cadvisor \
  --mount type=bind,source=/,target=/rootfs,readonly=true \
  --mount type=bind,source=/var/run,target=/var/run,readonly=false \
  --mount type=bind,source=/sys,target=/sys,readonly=true \
  --mount type=bind,source=/var/lib/docker/,target=/var/lib/docker,readonly=true \
  google/cadvisor:latest \
  -storage_driver=elasticsearch \
  -storage_driver_es_host="http://elasticsearch:9200"
注意:如果你想配置 cAdvisor 选项,参考这里

现在 cAdvisor 在发送数据给 Elasticsearch,我们通过定义一个索引模型来检索 Kibana 中的数据。有两种方式可以做到这一点:通过 Kibana 或者通过 API。在这里我们使用 API 方式实现。

我们需要在一个连接到 monitoring 网络的正在运行的容器中运行索引创建命令,你可以在 cAdvisor 容器中拿到 shell,不幸的是 Swarm 模式在开启服务时会在容器名称后面附加一个唯一的 ID 号,所以你需要手动指定 cAdvisor 容器的名称。

拿到 shell:

docker exec -ti <cadvisor-container-name> sh

创建索引:

curl -XPUT http://elasticsearch:9200/.kibana/index-pattern/cadvisor -d '{"title" : "cadvisor*",  "timeFieldName": "container_stats.timestamp"}'

如果你够懒,可以只执行下面这一句:

docker exec $(docker ps | grep cadvisor | awk '{print $1}' | head -1) curl -XPUT http://elasticsearch:9200/.kibana/index-pattern/cadvisor -d '{"title" : "cadvisor*",  "timeFieldName": "container_stats.timestamp"}'

把数据汇总成报表

你现在可以使用 Kibana 来创建一份美观的报表了。但是不要着急,我为你们建了一份报表和一些图形界面来方便你们入门。

访问 Kibana 界面 => Setting => Objects => Import,然后选择包含以下内容的 JSON 文件,就可以导入我的配置信息了:

[
  {
    "_id": "cAdvisor",
    "_type": "dashboard",
    "_source": {
      "title": "cAdvisor",
      "hits": 0,
      "description": "",
      "panelsJSON": "[{\"id\":\"Filesystem-usage\",\"type\":\"visualization\",\"panelIndex\":1,\"size_x\":6,\"size_y\":3,\"col\":1,\"row\":1},{\"id\":\"Memory-[Node-equal->Container]\",\"type\":\"visualization\",\"panelIndex\":2,\"size_x\":6,\"size_y\":4,\"col\":7,\"row\":4},{\"id\":\"memory-usage-by-machine\",\"type\":\"visualization\",\"panelIndex\":3,\"size_x\":6,\"size_y\":6,\"col\":1,\"row\":4},{\"id\":\"CPU-Total-Usage\",\"type\":\"visualization\",\"panelIndex\":4,\"size_x\":6,\"size_y\":5,\"col\":7,\"row\":8},{\"id\":\"Network-RX-TX\",\"type\":\"visualization\",\"panelIndex\":5,\"size_x\":6,\"size_y\":3,\"col\":7,\"row\":1}]",
      "optionsJSON": "{\"darkTheme\":false}",
      "uiStateJSON": "{}",
      "version": 1,
      "timeRestore": false,
      "kibanaSavedObjectMeta": {
        "searchSourceJSON": "{\"filter\":[{\"query\":{\"query_string\":{\"query\":\"*\",\"analyze_wildcard\":true}}}]}"
      }
    }
  },
  {
    "_id": "Network",
    "_type": "search",
    "_source": {
      "title": "Network",
      "description": "",
      "hits": 0,
      "columns": [
        "machine_name",
        "container_Name",
        "container_stats.network.name",
        "container_stats.network.interfaces",
        "container_stats.network.rx_bytes",
        "container_stats.network.rx_packets",
        "container_stats.network.rx_dropped",
        "container_stats.network.rx_errors",
        "container_stats.network.tx_packets",
        "container_stats.network.tx_bytes",
        "container_stats.network.tx_dropped",
        "container_stats.network.tx_errors"
      ],
      "sort": [
        "container_stats.timestamp",
        "desc"
      ],
      "version": 1,
      "kibanaSavedObjectMeta": {
        "searchSourceJSON": "{\"index\":\"cadvisor*\",\"query\":{\"query_string\":{\"analyze_wildcard\":true,\"query\":\"*\"}},\"highlight\":{\"pre_tags\":[\"@kibana-highlighted-field@\"],\"post_tags\":[\"@/kibana-highlighted-field@\"],\"fields\":{\"*\":{}},\"fragment_size\":2147483647},\"filter\":[]}"
      }
    }
  },
  {
    "_id": "Filesystem-usage",
    "_type": "visualization",
    "_source": {
      "title": "Filesystem usage",
      "visState": "{\"title\":\"Filesystem usage\",\"type\":\"histogram\",\"params\":{\"addLegend\":true,\"addTimeMarker\":false,\"addTooltip\":true,\"defaultYExtents\":false,\"mode\":\"stacked\",\"scale\":\"linear\",\"setYExtents\":false,\"shareYAxis\":true,\"times\":[],\"yAxis\":{}},\"aggs\":[{\"id\":\"1\",\"type\":\"avg\",\"schema\":\"metric\",\"params\":{\"field\":\"container_stats.filesystem.usage\",\"customLabel\":\"USED\"}},{\"id\":\"2\",\"type\":\"terms\",\"schema\":\"split\",\"params\":{\"field\":\"machine_name\",\"size\":5,\"order\":\"desc\",\"orderBy\":\"1\",\"row\":false}},{\"id\":\"3\",\"type\":\"avg\",\"schema\":\"metric\",\"params\":{\"field\":\"container_stats.filesystem.capacity\",\"customLabel\":\"AVAIL\"}},{\"id\":\"4\",\"type\":\"terms\",\"schema\":\"segment\",\"params\":{\"field\":\"container_stats.filesystem.device\",\"size\":5,\"order\":\"desc\",\"orderBy\":\"1\"}}],\"listeners\":{}}",
      "uiStateJSON": "{\"vis\":{\"colors\":{\"Average container_stats.filesystem.available\":\"#E24D42\",\"Average container_stats.filesystem.base_usage\":\"#890F02\",\"Average container_stats.filesystem.capacity\":\"#3F6833\",\"Average container_stats.filesystem.usage\":\"#E24D42\",\"USED\":\"#BF1B00\",\"AVAIL\":\"#508642\"}}}",
      "description": "",
      "version": 1,
      "kibanaSavedObjectMeta": {
        "searchSourceJSON": "{\"index\":\"cadvisor*\",\"query\":{\"query_string\":{\"analyze_wildcard\":true,\"query\":\"*\"}},\"filter\":[]}"
      }
    }
  },
  {
    "_id": "CPU-Total-Usage",
    "_type": "visualization",
    "_source": {
      "title": "CPU Total Usage",
      "visState": "{\"title\":\"CPU Total Usage\",\"type\":\"area\",\"params\":{\"shareYAxis\":true,\"addTooltip\":true,\"addLegend\":true,\"smoothLines\":false,\"scale\":\"linear\",\"interpolate\":\"linear\",\"mode\":\"stacked\",\"times\":[],\"addTimeMarker\":false,\"defaultYExtents\":false,\"setYExtents\":false,\"yAxis\":{}},\"aggs\":[{\"id\":\"1\",\"type\":\"avg\",\"schema\":\"metric\",\"params\":{\"field\":\"container_stats.cpu.usage.total\"}},{\"id\":\"2\",\"type\":\"date_histogram\",\"schema\":\"segment\",\"params\":{\"field\":\"container_stats.timestamp\",\"interval\":\"auto\",\"customInterval\":\"2h\",\"min_doc_count\":1,\"extended_bounds\":{}}},{\"id\":\"3\",\"type\":\"terms\",\"schema\":\"group\",\"params\":{\"field\":\"container_Name\",\"size\":5,\"order\":\"desc\",\"orderBy\":\"1\"}},{\"id\":\"4\",\"type\":\"terms\",\"schema\":\"split\",\"params\":{\"field\":\"machine_name\",\"size\":5,\"order\":\"desc\",\"orderBy\":\"1\",\"row\":true}}],\"listeners\":{}}",
      "uiStateJSON": "{}",
      "description": "",
      "version": 1,
      "kibanaSavedObjectMeta": {
        "searchSourceJSON": "{\"index\":\"cadvisor*\",\"query\":{\"query_string\":{\"query\":\"*\",\"analyze_wildcard\":true}},\"filter\":[]}"
      }
    }
  },
  {
    "_id": "memory-usage-by-machine",
    "_type": "visualization",
    "_source": {
      "title": "Memory [Node]",
      "visState": "{\"title\":\"Memory [Node]\",\"type\":\"area\",\"params\":{\"shareYAxis\":true,\"addTooltip\":true,\"addLegend\":true,\"smoothLines\":false,\"scale\":\"linear\",\"interpolate\":\"linear\",\"mode\":\"stacked\",\"times\":[],\"addTimeMarker\":false,\"defaultYExtents\":false,\"setYExtents\":false,\"yAxis\":{}},\"aggs\":[{\"id\":\"1\",\"type\":\"avg\",\"schema\":\"metric\",\"params\":{\"field\":\"container_stats.memory.usage\"}},{\"id\":\"2\",\"type\":\"date_histogram\",\"schema\":\"segment\",\"params\":{\"field\":\"container_stats.timestamp\",\"interval\":\"auto\",\"customInterval\":\"2h\",\"min_doc_count\":1,\"extended_bounds\":{}}},{\"id\":\"3\",\"type\":\"terms\",\"schema\":\"group\",\"params\":{\"field\":\"machine_name\",\"size\":5,\"order\":\"desc\",\"orderBy\":\"1\"}}],\"listeners\":{}}",
      "uiStateJSON": "{}",
      "description": "",
      "version": 1,
      "kibanaSavedObjectMeta": {
        "searchSourceJSON": "{\"index\":\"cadvisor*\",\"query\":{\"query_string\":{\"query\":\"*\",\"analyze_wildcard\":true}},\"filter\":[]}"
      }
    }
  },
  {
    "_id": "Network-RX-TX",
    "_type": "visualization",
    "_source": {
      "title": "Network RX TX",
      "visState": "{\"title\":\"Network RX TX\",\"type\":\"histogram\",\"params\":{\"addLegend\":true,\"addTimeMarker\":true,\"addTooltip\":true,\"defaultYExtents\":false,\"mode\":\"stacked\",\"scale\":\"linear\",\"setYExtents\":false,\"shareYAxis\":true,\"times\":[],\"yAxis\":{}},\"aggs\":[{\"id\":\"1\",\"type\":\"avg\",\"schema\":\"metric\",\"params\":{\"field\":\"container_stats.network.rx_bytes\",\"customLabel\":\"RX\"}},{\"id\":\"2\",\"type\":\"date_histogram\",\"schema\":\"segment\",\"params\":{\"field\":\"container_stats.timestamp\",\"interval\":\"s\",\"customInterval\":\"2h\",\"min_doc_count\":1,\"extended_bounds\":{}}},{\"id\":\"3\",\"type\":\"avg\",\"schema\":\"metric\",\"params\":{\"field\":\"container_stats.network.tx_bytes\",\"customLabel\":\"TX\"}}],\"listeners\":{}}",
      "uiStateJSON": "{\"vis\":{\"colors\":{\"RX\":\"#EAB839\",\"TX\":\"#BF1B00\"}}}",
      "description": "",
      "savedSearchId": "Network",
      "version": 1,
      "kibanaSavedObjectMeta": {
        "searchSourceJSON": "{\"filter\":[]}"
      }
    }
  },
  {
    "_id": "Memory-[Node-equal->Container]",
    "_type": "visualization",
    "_source": {
      "title": "Memory [Node=>Container]",
      "visState": "{\"title\":\"Memory [Node=>Container]\",\"type\":\"area\",\"params\":{\"shareYAxis\":true,\"addTooltip\":true,\"addLegend\":true,\"smoothLines\":false,\"scale\":\"linear\",\"interpolate\":\"linear\",\"mode\":\"stacked\",\"times\":[],\"addTimeMarker\":false,\"defaultYExtents\":false,\"setYExtents\":false,\"yAxis\":{}},\"aggs\":[{\"id\":\"1\",\"type\":\"avg\",\"schema\":\"metric\",\"params\":{\"field\":\"container_stats.memory.usage\"}},{\"id\":\"2\",\"type\":\"date_histogram\",\"schema\":\"segment\",\"params\":{\"field\":\"container_stats.timestamp\",\"interval\":\"auto\",\"customInterval\":\"2h\",\"min_doc_count\":1,\"extended_bounds\":{}}},{\"id\":\"3\",\"type\":\"terms\",\"schema\":\"group\",\"params\":{\"field\":\"container_Name\",\"size\":5,\"order\":\"desc\",\"orderBy\":\"1\"}},{\"id\":\"4\",\"type\":\"terms\",\"schema\":\"split\",\"params\":{\"field\":\"machine_name\",\"size\":5,\"order\":\"desc\",\"orderBy\":\"1\",\"row\":true}}],\"listeners\":{}}",
      "uiStateJSON": "{}",
      "description": "",
      "version": 1,
      "kibanaSavedObjectMeta": {
        "searchSourceJSON": "{\"index\":\"cadvisor*\",\"query\":{\"query_string\":{\"query\":\"* NOT container_Name.raw: \\\\\\\"/\\\\\\\" AND NOT container_Name.raw: \\\\\\\"/docker\\\\\\\"\",\"analyze_wildcard\":true}},\"filter\":[]}"
      }
    }
  }
]

这里还有很多东西可以玩,你也许想自定义报表界面,比如添加内存页错误状态,或者收发包的丢包数。如果你能实现开头列表处我没能实现的项目,那也是很好的。

总结

正确监控需要大量时间和精力,容器的 CPU、内存、IO、网络和磁盘,监控的这些参数还只是整个监控项目中的沧海一粟而已。

我不知道你做到了哪一阶段,但接下来的任务也许是:

  • 收集运行中的容器的日志
  • 收集应用的日志
  • 监控应用的性能
  • 报警
  • 监控健康状态

如果你有意见或建议,请留言。祝你玩得开心。

现在你可以关掉这些测试系统了:

docker-machine rm master1 worker{1,2}

via: https://blog.codeship.com/monitoring-docker-containers-with-elasticsearch-and-cadvisor/

作者:Lorenzo Fontana 译者:bazz2 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

Shinken 是一个用 Python 实现的开源的主机和网络监控框架,并与 Nagios like 兼容,它可以运行在所有支持 Python 程序的操作系统上,比如说 Linux、Unix 和 Windows。Shinken 是 Jean Gabes 为了验证一个新的 Nagios 架构思路而编写,但是这个想法被 Nagios 的作者拒绝后成为了一个独立的网络系统监视软件,并保持了与 Nagios 的兼容。

在这篇教程中,我将会描述如何从源代码编译安装 Shinken 和向监视系统中添加一台 Linux 主机。我将会以 Ubuntu 16.04 Xenial Xerus 操作系统来作为 Shinken 服务器和所监控的主机。

第一步 安装 Shinken 服务器

Shinken 是一个 Python 框架,我们可以通过 pip 安装或者从源码来安装它,在这一步中,我们将用源代码编译安装 Shinken。

在我们开始安装 Shinken 之前还需要完成几个步骤。

安装一些新的 Python 软件包并创建一个名为 shinken 的系统用户:

sudo apt-get install python-setuptools python-pip python-pycurl
useradd -m -s /bin/bash shinken

从 GitHub 仓库下载 Shinken 源代码:

git clone https://github.com/naparuba/shinken.git
cd shinken/

然后用以下命令安装 Shinken:

git checkout 2.4.3
python setup.py install

然后,为了得到更好的效果,我们还需要从 Ubuntu 软件库中安装 python-cherrypy3 软件包:

sudo apt-get install python-cherrypy3

到这里,Shinken 已经成功安装,接下来我们将 Shinken 添加到系统启动项并且启动它:

update-rc.d shinken defaults
systemctl start shinken

第二步 安装 Shinken Webui2

Webui2 是 Shinken 的 Web 界面(在 shinken.io 可以找到)。最简单的安装 Shinken webui2 的方法是使用shinken CLI 命令(必须作为 shinken 用户执行)。

切换到 shinken 用户:

su - shinken

初始化 shiken 配置文件,下面的命令将会创建一个新的配置文件 .shinken.ini

shinken --init

接下来用 shinken CLI 命令来安装 webui2

shinken install webui2

至此 webui2 已经安装好,但是我们还需要安装 MongoDB 和用 pip 来安装另一个 Python 软件包。在 root 下运行如下命令:

sudo apt-get install mongodb
pip install pymongo>=3.0.3 requests arrow bottle==0.12.8

接下来,切换到 shinken 目录下并且通过编辑 broker-master.cfg 文件来添加这个新的 webui2 模块:

cd /etc/shinken/brokers/
vim broker-master.cfg

在第 40 行添加一个模块选项:

modules     webui2

保存文件并且退出编辑器。

现在进入 contacts 目录下编辑 admin.cfg 来进行管理配置。

cd /etc/shinken/contacts/
vim admin.cfg

按照如下修改:

contact_name    admin       # Username 'admin'
password        yourpass    # Pass 'mypass'

保存和退出。

第三步 安装 Nagios 插件和 Shinken 软件包

在这一步中,我们将安装 Nagios 插件和一些 Perl 模块。然后从 shinken.io 安装其他的软件包来实现监视。

安装 Nagios 插件和安装 Perl 模块所需要的 cpanminus

sudo apt-get install nagios-plugins* cpanminus

cpanm 命令来安装 Perl 模块。

cpanm Net::SNMP
cpanm Time::HiRes
cpanm DBI

现在我们创建一个 utils.pm 文件的链接到 shinken 的目录,并且为 Log_File_Health 创建了一个新的日志目录 。

chmod u+s /usr/lib/nagios/plugins/check_icmp
ln -s /usr/lib/nagios/plugins/utils.pm /var/lib/shinken/libexec/
mkdir -p /var/log/rhosts/
touch /var/log/rhosts/remote-hosts.log

然后,从 shinken.io 安装 shinken 软件包 sshlinux-snmp 来监视 SSH 和 SNMP :

su - shinken
shinken install ssh
shinken install linux-snmp

第四步 添加一个 Linux 主机 host-one

我们将添加一个新的将被监控的 Linux 主机,IP 地址为 192.168.1.121,主机名为 host-one 的 Ubuntu 16.04。

连接到 host-one 主机:

ssh [email protected]

从 Ubuntu 软件库中安装 snmp 和snmpd 软件包:

sudo apt-get install snmp snmpd

然后,用 vim 编辑 snmpd.conf 配置文件:

vim /etc/snmp/snmpd.conf

注释掉第 15 行并取消注释第 17 行:

#agentAddress  udp:127.0.0.1:161
agentAddress udp:161,udp6:[::1]:161

注释掉第 51 和 53 行,然后加一行新的配置,如下:

#rocommunity mypass  default    -V systemonly
#rocommunity6 mypass  default   -V systemonly

rocommunity mypass

保存并退出。

现在用 systemctl 命令来启动 snmpd 服务:

systemctl start snmpd

在 shinken 服务器上通过在 hosts 文件夹下创建新的文件来定义一个新的主机:

cd /etc/shinken/hosts/
vim host-one.cfg

粘贴如下配置信息:

define host{
        use                 generic-host,linux-snmp,ssh
        contact_groups      admins
        host_name           host-one
        address             192.168.1.121
        _SNMPCOMMUNITY      mypass        # SNMP Pass Config on snmpd.conf
    }

保存并退出。

在 shinken 服务器上编辑 SNMP 配置文件。

vim /etc/shinken/resource.d/snmp.cfg

public 改为 mypass -必须和你在客户端 snmpd 配置文件中使用的密码相同:

$SNMPCOMMUNITYREAD$=mypass

保存并退出。

现在将服务端和客户端都重启:

reboot

现在 Linux 主机已经被成功地添加到 shinken 服务器中了。

第五步 访问 Shinken Webui2

在端口 7677 访问 Shinken webui2 (将 URL 中的 IP 替换成你自己的 IP 地址):

http://192.168.1.120:7767

用管理员用户和密码登录(你在 admin.cfg 文件中设置的)

Webui2 中的 Shinken 面板:

我们的两个服务器正在被 Shinken 监控:

列出所有被 linux-snmp 监控的服务:

所有主机和服务的状态信息:

第6步 Shinken 的常见问题

NTP 服务器相关的问题

当你得到如下的 NTP 错误提示

TimeSync - CRITICAL ( NTP CRITICAL: No response from the NTP server)
TimeSync - CRITICAL ( NTP CRITICAL: Offset unknown )

为了解决这个问题,在所有 Linux 主机上安装 ntp。

sudo apt-get install ntp ntpdate

编辑 ntp 配置文件:

vim /etc/ntp.conf

注释掉所有 pools 并替换为:

#pool 0.ubuntu.pool.ntp.org iburst
#pool 1.ubuntu.pool.ntp.org iburst
#pool 2.ubuntu.pool.ntp.org iburst
#pool 3.ubuntu.pool.ntp.org iburst

pool 0.id.pool.ntp.org
pool 1.asia.pool.ntp.org
pool 0.asia.pool.ntp.org

然后,在新的一行添加如下限制规则:

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict 192.168.1.120 #shinken server IP address
restrict ::1
NOTE: 192.168.1.120 is the Shinken server IP address.

保存并退出。

启动 ntp 并且检查 Shinken 面板。

ntpd

check\_netint.pl Not Found 问题

从 github 仓库下载源代码到 shinken 的库目录下:

cd /var/lib/shinken/libexec/
wget https://raw.githubusercontent.com/Sysnove/shinken-plugins/master/check_netint.pl
chmod +x check_netint.pl
chown shinken:shinken check_netint.pl

网络占用的问题

这是错误信息:

ERROR : Unknown interface eth\d+

检查你的网络接口并且编辑 linux-snmp 模版。

在我的 Ununtu 服务器,网卡是 “enp0s8”,而不是 eth0,所以我遇到了这个错误。

vim 编辑 linux-snmp 模版:

vim /etc/shinken/packs/linux-snmp/templates.cfg

在第 24 行添加网络接口信息:

_NET_IFACES         eth\d+|em\d+|enp0s8

保存并退出。


via: https://www.howtoforge.com/tutorial/server-monitoring-with-shinken-on-ubuntu-16-04/

作者:Muhammad Arul 译者:LinuxBars 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

Save and exit.

Multiload-ng 是一个 GTK2 图形化系统监视器应用,可集成到 Xfce、LXDE 及 MATE 的桌面面板中, 它 fork 自原来的 GNOME Multiload 应用。它也可以运行在一个独立的窗口中。

Multiload-ng 的特点有:

  • 支持以下资源的图形块: CPU,内存,网络,交换空间,平均负载,磁盘以及温度;
  • 高度可定制;
  • 支持配色方案;
  • 自动适应容器(面板或窗口)的改变;
  • 极低的 CPU 和内存占用;
  • 提供基本或详细的提示信息;
  • 可自定义双击触发的动作。

相比于原来的 Multiload 应用,Multiload-ng 含有一个额外的图形块(温度),以及更多独立的图形自定义选项,例如独立的边框颜色,支持配色方案,可根据自定义的动作对鼠标的点击做出反应,图形块的方向可以被设定为与面板的方向无关。

它也可以运行在一个独立的窗口中,而不需要面板:

另外,它的 GitHub page 上说还会带来更多的图形块支持。

下图展示的是在带有一个垂直面板的 Xubuntu 16.04 中,该应用分别处于水平和垂直方向的效果:

这个应用的偏好设置窗口虽然不是非常好看,但是有计划去改进它:

Multiload-ng 当前使用的是 GTK2,所以它不能在构建自 GTK3 下的 Xfce 或 MATE 桌面环境(面板)下工作。

对于 Ubuntu 系统而言,只有 Ubuntu MATE 16.10 使用 GTK3。但是鉴于 MATE 的系统监视器应用也是 Multiload GNOME 的一个分支,所以它们大多数的功能相同(除了 Multiload-ng 提供的额外自定义选项和温度图形块)。

该应用的愿望清单 中提及到了计划支持 GTK3 的集成以及各种各样的改进,例如温度块资料的更多来源,能够显示十进制(KB、MB、GB……)或二进制(KiB、MiB、GiB……)单位等等。

安装 Multiload-ng

请注意因为依赖的关系, Multiload-ng 不能在 Lubuntu 14.04 上构建。

Multiload-ng 可在 WebUpd8 的主 PPA (针对 Ubuntu 14.04 - 16.04 / Linux Mint 17.x 和 18)中获取到。可以使用下面的命令来添加 PPA 并更新软件源:

sudo add-apt-repository ppa:nilarimogard/webupd8
sudo apt update

然后可以使用下面的命令来安装这个应用:

对于 LXDE (Lubuntu):

sudo apt install lxpanel-multiload-ng-plugin

对于 Xfce (Xubuntu,Linux Mint Xfce):

sudo apt install xfce4-multiload-ng-plugin

对于 MATE (Ubuntu MATE,Linux Mint MATE):

sudo apt install mate-multiload-ng-applet

独立安装 (不需要集成到面板):

sudo apt install multiload-ng-standalone

一旦安装完毕,便可以像其他应用那样添加到桌面面板中了。需要注意的是在 LXDE 中,Multiload-ng 不能马上出现在面板清单中,除非重新启动面板。你可以通过重启会话(登出后再登录)或者使用下面的命令来重启面板:

lxpanelctl restart

独立的 Multiload-ng 应用可以像其他正常应用那样从菜单中启动。

如果要下载源码或报告 bug 等,请看 Multiload-ng 的 GitHub page


via: http://www.webupd8.org/2016/08/alternative-system-monitor-applet-for.html

作者:Andrew 译者:FSSlc 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出