iftop でネットワーク接続状況をリアルタイム監視

iftop 概要

CLI上で利用できるネットワークの接続状況をリアルモニタリングするツールです。
→ ネットワークのボトルネックを特定する為に利用します。

単にネットワークのモニタリングであれば、モニタリングツールで良いですが

具体的にどこ(ドメイン・IP・ポート)にどれくらい(データ転送量)がわかります。

インストール方法

  • Ubuntu
1
$ sudo apt-get install -y iftop
  • CentOS
1
2
$ sudo yum -y install epel-release
$ sudo yum -y install iftop

使い方

よく利用するのはこんな形です。
※eth0 がない場合は -i eth0 を除いてください。

1
$ sudo iftop -i eth0 -B -P -n -N
  • -i インターフェース指定
  • -B 表示単位を Byte にする
  • -P プロトコル or ポート表示
  • -n ドメインでなく ip で表示
  • -N プロトコルサービス名でなくポート番号で表示

表示項目

=> が送信、
<= が受信です

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
                           24.4kB                      48.8kB                      73.2kB                      97.7kB                 122kB
+--------------------------+---------------------------+---------------------------+---------------------------+---------------------------
ip-10-13-1-101.ap-northeast-1.compute.internal:http => ip-10-13-100-41.ap-northeast-1.compute.internal:62635 559kB 121kB 67.1kB
<= 3.60kB 1.90kB 1.05kB
ip-10-13-1-101.ap-northeast-1.compute.internal:35244 => ip-10-13-102-56.ap-northeast-1.compute.internal:mysql 0B 2.18kB 1.21kB
<= 0B 23.1kB 12.8kB
ip-10-13-1-101.ap-northeast-1.compute.internal:35247 => ip-10-13-102-56.ap-northeast-1.compute.internal:mysql 0B 2.13kB 1.18kB
<= 0B 23.0kB 12.8kB
ip-10-13-1-101.ap-northeast-1.compute.internal:http => ip-10-13-0-231.ap-northeast-1.compute.internal:8239 0B 7.73kB 4.29kB
<= 0B 1.16kB 658B
ip-10-13-1-101.ap-northeast-1.compute.internal:ssh => ip-10-13-0-11.ap-northeast-1.compute.internal:56320 612B 576B 522B
<= 26B 26B 32B
ip-10-13-1-101.ap-northeast-1.compute.internal:http => ip-10-13-100-41.ap-northeast-1.compute.internal:62657 0B 49B 27B
<= 0B 92B 51B
ip-10-13-1-101.ap-northeast-1.compute.internal:40069 => ip-10-13-103-247.ap-northeast-1.compute.internal:6379 0B 99B 55B
<= 0B 34B 19B
ip-10-13-1-101.ap-northeast-1.compute.internal:40072 => ip-10-13-103-247.ap-northeast-1.compute.internal:6379 0B 99B 55B
<= 0B 34B 19B
ip-10-13-1-101.ap-northeast-1.compute.internal:http => ip-10-13-100-73.ap-northeast-1.compute.internal:27698 0B 44B 25B
<= 0B 33B 18B
ip-10-13-1-101.ap-northeast-1.compute.internal:53696 => ip-10-13-0-2.ap-northeast-1.compute.internal:domain 0B 21B 12B
<= 0B 31B 17B
ip-10-13-1-101.ap-northeast-1.compute.internal:41975 => ip-10-13-0-2.ap-northeast-1.compute.internal:domain 0B 21B 12B
<= 0B 31B 17B
-------------------------------------------------------------------------------------------------------------------------------------------
TX: cum: 1.31MB peak: 560kB rates: 560kB 134kB 74.7kB
RX: 505kB 117kB 3.69kB 49.8kB 28.1kB
TOTAL: 1.81MB 564kB 564kB 184kB 103kB
Item Value
TX (Transmitter) 送信量
RX (Receiver) 受信量
TOTAL iftop 起動からの総量
cum 総量
peak 最大
右端3列 (各トラフィック, rates含む) 2秒、10秒、40秒の転送量平均値

※TX,RX の 「X」 は省略しますよという意味

閲覧し続けると気になる処理があった時には
Shift + P で一旦停止させます。

もう一度開始したい場合は Shift + P です。

実際のCLI

以下見ていただくと白い帯グラフが左から伸びているのが見えるかと思います。
この横棒が一番上のバーの目盛りに相応してぱっと見でどの程度かわかるのが便利です。

DB への接続を確かめる

DB (MySQL) のデフォルトポート 3306 への送受信を調べたいとき

1
$ sudo iftop -B -P -n -N -f "port 3306"

当然ながら受信の方が大きいです。

