清风小荷塘改名了

特色

清风小荷塘改名了,从此不再叫清风小荷塘了。
自从07年定下这个名字,一直沿用至今。
现在的清风小荷塘,已不再是一个书生意气、单纯懵懂的少年了,变成了一个满脸胡渣的大叔。
一直想不到啥好的博客名字。就乱起一个吧。
麻烦友情链接里的朋友们,改一下我的链接名吧,谢谢。

生查子
宋·欧阳修
去年元夜时,花市灯如昼。
月上柳梢头,人约黄昏后。

今年元夜时,月与灯依旧。
不见去年人,泪湿春衫袖。

使用Prometheus和Grafana构建集群监控系统(三): 一些metric的计算语句

本文可能不定期更新.

1, node exporter的一些计算语句

CPU使用率(单位为percent)
100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

内存已使用(单位为bytes)
node_memory_MemTotal_bytes - node_memory_MemFree_bytes - node_memory_Cached_bytes - node_memory_Buffers_bytes - node_memory_Slab_bytes

内存使用量(单位为bytes/sec)
node_memory_MemTotal_bytes - node_memory_MemFree_bytes - node_memory_Cached_bytes - node_memory_Buffers_bytes - node_memory_Slab_bytes

内存使用率(单位为percent)
((node_memory_MemTotal_bytes - node_memory_MemFree_bytes - node_memory_Cached_bytes - node_memory_Buffers_bytes - node_memory_Slab_bytes)/node_memory_MemTotal_bytes) * 100

server1的内存使用率(单位为percent)
((node_memory_MemTotal_bytes{instance="server1"} - node_memory_MemAvailable_bytes{instance="server1"})/node_memory_MemTotal_bytes{instance="server1"}) * 100

server2的磁盘使用率(单位为percent)
((node_filesystem_size_bytes{fstype=~"xfs|ext4",instance="server2"} - node_filesystem_free_bytes{fstype=~"xfs|ext4",instance="server2"}) / node_filesystem_size_bytes{fstype=~"xfs|ext4",instance="server2"}) * 100

uptime时间(单位为seconds)
time() - node_boot_time

server1的uptime时间(单位为seconds)
time() - node_boot_time_seconds{instance="server1"}

网络流出量(单位为bytes/sec)
irate(node_network_transmit_bytes_total{device!~"lo|bond[0-9]|cbr[0-9]|veth.*"}[5m]) > 0

server1的网络流出量(单位为bytes/sec)
irate(node_network_transmit_bytes_total{instance="server1", device!~"lo|bond[0-9]|cbr[0-9]|veth.*"}[5m]) > 0

网络流入量(单位为bytes/sec)
irate(node_network_receive_bytes_total{device!~"lo|bond[0-9]|cbr[0-9]|veth.*"}[5m]) > 0

server1的网络流入量(单位为bytes/sec)
irate(node_network_receive_bytes_total{instance="server1", device!~"lo|bond[0-9]|cbr[0-9]|veth.*"}[5m]) > 0

磁盘读取速度(单位为bytes/sec)
irate(node_disk_read_bytes_total{device=~"sd.*"}[5m])

继续阅读

使用Prometheus和Grafana构建集群监控系统(二): 定制Grafana展示界面

本文承接上一篇使用Prometheus和Grafana构建集群监控系统(一): 配置与搭建, 将演示一下如何在Grafana中定制一个好看的界面, 最终形成的界面如下图(点击图片查看大图):
定制Grafana展示界面

好了, 接下来开始我们的Grafana界面定制过程吧.

先添加一个Dashboard
定制Grafana展示界面 继续阅读

使用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具有更大的占用空间,但提供了大量的输入,过滤和输出插件,用于收集,丰富和转换来自各种来源的数据。

继续阅读

第 1 页,共 152 页123456...102030...最旧 »