使用Prometheus和Grafana构建集群监控系统(一): 配置与搭建

1, 基础知识

目前在服务器监控领域, 除了老牌的Zabbix和nagios外, Prometheus和Grafana也是目前较为流行的监控方案, 本文介绍Prometheus和Grafana的配置方法.

什么是Grafana?

Grafana是一个图形化工具, 它可以从很多种数据源(例如Prometheus)中读取数据信息, 使用很漂亮的图表来展示数据, 并且有很多开源的dashborad可以使用, 制作自己的dashboard也很简单, 总之, 可以快速地搭建起一个非常精美的监控平台.

什么是TSDB?

TSDB(Time Series Database)时间序列数据库, 简单来说就是存储随时间变化的数据的数据库. 什么是随时间变化的数据呢?举个简单的例子, 比如, CPU使用率, 典型的随时间变化的量, 这一秒是50%, 下一秒也许就是80%了. 或者是温度, 今天是20度, 明天可能就是18度了.

常见的TSDB(时间序列数据库): influxDB, RRDtool, Graphite, OpenTSDB, Kdb+, Druid, KairosDB, Prometheus等.

什么是Prometheus?

Prometheus(中文名:普罗米修斯)是由SoundCloud开发的开源监控报警系统和时序列数据库(TSDB). Prometheus使用Go语言开发, 是Google BorgMon监控系统的开源版本. 2016年由Google发起Linux基金会旗下的原生云基金会(Cloud Native Computing Foundation), 将Prometheus纳入其下第二大开源项目.

Prometheus的基本原理是通过HTTP协议周期性抓取被监控组件的状态, 任意组件只要提供对应的HTTP接口就可以接入监控. 不需要任何SDK或者其他的集成过程. 这样做非常适合做虚拟化环境监控系统, 比如VM、Docker、Kubernetes等. 输出被监控组件信息的HTTP接口被叫做exporter. 目前互联网公司常用的组件大部分都有exporter可以直接使用, 比如Varnish、Haproxy、Nginx、MySQL、Linux系统信息(包括磁盘、内存、CPU、网络等等).

Prometheus获取数据的策略是Pull而不是Push, 也就是说, 它会自己去抓取, 而不用你来推送. 抓取使用的是HTTP协议, 在配置文件中指定目标程序的端口, 路径及间隔时间即可. 这也就意味着任何程序想要使用Prometheus存储数据都很简单, 定义一个HTTP接口即可. 继续阅读

Windows下使用Vagrant

Vagrant是用来快速构建虚拟机的工具,只需要短短数行命令,就可以帮我们构建一个基于Virtualbox/VMware的虚拟机。在Linux系统下使用非常方便。本文介绍其在Windows下的使用方法(虽然本文介绍的是Windows下的使用方法, 但其在Linux下使用类似, 比如下方的建立文件夹就用mkdir, 编辑Vagrantfile文件就用vim即可)。

1,准备工作

1.1,安装Virtualbox和Vagrant,这里不多说;

1.2,新建一个文件夹,例如”C:\vm1″,并进入到此目录;

1.3,在Powershell中进入此目录,方法如下(以下方法任选其一):
方法1(推荐):按一下Shift+F10后松开,然后按S
方法2:在目录空白处鼠标右键,在右键菜单中选择”在此处打开 Powershell 窗口(s)”
方法3:按一下Windows+X后松开,然后按I,此时进入的Powershell不在”C:\vm1″目录,我们可以手动运行”cd C:\vm1″命令进入之

2,在Powershell中初始化虚拟机

在https://app.vagrantup.com找到你想要的虚拟机,
比如https://app.vagrantup.com/ubuntu/boxes/xenial64
页面上有个简单的介绍, 只需要下面几行命令

以下命令会在当前目录下(本文是C:\vm1)生成一个Vagrantfile的文件,记录该虚拟机的大致配置信息

$ vagrant init ubuntu/xenial64    #Ubuntu 16.04 

or

$ vagrant init debian/stretch64   #Debian 9

or

$ vagrant init centos/7           #Centos 7

3,虚拟机设定: 指定虚拟机IP
这个非常重要,因为使用Vagrantfile安装的虚拟机默认guest与host网络互不相通
使用Notepad++等工具打开这个Vagrantfile文件,取消注释如下行(即将虚拟机的IP指定为192.168.33.10,如果系统中已经有192.168.33.10的虚拟机在运行,请把这里的IP改成其它)

  # config.vm.network "private_network", ip: "192.168.33.10"

4,虚拟机设定: 指定虚拟机内存大小
根据情况取消注释如下内容 继续阅读