補足

実際に負荷が高い時等、特定のインシデントがあった際に追記していこうと思います♪

Reference

node_exporter シェルでクエリ自作

node_exporter シェルでクエリ自作

概要

node_expoter のオプション --collector.textfile.directory で指定したディレクトリに *.prom という拡張子を配置することで
そこに記述したメトリクス情報を prometheus server が読み取ってくれます。

この *.prom ファイルを一定時間毎に更新すればメトリクスが自作できる、というものです。

手順

  • node_exporter 自体のインストール・セットアップは以下ご参照ください。

上記手順では以下に node_exporter を配置しています。
環境によって適宜書き換えてください。

1
/usr/local/node_exporter/node_exporter

text_collector ディレクトリ作成

1
2
$ cd /usr/local/node_exporter
$ mkdir text_collector

shell 作成

今回は httpd の process count のメトリクス追加することとします。

  • /usr/local/node_exporter/text_collector/httpd.sh 作成

cron 設定

1
2
# node_exporter httpd 5分毎更新
*/5 * * * * /usr/local/node_exporter/text_collector/httpd.sh

httpd.prom 作成確認

  • /usr/local/node_exporter/text_collector/httpd.prom
1
node_httpd_count 24

上記の node_httpd_count がメトリクス名になります。

node_expoter 再起動

以下のようにディレクトリ指定します。

1
node_expoter --collector.textfile.directory /usr/local/node_exporter/text_collector

作成したメトリクスを指定し確認する。

無事できました!

これを利用してるとシェル芸で色々事足りることもあります ♪

一助になれば何よりです。

node_expoter error occured ! hwmon collector failed

node_expoter error occured ! hwmon collector failed

概要

Amazon Linux に node_exporter をインストールし起動した所以下のエラーが発生し、起動停止してしまいました。

1
ERRO[0007] ERROR: hwmon collector failed after 0.000011s: open /proc/class/hwmon: no such file or directory  source="node_exporter.go:92"

hwmon とは?

Hard Ware MONitoring. Linux カーネルのセンサーチップから Hard Ware の温度やファン回転数や電圧を取得できる。

環境情報は以下の通りです。

  • Amazon Linux AMI release 2016.09
  • node_exporter version 0.14.0-rc.1 (branch: master, revision:5a07f4173d97fa0dd307db5bd3c2e6da26a4b16e)

上記エラーですが issue として上がっていました。
そして解決されてました!

タイミングが悪かったのかマージされる前の release を取得していた為
このエラーに遭遇していました。

最新のソースは master ブランチしてビルドするのが良さそうです。

以下に Amazon Linux で実施したインストール手順をまとめました。

手順

Golang インストール

以下 Golang オフィシャルサイトにある標準的なインストール方法です。参考にしてください。

node_exporter をソースからインストールしビルド

1
2
3
4
5
6
7
8
9
$ mkdir -p $GOPATH/src/github.com/prometheus
$ cd $GOPATH/src/github.com/prometheus
$ git clone https://github.com/prometheus/node_exporter
$ cd node_exporter
$ make build

// version 確認
$ ./node_exporter --version
node_exporter, version 0.14.0-rc.1 (branch: master, revision: 428bc92b1c9b38f6de96bceb67bc5d9b3bdcf6e7)

ついでに起動スクリプト

  • 事前準備
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// pid ファイル置き場 作成
$ sudo mkdir -p /var/run/prometheus

// log ファイル置き場 作成
$ sudo mkdir -p /var/log/prometheus

// daemonize インストール
$ cd /usr/local/src
$ sudo git clone https://github.com/bmc/daemonize
$ cd daemonize
$ sudo ./configure
$ sudo make
$ sudo make install

// PATHが通ってなかったらPATHに乗せる
$ sudo cp daemonize /bin/

$ which daemonize
/bin/daemonize
  • 起動スクリプト作成
1
2
3
4
$ cd /etc/init.d
$ sudo git clone https://gist.github.com/kenzo0107/eebb6c1c06ba04b7073c171580cec445
$ sudo cp eebb6c1c06ba04b7073c171580cec445/node_exporter.init ./node_exporter
$ sudo chmod 0755 node_exporter
  • 起動
1
$ sudo /etc/init.d/node_exporter start

無事エラーなく起動するようになりました ♪

Alertmanager 構築手順

Alertmanager 構築手順

概要

前回 Node Exporter 構築しました。

今回は監視実施サーバで Alertmanager 構築を実施します。

今回やること 3 行まとめ

  • Alertmanager インストール & 起動スクリプト作成
  • Prometheus 通知条件設定
  • Alertmanager で Slack 通知

