第2回 OSS運用管理勉強会運用あるある(Zabbix)

運用あるある(Zabbix)

運用の現場での監視運用ツールの活用

株式会社サイタスマネジメント
米田真治
2013/9/26 第2回 OSS運用管理勉強会 1

トピックス

—  運用業務のよくある状況
—  運用監視ツールのポイント
—  Zabbixの活用ケース
◦  自動登録
◦  カスタム監視


自己紹介

—  米田
真治 (こめだ
しんじ)
◦  株式会社サイタスマネジメント CTO
—  経歴
◦  学生時代にUNIXに出会う
◦  Internetにつながる環境がきた
◦  いろんなプログラムをビルドしているうちに、
開発・構築の楽しさに目覚める
◦  学科のシステム管理を経験
◦  システム運用のおもしろさを覚える

◦  就職してISPのサーバ構築・運用に携わる
◦  2000年6月
サイタスマネジメント創業

会社紹介

サイタスマネジメントでは24時間365日のシステム監
視・運用管理サービスを中心に、お客様の悩みや課
題に応じたソリューションをご提供いたします。
—  システム監視・運用管理マネジメントサービス

◦  監視通知サービス:トラブルの未然防止・早期発見により
システムの安定稼動を支援

◦  障害対応サービス: 経験豊富なエンジニアによる迅速な
ネットワーク復旧支援

◦  運用管理代行サービス:高品質で幅広いサポートメニューで
システム運用の負担を軽減

◦  レポーティング: システムの運用状況や課題を把握し、改
善提案を実施
—  サーバ・ネットワーク構築

http://www.situs.co.jp/

運用業務のよくある状況

高い負荷、負担

リリース先行により運用設計が不明確なままサービスイン

監視

連絡体制

運用オペレーションマニュアル

「運用でカバーする」という悪魔の声

属人的

人に依存する問題
キーパーソンに聞かないとわからない

人のスキル、属人化

運用の現場では、幅広い知識と深い経験が求められます

コスト
費用対効果

ハードウェア・ソフトウェア
保守費用

人件費


仮想化の恩恵

—  仮想化技術
◦  仮想化のソフトウェアレイヤーが、個々の
ハードウェア障害に対する保護を提供する
◦  OSやアプリケーションはハードウェアの
フォールトトレランスを確保する。
—  オンプレミスの仮想化基盤
◦  可用性の確保が重大

—  クラウドの利用
◦  スピード
—  仮想環境やクラウドの活用で
サーバの追加があっという間にできる
–  動的に運用管理の対象が増減する


運用サイドで起こる問題

—  たとえば、
—  キャンペーンによるトラフィック過多

◦  スポットCMなどのキャンペーン広告

◦  ニュース番組で紹介される
◦  SNSでの口コミ

◦  スケールアウト実施
—  新サービスの開始
◦  サーバが一挙に増える

—  たくさんのVM
◦  設定変更、情報の更新が追いつかない


ITシステムのライフサイクル

ウィキペディア故障率曲線より


運用現場の感覚

予期せぬ
トラブル
ワークアラウンド
問題解消

イ
ン
シ
デ
ン
ト
件
数

ハードウェアの経年劣化
2次リリース
サービス追加
バージョンアップ

サービスイン

予期せぬ
トラブル
ワークアラウンド
問題解消


DevOps

Dev
開発エンジニア
リリースエンジニア

Ops
インフラエンジニア
運用エンジニア

Biz
提供サービス主管

スピードが求められる時代

Dev, Ops は技術やサービスの提供者
Bizから

◦  何を求められているのか

◦  何を期待されているのか

Dev

Ops
Biz
「スピードが求められる開発部門」

「安定運用が求められる運用部門」

プロセス自動化

• ユニットテスト
• PuppetやChefなどの構成管理
ツール

状況の共有

リリースプロセス

自動化できる運用ツール
• 対応時間の短縮
• 作業の削減と品質の確保


運用の現場は人のネットワーク

—  頻繁なリリースには、
DevとOpsとの効果的な連係が必要

—  運用への影響(変化)を共有する

ノード追加

•  意図したものなのか

•  意図しないノード追加(=異常)なのか

必要な監視は設定されているか

•  対応がわかっているアラーム

•  未知のアラーム

プロセスの自動化
開発メンバーは運用チームの仕事を
知っている必要がある

