Grafana是一个独立运行的系统，内置了Web服务器。它可以基于仪表盘的方式来展示、分析时间序列数据。

Grafana支持多种数据源，例如：Graphite、OpenTSDB、InfluxDB、Elasticsearch。你可以混合使用多种数据源。它对Graphite有以下增强的支持：

1. 点击修改Metrics路径的每一个片断
2. 快速的添加函数，支持点击函数参数以修改之
3. 修改函数顺序
4. 丰富的模板支持

在UI方面，Grafana具有以下特性：

1. 丰富的、基于客户端的图表组件：Bar图、区域图、线图。支持多Y轴
2. 支持点击/选择以缩放（Zoom）时间区间
3. 支持混合多种图表组件，一起展示或者堆叠展示
4. 支持定制图表的配色，支持黑白两种主题
5. 支持拖放仪表盘面板（Panel），支持多种面板类型
6. 支持脚本化仪表盘、仪表盘模板
7. 通过来自数据源的事件（例如Graphite的Events），可以对仪表进行标注

依次执行下面的命令完成安装：

# CentOS
yum install initscripts fontconfig
wget https://grafanarel.s3.amazonaws.com/builds/grafana-3.1.1-1470047149.x86_64.rpm
rpm -Uvh grafana-3.1.1-1470047149.x86_64.rpm

设置为开机启动：

/bin/systemctl daemon-reload
/bin/systemctl enable grafana-server.service

启动服务：

systemctl start grafana-server.service

helm repo update gmem
helm del --purge grafana
helm install gmem/grafana --name grafana --namespace kube-system

# 执行下面的命令获得初始密码
kubectl get secret --namespace kube-system grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo

值覆盖情况参考：https://github.com/gmemcc/charts/tree/master/grafana

grafana-cli plugins install grafana-kubernetes-app
grafana-cli plugins install natel-plotly-panel
grafana-cli plugins install kentik-app
grafana-cli plugins install alexanderzobnin-zabbix-app
grafana-cli plugins install grafana-worldmap-panel
grafana-cli plugins install grafana-clock-panel
grafana-cli plugins install grafana-piechart-panel
grafana-cli plugins install percona-percona-app
grafana-cli plugins install digrich-bubblechart-panel
grafana-cli plugins install digiapulssi-breadcrumb-panel
grafana-cli plugins install petrslavotinek-carpetplot-panel
grafana-cli plugins install neocat-cal-heatmap-panel
grafana-cli plugins install briangann-gauge-panel
grafana-cli plugins install jdbranham-diagram-panel

安装插件后，需要重新启动Grafana服务：

service grafana-server restart

当Grafana服务启动时，会读取

/etc/sysconfig/grafana-server

默认的，日志文件存储目录为/var/log/grafana，数据存储目录为/var/lib/grafana。默认使用SQLite数据库/var/lib/grafana/grafana.db。

如果基于deb/rpm包进行安装，则主配置文件的位置为：

/etc/grafana/grafana.ini

127.0.0.1:3306

使用Grafana的日常工作包括：用户管理、系统管理、仪表盘设计、数据源管理，等等。所有这些工作都在Web界面

http://GRAFANA_HOST:3000

点击Web界面左上角的图标，下拉列表中选择Data Sources，即可管理数据源。

点击Add data source按钮，添加新的数据源，参考下图：

注意Access设置成proxy，则数据通过Grafana间接获取，否则，数据直接通过客户端获取。添加Graphite数据源后，可以点击Dashboards选项卡，获得其预置的仪表盘Graphite Carbon Metrics并导入到Grafana中。

点击Web界面左上角的图标，下拉列表中选择Dashboards  ⇨ New，可以新建仪表盘。在新仪表盘中，点击左侧的绿条，可以添加新的面板；点击右下侧ADD ROW按钮则可以新建一行。

The post 使用Grafana展示时间序列数据 appeared first on 绿色记忆.

Graphite是一个开源项目，可以作为时间序列数据库（TSDB）使用，当你需要存储随着时间变化的数值时，应当考虑使用时间序列数据库。

除了数据的存储、查询外，Graphite还提供数据可视化（UI层）功能，它可以很好的在廉价的硬件上运行。你可以使用Graphite来监控网站、应用程序、网络服务器等的性能数据（Metrics），轻松实现基于时间维的分析。

Graphite本身不负责性能数据的采集，但是它提供了简单易用的接口，公共这些接口你可以把基于数字的性能数据存储到Graphite中。

Graphite由三个组件构成：

1. Carbon：一个基于Twisted（Python事件驱动网络框架）的守护程序，负责监听外部的时间序列数据
2. Whisper：一个简单的存储时间序列数据的数据库，设计上和RRDtool类似 
3. Graphite-Web：一个基于Django（Python Web框架）的Web应用，使用Cairo（一个2D图形库）来渲染性能数据的图表，使用ExtJS作为基础UI框架

下面是Graphite的架构图：

一旦你把数据送给Carbon，它就立刻可以在Webapp的图表中显示，因为数据在被写入文件系统之前，会驻留在缓存中。

除了使用Graphite Webapp，你也可以通过URL API，将图表嵌入到自己的应用程序中去。如何使用Graphite

使用Graphite来监控你的性能数据，你需要完成以下工作：

1. 理解Graphite组件的职责和相互关系
2. 安装Graphite及其依赖
3. 基础的配置，让Graphite能运行起来
4. 设计Metrics路径
5. 配置Metrics的驻留规则、聚合规则等
6. 向Graphite发送Metrics
7. 从Graphite获取Metrics并展示

Metrics路径由点号分隔的字符串构成，类似于Python的包名称。路径是Metrics的标识。

你应当仔细的设计此路径的命名空间，以反映出所有Metrics之间的层次关系。例如servers.zircon.cpu，这个三级路径设计中，第一级表示设备类别，第二级表示设备名称，第三级表示监测点类型。

Carbon由一系列的守护进程组成，这些守护进程共同组成Graphite的存储后端。在最小化的安装下，只有一个守护进程carbon-cache.py。根据需要你可以启用carbon-relay.py、carbon-aggregator.py以便实现Metrics分发、定制聚合规则。各Carbon守护进程简介如下：

Whisper是一个固定大小（fixed-size）的数据库，其设计和用途与RRD（round-robin-database）类似。它能提供快速、可靠的数值数据的存储。

Whisper能够对最近的数据进行高分辨率的存储，而对久远的历史数据，自动降低其存储精度（减少样本数量）。

在大多数场景下，Whisper有足够好的性能。它比RRDtool慢，主要原因是Whisper基于Python编写，这个性能差异很小，通常不需要考虑。

Whisper数据库以文件方式存放在磁盘上，扩展名.wsp。Carbon会为每个Metrics创建一个.wsp文件，路径的最后一节作为文件的basename，路径的其它部分形成目录层次。

在Whisper中存储的每一个数值，称为数据点（Data Points）。

在磁盘上，数据点以大端、双精度浮点数存储。每个数据还附带一个时间戳信息，时间戳为1970-01-01到数据采集时间的秒数。

一个Whisper数据库文件可以包含一个或者多个“归档”，归档是数据文件中的逻辑段。

每个归档具有不同的数据分辨率（一定时间段内，数据点数量越多，则分辨率越高）。归档以最高分辨率（最小驻留时间） —— 最低分辨率（最长驻留时间）的顺序，在数据库文件中顺序排列。

为了精确的从高分辨率向低分辨率的归档聚合，高分辨率归档和它之后的低分辨率归档，其分辨率应当具有整除关系。例如，第一个归档分辨率为60秒/数据点，那么第二个归档可以是300秒/数据点，第三个归档可以是3600秒/数据点。

一个数据库的总计驻留时间（存放的数据点跨越的时间），由最长驻留时间的（最后一个）归档确定。因为之前的那些归档，时间区间都是它的子区间。

把数据点转移到低分辨率归档时，面临着如何把多个数据点转变为单个数据点的问题。Whisper支持average、sum、last、max、min等聚合函数。

注意，这里的聚合和Carbon提供的前置聚合不是一回事。

当Whisper向一个多归档数据写入Metrics时，数据点将被同时写入到所有的归档中。这意味着聚合动作随时可能发生。

当从Whisper中获取数据时，第一个能完整覆盖所需区间的归档被使用。

Whisper的磁盘利用效率不高，因为：

1. 每个数据点要附加一个时间戳信息
2. 由于归档的时间区间有重叠，因此数据存在冗余
3. 归档中的时间槽位（time-slots）总是占据着磁盘空间，不管有没有值存储在其中