KVM VPS重启后hwclock时间发生变化

hwclock就是硬件时间, 类似于物理机上的BIOS time. 这个时间是可以和操作系统的时间不一样的. 如果hwclock是一个错误的时间的话, 一些强烈依赖时间的service就有可能会出错, 本文介绍Ubuntu下面的解决方法.

hwclock时间通常可以使用以下命令来查看

hwclock -r            #查看hwclock时间
hwclock -w --systohc  #将操作系统时间写入hwclock时间

1, 安装htpdate(非必需步骤)
此项非必需. 仅仅是因为我的CloudCone vps屏蔽了ntp使用的UDP 123端口, 我才需要这一步, 对于大多数KVM VPS来说, 这一项是不必要的.

$ apt-get install htpdate
$ systemctl status htpdate.service  #此时应该是默认进入运行状态且系统时间已经同步正确了
 
$ grep -v ^# /etc/default/htpdate   #查看其配置
HTP_SERVERS="www.pool.ntp.org www.ntp.br www.wikipedia.org"
HTP_OPTIONS="-D -s"

2, 编写systemd服务
请注意, 如果你没有执行第一步的话, 请把下方文件中的htpdate.service去掉.

$ vim /etc/systemd/system/hwclock-sync.service    #写入如下内容
[Unit]
  Description=update hwclock time
  After=network-online.target htpdate.service
  Wants=network-online.target htpdate.service

[Service]
  Type=onshot
  ExecStart=/sbin/hwclock -w --systohc
  RemainAfterExit=yes

[Install]
  WantedBy=multi-user.target

继续阅读

为什么ntp服务已经运行, 系统时间仍是错误的?(Ubuntu)

用的是CloudCone的VPS, 发现一件很诡异的事情. 系统从没有动过, 安装的ntp服务一直也在运行, 时区也是正确的, 偏偏系统时间是错误的. 即使卸载再重新安装ntp服务也是一样.

问题排除

$ ntpdate -ud ntp.ubuntu.com

17 Sep 14:05:04 ntpdate[9117]: ntpdate 4.2.8p10@1.3728-o (1)
Looking for host ntp.ubuntu.com and service ntp
91.189.89.198 reversed to chilipepper.canonical.com
host found : chilipepper.canonical.com
transmit(91.189.89.198)
transmit(91.189.89.199)
transmit(91.189.94.4)
transmit(91.189.91.157)
transmit(91.189.89.198)
transmit(91.189.89.199)
transmit(91.189.94.4)
transmit(91.189.91.157)
transmit(91.189.89.198)
transmit(91.189.89.199)
transmit(91.189.94.4)
transmit(91.189.91.157)
transmit(91.189.89.198)
transmit(91.189.89.199)
transmit(91.189.94.4)
transmit(91.189.91.157)
transmit(91.189.89.198)
transmit(91.189.89.199)
transmit(91.189.94.4)
transmit(91.189.91.157)
91.189.89.198: Server dropped: no data
91.189.89.199: Server dropped: no data
91.189.94.4: Server dropped: no data
91.189.91.157: Server dropped: no data
server 91.189.89.198, port 123
stratum 0, precision 0, leap 00, trust 000
refid [91.189.89.198], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Thu, Feb  7 2036 14:28:16.000
originate timestamp: 00000000.00000000  Thu, Feb  7 2036 14:28:16.000
transmit timestamp:  df49c296.3d0a1d7b  Mon, Sep 17 2018 14:05:10.238
filter delay:  0.00000  0.00000  0.00000  0.00000 
         0.00000  0.00000  0.00000  0.00000 
filter offset: 0.000000 0.000000 0.000000 0.000000
         0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000

server 91.189.89.199, port 123
stratum 0, precision 0, leap 00, trust 000
refid [91.189.89.199], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Thu, Feb  7 2036 14:28:16.000
originate timestamp: 00000000.00000000  Thu, Feb  7 2036 14:28:16.000
transmit timestamp:  df49c296.703703de  Mon, Sep 17 2018 14:05:10.438
filter delay:  0.00000  0.00000  0.00000  0.00000 
         0.00000  0.00000  0.00000  0.00000 
filter offset: 0.000000 0.000000 0.000000 0.000000
         0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000

server 91.189.94.4, port 123
stratum 0, precision 0, leap 00, trust 000
refid [91.189.94.4], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Thu, Feb  7 2036 14:28:16.000
originate timestamp: 00000000.00000000  Thu, Feb  7 2036 14:28:16.000
transmit timestamp:  df49c296.a3685167  Mon, Sep 17 2018 14:05:10.638
filter delay:  0.00000  0.00000  0.00000  0.00000 
         0.00000  0.00000  0.00000  0.00000 