運用メンバーは開発チームの仕事を
知っている必要がある


監視とメータリング

利用者によって、見たい情報が違う

レポートする内容が違う

Dev
アプリケーションの
異常

性能・レスポンス

ユーザの振るまい

ログ

Ops
機器の状態

サービスの状態

性能・レスポンス

キャパシティ

障害・故障の履歴

Biz
サービスに対する
ユーザの反応

インシデントと
ビジネスインパクト

キャパシティ
コスト


運用監視ツールのポイント

—  監視機能
◦  柔軟性と拡張性
—  自動化と省力化
◦  自動構成
–  ディスカバリー機能
◦  定型化
–  モデルやテンプレート
◦  コマンドの活用
–  自動アクション
–  作業属人化の排除
–  作業品質を均一化
—  見える化
◦  状況の共有
◦  メータリング
◦  柔軟なレポート
—  履歴が残る
◦  履歴の追跡や監査
—  拡張性
◦  API

Zabbixが備える有用な機能

—  拡張性のある監視機能
—  Zabbix Agent
◦  エージェント自動登録
◦  ログ監視
◦  Windowsサポート
–  perf_counter、イベントログ、サービス
—  ディスカバリー
—  複合条件でのトリガー
—  アクション機能
◦  ホストに対するスクリプト実行
◦  リモートコマンド実行
–  トリガー条件でのコマンド実行
—  レポート
—  API


Zabbixの困ったところ
監視設定の点

—  SNMPでの監視設定はものすごく融通が利かない
Ø  ダイナミックインデックスが使えるようになりました(1.5以降)
—  ダイナミックインデックスのパフォーマンスが悪い
Ø  キャッシュされるようになりました(1.6.3以降)
Ø  SNMPリクエスト
シングルコネクションになりました(1.7以降)
—  構成が微妙に違うとテンプレートを分けないと吸収できない
Ø  ローレベルディスカバリが使えるようになりました(2.0から)
Ø  ようやく一人前になったかも

Zabbix
動的な監視対象の追加

対象ノードの
自動検出

オート
ディスカバリ
エージェント
自動登録

自動登録
アクション

テンプレート
の適用

ホストOS

サービス
監視

アイテム
ディスカバリ
アクション

ローレベル
ディスカバリ

ローレベル
ディスカバリ

グラフ
トリガー
アイテム
グラフ
トリガー

Zabbix
動的な監視項目の追加

—  アイテムの自動検出
◦  ローレベルディスカバリ(Zabbix2.0から)
テンプレート

ディスカバリ
ルール

アイテムの
プロトタイプ

トリガーの
プロトタイプ

グラフの
プロトタイプ

ディスカバリルール
•  タイプ
Zabbix エージェント

vfs.fs.discovery ファイルシステム

net.if.discovery ネットワーク
カスタムLLDルール
JSON形式でリストを返します
•  タイプ SNMP agent ＝ SNMP OIDディスカバリ


SNMP OIDディスカバリ
ディスカバリルール

mysqldプロセスが起動していればディスカバリーしたいとき


SNMP OIDディスカバリ
アイテムのプロトタイプ

hwSWRun*ではPidが変わるとインデックスが変わるので
{#SNMPINDEX}ではなくダイナミックインデックス

Zabbix
エージェントの
アイテム

SNMP
エージェントの
アイテム

スクリプト実行による
カスタム監視

—  Zabbix Agent 経由 (UserParameter)

—  外部チェック
—  返せる値は一つだけ
—  複数の値があるならzabbix_senderで
◦  アイテムのタイプ
Zabbixトラッパー
—  ポーリングのスケジュールリングは
Zabbixに任せる

Zabbix Agent 経由

—  UserParameter
◦  リクエストのたびにコマンドが起動されます
—  例: Collectdで収集した値を取り出す
UserParameter=collectd[*],echo "GETVAL $1" | nc -U /var/
run/collectd/unixsock | egrep '^(value|$2)=' | awk
'{printf "%fn", $$1}'

—  zabbix_get で確認
$ zabbix_get -s localhost -k 'collectd[localhost/
entropy/entropy]'
3589.000000
$ zabbix_get -s localhost -k 'collectd[localhost/
load/load,shortterm]'
0.000000


外部チェック
Nagios plugin プログラムの活用