Alertmanager の役割

アラートのレベルによって通知先をどの程度の頻度で送信するかを管理します。
あくまで、通知先の管理をします。

実際のアラート条件の設定は Prometheus Server でします。

環境

  • CentOS Linux release 7.3.1611 (Core)

Alertmanager インストール

  • パッケージインストール
1
2
3
4
5
$ cd /usr/local/src
$ sudo wget https://github.com/prometheus/alertmanager/releases/download/v0.5.1/alertmanager-0.5.1.linux-amd64.tar.gz
$ sudo tar -C /usr/local -xvf alertmanager-0.5.1.linux-amd64.tar.gz
$ cd /usr/local
$ sudo mv alertmanager-0.5.1.linux-amd64 alertmanager
  • シンボリックリンク作成
1
2
3
4
5
6
7
8
$ sudo ln -s /usr/local/alertmanager/alertmanager /bin/alertmanager

$ alertmanager --version

alertmanager, version 0.5.1 (branch: master, revision: 0ea1cac51e6a620ec09d053f0484b97932b5c902)
build user: root@fb407787b8bf
build date: 20161125-08:14:40
go version: go1.7.3

Alert 通知先設定

以下 Slack へ通知設定です。

1
2
3
$ cd /usr/local/alertmanager
$ git clone https://gist.github.com/kenzo0107/71574c2d4d70ba7a9efaa88b4ff1be1b
$ mv 71574c2d4d70ba7a9efaa88b4ff1be1b/alertmanager.yml .
  • alertmanager.yml

slack 通知箇所を適宜変更して下さい。

Alertmanager 起動

とりあえず起動するならこれだけ

1
$ sudo alertmanager -config.file alertmanager.yml

http://alertmanager_server:9093/#/alerts にアクセスすると以下のような画面が表示されます。

Prometheus 同様、Alertmanager も起動スクリプトを作成しそこで起動管理をします。

起動スクリプト作成

  • オプションファイル作成
1
2
3
$ cat << 'EOF' > /usr/local/alertmanager/option
OPTIONS="-config.file /usr/local/alertmanager/alertmanager.yml"
EOF
  • Alertmanager 起動スクリプト
1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ sudo cat << 'EOF' | sudo tee /usr/lib/systemd/system/alertmanager.service
[Unit]
Description=Prometheus alertmanager Service
After=syslog.target prometheus.alertmanager.service

[Service]
Type=simple
EnvironmentFile=-/usr/local/alertmanager/option
ExecStart=/bin/alertmanager $OPTIONS
PrivateTmp=false

[Install]
WantedBy=multi-user.target
EOF
  • 起動設定
1
2
3
4
$ sudo systemctl daemon-reload
$ sudo systemctl enable alertmanager.service
$ sudo systemctl start alertmanager.service
$ sudo systemctl status alertmanager.service -l

アラート通知条件設定

アラート通知条件は Prometheus Server 側で設定します。

Prometheus Official - ALERTING RULES

サンプルとして以下設定します。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
$ cd /usr/local/prometheus-server
$ cat << 'EOF' > alerts.rules

# インスタンスに 5分以上(FOR) アクセスできない場合(IF up == 0)
# severity = "critical" とラベル付けし通知
ALERT InstanceDown
IF up == 0
FOR 5m
LABELS { severity = "critical" }
ANNOTATIONS {
summary = "Instance {{ $labels.instance }} down",
description = "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes.",
}

// Prometheus 設定ファイルチェック
$ promtool check-config prometheus.yml

Checking prometheus.yml
SUCCESS: 1 rule files found

Checking alerts.rules
SUCCESS: 1 rules found

Prometheus Server で Alertmanager URL 設定

Prometheus の起動オプションで Alertmanager URL 設定します。

1
-alertmanager.url=http://localhost:9093
1
2
3
4
5
6
7
$ cd /usr/local/prometheus-server
$ cat << 'EOF' > option
OPTIONS="-config.file=/usr/local/prometheus-server/prometheus.yml -web.console.libraries=/usr/local/prometheus-server/console_libraries -web.console.templates=/usr/local/prometheus-server/consoles -alertmanager.url=http://localhost:9093"
EOF

// Prometheus 再起動
$ sudo systemctl restart prometheus.service

注意

今回 Alertmanager は Prometheus Server と同サーバ上に設定しているので

1
http://localhost:9093

となっていますが、ドメインが異なる場合は適宜設定してください。

Prometheus Alerts ページアクセス

設定した通知条件が表示されています。

通知試験

監視対象サーバの node_exporter を停止してみます。

1
$ sudo systemctl stop node_exporter

すると…