这些特征是故意的，主要出于性能方面的考虑。

1. RRD不能去填充以前的时间槽位。这意味着每一条数据都必须是更新的，不会“补录”
2. RRD不能很好的支持不规则的数据更新。如果RRD接收到一条数据，但是后续数据没有到来，则前一条数据可能丢失

git clone https://github.com/graphite-project/graphite-web.git
graphite-web/check-dependencies.py
# 根据输出的提示来判断缺少哪些依赖，然后安装

yum -y install python-devel     # Carbon 依赖于 Python Development Headers

yum install pycairo             # Cairo库的Python绑定

pip install django              # Web框架
pip install django-tagging

pip install pytz

yum install fontconfig

yum install -y memcached        # 可选，缓存支持
pip install python-memcached    
                                # 可选，RDDTool
yum install cairo-devel libxml2-devel pango-devel pango libpng-devel freetype freetype-devel libart_lgpl-devel rrdtool-devel

pip install python-rrdtool      # 可选，RRD支持

pip install whitenoise          # 用于Web静态文件处理

yum install pyOpenSSL           # OpenSSL的Python绑定
pip install service_identity    # SSL相关

pip install https://github.com/graphite-project/ceres/tarball/master
pip install whisper
pip install carbon
pip install graphite-web

sudo groupadd graphite
sudo usermod -a -G graphite root
sudo usermod -a -G graphite apache
sudo chgrp -R graphite /opt/graphite/storage
sudo chmod -R 770 /opt/graphite/storage

Whisper被安装到Python全局site-packages目录，另外两个Graphite组件安装到

/opt/graphite

$GRAPHITE_ROOT

$STORAGE_DIR

你需要让Graphite-web的底层框架Django执行数据库的初始化。此数据库被用来存放用户设置、仪表盘，以及支持事件功能。

默认情况下，Graphite-web使用位于$STORAGE_DIR/graphite.db的SQLite数据库。如果要运行多个Graphite-web实例，则必须使用MySQL等数据库以便多个实例可以共享数据。 

执行下面的命令初始化SQLite数据库：

PYTHONPATH=/opt/graphite/webapp django-admin.py migrate --settings=graphite.settings --run-syncdb
# 完毕后 $STORAGE_DIR/graphite.db自动创建

Django应用需要在Web服务器中运行，Web服务器需要对SQLite数据文件有读写权限。假设你使用Apache2，运行Apache2的用户为apache，则需要执行：

sudo chgrp graphite /opt/graphite/storage/graphite.db

Graphite不建议修改settings.py，所有定制化的配置，都应该在此文件中进行。常用的设置项如下表：

rrdtool flushcached

DEFAULT_CACHE_POLICY = [
    (0, 60), # 默认缓存60秒
    (7200, 120) # >= 2小时以上时间范围的查询，缓存2分钟
] 

# 如果报Unknown command: 'collectstatic' 说明INSTALLED_APPS中缺少
# django.contrib.staticfiles	
PYTHONPATH=/opt/graphite/webapp django-admin.py collectstatic 
    --noinput --settings=graphite.settings

Alias /static/ "/opt/graphite/static"

我们的配置如下：

# 如果不设置，会导致报错：AttributeError: 'Settings' object has no attribute 'URL_PREFIX
URL_PREFIX = '/'

多种Web服务器可以用于运行基于Django的Web应用，这里我们选择Apache2。在CentOS下安装Apache2：

yum install httpd

要让Apache2能够运行Python Web应用，需要安装模块mod_wsgi。参考Django学习笔记完成mod_wsgi的构建与安装。

在/opt/graphite/examples/目录下，example-graphite-vhost.conf可以作为Apache虚拟主机的模板，复制该文件到/etc/httpd/conf.d/目录下，然后修改：

<IfModule !wsgi_module.c>
    LoadModule wsgi_module modules/mod_wsgi.so
</IfModule>
WSGISocketPrefix run/wsgi
<VirtualHost *:7767>
        ServerName xcentos7.local
        DocumentRoot "/opt/graphite/webapp"
        ErrorLog /opt/graphite/storage/log/webapp/error.log
        CustomLog /opt/graphite/storage/log/webapp/access.log common
        WSGIDaemonProcess graphite processes=5 threads=5 display-name='%{GROUP}' inactivity-timeout=120
        WSGIProcessGroup graphite
        WSGIApplicationGroup %{GLOBAL}
        WSGIImportScript /opt/graphite/conf/graphite.wsgi process-group=graphite application-group=%{GLOBAL}
        WSGIScriptAlias / /opt/graphite/conf/graphite.wsgi
        Alias /content/ /opt/graphite/webapp/content/
        <Directory /opt/graphite/webapp/content/>
            Require all granted
        </Directory>
        <Directory /opt/graphite/conf/>
            Require all granted
        </Directory>
</VirtualHost>

如果配置没有问题，启动Web服务器后访问：

http://GRAPHITE_HOST:GRAPHITE_PORT/render

所有Carbon守护进程可以基于多种通信协议，监听时间序列数据，并且对数据进行不同的处理。

Carbon的配置文件位于/opt/graphite/conf/目录，默认情况下没有预置的配置文件，但是Graphite提供了若干配置文件样例。你可以复制这些配置文件并定制：

pushd /opt/graphite/conf
cp carbon.conf.example carbon.conf
cp storage-schemas.conf.example storage-schemas.conf

这是主配置文件，为每个Carbon守护进程定义配置项。该配置文件按段区分不同守护进程的配置：

这个配置文件用于定义Metrics的驻留率（ retention rates）——即Metrics的数据点（datapoints）以什么频率保存，保存多长时间。关于该配置文件，需要注意：

1. 该配置文件可以由多个段（Section）组成。每个段定义一个存储规则
2. 这些规则按照从上到下的顺序对Metrics进行匹配，第一个匹配的规则对Metrics生效
3. 匹配Metrics时，采用的是正则表达式
4. 对于一个Metrics，其存储规则在接收到第一个数据时固化。因而修改此配置文件不会影响到既有的.wsp文件。要应用到既有的.wsp可以调用whisper-resize.py

每个规则由三个部分组成：

# 段名称（规则名称），主要是文档用途。在匹配段的Metrics被创建时，日志creates.log中会显示此名称
[rulename]
# 匹配Metrics路径（Metrics的全限定名称，点号分隔）的正则式
# 举例：^servers\.www.*\.workers\.busyWorkers$
pattern=regex
# 驻留率表达式，数据点间隔:存留天数，时间后缀s,m,h,d,y分别表示秒、分、小时、天、年
# 举例：10s:14d 表示每个数据点表示10秒（相当于每10秒采集数据一次），并且存储14天的数据
retentions=retention rate

注意，你可以指定多重驻留率表达式（retention rate），逗号分隔每个表达式。一般从最高精度:最短存留时间开始指定，直到最低精度:最长存留时间。例如：

15s:7d,1m:21d,15m:5y

设置多重驻留率表达式，可以在保存足够长时间的历史数据的前提下，尽量减少磁盘I/O和消耗的存储空间。当跨越驻留表达式的时间区间（上例中7天，21天）后，whisper会自动降低采样率（downsamples），默认算法是取平均值，可以通过storage-aggregation.conf定制聚合方式

这个配置文件定义如何在降低采样率（转换为低精度存储时） 如何对数据进行聚合。该文件的格式与storage-schemas.conf类似：

[rulename]
pattern = rexexp
# 0-1之间的浮点数，默认0.5。聚合区间内的值，至少多少比例为非空，聚合后的值才是非空
xFilesFactor = 0.5
# 数据聚合方式，默认average
aggregationMethod = average | sum | min | max | last

同样的，修改此文件不会影响已经生成的.wsp文件， 要应用到既有的.wsp文件，可以调用whisper-set-aggregation-method.py。

这个配置文件指定中继规则——即需要把何种Metrics转发给何种后端。中继由Carbon的中继进程负责执行。该文件格式如下：

[rulename]
pattern = regex
servers = ip:port,ip:port,...

该配置文件定义聚合出来的Metrics——由几个Metrics聚合而成的新的Metrics。聚合由Carbon的聚合进程负责执行。

注意：这里的聚合storage-aggregation.conf提及的聚合不同。后者用于单一Metrics的降低采样，而前者用于生成新的Metrics。

与其它配置文件不同，该文件一旦更改，立即生效。

该文件的格式如下：