#!/bin/sh
ZABBIX_SENDER=/usr/bin/zabbix_sender
ZABBIX_SERVER=localhost
PLUGIN=check_xxx
CHECK_PLUGIN=/path/to/$PLUGIN
ARGS="-H $1 …"
output=$($CHECK_PLUGIN $ARGS" 2>/dev/null)
status=$?
for perf in ${output##*|}; do
key=${perf%%'='*}
val=${perf##$key'=’}
val=${val%%';'*}
val=${val%%[A-Za-z]*}
echo "$1” $PLUGIN."$key" $val
done | $ZABBIX_SENDER -z $ZABBIX_SERVER -i - >/dev/null 2>&1
#echo "$status”
echo $output

スクリプト監視の注意点
—  タイムアウト
◦  Option:Timeout Range: 1-30
◦  越えても強制終了はされませんが

—  キューの状態
◦  実行に時間がかかると、チェック全体で更新待ちが増える
ことになります
—  トラッパーの数
◦  送信元
–  エージェントのアクティブチェック
–  zabbix_sender
◦  ソケットの数をみて調整
–  トラッパーポート10051
—  値を返すとき
◦  指数形式の数値が扱えません
—  スクリプト起動のオーバーヘッド


Web監視
—  Zabbix Agent 経由
—  web.page.get ウェブページの内容の取得
◦  web.page.perf ウェブページ全体のロードにかかる時間の取得
◦  web.page.regexp ウェブページで最初に正規表現に一致した文字列の取得
◦  単一リクエスト・1機能
—  ウェブ監視
◦  固定シナリオ
–  ステップごとの、スピード、レスポンスタイム
◦  テンプレート化できない

動的シナリオのWeb監視
外部チェックスクリプトで実現

—  WebInject (Web/HTTP Test Tool)
◦  http://webinject.org/
◦  Webサービスを自動的にテストするためのツー
ルです
webinject.pl -c config.xml
<testcasefile>testcases.xml</testcasefile>
<globalhttplog>onfail</globalhttplog>
<reporttype>nagios</reporttype>
config.xml

正常時
WebInject OK - All tests passed successfully in 0.195 seconds |
time=0.195;;;0

エラーの時
WebInject CRITICAL - Test case number 3 failed |time=2.937;;;0

WebInject シナリオ

<testcases repeat="1">
<case
id="1”
method="get”
url="{BASEURL}”
verifypositive="Zabbix 2.0.8 Copyright 2001-2013 by Zabbix SIA"
/>
<case
id="2”
method="post”
url="{BASEURL}/index.php”
postbody='request=&name=admin&password=zabbix&autologin=1&enter=S
ign+in’
verifyresponsecode='302’
parseresponse='Location: |n'
/>
<case
id="3”
method="get”
url="{BASEURL}/{PARSEDRESULT}”
parseresponse='<a class=”[^”]*" href=”|">概要</a>'
/>
<case
id="4”
method="get”
url="{BASEURL}/{PARSEDRESULT}”
/>
</testcases>

WebInject
ラッパースクリプト

#!/bin/sh
WEBINJECT=/apth/to/webinject.pl
cd /path/of/scenario
output=$($WEBINJECT -c "$1.xml" 2>/dev/null)
status=$?
for perf in ${output##*|}; do
key=${perf%%'='*}
val=${perf##$key'='}
val=${val%%';'*}
echo "$1" webinject."$key" $val
done | $ZABBIX_SENDER -z $ZABBIX_SERVER -i - >/dev/null 2>&1
case "$status" in
0) echo ${output%%' in '*};;
[123]) echo ${output%%'|'*};;
esac


状況によって動作を変える必要
がある場合

—  LL と
Mechanize ライブラリをつかっ
てスクリプトを作成します

◦  PerlのWWW::Mechanize
◦  RubyのMechanize
◦  Pythonのmechanize

カスタム通知
メディアとしてスクリプトを使う

—  TTYtterを使った通知の例
#!/usr/bin/python
import sys
user = sys.argv[1]
subj = sys.argv[2].decode('utf-8')
body = sys.argv[3].decode('utf-8')
msg = '/dm @%s %s %s' % (user, subj, body)
msg = msg[0:140]
cmd = ['/usr/local/bin/ttytter', '-script'];
p = Popen(cmd, stdout=PIPE, stdin=PIPE, stderr=STDOUT)
p.stdin.write("%sn" % msg.encode('utf-8'))
p.stdin.close()


ディスカバリの通知を活用

Discovery rule: {DISCOVERY.RULE.NAME}
Device IP: {DISCOVERY.DEVICE.IPADDRESS}
Device DNS: {DISCOVERY.DEVICE.DNS}
Device status: {DISCOVERY.DEVICE.STATUS}
Device uptime: {DISCOVERY.DEVICE.UPTIME}
Device service name: {DISCOVERY.SERVICE.NAME}
Device service port: {DISCOVERY.SERVICE.PORT}
Device service status: {DISCOVERY.SERVICE.STATUS}
Device service uptime: {DISCOVERY.SERVICE.UPTIME}

通知メッセージの定義

ディスカバリの通知を活用
Pythonでのパターンマッチ例

pattern =
r'''(Discovery rule: (?P<rule_name>.*))
(Device IP: (?P<device_ip>.*))
(Device DNS: (?P<device_dns>.*))
(Device status: (?P<device_status>.*))
(Device uptime: (?P<device_uptime>.*))
(Device service name: (?P<service_name>.*))
(Device service port: (?P<service_port>.*))
(Device service status: (?P<service_status>.*))
(Device service uptime: (?P<service_uptime>.*))'''
result = re.match(pattern, body)
if result:
print result.groupdict()

AWS
—  HyClops for Zabbix
(第1回
OSS運用管理勉強会)
◦  http://tech-sketch.github.io/hyclops/jp/
—  Mikoomi Amzon EC2 Plugin
◦  http://code.google.com/p/mikoomi/wiki/04
—  Cloudwatch monitoring for Zabbix
◦  https://github.com/lorieri/zabbix/tree/master/
templates/cloudwatch


SLAとビジネスインパクト

—  ITサービス

SLA

—  レポート
◦  稼働レポート
◦  障害発生数上位100項目


メータリング

思ってたんとちがう
—  システムがどこで問題を引き起こすことになるかを
知ることはできない。

—  問題は驚くべき箇所で起こる。

—  なにか変だと感じたときは、かならず問題を抱えている。

—  発生する可能性がある問題は、いつかかならず発生する。

—  悪魔は細部に宿る

—  木を見て森も見る

—  計測すべし

—  見える化


Zabbixの困ったところ
グラフ

—  測定した値を関数で処理してプロットしたい
Ø  すでにデータベースに入っている値しかプロットできません
—  トレンドとかが出せるとうれしいけど
◦  最小二乗法やHolt-Wintersによる傾向

◦  σバンド

Ø  必要な関数が実装されていないのでむりです
Ø  ほかのツールを使いましょう
—  それでも移動平均くらいなら

◦  avg(3600)
◦  avg(3600,86400)
—  タイムシフトによる過去一週間の平均
◦  (avg(60,86400)+avg(60,172800)+avg(60,259200)+…+avg(60,604800))/7

Zabbixでできること
カスタムグラフの作成

—  過去の傾向
◦  タイムシフトを利用した計算
–  last(86400)
–  avg(300,86400)
—  Percentile
◦  Zabbix 2.0 からサポート
◦  ノーマルグラフのみ

—  アグリゲート
◦  ホストグループを対象に計算
◦  grpavg Average value
◦  grpmax Maximum value
◦  grpmin Minimum value
◦  grpsum Sum of values


タイムシフトによる過去一週間の平均

RRDtoolから
Zabbixのデータを参照

itemid を調べてデータベースから直接とりだす
DEF:v=sql//mysql/host=localhost/dbname=zabbix/
username=user/password=rdonly//history/clock/
value/itemid=23397:avg:LAST

RRDtool は
libdbi を有効にしてビルドされているものを使います


サンプル
上がZabbix、下がRRDtool


運用の現場はたのしい

運用の現場では、
—  幅広い知識がつき、
—  いろんな経験ができます

使ってたのしいツールを、使いましょう
カスタマイズで、もっとたのしく
—  機能が足りなければ作ることも
見えるとたのしい
楽になるとたのしい
作り込んだ物がうごくと、
もっとたのしい

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


第2回 OSS運用管理勉強会運用あるある(Zabbix)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to 第2回 OSS運用管理勉強会運用あるある(Zabbix)

Similar to 第2回 OSS運用管理勉強会運用あるある(Zabbix) (20)

More from 真治米田

More from 真治米田 (8)