Slack に通知が届きました!

http://alertmanager_server:9093/#/alerts にアクセスすると通知内容一覧が表示されます。

以上で簡単ながら
Prometheus からリモートサーバを監視しアラート通知するところまでを
まとめました。

  1. Prometheus でサーバ監視
  2. Node Exporter 構築手順 + Prometheus から AWS オートスケール監視
  3. Alertmanager 構築手順

補足

フロントエンド

Grafana 3.x 以降でデフォルトプラグインで Prometheus をサポートしていたりと
Prometheus のフロントは Grafana が導入しやすく相性が良かったです。

メトリクスを自作したり、Prometheus 独自のクエリを駆使して
様々なメトリクス監視が実現できます。

My alerts.rules

Learning

改めて自身で構築してみて
Line Casual Talks #1, #2 を見直すと非常に理解が深まると思います。

一助になれば何よりです。

以上です。
ご静聴ありがとうございました。

Node Exporter 構築手順 + Prometheus からAWSオートスケール監視

Node Exporter 構築手順 + Prometheus からAWSオートスケール監視

概要

前回 Prometheus Server 構築しました。

今回は 監視対象サーバで Node Exporter 構築を実施します。

今回やること 3 行まとめ

  • Node Exporter インストール
  • Node Exporter 起動スクリプト作成
  • Node Exporter 起動し Prometheus Server からモニタリング

環境

  • CentOS Linux release 7.1.1503 (Core)

Node Exporter インストール

  • パッケージインストール
1
2
3
4
5
$ cd /usr/local/src
$ sudo wget https://github.com/prometheus/node_exporter/releases/download/v0.14.0-rc.1/node_exporter-0.14.0-rc.1.linux-amd64.tar.gz
$ sudo tar -C /usr/local -xvf node_exporter-0.14.0-rc.1.linux-amd64.tar.gz
$ cd /usr/local
$ sudo mv node_exporter-0.14.0-rc.1.linux-amd64 node_exporter
  • シンボリックリンク作成
1
2
3
4
5
6
7
$ sudo ln -s /usr/local/node_exporter/node_exporter /bin/node_exporter

$ node_exporter --version
node_exporter, version 0.14.0-rc.1 (branch: master, revision: 5a07f4173d97fa0dd307db5bd3c2e6da26a4b16e)
build user: root@ed143c8f2fcd
build date: 20170116-16:00:03
go version: go1.7.4

Node Exporter 起動

とりあえず起動するならこれだけ

1
$ sudo node_exporter

http://node_exporter_server:9100/metrics にアクセスし
取得できる node_exporter で取得しているサーバのメトリクス情報が確認できます。

Prometheus 同様、Node Exporter も起動スクリプトを作成しそこで起動管理をします。

起動スクリプト作成

  • Node Exporter 起動スクリプト
1
2
3
4
5
6
7
8
9
10
11
12
$ sudo cat << 'EOF' | sudo tee /usr/lib/systemd/system/node_exporter.service
[Unit]
Description=Node Exporter

[Service]
Type=simple
ExecStart=/bin/node_exporter
PrivateTmp=false

[Install]
WantedBy=multi-user.target
EOF
  • 起動設定
1
2
3
4
$ sudo systemctl daemon-reload
$ sudo systemctl enable node_exporter.service
$ sudo systemctl start node_exporter.service
$ sudo systemctl status node_exporter.service -l

アクセスしてみる

http://node_exporter_server:9100/metrics にアクセスします。

以下のように表示されていれば Node Exporter 起動成功です。

Prometheus から監視

今回は AWS EC2 インスタンスで起動中の node_exporter によるメトリクス取得設定です。

※ 監視実施サーバに AmazonEC2ReadOnlyAccess をアタッチしたロール設定をする必要があります。
※ 監視対象サーバに 監視対象サーバから 9100 ポート へアクセスできるようにセキュリティグループ設定します。

  • /usr/local/prometheus-server/prometheus.yml 編集

以下設定は region 指定しアクセス権のある Instance のメトリクスを取得します。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# my global config
global:
scrape_interval: 15s
evaluation_interval: 15s

external_labels:
monitor: 'codelab-monitor'

rule_files:
# - "first.rules"
# - "second.rules"

scrape_configs:
- job_name: 'prometheus'

static_configs:
- targets: ['localhost:9090']

- job_name: 'node'
ec2_sd_configs:
- region: ap-northeast-1
access_key: ********************
secret_key: ****************************************
port: 9100

タグで監視対象を絞る

全インスタンスを監視であれば上記で問題ありません。