# 捕获任何匹配input_pattern的Metrics，使用method聚合成新的Metrics：output_template
# frequency：每隔多久执行一次聚合
# method：可选sum/avg
output_template (frequency) = method input_pattern

举例，假设你的Metrics的命名规则是：

<env>.applications.<app>.<server>.<metric>

这是你可以配置如下聚合规则，来计算所有应用程序的请求的总数：

<env>.applications.<app>.all.requests (60) = sum <env>.applications.<app>.*.requests

在此规则下，下面的Metrics：

test.applications.pems.221.request
test.applications.pems.6.request
test.applications.pems.5.request
test.applications.pems.201.request

会每个60秒求和并生成 

test.applications.pems.all.request

该配置文件定义Metrics名称的改写规则。 与其它配置文件不同，该文件一旦更改，立即生效。该文件的格式如下：

[pre]
# pre段的规则，在接收到数据后立即执行改写
[post]
# post段的规则，在聚合完毕后执行改写
regex-pattern = replacement-text

 举例：

# \1表示第一个捕获，即[a-z0-9]+
^collectd\.([a-z0-9]+)\. = \1.system.
# collectd.prod.cpu-0.idle-time 会被改写为 prod.system.cpu-0.idle-item

Carbon提供黑白名单功能。白名单：仅仅接受其中列出的Metrics；黑名单：拒绝其中列出Metrics。

要启用黑白名单功能，需要修改carbon.conf，设置

USE_WHITELIST = True

如何启动Graphite Webapp依赖于其运行的Web服务软件，以Apache为例：

# CentOS 7
systemctl restart httpd

Carbon组件需要执行下面的命令来启动：

/opt/graphite/bin/carbon-cache.py start

SQLite是一个“文件数据库”，不需要启动。如果Graphite Webapp使用其它数据库，例如MySQL，则需要启动之。 

你可以通过多种方式向Graphite（的Carbon组件）发送Metrics数据点。主要的三种数据格式是：Plaintext、Pickle、AMQP 

这种方式非常简单，你可以用如下格式来发送一条Metrics数据点：

<metric path> <metric value> <metric timestamp>
# 举例：
servers.zircon.cpu 85 1470303923

出于测试目的，你可以直接通过命令向Carbon发送Metrics数据：

PORT=2003
SERVER=127.0.0.1
echo "servers.zircon.cpu 85 `date +%s`" | nc ${SERVER} ${PORT}

Pickle是Python下的对象串行化框架，Pickle协议即它的串行化格式协议。使用该协议，你可以一次发送多个Metrics，并且串行化后的数据比较紧凑，因此Pickle协议性能更好。

下面是构建Pickle报文的示例代码：

listOfMetricTuples = [
    (path, (timestamp, value)),
    ...
]
payload = pickle.dumps(listOfMetricTuples, protocol=2)
header = struct.pack("!L", len(payload))
message = header + payload
# 然后通过Socket把message发送出去即可

import pickle
import socket
import struct
import sys
import time
from time import sleep

import psutil


def get_cpu_load():
    load = psutil.cpu_percent()
    print load
    return load


if __name__ == '__main__':
    CARBON_HOST = '172.16.87.132'
    CARBON_PORT = 2004
    s = socket.socket()
    try:
        s.connect((CARBON_HOST, CARBON_PORT))
        while True:
            data = [
                ('servers.zircon.cpu', (time.time(), get_cpu_load()))
            ]
            pkg = pickle.dumps(data, 1)
            s.sendall(struct.pack('!L', len(pkg)))
            s.sendall(pkg)
            sleep(5)
    except socket.error:
        raise SystemExit("Failed to connect to %(host)s:%(port)" % {'host': CARBON_HOST, 'port': CARBON_PORT})
    except KeyboardInterrupt:
        sys.stderr.write("\nExiting on CTRL-C\n")
        sys.exit(0) 

要从Graphite获取数据用于展示，可以使用Graphite Webapp暴露的Render URL API（RUA）。你可以通过

http://GRAPHITE_HOST:GRAPHITE_PORT/render

访问此API。要向RUA传递参数，可以使用URL请求参数方式：

&name=value

下面列出几个RUA的URL示例：

# Zircon的CPU负载图，获取800x600的图片
http://graphite/render?target=servers.zircon.cpu&height=800&width=600
# 最近12小时，所有服务器的CPU负载平均值
http://graphite/render?target=averageSeries(servers.*.load)&from=-12hours
# 获取原始数据而不是图片，JSON格式
http://graphite/render?target=servers.zircon.cpu&format=json

该参数用来指定从何处获取数据，你可以指定：

1. 单个Metrics路径
2. 带有通配符的的Metrics路径，匹配多个Metrics
3. 函数调用，针对作为入参的Metrics进行各种转换、合并操作

你可以在路径中使用三种风格的通配符：

1. *

    可以匹配0-N个字符，例如

   servers.dev-*.cpu

    ，可以匹配所有开发服务器的CPU负载Metrics。

2. [...]

    可以匹配列表中枚举的单个字符，例如

   servers.dev-[a-z0-9].cpu

    ，可以匹配dev-0、dev-1等服务器的CPU负载Metrics。

3. {...}

    可以匹配列表中枚举的单个字符串，例如

   servers.{dev-0,dev-1}.cpu

    ，匹配dev-0、dev-2的CPU负载Metrics。

注意：所有通配符都不能跨越点号。 

你可以指定target为template函数调用，从而在Metrics路径中使用变量，例如：

# $varname 用来声明变量占位符
# template[varname]参数用来传递变量值
&target=template(servers.$servername.cpu)&template[servername]=zircon

# 可以使用数字代替变量名
&target=template(servers.$1.cpu)&template[1]=zircon

# template可以内嵌其它函数
&target=template(constantLine($number))&template[number]=123

可用的函数较多，这里不一一列举说明，参见官方文档。

这两个可选参数用来指定相对或者绝对的时间区间（time period）。from表示区间起点，如果忽略，默认值是24小时之前；until表示区间终点，如果或略，默认值是当前时间点。

如果要使用相对时间，需要加上

-

你可以指定

HH:MM_YYYYMMDD

YYYYMMDD

 MM/DD/YY

该参数用来指定要获取的数据的格式。 支持以下取值：

<target name>,<start timestamp>,<end timestamp>,<series step>|[data]*

entries,1311836008,1311836013,1|1.0,2.0,3.0,5.0,6.0

entries,2011-07-28 01:53:28,1.0
entries,2011-07-28 01:53:29,2.0
entries,2011-07-28 01:53:30,3.0
entries,2011-07-28 01:53:31,5.0
entries,2011-07-28 01:53:32,6.0

[{
  "target": "entries",
  "datapoints": [
    [1.0, 1311836008],
    [2.0, 1311836009],
    [3.0, 1311836010],
    [5.0, 1311836011],
    [6.0, 1311836012]
  ]
}]

{
  "labels" : [
    "Time",
    "entries"
  ],
  "data" : [
    [1468791890000, 0.0],
    [1468791900000, 0.0]
  ]
}

[{
  "target": "entries",
  "datapoints": [{
    "y": 0.0,
    "x": 1468791890
  }, {
    "y": 0.0,
    "x": 1468791900
  }]
}]

[
  {
    'name' : 'summarize(test.data, "30min", "sum")',
    'start': 1335398400,
    'end'  : 1335425400,
    'step' : 1800,
    'values' : [None, None, 1.0, None],
  }
]

你可以指定多个参数，来控制生成的图形的样式：

# 颜色名称
&bgcolor=blue
# HEX代码
&bgcolor=2222FF
# HEX代码，包含透明度
&bgcolor=5522FF60

上一章内容我们讨论了如何获取Graphite数据。通过Render URL API，我们不但可以获得文本数据，还可以直接获得渲染好的图片。这意味着通过Render URL API本身就可以实现Metrics的渲染，你只需要把生成的图片嵌入到自己的应用程序中即可。

Graphite Webapp本身提供了基于ExtJS的一个管理界面，你可以通过

http://GRAPHITE_HOST:GRAPHITE_PORT/admin

Graphite生成的Metrics曲线的图片，不是非常美观，而静态图片也缺乏交互性。因此，实际项目中常常结合使用第三方基于JavaScript的Charts库来做展示，例如：

1. Grafana：UI比较绚丽，支持设计仪表盘、时间区间联动。参见：使用Grafana展示时间序列数据
2. Graphene：一个较为简单的，基于D3.js和Backbone.js的Graphite仪表盘工具

除了简单的，基于Key/Value的Metrics数据，Graphite还可以存储、展示随机出现的数据——事件。