filter offset: 0.000000 0.000000 0.000000 0.000000
         0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000

server 91.189.91.157, port 123
stratum 0, precision 0, leap 00, trust 000
refid [91.189.91.157], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Thu, Feb  7 2036 14:28:16.000
originate timestamp: 00000000.00000000  Thu, Feb  7 2036 14:28:16.000
transmit timestamp:  df49c296.d69f3de6  Mon, Sep 17 2018 14:05:10.838
filter delay:  0.00000  0.00000  0.00000  0.00000 
         0.00000  0.00000  0.00000  0.00000 
filter offset: 0.000000 0.000000 0.000000 0.000000
         0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000

17 Sep 14:05:12 ntpdate[9117]: no server suitable for synchronization found

继续阅读

Filebeat or Logstash?

Filebeat和Logstash都是ES套件(ES stack)中的组成部分, 其中, Filebeat还是beats家族的成员之一. Filebeat和Logstash都可以将日志文件输出到ElasticSearch, 且众所周知, Filebeat非常轻量级, 而Logstash由于使用JVM的原因性能堪忧, 那么是不是说我们可以抛弃笨重的Logstash了呢?

What is the difference between Logstash and Beats?

Beats are lightweight data shippers that you install as agents on your servers to send specific types of operational data to Elasticsearch. Beats have a small footprint and use fewer system resources than Logstash.

Logstash has a larger footprint, but provides a broad array of input, filter, and output plugins for collecting, enriching, and transforming data from a variety of sources.

翻译:

Logstash和Beats有什么区别?

Beats是轻量级数据托运者,您可以在服务器上将其作为代理安装,以将特定类型的操作数据发送到Elasticsearch。与Logstash相比,节拍占用空间小,使用的系统资源更少。

Logstash具有更大的占用空间,但提供了大量的输入,过滤和输出插件,用于收集,丰富和转换来自各种来源的数据。

继续阅读

配置filebeat+logstash收集nginx系统日志(一)

环境设定

192.168.33.10 #安装ElasticSearch及kibana, 建议内存4G以上
192.168.33.11 #安装logstash, 建议内存4G以上
192.168.33.12 #安装filebeat及nginx, 建议内存2G以上

原理分析

1, filebeat收集nginx的日志, 并将其发送给logstash, 因此filebeat需要指定nginx日志的位置及logstash的地址/端口信息.
2, logstash收到日志以后, 对日志进行解析(filter, 分析出其中的关键片断, 例如时间/客户端IP/访问URL/HTTP返回状态等信息), 然后传送给ElasticSearch.
3, kibana负责展示ElasticSearch里的日志内容

1, 安装安装ElasticSearch及kibana

参考这篇文章.

2, 安装及配置logstash

本文中的Logstash安装在192.168.33.11上面.

$ yum install logstash

$ cp /etc/logstash/logstash.yml /etc/logstash/logstash.yml.`date +%Y%m%d`
$ vim /etc/logstash/logstash.yml  #修改如下配置项
...
path.data: /var/lib/logstash
path.config: /etc/logstash/conf.d
...
http.host: "192.168.33.11"
path.logs: /var/log/logstash
...

继续阅读

godaddy的.app域名申请一年的免费SSL

.app域名是谷歌推出的自带免费SSL证书的域名, 如果你在Godaddy购买了.app域名, 那么你的域名会自动带有一年的免费SSL证书(需要在Godaddy申请), 本文简单写一下申请方法.

假设你申请到的域名是example.app

1, 生成csr
参考Godaddy帮助文档里的这篇文章

$ openssl req -new -newkey rsa:2048 -nodes -keyout example.app.key -out example.app.csr

回车以后会问你一些信息,例如国家,城市等,在询问到Common Name (e.g. server FQDN or YOUR name)时建议填写你的域名信息,例如example.app

然后就会生成下面2个文件
example.app.csr
example.app.key

去Godaddy页面上申请SSL证书, 当然, 需要.csr文件中的内容

只需要几分钟, Godaddy会为你准备好证书, Download之. Download的时候, 由于”Server type”没有”Nginx”, 因此我选择了”Other”

2, 准备SSL证书
参考Godaddy帮助文档里的这篇文章

$ unzip example.app.zip

$ ls    #会解压出来2个文件
8a982df92de94106.crt  gd_bundle-g2-g1.crt  example.app.zip

生成example.app.crt文件

cat 8a982df92de94106.crt gd_bundle-g2-g1.crt >> example.app.crt

继续阅读