ですが、監視対象をある程度条件で絞りたいケースがあります。
そんな時、Prometheus では relabel_configs でインスタンスの設定タグで絞る方法があります。

  • インスタンスのタグ設定
  • prometheus.yml 設定
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
# my global config
global:
scrape_interval: 15s
evaluation_interval: 15s

external_labels:
monitor: 'codelab-monitor'

rule_files:
# - "first.rules"
# - "second.rules"

scrape_configs:
- job_name: 'prometheus'

static_configs:
- targets: ['localhost:9090']

- job_name: 'node'
ec2_sd_configs:
- region: ap-northeast-1
access_key: ********************
secret_key: ****************************************
port: 9100
relabel_configs:
- source_labels: [__meta_ec2_tag_Stage]
regex: production
action: keep
- source_labels: [__meta_ec2_tag_Role]
regex: web
action: keep
  • prometheus.yml 編集後、再起動
1
$ sudo systemctl restart prometheus.service

Prometheus から node_exporter 起動したサーバを監視できているか確認

http://prometheus_server:9090/consoles/node.html

Up : Yes となっている Node のリンクをクリックすると CPU, Disck のグラフが確認できます。

次回は 監視対象で Alertmanager 構築します。

参照

Prometheus でサーバ監視

Prometheus でサーバ監視

概要

以前 Ansible + Vagrant で Prometheus モニタリング環境構築について書きました。

今回は具体的によくある設定ユースケースを順追って設定していきます。

  1. Prometheus Server 構築
  2. 監視対象で Node Exporter 構築
  3. Alertmanager 構築

今回やること 3 行まとめ

  • Prometheus Server モジュールインストール
  • Prometheus Server 起動スクリプト作成
  • Prometheus Server 起動し自身のサーバモニタリング

Prometheus の設定ファイルについては
全体像を理解した後が良いと思いますので
Node Exporter の設定の後に実施したいと思います。

環境

  • CentOS Linux release 7.3.1611 (Core)

Prometheus インストール

1
2
3
4
5
$ cd /usr/local/src
$ sudo wget https://github.com/prometheus/prometheus/releases/download/v1.4.1/prometheus-1.4.1.linux-amd64.tar.gz
$ sudo tar -C /usr/local -xvf prometheus-1.4.1.linux-amd64.tar.gz
$ cd /usr/local
$ sudo mv prometheus-1.4.1.linux-amd64 prometheus-server
  • シンボリックリンク作成
1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ sudo ln -s /usr/local/prometheus-server/prometheus /bin/prometheus
$ sudo ln -s /usr/local/prometheus-server/promtool /bin/promtool

$ prometheus --version
prometheus, version 1.4.1 (branch: master, revision: 2a89e8733f240d3cd57a6520b52c36ac4744ce12)
build user: root@e685d23d8809
build date: 20161128-09:59:22
go version: go1.7.3

$ promtool version
promtool, version 1.4.1 (branch: master, revision: 2a89e8733f240d3cd57a6520b52c36ac4744ce12)
build user: root@e685d23d8809
build date: 20161128-09:59:22
go version: go1.7.3

Prometheus 起動

とりあえず起動するならこれだけ

1
$ sudo prometheus -config.file=/usr/local/prometheus-server/prometheus.yml

ただ ↑ これを毎回実行するのは辛いので起動スクリプトを作成して
サーバ再起動時に自動起動したり
systemctl start ... と実行したい。

起動スクリプト作成

  • Prometheus オプションファイル作成
1
2
3
$ cat << 'EOF' > /usr/local/prometheus-server/option
OPTIONS="-config.file=/usr/local/prometheus-server/prometheus.yml -web.console.libraries=/usr/local/prometheus-server/console_libraries -web.console.templates=/usr/local/prometheus-server/consoles"
EOF
  • Prometheus 起動スクリプト
1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ sudo cat << 'EOF' | sudo tee /usr/lib/systemd/system/prometheus.service
[Unit]
Description=Prometheus Service
After=syslog.target prometheus.service

[Service]
Type=simple
EnvironmentFile=-/usr/local/prometheus-server/option
ExecStart=/bin/prometheus $OPTIONS
PrivateTmp=false

[Install]
WantedBy=multi-user.target
EOF
  • 起動設定
1
2
3
4
$ sudo systemctl daemon-reload
$ sudo systemctl enable prometheus.service
$ sudo systemctl start prometheus.service
$ sudo systemctl status prometheus.service -l

アクセスしてみる

<IP Address>:9090 にアクセスします。
以下のように表示されていれば Prometheus 起動成功です。

Imgur

オプション設定でも設定した、 /usr/local/prometheus-server/consoles の各 html にもアクセスしてみてください。