事件不适合存储在Whisper中，因此它被存储在Graphite的Webapp的数据库中（默认使用SQLite）。

通过向

http://GRAPHITE_HOST:GRAPHITE_PORT/events/

{ 
    "what": "事件类型", 
    "tags": "标签",
    "data": "事件相关的数据" 
}

指定target为

event(*tags)

/render

[
   {
      "target" : "events(mytag)",
      "datapoints" : [
         [
            1,
            1388966651
         ],
         [
            3,
            1388966652
         ]
      ]
   }
]

你也可以通过

/render/events/get_data

[
   {
      "when" : 1392046352,
      "tags" : "mytag",
      "data" : "...",
      "id" : 2,
      "what" : "Event - deploy"
   }
] 

Django的request对象曾经有一个属性REQUEST，用来获得通过GET或者POST请求传递的请求参数，在1.9版本中此属性已经移除。

Graphite代码没有即时更新，存在不兼容的问题，修改一下即可：

def parseOptions(request):
   queryParams = request.GET # request.REQUEST已经被移除

还有很多其它views.py存在同样的问题，最好搜索一下一并修改。如果觉得麻烦可以安装兼容版本的Django：

pip install django==1.8.14

The post Graphite学习笔记 appeared first on 绿色记忆.

Shinken是一个开源的IT监控框架，基于Python编写。Shinken从2009年开始发布，起初是作为一个简单的监控解决方案，由于越来越多的模块的加入，至2014年它被重新定位为“框架”。

Shinken的优势包括：

1. 跨平台，它可以在Windows、Linux上部署和运行
2. 独立性，不依赖于其它监控解决方案
3. 可扩容，能够很好的支持不断扩张的、大规模的监控需求

守护程序角色

# 如果机器上没有安装pip
apt-get install python-pip python-pycurl
# 添加shiken专用户
adduser shinken
# 安装shinken
pip install shinken

使用这种方式，你可以方便的调试或者修改Shinken的源码：

adduser shinken
wget http://www.shinken-monitoring.org/pub/shinken-2.4.tar.gz
tar -xvzf shinken-2.4.tar.gz
cd shinken-2.4
python setup.py install

在生产环境下可以设置Shinken为自启动：

# RedHat / CentOS
chkconfig shinken on
# Debian / Ubuntu
update-rc.d shinken defaults

# 启动
service shinken start

你可以可以通过脚本启动：

./bin/launch_all.sh

开发环境下，如果你需要修改Shinken源码，需使用第二种安装方式。然后注释掉shinken.cfg中用户、组信息，以当前用户的身份启动Shinken：

./bin/shinken-scheduler -c /etc/shinken/daemons/schedulerd.ini -d
./bin/shinken-poller -c /etc/shinken/daemons/pollerd.ini -d
./bin/shinken-broker -c /etc/shinken/daemons/brokerd.ini -d
./bin/shinken-reactionner -c /etc/shinken/daemons/reactionnerd.ini -d
./bin/shinken-arbiter -c /etc/shinken/shinken.cfg -d
./bin/shinken-receiver -c /etc/shinken/daemons/receiverd.ini -d

安装后以及运行时，Shinken会使用下面的目录：

安装步骤参考Linux下基于源码的安装方式，不需要添加用户，解压可以手工进行。

Windows下所有目录都位于Shinken安装目录下，例如

/etc/shinken

Windows下%SHINKEN_HOME%\etc

每次修改配置后，你都应该在重启Shinken之前进行验证，因为配置存在问题会导致Shinken无法启动。

调用下面的命令执行验证：

/usr/bin/shinken-arbiter -v -c /etc/shinken/shinken.cfg 

如果配置存在错误，该命令会输出ERROR信息并指出问题所在位置。警告信息一般可以忽略。

# 启动
/etc/rc.d/init.d/shinken start
# 重启
/etc/rc.d/init.d/shinken restart
# 停止
/etc/rc.d/init.d/shinken stop

Shinken提供了一个同名的命令，可以用于在shinken.io上检索、安装，上传包（Pack，包含对象定义模板）或者模块（扩充Shinken功能的Python模块）。初次使用该命令，需要初始化：

# 首次使用shinken命令时执行
shinken --init

http://user:password@proxy-server:port

在安装完毕后，你就获得一个基本的Shinken配置，可以直接启动之。

/etc/shinken/daemons目录存放了*.ini文件，这些文件描述了在本机需要运行的守护程序。基本配置下Shinken单机运行，因而此目录下有5个文件（Arbiter的配置在主配置文件中）。分别定义Broker、Poller、Reactionner、Receiver、Scheduler这五个守护程序使用的端口、工作目录等重要信息。

需要注意的是，这些守护程序不一定要在单机上运行，你可以分散部署，只需要将它们作为对象引用到主配置文件中。

我们看一下配置文件的内容：

[daemon]

# 该程序启动后，立即修改工作目录为：
workdir = /var/run/shinken
logdir  = /var/log/shinken
# PID文件，有了它以后我们可以杀死该守护程序
pidfile=%(workdir)s/schedulerd.pid
# TCP监听端口，默认：
# scheduler: 7768
# poller: 7771
# reactionner: 7769
# broker: 7772
# arbiter: 7770
port=7768
# TCP监听地址
host=0.0.0.0
# 用于运行守护程序的用户，以及用户的组
user=shinken
group=shinken
# 如果设置为1，则你可以在root用户下运行此守护程序
idontcareaboutsecurity=0

# Set to 0 if you want to make this daemon NOT run
# 是否启用此守护程序，如果设置为0则不会运行
daemon_enabled=1


#-- SSL相关的配置 --
use_ssl=0
# WARNING : Use full paths for certs
#ca_cert=/etc/shinken/certs/ca.pem
#server_cert=/etc/shinken/certs/server.cert
#server_key=/etc/shinken/certs/server.key
hard_ssl_name_check=0
http_backend=auto
daemon_thread_pool_size=16

#-- 和该守护程序相关的本地日志配置 --
# Enabled by default to ease troubleshooting
use_local_log=1
local_log=%(logdir)s/schedulerd.log

# accepted log level values= DEBUG,INFO,WARNING,ERROR,CRITICAL
log_level=WARNING

# The path to the modules directory
modules_dir=/var/lib/shinken/modules

守护程序作为Shinken架构中的一种资源，必须在主配置文件中进行定义，才能被使用。 

通常，守护程序定义文件依据类型的不同，存放在不同目录中，并且每个文件对应一个守护程序。该文件使用类似于对象定义的语法，描述此守护程序的名称、如何连接、是否Standby（Spare）。下面是一个Scheduler定义的例子：

define scheduler {
    # 守护程序的名称
    scheduler_name      scheduler-master
    # 如何连接到此守护程序
    address             localhost 
    port                7768
    # 是否备用
    spare               0
    # 权重，某些Scheduler可以管理更多的主机
    weight              1
    # PING超时
    timeout             3
    # 数据发送超时
    data_timeout        120 
    # 如果PING超时多少次，认为此节点挂掉
    max_check_attempts  3
    # 每60秒PING此节点
    check_interval      60
    # 此守护程序加载的模块
    modules
    # 所属的领域，用于多数据中心等大型场景
    realm   All
    skip_initial_broks  0
    use_ssl	          0
    hard_ssl_name_check   0
}

注意，某些守护程序有特殊的配置选项，例如：

所有守护程序都可以使用模块。对于Broker来说模块是必须的，它依赖模块来完成实际的工作。基本配置没有预定义任何模块。

模块具有公共的选项：

每个模块具有自己的其它特殊配置项，需要查看模块的文档。

这里，我们定义一个模块，为基本配置增加日志记录的功能：

define module{
     module_name      simple-log
     module_type      simple-log
     path             /var/log/shinken/shinken.log
}

然后修改默认的Broker：

modules            simple-log

默认情况下simple-log模块是没有安装的，因此你会在/var/log/shinken/brokerd.log中发现警告信息：The module type simple-log for simple-log was not found in modules。执行下面的命令来安装模块：

# 到shinken.io搜索包
shinken search log
# 安装模块到/var/lib/shinken/modules/目录下
shinken install simple-log

重启Shinken，你会发现所有守护程序的日志被收集到 /var/log/shinken/shinken.log文件中了。

Shinken包含一系列内部模块，这些模块可以被多种守护程序加载，参与到数据获取中去。这些模块包括NPRE、SNMP等。

Shinken同时依赖于外部程序——检查插件（Check plugins）来监控更多种类的设备、应用、以及网络服务。