<IP Address>:9090/consoles/prometheus-overview.html?instance=localhost%3a9090

次回は 監視対象で Node Exporter 構築 します。

LINE Notify で Zabbix Alert 通知

LINE Notify で Zabbix Alert 通知

概要

Zabbix アラート を LINE Notify を利用して
LINE にメッセージを送るように設定しました。

手順

LINE Notify アクセス

[https://notify-bot.line.me/ja/]

登録してログイン

サービス登録

この情報が審査されるということは特になかったですが
ある程度精度の高い情報を入力して登録しときました

トークルーム選択しトークン発行

発行したトークンコピー

Zabbix スクリプト設定

Env

  • Zabbix 3.0
  • CentOS Linux release 7.2.1511 (Core)

Install Steps

1
2
3
4
5
[Zabbix-Server]$ cd /usr/lib/zabbix/alertscripts    # AlertScriptsPath
[Zabbix-Server]$ git clone https://github.com/kenzo0107/zabbix3-linenotify
[Zabbix-Server]$ mv zabbix3-slack/line_notify.sh .
[Zabbix-Server]$ rm -r zabbix3-linenotify
[Zabbix-Server]$ chmod 755 line_notify.sh

Media Types 設定

Users > Media 設定

通知テスト

テスト環境などで
Nginx の process が 1 つ以上になったらアラート出すように設定してみた結果

所感

トークルームに参加するにも
LINE アカウントはプライベートアカウントなので
ちょっと知られたくないわ〜という時は
何とも言えない気持ちになる方もいることがわかりました。

ご利用は計画的に。

今後の期待

個人的に
Twilio みたいに LINE Notify で電話通知出来たら嬉しいです。

まずは障害がない世界を ♪

以上です。

SlowQuery を検知して Explain で解析し Slack へ通知

SlowQuery を検知して Explain で解析し Slack へ通知

fluentd でエラーログを Slack へ通知 の続きです。

概要

MySQL DB サーバ の SlowQuery 状況を
リアルタイムに Slack で確認できるようにする為に導入しました。

環境

  • CentOS 6.5
  • td-agent 0.12.26

Fluent Plugin インストール

今回必要モジュールをインストールします。

1
2
3
# td-agent-gem install fluent-plugin-nata2
# td-agent-gem install fluent-plugin-mysql_explain
# td-agent-gem install fluent-plugin-sql_fingerprint

Percona Tool Kit インストール

fluent-plugin-sql_fingerprint で利用する fingersprint をインストールします。

1
2
# rpm -Uhv http://www.percona.com/downloads/percona-release/percona-release-0.0-1.x86_64.rpm
# yum install -y percona-toolkit-2.2.5-2.noarch

fluentd 設定ファイル作成

以下ファイル設定するとします。

  • /etc/td-agent/conf.d/mysql.conf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
<source>
type mysqlslowquery_ex
read_from_head
path /var/lib/mysql/mysql-slow.log
pos_file /var/log/td-agent/mysql-slow.pos
tag mysqld.slow_query.bp
last_dbname_file /tmp/slowquery.log.lastdb
</source>

<filter mysqld.slow_query.**>
type record_transformer
<record>
hostname ${hostname}
</record>
</filter>

<filter mysqld.slow_query.**>
type mysql_explain
host 127.0.0.1
port 3306
database <DB_NAME>
username <DB_USER>
password <DB_PASSWORD>
sql_key sql
added_key explain
</filter>

<filter mysqld.slow_query.**>
type sql_fingerprint
fingerprint_tool_path /usr/bin/pt-fingerprint
</filter>

<match mysqld.slow_query.**>

type copy

<store>
type slack
webhook_url <Slack Webhook URL>
channel <Slack Channel>
username xxx DB1 [MySQL] Slow Query
icon_emoji :ghost:
color danger
message "*[User]* %s\r\n *[Host]* %s\r\n *[Query Time]* %s\r\n *[Lock Time]* %s\r\n *[Rows sent]* %s\r\n *[Rows Examined]* %s\r\n *[SQL]* %s \r\n *[Explain]* %s \r\n"
message_keys user,host,query_time,lock_time,rows_sent,rows_examined,fingerprint,explain
flush_interval 1m
</store>

</match>

※slowquery のパス、DB のアクセスアカウントなどは各環境により変更してください。

td-agent 再起動

1
# service td-agent restart

確認

SlowQuery を発行し、Slack に通知されるか確認します。

  • 3 秒 sleep させ、my.cnf に設定されている long-query-time の閾値の秒数を超えるようにしています。
1
mysql > SELECT count(*), sleep(3) FROM <table>;
  • Slack 通知確認

Slack に通知されました!

show more をクリックすると Explain が通知されているのがわかる。

総評

リアルタイム通知は
特に新規開発時に効果的でした。

また
ElasticSearch へ蓄積し時間軸で分析するのは
サイトのイベントとの相関性が見え面白いです。

その環境と状況により発生するスロークエリが見えてきます。

以上です。

Zabbix + Reactio 連携

Zabbix + Reactio 連携

概要

Reactio の無料化によりその機能が解放され、様々な監視・アラートツールとの連携が可能になりました。
これを機に Zabbix + Reactio 連携したのでまとめました。

Reactio が無料になります

環境

  • Zabbix 3.0
  • CentOS Linux release 7.2.1511 (Core)

Zabbix 3.0 がインストールされ起動されていることを前提とします。

Zabbix 管理画面で Host 設定

※既に設定されている場合はスキップしてください。

Configuration > Hosts > create

  • Host name: Project1

Reactio プロジェクト作成

プロジェクト毎にインシデントを管理します。

https://<Organization ID>.reactio.jp/settings/project

Zabbix 管理画面で設定している Host 名を Project 名とします。

Reactio API 発行

プロジェクト作成ページと同ページ内にある API 項目の 「+」ボタンクリックし API KEY 発行します。

zabbix-reactio インストール

1
2
$ cd /usr/lib/zabbix/alertscripts
$ git clone http://github.com/zabbix-reactio

Zabbix DB 情報 と Reactio で作成した Project と 発行した API KEY を設定ファイルに設定

1
2
$ cd /usr/lib/zabbix/alertscripts/zabbix-reactio
$ vi config.inc
  • db_info に DB 情報設定
  • <Organization ID> 設定
  • Project = API KEY 設定
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[db_info]
host = <DB Host>
user = <DB user>
pass = <DB pass>
db = <DB name>

[reactio_url]
default = https://<Organization ID>.reactio.jp/api/v1/incidents

[api_key]
Project1 = <Project1's API KEY>
Project2 = <Project2's API KEY>
Project3 = <Project3's API KEY>
...
...

DB カラム追加

  • Zabbix alerts テーブルに Reactio Incident ID カラムを追加します。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
$ cd /usr/lib/zabbix/alertscripts/zabbix-reactio
$ mysql -h <DB Host> -u <DB user> -p<DB pass> <DB name> -e "`cat add_reactioincidentid.sql`"
$ mysql -h <DB Host> -u <DB user> -p<DB pass> <DB name> -e "SHOW COLUMNS FROM alerts"

+---------------------+---------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------------------+---------------------+------+-----+---------+-------+
| alertid | bigint(20) unsigned | NO | PRI | NULL | |
| actionid | bigint(20) unsigned | NO | MUL | NULL | |
| eventid | bigint(20) unsigned | NO | MUL | NULL | |
| userid | bigint(20) unsigned | YES | MUL | NULL | |
| clock | int(11) | NO | MUL | 0 | |
| mediatypeid | bigint(20) unsigned | YES | MUL | NULL | |
| sendto | varchar(100) | NO | | | |
| subject | varchar(255) | NO | | | |
| message | text | NO | | NULL | |
| status | int(11) | NO | MUL | 0 | |
| retries | int(11) | NO | | 0 | |
| error | varchar(128) | NO | | | |
| esc_step | int(11) | NO | | 0 | |
| alerttype | int(11) | NO | | 0 | |
| reactio_incident_id | int(11) | NO | | 0 | | ← 追加されているのが確認できます
+---------------------+---------------------+------+-----+---------+-------+

Reacito では全てのインシデントは ID で管理されています。
Zabbix で障害アラート通知時に Reactio インシデント作成 API をコールし インシデント ID を保存します。

このインシデント ID は Zabbix で障害回復アラート通知時に Reatio インシデントステータス更新 API をコールする際に利用します。

Zabbix Media types: Reactio 作成

Administration > Media types Create media type ボタンクリック

以下値を入力し Add ボタンクリック

Item Value
Name Reactio
Type Script
Script name zabbix-reactio/reactio.php
Script Parameters 1 {ALERT.SUBJECT}
Script Parameters 2 {ALERT.MESSAGE}

Zabbix Users: Reactio 作成

Administration > Users Create media type ボタンクリック

  • Reactio ユーザ作成
  • Media タブをクリックし Media 情報入力
  • Permission タブをクリックし Zabbix Super Admin 選択
  • Add ボタン クリックし一覧に表示されることを確認

Zabbix Actions: Reactio Notification 作成

Configuration > Actions Create ボタンクリック

  • Action タブ選択し Action 情報入力
Item Value
Name Reactio Notification
Default subject PROBLEM alert - {TRIGGER.NAME} is {TRIGGER.STATUS}
Default message HOST: {HOST.NAME}
TRIGGER_NAME: {TRIGGER.NAME}
TRIGGER_STATUS: {TRIGGER.STATUS}
TRIGGER_SEVERITY: {TRIGGER.SEVERITY}
DATETIME: {DATE} / {TIME}
ITEM_ID: {ITEM.ID1}
ITEM_NAME: {ITEM.NAME1}
ITEM_KEY: {ITEM.KEY1}
ITEM_VALUE: {ITEM.VALUE1}
EVENT_ID: {EVENT.ID}
TRIGGER_URL: {TRIGGER.URL}
Recovery message チェック
Recovery subject RECOVERY alert - {TRIGGER.NAME} is {TRIGGER.STATUS}
Recovery message HOST: {HOST.NAME}
TRIGGER_NAME: {TRIGGER.NAME}
TRIGGER_STATUS: {TRIGGER.STATUS}
TRIGGER_SEVERITY: {TRIGGER.SEVERITY}
DATETIME: {DATE} / {TIME}
ITEM_ID: {ITEM.ID1}
ITEM_NAME: {ITEM.NAME1}
ITEM_KEY: {ITEM.KEY1}
ITEM_VALUE: {ITEM.VALUE1}
EVENT_ID: {EVENT.ID}
TRIGGER_URL: {TRIGGER.URL}
Enabled チェック

以下項目から判断して Reactio API を叩いてます。

  • subject の PROBLEM/RECOVERY
  • HOST: {HOST.NAME}
  • EVENT_ID: {EVENT.ID}

メッセージを整形する場合でも、 上記項目は残しておくようにしてください。

  • Operations タブ選択し Operations 情報入力

以上 Zabbix で Reactio 連携設定完了しました。

実行結果

  • インシデント作成できた!
  • 作成したインシデントのステータスが更新された!

今後

当方、運用し始めです。
障害レベルによってメッセージを変更したりと今後更新検討致します。

是非以下も合わせて Zabbix-Slack 連携もご利用ください。

zabbix3-slack

以上
ご清聴ありがとうございました。

Ansible+Vagrant でシンプルなPrometheusモニタリング環境構築

Ansible+Vagrant でシンプルなPrometheusモニタリング環境構築

概要

Prometheus 入門 にあるチュートリアルを
Ansible で簡単に構築できるようにした、
というものです。

先日 2016 年 6 月 14 日、
LINE 株式会社でのPrometheus Casual Talks #1に参加し
ナレッジのおさらいなどしたく、
構築法をまとめました。

Prometheus とは

最近話題の Pull 型の Query Filtering 可能で Grafana 等と連携できる モニタリング/Alert ツールです。

構成

Imgur

  • Prometheus Server × 1
  • Prometheus Client × 2

環境

  • CentOS 6.5
  • Prometheus Server 0.20.0
  • Supervisor 3.3.0
  • Go 1.6.2
  • Ansibl 2.1.0.0
  • Vagrant 1.8.1
  • MacOSX 10.11.5

前提条件

以下ツールをインストールしておいてください。

  • VirtualBox
  • Vagrant
  • Ansible

使い方

1. git repository を clone

[https://github.com/kenzo0107/Vagrant-Prometheus]

1
$ git clone https://github.com/kenzo0107/Vagrant-Prometheus

2. Vagrant VM 起動

1
2
$ cd Vagrant-Prometheus
$ vagrant up

3 node running !

  • 1 node: Prometheus Server
    • 192.168.11.30
  • other 2 nodes: Prometheus Client Server
    • 192.168.33.31
    • 192.168.33.32

3. ssh.config 追加

1
$ vagrant ssh-config > ssh.config

4. ping 疎通試験

1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ ansible default -m ping

server | SUCCESS => {
"changed": false,
"ping": "pong"
}
client1 | SUCCESS => {
"changed": false,
"ping": "pong"
}
client2 | SUCCESS => {
"changed": false,
"ping": "pong"
}

ok, success.

5. 2node に PrometheusClient 設定

1
$ ansible-playbook set_clients_prometheus.yml

6. PrometheusClient の起動確認

以下 PrometheusClient を起動しているサーバにアクセスし
起動されているか確認します。

以下のように表示されれば成功です。

7. PrometheusServer 設定

1
$ ansible-playbook set_server_prometheus.yml

8. PrometheusServer 確認

http://192.168.33.30:9090 にアクセス

以下のように表示されれば成功です。

是非多少なりとも一助となれば何よりです!
いじくり倒してみてください!

以上