插件可以是编译好的可执行文件或者脚本，它们可以被调用，以便检查主机/服务的状态。Shinken使用插件的调用返回值来确定主机、服务的当前状态，以及被监控服务的性能数据。

插件作为监控逻辑组件和被监控主机/服务之间的抽象层。具有一定的接口规范，你可以编写自己的插件来监控任何东西。

Shinken插件有很多，支持的监控协议包括：WMI, SNMP, SSH, NRPE, TCP, UDP, ICMP, OPC, LDAP 等。

支持的监控对象包括各种OS、服务器和网络硬件、各种网络协议、各种性能数据、应用程序和数据库。

插件没有和Shinken运行时一同分发，需要单独获取。可以从：

1. Monitoring Plugins Project
2. Nagios Downloads Page
3. NagiosExchange.org

等地方获取插件。很多插件都提供帮助，你应该通过阅读帮助来了解如何使用之：

./check_http --help

Shinken的灵活性依赖于宏机制，你可以在命令中使用宏。通过宏你可以引用主机、服务等信息。

Shinken宏使用

$

$$

在执行命令前，Shinken会替换命令定义中所有宏为实际值，这些值由上下文决定。宏替换发生在任何命令上，包括主机/服务检查、通知、事件处理器等。

你可以使用

$ARGn$

# 定义命令
define command{
  command_name    check_ping
  # ARG1表示第一个入参
  command_line    /var/lib/shinken/libexec/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$
}

调用命令时，以

!

define service{
  host_name    linux
  # 调用命令。给check_ping命令传递了两个参数，每个参数以叹号开始
  # 200.0,80%
  # 400.0,40%
  check_command    check_ping!200.0,80%!400.0,40%
}

如果调用命令需要传递叹号（!）本身，可以使用反斜杠转义。 

通常，当你使用主机/服务宏时，这些宏指向当前命令所针对的主机/服务。如果你想引用其它主机/服务时，可以使用按需宏机制。

按需宏和普通宏类似，只是它后缀一个用于识别主机/服务的标识符：

# 语法格式。把HOSTMACRONAME、SERVICEMACRONAME替换成真实的宏名称，:后面替换成真实的属性值即可
$HOSTMACRONAME:host_name$
$SERVICEMACRONAME:host_name:service_description$

# 举例
$HOSTDOWNTIME:myhost$   #myhosq的宕机时间
$SERVICESTATEID:server:database$  #server的database服务的状态ID
$CONTACTEMAIL:john$   #john的电子邮件

你还可以使用宏来获得一个组中的全部联系人、主机、服务的属性，使用特定分隔符分隔多个值：

#语法格式。HOSTMACRONAME等替换成真实的宏名称，*group_name替换为真实的组名称，delimiter替换为分隔符即可
$HOSTMACRONAME:hostgroup_name:delimiter$
$SERVICEMACRONAME:servicegroup_name:delimiter$
$CONTACTMACRONAME:contactgroup_name:delimiter$

你在主机、服务、联系人等的定义中声明的定制对象变量（custom object variables） 均可以作为宏使用：

#语法格式。
$_HOSTvarname$
$_SERVICEvarname$
$_CONTACTvarname$

#举例：
define host{
  ...
  # 定制变量必须以_开头
  _MACADDRESS    00:01:02:03:04:05
  ...
}
# 你可以使用 $_HOSTMACADDRESS$ 来访问MAC地址这一定制变量

大部分宏被导出为环境变量，脚本或者命令可以很容易的引用之。

$USERn$

参考官方文档。

以下时机Shinken的守护程序对主机执行检查：

1. 根据主机的check_interval、retry_interval选项周期性、定时检查。如果check_interval设置为0则不进行周期性检查
2. 当主机下某个服务的状态改变，按需检查
3. 作为主机可到达性逻辑的一部分，按需检查。这种情况下，主机是路由器等网络设备
4. 在进行预测性主机依赖性检查（predictive host dependency checks）时，按需进行

主机检查是并行执行的。

按需检查的性能可以通过已缓存的主机检查（Cached Host Checks）极大的提高。Shinken可以放弃检查执行，而使用最近的检查结果。

通过定义主机执行依赖（host execution dependencies），你可以基于其它一个或多个主机的状态，禁止某一主机的检查。

被检查的主机可以处于三种状态之一：UP、DOWN、UNREACHABLE。

主机检查由插件进行，插件的返回状态和主机状态映射如下表。注意，依据插件结果初步判定为DOWN时，需要依赖于父主机状态，来确定主机的真实（最终）状态：

Shinken可能发现主机状态在UP/DOWN/UNREACHABLE之间变化，并采取一定的操作。

状态变革会导致不同的状态类型（State types）：HARD/SOFT，可能相应的触发事件处理器或者通知。

当主机状态频繁变化时，称为动荡（flapping），动荡的一个例子是，主机由于某种原因反复的重启（例如系统更新导致）。Shinken可以在检测到动荡后暂停通知发送，直到主机状态稳定下来。 

以下时机Shinken的守护程序对服务执行检查：

1. 根据服务的check_interval、retry_interval选项周期性、定时检查
2. 在进行预测性服务依赖性检查（predictive service dependency checks）时，按需进行

与主机检查一样：

1. 缓存可以很大的提高On-demand服务检查的性能
2. 检查是并行执行的
3. 通过定义服务执行依赖（service execution dependencies），你可以基于其它一个或多个服务的状态，禁止某一服务的检查

被检查的服务可以处于几种状态之一：OK、WARNING、UNKNOWN、CRITICAL。

服务检查由插件执行，插件的返回状态直接对应到上面几个服务状态。

服务的状态变更、动荡的处理和主机类似。

主动检查是Shinken主要使用的检查方式。主动检查由Shinken发起，依据计划周期性的执行。具体步骤如下：

1. 周期性、On-demand触发检查
2. 守护程序调用插件，并传递必要信息
3. 插件执行实际的坚持并报告结果给守护程序
4. 守护程序处理结果，执行适当的操作，例如发送通知、执行事件处理器

集成的数据获取模块，是可以被守护程序启动的组件。这些组件可以高性能的获取数据，效率比周期性的调用插件脚本高。

SNMP数据获取模块：SnmpBooster

NRPE数据获取模块：NRPE

NRPE是一种通信协议，它和安装在远程主机上的代理（Agent）进行交互。

Shinken也支持被动的得到对象的状态。被动检查由外部程序发起，并将检查结果提交给Shinken。

对于天生异步的、不能通过轮询（Polling）很好的检查的服务，被动检查很适用。适合被动检查的例子包括：

1. SNMP陷阱、安全报警。你永远不知道一定时间内有多少陷阱、报警
2. 安装了代理（Agent）的主机上的聚合检查，这种检查的执行间隔会相当低
3. 直接从英语程序中提交检查结果，不依赖于中介日志文件（syslog、event log等）

在主配置文件中设置accept_passive_service_checks为1。对于不需要主动检查的主机、服务，设置passive_checks_enabled为0。

外部程序可以向Shinken的外部命令管道（external command pipe）写入一条PROCESS_SERVICE_CHECK_RESULT外部命令，以提交检查结果。该命令的格式为：

# timestamp，格式为time_t即1970到现在的秒数。执行服务检查的时间点
# host_name，服务所属主机的短名
# svc_description，服务定义中的服务描述
# return_code，检查结果，0=OK, 1=WARNING, 2=CRITICAL, 3=UNKNOWN
# plugin_output，插件的文本输出
[timestamp] PROCESS_SERVICE_CHECK_RESULT;configobjects/host_name;svc_description;return_code;plugin_output

被检查的服务必须在Shinken中预先定义，否则提交的检查结果自动丢弃。

外部程序可以向Shinken的外部命令管道（external command pipe）写入一条PROCESS_HOST_CHECK_RESULT外部命令，以提交检查结果。该命令的格式为：

# host_status，主机状态 0=UP, 1=DOWN, 2=UNREACHABLE
[timestamp] PROCESS_HOST_CHECK_RESULT;configobjects/host_name;configobjects/host_status;plugin_output

与主动检查不同，Shinken不会把结果作为初步结果，进而根据父主机状态判断最终结果。你提交的必须就是主机的实际状态。 

被监控主机/服务的当前状态（Current state）由两个字段决定：

1. 主机或服务的状态（status，先前所有提及的状态，都是这个单词），即OK, WARNING, UP, DOWN...
2. 主机或服务所处的状态类型（State type）

状态类型有两种：软状态（SOFT）、硬状态（HARD）。状态类型非常重要，它们用于决定何时执行事件处理器，何时发送最初的通知。

为了防止因为临时故障而错误的报警，Shinken允许配置主机/服务的max_check_attempts。最有在最大尝试次数到达后，才会认为是真正出现问题。

重新检查与状态类型密切相关

以下情况下，服务/主机处于软状态：

1. 当服务/主机从OK/UP变为non-OK/non-UP状态后，到达max_check_attempts之前。这种情况称为软错误
2. 当服务/主机从软错误中恢复时。这种情况称为软恢复

当对象进入软状态时：

1. 日志记录SOFT状态，仅当你在主配置文件启用log_service_retries或log_host_retries时
2. 调用事件处理器来处理SOFT状态。这是软状态下重要的行为，你可以在到达HARD状态前积极的修复问题。事件处理器执行时， $HOSTSTATETYPE$、 $SERVICESTATETYPE$宏的值为SOFT提示当前处于软状态

以下情况下，服务/主机处于硬状态：

1. 服务/主机从OK/UP变为non-OK/non-UP状态后，到达max_check_attempts之后仍然没有恢复。这种情况称为硬错误
2. 当服务/主机从硬错误转换到其它错误状态时，例如WARNING、CRITICAL
3. 当服务的检查结果是一个non-OK状态且它所属主机为DOWN或UNREACHABLE状态
4. 当服务/主机从硬错误状态恢复。这种情况称为硬恢复
5. 当被动检查结果送达，默认总是认为是硬状态。除非启用passive_host_checks_are_soft选项

当对象进入硬状态时：

1. 日志记录HARD状态
2. 调用事件处理器来处理HARD状态
3. 通知联系人，告知问题或者恢复。事件处理器执行时， $HOSTSTATETYPE$、 $SERVICESTATETYPE$宏的值为HARD提示当前处于硬状态

我们常说“外网挂了”，外网真的会挂吗？几乎不可能，问题肯定出现在你的机器到Internet的链路上。链路上的任何一个路由器/交换机出现故障，你都会无法上网。

在Shinken的监控业务中也是这样，守护程序所在机器到目标主机之间的链路上任何一个节点出现故障，目标主机都会处于non-UP状态。Shinken有能力区分这个non-Up是DOWN还是UNREACHABLE，前提是你正确的配置网络依赖。

你必须站在Shinken守护程序的角度来看问题，守护程序需要经过哪些主机（网络设备）才能到到目标主机？你需要把这些中介的设备配置为目标主机的祖先主机，例如：

# 父子关系的配置必须真实的反映网络拓扑
define host{
  host_name    Switch1
  parents    Shinken  #声明自己的父主机，父主机总是离Shinken守护程序更近（跳数少）
}
define host{
  host_name    Web
  parents    Switch1
}
define host{
  host_name    FTP
  parents    Switch1
}
define host{
  host_name    Router1
  parents    Switch1
}
define host{
  host_name    somewebsite.com
  parents    Router1
}

类似上面的配置，形成从守护程序到目标主机的单向图，Shinken依据此图判断目标主机是不可达，还是宕机。 

某些情况下你可能有多重链路可以到达目标主机，此时应该为目标主机（或者链路上的中介节点）配置多个父主机。

只有全部父主机不可达、宕机，子主机才会被判定为不可达。

Shinken只会针对问题的根源（Root problems）发送通知，这避免了发送大量的通知给联系人。只有主机状态是DOWN时通知才会发送，主机是UNREACHABLE时不会发送，但是它的某个祖先主机的DOWN通知可能被发送。

同样的，DOWN/UNREACHABLE主机上服务的通知也不会发送，它们不是问题的根源所在。

服务和主机（逻辑）依赖是Shinken的高级特性。允许你基于其它主机/服务的状态，来控制目标主机/服务的行为。

以服务依赖为例，一个Web服务常常会依赖于一个数据库服务。如果数据库服务宕机了，你向联系人通知说Web服务挂了是没有意义的。你应该正确配置服务之间的依赖关系，以便Shinken能够报告问题的根源。

关于服务依赖，你需要知道：

1. 一个服务可以依赖于1-N个其它服务
2. 一个服务可以依赖于其它主机上的服务
3. 通过服务依赖配置，你可以在服务的某些状态下，抑制检查的执行、通知的发送
4. 依赖关系可以仅在特定时间段内启用

# 位于srv-web上的service服务
define service{
  host_name              srv-web
  service_description    Http
  # 依赖位于srv-db上的mysql服务
  service_dependencies   srv-db,mysql
}

依赖是可以继承（inherited，应该理解为传递性依赖）。以上面的例子讲，假设mysql服务依赖srv-dns,dns，那么http出现问题时会检查mysql，进一步会检查srv-dns以确认问题根源。

网络依赖同样会影响问题根源的判断，如果http出现问题的同时发现srv-db宕机，那么后者会被看作问题的根源，前者只作为后者的impact。

Shinken允许在返回状态数据的同时，附带记录可选的性能数据。你可以把性能数据返回给外部程序进行处理。

性能数据分为两个类别：

Shinken插件至少会返回一行人类可读的文本，用来描述某种类型的可度量数据，例如check_ping插件返回的文本可以如下：

PING ok - Packet loss = 0%, RTA = 0.80 ms

类似这样的输出，可以通过

$HOSTOUTPUT$

$SERVICEOUTPUT$

可选的，插件还可以返回性能数据，以管道符号

|

PING ok - Packet loss = 0%, RTA = 0.80 ms | percent_packet_loss=0, rta=0.80

输出中的性能数据部分，可以通过 

$HOSTPERFDATA$ 

$SERVICEPERFDATA$

Shinken守护程序不直接处理性能数据，因此它也不关心其格式。

如果你需要处理性能数据，则需要启用process_performance_data选项，并配置Shinken，让性能数据写入到文件，或者执行命令。

选项host_perfdata_command、service_perfdata_command用于指定处理性能数据的命令。下面是命令的例子：

define command{
  command_name    store-service-perfdata
  command_line    /bin/echo -e "$LASTSERVICECHECK$\t$HOSTNAME$\t$SERVICEDESC$\t$SERVICESTATE$\t$SERVICEATTEMPT$\t
                                $SERVICESTATETYPE$\t$SERVICEEXECUTIONTIME$\t$SERVICELATENCY$\t$SERVICEOUTPUT$\t
                                $SERVICEPERFDATA$" >> /var/lib/shinken/service-perfdata.dat
}

调用命令的方式可能会导致较高的CPU负载，特别是需要处理大量主机/服务时，最好先写入文件，然后由外部程序处理。使用host_perfdata_file、service_perfdata_file选项你可以指定写入到什么文件；而host_perfdata_file_template、service_perfdata_file_template 选项用于指定输出的模板。

在让Shinken真正能工作之前，你需要配置若干个文件。在目录

/etc/shinken/

编辑任何配置文件时，都要记住：

1. #开头的行是注释，不进行处理
2. 变量名大小写敏感

从2.0开始Shinken引入新的配置文件布局，基本的配置文件现在被分割到多个小的文件中。新的布局更好管理，例如一个文件对应一个对象的配置。

配置文件可以分为以下几类：

shinken.cfg

module

resource_file

cfg_file

cfg_dir

service_check_timeout=60
host_check_timeout=30 

在进行对象定义的时候，你可以使用对象继承机制，降低配置文件字段的冗余。

所有对象都可以使用以下三个和继承、递归相关的变量：

define someobjecttype{
       object-specific variables ...
       # 对象的名称，可以被其它对象引用，对于同一类型的对象，其名称必须唯一
       name            template_name
       # 你想从中继承属性/变量的“模板对象”
       use             name_of_template_to_use
       # 是否向Shinken注册此定义，如果该定义纯粹是作为模板使用的不完全定义，应该设置为0
       # 默认1，表示注册，该字段不会被继承
       register        [0/1]
}

有一点很重要，对象在本地自己定义的变量，总是比继承自模板的优先级高。也就是说，对象定义可以覆盖继承得到的值。

Shinken不限制对象继承的深度，上述的覆盖行为从祖代向子代逐步进行。

你在主机/服务/联系人中声明的自定义变量（_开头的），可以和普通变量一样被继承。

对于字符串类型的变量，你可以将其设置为null，防止从模板继承值：

event_handler null

默认的，你在对象里声明一个变量，会覆盖模板中的同名变量。

对于标准变量（非自定义）的字符串变量，Shinken支持所谓加性继承（additive inheritance），即把对象声明的值附加到继承值的后面。

要启用加性继承，只需要在声明值的时候前缀+号：

# 模板
hostgroups              all-servers

# use模板的对象
hostgroups             +linux-servers,web-servers
# 实际相当于
hostgroups             all-servers,linux-servers,web-servers

通常情况下，你要么继承，要么声明一个变量值，但是由几个例外情况。在这些情况下，Shinken会从相关对象继承值：

 一个对象可以同时继承多个模板，例如：

define host{
       name                    generic-host
       active_checks_enabled   1
       check_interval          10
       register                0
}
define host{
       name                    development-server
       check_interval          15
       notification_options    d,u,r
       register                0
}
define host{
       use                    generic-host,development-server
       host_name              devweb
}

对象devweb的实际定义相当于：

define host{
       host_name               devweb1
       active_checks_enabled   1
       check_interval          10
       notification_options    d,u,r
}

可以看到，声明在use列表前面的模板，具有更高的优先级。 

上面提到过，通过隐含继承，可以让Service自动从Host继承特定变量。对于不支持隐含继承的变量，你可以在主机中使用指令：

# 对于属于该主机的xxx服务，设置其yyy为zzz
service_overrides xxx,yyy zzz
# 支持多行值
service_overrides xxx,yyy zzz
                  aaa,bbb ccc

# 举例
define host {
       host_name               web-back-01
       hostgroups              web
       service_overrides       HTTP,notification_options c,r
}

这样可以避免从Pack中继承不匹配实际需求的值。

注意：service_overrides属性可以从模板继承。

你可以使用service_excludes指令，从Pack中排除继承得来的服务定义：

define host {
       use                     web-front
       host_name               web-back-01
       service_excludes        mgr
}

通过多次使用cfg_file、cfg_dir指令，你可以编写多个对象定义文件。安装好Shinken后，/etc/shinken/目录中有很多样例对象定义文件，这些文件存放在各自的目录中。

定义格式： 

# 语法
define host {
    optionname   optionvalue
}

# 示例
define host{
    host_name                      bogus-router
    alias                          Bogus Router #1
    address                        192.168.1.254
    parents                        server-backbone
    check_command                  check-host-alive
    check_interval                 5
    retry_interval                 1
    max_check_attempts             5
    check_period                   24x7
    process_perf_data              0
    retain_nonstatus_information   0
    contact_groups                 router-admins
    notification_interval          30
    notification_period            24x7
    notification_options           d,u,r
    realm                          Europe
    poller_tag                     DMZ
    icon_set                       server
}

选项列表：

service_overrides      HTTP,notification_period workhours

hostgroup_name=(linux|windows)&!qualification,routers

bp_rule

# 支持逻辑操作符
# 如果websrv1的apache服务或者websrv2的apache服务OK，并且dbsrv1上的oracle数据库OK
# 那么当前服务的状态判断为OK
bp_rule(websrv1,apache | websrv2,apache) & dbsrv1,oracle

host,service_description,host,service_description

通过Shinken支持的接口，管理员可以直观的看到监控数据，例如主机/服务的状态。

Shinken自带一个WebUI，你也可以使用其它开源/商业的Web前端，这些前端使用LiveStatus API或者SQL backend。LiveStatus具有很好的实时性、可扩容性和灵活性。

安装必要的模块：

# Web UI
shinken install webui
# 身份验证机制
shinken install auth-cfg-password
# 用户配置存储
shinken install sqlitedb

修改模块定义（安装WebUI模块后，此定义会自动生成）：

define module {
    module_name         webui
    module_type         webui
    host                0.0.0.0     # 监听所有网络接口
    port                7767
    auth_secret         CHANGEME    # 修改，防止Cookie伪造
    allow_html_output   1           # 是否允许插件输出HTML特殊字符
    max_output_length   1024        # 插件输出的最大长度
    manage_acl          1           # Use contacts ACL. 0 allow actions for all.
    play_sound          0           # 出现新的未确认问题时播放声音
    login_text          Welcome on Shinken WebUI   # 登陆表单提示信息
    modules             auth-cfg-password SQLitedb # 使用Shinken联系人进行身份验证，使用SQLitedb存储用户设置
}

修改用于登陆的联系人：

# 基本配置已经包含此联系人
define contact{
    use             generic-contact
    contact_name    admin
    email           shinken@localhost
    # 修改密码
    password        admin             
    is_admin        1
    expert          1
}

然后，需要让代理加载此模块定义：

define broker {
    ...
    modules   webui
}

现在你可以访问 http://ip:7767/user/login并登陆了。

使用Shinken WebUI2 

新版本的WebUI，内部集成了身份验证、存储、日志模块，简化了安装和配置。

安装模块：

pip install bottle
shinken install webui2

完毕后修改代理定义，把webui模块改为webui2，重启Shinken即可。

基于Livestatus的前端包括：

1. Thruk，适用于中小规模的场景
2. Multisite，适用于最大规模的可扩容性需求
3. Nagvis，用于图形化的展示，可以显示网络拓扑图，并标注每个主机的状态

获得livestatus模块定义：

# 使用SQLite存储历史日志
shinken install logstore-sqlite
# 获得livestatus模块定义
shinken install livestatus

在代理定义中加载livestatus模块

define broker {
    modules   webui2,livestatus
} 

禁用SELinux： 

SELINUX=disabled

安装必要的软件：

yum install httpd
yum install mod_fcgid

wget http://download.thruk.org/pkg/v2.08/rhel7/x86_64/libthruk-2.08-1.rhel7.x86_64.rpm
rpm -ivh ./libthruk-2.08-1.rhel7.x86_64.rpm
wget http://download.thruk.org/pkg/v2.08/rhel7/x86_64/thruk-base-2.08-1.rhel7.x86_64.rpm
rpm -ivh ./thruk-base-2.08-1.rhel7.x86_64.rpm 
wget http://download.thruk.org/pkg/v2.08/rhel7/x86_64/thruk-plugin-reporting-2.08-1.rhel7.x86_64.rpm
rpm -ivh ./thruk-plugin-reporting-2.08-1.rhel7.x86_64.rpm
wget http://download.thruk.org/pkg/v2.08/rhel7/x86_64/thruk-2.08-1.rhel7.x86_64.rpm
rpm -ivh ./thruk-2.08-1.rhel7.x86_64.rpm 

chkconfig httpd on
service httpd start

上述步骤完毕后，你可以通过http://ip/thruk/来访问Thruk了，默认登陆用户名密码是thrukadmin/thrukadmin。

enable_shinken_features = 1
<Component Thruk::Backend>
    <peer>
        name   = External Shinken
        type   = livestatus
        <options>
            peer    = 127.0.0.1:50000
        </options>
    </peer>
</Component>

注意livestatus的IP和端口要和livestatus的模块定义匹配。

完成配置后，重启Shinken，然后登陆到Thruk。在左侧菜单点击Config Tool，右上角Configuration Type选择Backends，点击Test测试。参考下图：

注意：从启动Shinken到livestatus可用，可能需要几分钟时间。

你可以使用预定义的模板来监控Windows设备，并获得内存用量、CPU负载、磁盘用量、系统服务状态、进程、系统事件日志等方面的信息。

有两种方法监控Windows设备：

1. 基于代理的方式：在目标设备上安装NSClient++
2. 无代理的方式：通过WMI协议直接通过网络轮询Windows状态

前提条件：你需要一个合法的Windows本地/域账号，用于执行WMI查询。

安装windows包：

shinken install windiws

安装必要的Perl模块：

yum -y install perl-Number-Format 
yum -y install perl-Config-IniFiles 
yum -y install -y perl-DateTime  

修改主机配置：

define host{
   # 继承windows模板
   use                     windows  
   _DOMAIN                 $DOMAIN$
   _DOMAINUSERSHORT        logonuser
   _DOMAINPASSWORD         passwd
}

与Windows设备的监控类似，你也可以监控Linux的内存用量、CPU负载、磁盘用量、进程等方面的信息。

你可以通过多种方式来监控Linux：

1. 通过SNMP代理
2. 基于一个本地的代理，可以高频率获取数据，支持主动、被动通信方式
3. 基于SSH的方式，只适用于非频繁的检测，可扩容性差

首先，你需要在目标设备上安装SNMP守护程序：

# CentOS 7
yum install net-snmp net-snmp-devel net-snmp-libs net-snmp-utils
systemctl enable snmpd
systemctl start  snmpd

# Debian/Ubuntu
apt-get install snmpd
sudo update-rc.d snmpd defaults
service snmpd start

修改snmpd的配置文件：

# Ubuntu 14.04
# 注释掉 agentAddress  udp:127.0.0.1:161，添加
agentAddress udp:161,udp6:[::1]:161
# 将 rocommunity public  default    -V systemonly 改为
rocommunity public

# CentOS 7
# 把默认的两行view systemview去掉，改为：
view systemview included .1.3.6.1

# 最好更改团体名（下面的public），以避免安全问题
# CentOS 7
com2sec notConfigUser  default       public
# Ubuntu 14.04
rocommunity public  default    -V systemonly

然后，你需要在监控服务器上执行以下操作：

1. 安装Perl的SNMP支持：

   yum -y install perl-Net-SNMP

    
2. 安装相关Shinken包：

   shinken install linux-snmp

    
3. 修改主机配置：
   

   define host{
       # 继承linux-snmp模板
       use                 linux-snmp
       # 指定团体名，默认是读取宏$SNMPCOMMUNITYREAD$的值，你可以在资源中定义该宏
       _SNMPCOMMUNITY      public
       # 监控哪个网络接口的使用情况
       _NET_IFACES         eth0
   }

完毕后，重启Shinken即可。

某些廉价的交换机、集线器没有IP地址，因而无法监控。相反的，一些高档网络设备则提供SNMP查询功能。

Shinken支持监控：

1. 丢包率、延迟
2. SNMP状态信息，需要交换机支持SNMP
3. 带宽/通信速率，需要安装MRTG，需要交换机支持SNMP

define service{
   use                    generic-service
   host_name              router
   service_description    PING
   # CRITICAL：RTA大于600ms或者丢包率不小于60%
   # WARNING：RTA大于200ms或者丢包率不小于20%
   # OK：RTA小于200ms并且丢包率小于20%
   check_command          check_ping!200.0,20%!600.0,60%
}

你可以执行命令：

snmpwalk -v1 -c public 192.168.1.1 -m ALL .1

监控命令举例：

# 监控路由器已经启动的时间
check_command        check_snmp!-C public -o sysUpTime.0
# 监控端口1的连接状态
check_command       check_snmp!-C public -o ifOperStatus.1 -r 1 -m RFC1213-MIB

如果你安装了MRTG ，则Shinken支持通过

check_mrtgtraf

define service{
   use                 generic-service
   host_name           router
   # 端口1的带宽使用情况
   service_description Port 1 Bandwidth Usage
   check_command       check_local_mrtgtraf!/var/lib/mrtg/192.168.1.253_1.log!AVG!1000000,2000000!5000000,5000000!10
}

通过该插件，你可以监控任意支持SNMP的网络设备（主要是交换机、路由器）的网络使用情况、CPU负载、内存使用、端口使用、硬件状态等方面的信息。 监控命令举例：

# 列出所有接口的状态
/var/lib/shinken/libexec/check_nwc_health --hostname 192.168.0.1 --timeout 60 --community "public" --mode interface-status
# 显示健康状态 
/var/lib/shinken/libexec/check_nwc_health --hostname 192.168.0.1 --timeout 60 --community "public" --mode hardware-health

支持JetDirect协议的打印机往往也启用了SNMP，可以通过插件check_hpjd监控之。

安装包：

shinken install hp-printers

修改主机配置：

define host {
    use    printer-hp
} 

这里的公共服务是指对外开放的，可以通过网络访问的服务、应用或者协议。公共服务的例子包括：HTTP、POP3、IMAP、FTP、SSH等。

官方的Nagios/Shinken插件支持很多常见服务、协议的监控。如果找不到合适的插件，你也可以自己开发。

安装http包：

shinken install http

修改主机配置：

define host{
        # 继承http或（和）https模板
        use                http,https  
        # 监听端口
        _CHECK_HTTP_PORT   80
        _CHECK_HTTPS_PORT  443
        # 测试的URI
        _CHECK_HTTP_URI    /index.html
        _CHECK_HTTPS_URI   /index.html
}

安装ftp包：

shinken install ftp

修改主机配置：

define host{
        # 继承ftp模板
        use               ftp
}

安装ssh包：

shinken install ssh

修改主机配置，继承ssh。注意，如果你的主机已经继承linux，则不需要再继承ssh。

使用Shinken你可以很好的监控MySQL的运行状态，获取包括InnoDB缓冲池状态、连接数、查询缓存命中率、缓慢查询、锁争用在内的数据。

安装mysql包：

shinken install mysql

安装MySQL的Perl驱动：

yum install -y perl-DBD-MySQL

修改主机配置：

define host{
        # 继承MySQL模板
        use                     mysql
        _MYSQLUSER              pems
        _MYSQLPASSWORD          pemsroot
} 

前提条件：你需要一个合法的Windows本地/域账号。

你可以监控：连接数、错误数量、登陆用户数等方面的信息。

安装需要的包：

shiken install windows
shinken install  iis

修改主机配置：

define host {
    # 继承iis和windows
    user    iis,windows
}

Shinken还提供了很多其它的包，方便你监控常见的服务：

# 监控邮件服务
shinken install imap
shinken install smtp
shinken install pop3

[1467096368] ERROR: [Shinken] Fail launching command: /usr/lib/nagios/plugins/check_ping -H localhost -w 1000,100% -c 3000,100% -p 1 [Errno 2] No such file or directory False

Shinken基本配置中的命令，主要是调用$NAGIOSPLUGINSDIR$目录下的监控插件（命令行），例如：

define command {
    command_name    check_ping
    command_line    $NAGIOSPLUGINSDIR$/check_icmp -H $HOSTADDRESS$ -w 3000,100% -c 5000,100% -p 10
}

宏$NAGIOSPLUGINSDIR$指向插件的安装目录，该宏的默认值定义在： 

# Nagios legacy macros
$USER1$=$NAGIOSPLUGINSDIR$
$NAGIOSPLUGINSDIR$=/usr/lib/nagios/plugins

#-- Location of the plugins for Shinken
$PLUGINSDIR$=/var/lib/shinken/libexec

如果你没有安装这些插件，或者安装位置不是/usr/lib/nagios/plugins，就会报找不到文件的错误。

你可以从多个地方获取插件：

1. Nagios Core Plugins：你可以下载50个核心Nagios插件
2. The Monitoring Plugins Project：监控插件项目，这个开源项目维护更多的插件

安装插件的示例脚本：

yum -y install openssl openssl-devel

wget https://www.monitoring-plugins.org/download/monitoring-plugins-2.1.2.tar.gz
tar xzf monitoring-plugins-2.1.2.tar.gz 
cd monitoring-plugins-2.1.2/
./configure --with-openssl
make && make install

修改宏定义，指向监控插件实际安装目录：

$NAGIOSPLUGINSDIR$=/usr/local/libexec

出现此错误的原因是编译插件的时候没有安装OpenSSL，参考上面的脚本，先安装OpenSSL再配置、构建、安装插件。

出现此错误的原因是没有安装Perl的MySQL驱动，安装即可：

yum -y install -y perl-DBD-MySQL

出现此错误的原因是缺少对应的Perl模块，安装即可：

yum -y install perl-Number-Format

出现此错误的原因是缺少对应的Perl模块，安装即可：

yum -y install perl-Config-IniFiles

出现此错误的原因是缺少对应的Perl模块，安装即可：

yum -y install -y perl-DateTime

安装缺少的函数库：

yum -y install redhat-lsb redhat-lsb-core

某些Shinken插件可能没有随基本配置安装，你可以到shiken-plugins网站下载：

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

该插件是Native应用程序，需要手工编译：

wget https://labs.consol.de/assets/downloads/nagios/check_nwc_health-5.7.1.1.tar.gz
tar xzf check_nwc_health-5.7.1.1.tar.gz  && rm -f check_nwc_health-5.7.1.1.tar.gz
cd check_nwc_health-5.7.1.1/
./configure  && make
cp plugins-scripts/check_nwc_health* /var/lib/shinken/libexec/

# 初次使用cpanm命令时
cpan App::cpanminus

# 安装Load模块
cpanm Module::Load

# cpanm默认安装位置为~/perl5/lib/perl5/无法被check_nwc_health命令找到，因此需要手工拷贝一下
mkdir /usr/lib64/perl5/vendor_perl/Module
cp /root/perl5/lib/perl5/Module/Load.pm /usr/lib64/perl5/vendor_perl/Module

The post Shinken学习笔记 appeared first on 绿色记忆.