Japanese |
オープンソース統合監視ツール Zabbix を使ってみよう（入門編）
第 2 回 Zabbix のさまざまな監視機能を試してみよう
1. はじめに
前回は、Zabbix のインストール、基本的な設定、監視対象と基本的な監視項目の設定方法までを行いました。
今回は、その他の監視機能の説明や、指定した条件による障害検知とアラートメールの送信、
グラフ表示機能などを紹介します。
2. Zabbix の監視機能について
Zabbix では多種多様な用途、目的に対応するために、さまざまな監視方法に対応しています。
以下は Zabbix が対応している各機能の概要です。
監視タイプ
監視項目の例
Zabbix エージェント
Zabbixエージェントによる監視 （サーバからエージェントに対してデータを要求）
CPU使用率、メモリ使用率、ディスク使用率、ファイル監視、Web 監視
Zabbix エージェント（アクティブ）
Zabbix エージェントによる監視（エージェントからサーバに定期的にデータを送信）
SNMP エージェント
SNMP エージェントによる監視
CPU 使用率、メモリ使用率、ディスク使用率、ディスクI/O、ネットワークI/O
SNMP トラップ
SNMP トラップによる監視
IPMI チェック
IPMI によるハードウェア監視
シンプルチェック
エージェントを使用しない監視
ICMP ping、TCP 疎通、TCP 応答時間
内部チェック
Zabbix サーバ自身の監視
稼働時間、アイテム数、プロセスの CPU 使用率
SSH チェック
SSH 経由による監視
Telnet チェック
Telnet 経由による監視
外部チェック
スクリプトやコマンドによる監視
トラッパーアイテム
外部からデータを受け取る
zabbix_sender コマンドによるデータ送信
JMX による Java アプリケーション監視
3. Zabbix エージェント監視の種類
ここでは、最も使用頻度が高いと思われる Zabbix エージェントの監視項目のうち、代表的なものを紹介します。
その他のキーや監視タイプについては、Zabbix マニュアルの以下の項目を参照してください。
Zabbix エージェントの代表的なキー一覧
CPU 使用率
system.cpu.util[&cpu&,&type&,&mode&]
system.cpu.load[&cpu&,&mode&]
使用率 (%)
system.cpu.util[,user,avg5]
system.cpu.load[,avg5]
メモリ使用率
vm.memory.size[&mode&]
バイト数 / %
vm.memory.size[free]
ディスク使用率
vfs.fs.size[fs,&mode&]
バイト数 / %
vfs.fs.size[/,pfree]
ネットワーク使用率
net.if.in[if,&mode&]
net.if.out[if,&mode&]
net.if.in[eth0,bytes]
net.if.out[eth0,bytes]
プロセス起動数
proc.num[&name&,&user&,&state&,&cmdline&]
プロセス数
proc.num[httpd,apache]
net.tcp.port[&ip&,port]
net.tcp.service[service,&ip&,&port&]
0(down) / 1(up)
net.tcp.port[,80]
net.tcp.service[http]
ファイルのチェックサム
vfs.file.cksum[file]
チェックサム
vfs.file.cksum[/etc/passwd]
Zabbix エージェント（アクティブ）の代表的なキー一覧
log[file,&regexp&,&encoding&,&maxlines&,&mode&]
logrt[file_format,&regexp&,&encoding&,&maxlines&,&mode&]
log[/var/log/messages,,,100]
logrt["/var/log/messages-[0-9]{8}$",,,100]
4. ログ監視について
ログの監視を行うには、Zabbix　エージェント（アクティブ）を使用する必要があります。
通常の Zabbix エージェントは、サーバから定期的にデータを要求しに行きますが、
Zabbix エージェント（アクティブ）は、エージェント自身が能動的に監視を行い、
データをサーバに送信します。
log[file,&regexp&,&encoding&,&maxlines&,&mode&] は、
1 つのログファイルのみを監視します。
logrt[file_format,&regexp&,&encoding&,&maxlines&,&mode&] は、
ローテートされた複数のログファイルを監視します。
ファイル名の候補は正規表現で指定します。
例えば、「/var/log/messages-[0-9]{8}$」であれば「/var/log/messages-」などのファイルが対象になります。
また、ログ監視では Zabbix エージェントを動作させるユーザ（zabbix）が
ログファイルにアクセスする権限が必要になりますので注意してください。
5. メディアタイプとメディアの設定
障害を検知した場合にメールを送信するには、事前にメディアタイプとメディアを設定しておく必要があります。
まずメディアタイプでメールの送信に使用するメールサーバを設定します。
管理 (Administration) →
メディアタイプ (Media types) を選択します。
一覧から「Email」をクリックします。
「SMTPサーバー」(「SMTP server」)、「SMTP helo」、「送信元メールアドレス」(「SMTP email」) を
環境にあわせて適切に編集し、保存 (Save) をクリックします。
次に、各ユーザのメール送信先を設定します。ここでは Admin、user について設定します。
右上の [プロファイル]([Profile]) をクリックして、[メディア]([Media]) を選択します。
[追加]([Add]) をクリックすると「新規メディア」(「New media」)ウィンドウが表示されますので、
以下の項目を入力し、追加 (Add) をクリックします。
タイプEmail
送信先（障害を通知するメールアドレス）
有効な時間帯1-7,00:00-24:00
指定した深刻度のときに使用軽度の障害、重度の障害、致命的な障害にチェックを入れる
ステータス有効
保存 (Save) をクリックします。
以上で、Zabbix が障害を検知した場合に指定したアドレスにメールが送信されるようになりました。
6. トリガーの設定
Zabbix では、障害と復旧の検知の設定をトリガーと呼びます。
前回は CPU 使用率を監視するアイテムを作成しました。
今回は、それに対して、5 分間の CPU 使用率の平均値が一定の閾値を上回った場合は障害と判定し、
アラートメールを送信するように設定してみましょう。まずトリガーを作成します。
設定 (Configuration) →
テンプレート (Templates) を選択します。
テンプレート一覧の「テストテンプレート」の
トリガー (0) (「Triggers (0)」)をクリックします。
右上の トリガーの作成 (Create trigger) をクリックします。
以下の項目を入力し、保存 (Save) をクリックします。
名前CPU usage is too high
条件式{Test template:system.cpu.util[,,].avg(300)}&90
説明最近 5 分間の CPU 使用率の平均が 90 % を超えています
深刻度軽度の障害
条件式は直接入力することもできますし、右の 追加 (Add) ボタンをクリックして
「アクションの実行条件」ウィンドウを開き、各項目を以下のように入力して
挿入 (Insert) ボタンをクリックすることでも入力できます。
アイテムTest template:CPU usage
機能期間 T の値の平均値 & N
最新の (T)300 秒
トリガーの作成に成功すると、以下のようにトリガー一覧に表示されます
（トリガー作成直後の場合は、まだ値を取得できていないためエラーが表示されることがあります）。
アクションの設定
Zabbixでは、障害発生時や復旧時の動作の設定をアクションと呼びます。
先程設定したトリガーで障害を検知した場合に、指定したユーザにメールを送信するアクションを作成します。
設定 (Configuration) →
アクション (Actions) を選択します。
右上の アクションの作成 (Create action) をクリックします。
「アクション」(「Action」)タブで以下の項目を入力します。
名前Report problems to user
デフォルトのアクション実行ステップの期間3600
デフォルトの件名?デフォルトのメッセージ（初期状態で入力済みのものを使用）
リカバリメッセージチェックしない
有効チェックする
「アクションの実行条件」(「Conditions」) タブで以下の項目を入力します（初期状態で入力済みです）。
計算のタイプAND / OR
アクションの実行条件
(A) メンテナンスの状態 期間外 "メンテナンス"
(B) トリガーの値 = "障害"
「アクションの実行内容」(「Operations」)タブで 「 新規 」 をクリックし、
以下の内容を入力して 追加 (Add) をクリックします。
ステップ開始: 1 終了: 1 ステップの期間: 0
実行内容のタイプメッセージの送信
ユーザーに送信Admin, user
次のメディアのみ使用Email
デフォルトのメッセージyes
すべての入力が完了したら、保存 (Save) をクリックします。
アクション一覧に作成したアクションが表示されます。
障害検知の確認
それでは、実際に疑似的に障害を発生させ、それが検知されるかを確認してみましょう。
Zabbix エージェントが動作している監視対象のホストにログインし、
以下のコマンドを実行して 5 分以上待ち、Ctrl-C で停止します。
※ CPU 使用率が 100 % になるため、実際にサービスが稼働しているホストでは
実行しないでください。
$ yes & /dev/null
(Ctrl-Cで停止)
障害が検知されると、管理画面のダッシュボードの「システムステータス」、
「ホストステータス」、「最新 20 件の障害」にそれが表示されます。
また、ユーザのメディアで設定したメールアドレスに、以下のような障害通知メールが届きます。
From: &zabbix@zabbix-server.localdomain&
Subject: PROBLEM: CPU usage is too high
Date: Fri, 12 Apr :53 +0900
Trigger: CPU usage is too high
Trigger status: PROBLEM
Trigger severity: Average
Trigger URL:
Item values:
1. CPU usage (zabbix-agent:system.cpu.util[,,]): 99.1168
2. *UNKNOWN* (*UNKNOWN*:*UNKNOWN*): *UNKNOWN*
3. *UNKNOWN* (*UNKNOWN*:*UNKNOWN*): *UNKNOWN*
監視データ (Monitoring) →
イベント (Events) を選択すると、
過去に発生した障害もしくは復旧の履歴を参照することができます。
グラフの作成
Zabbix では、特に設定を行わなくても各アイテムの履歴をグラフで表示することができますが、
複数の監視項目のデータを 1 つのグラフにまとめて表示することもできます。
これにより、一目でシステムの状態を把握することができます。
グラフは以下の手順で作成します。
なお、事前に、名前「CPU load」、タイプ「Zabbixエージェント」、キー「system.cpu.load[,]」、
データ型「数値（浮動小数）」、更新間隔（秒）「30」というアイテムを作成し、
テンプレートに追加しておきます。
設定 (Configuration) →
テンプレート (Templates) を選択します。
テンプレート一覧の「テストテンプレート」の
グラフ (0) (「Graphs (0)」) を
クリックします。
右上の グラフの作成 (Create graph) をクリックします。
以下の項目を入力します。
名前CPU load/usage
グラフのタイプノーマル
凡例を表示チェックする
ワーキングタイムの表示チェックする
トリガーを表示チェックする
Y軸の最小値計算
Y軸の最大値計算
アイテムの「追加 (Add)」をクリックし、対象のアイテムにチェックを入れて
[選択]([Select]) をクリックします。
追加された項目について以下のように設定します。
アイテム: 1： テストテンプレート： CPU load
平均線右C80000
アイテム: 2： テストテンプレート： CPU usage
平均線左00C800
保存 (Save) をクリックします。
作成したグラフを表示するには、監視データ (Monitoring) →
グラフ (Graphs) を選択し、
右上の「グループ」(「Group」)、「ホスト」(「Host」)、「グラフ」(「Graph」)から対象のグラフを選択してください。
右軸（赤）がロードアベレージ値（1 分間）、左軸（緑）が CPU 使用率になります。
また、上部のスライダーを調整して、表示開始時刻と期間を指定することができます。
スクリーンの作成
Zabbix のスクリーンは、複数のグラフやイベント履歴、システムの情報といった
さまざまな情報を一つの画面に自由に並べて表示する機能です。
実際にスクリーンを作成してみましょう。
[設定]([Configuration]) → [スクリーン]([Screens]) を選択します。
右上の [スクリーンの作成]([Create screen]) をクリックします。
以下の項目を入力し、保存 (Save) をクリックします。
名前My screen
スクリーン一覧から「My screen」をクリックします。
変更したい箇所の [変更]([Change]) をクリックします。
また、[+][-] をクリックすると、行数、列数を変更することができます。
「リソース」(「Resource」)で参照したい情報を選択します。
情報の種類に応じて、表示する行数や幅、高さなどを調整します。
ここでは、以下の 3 つのリソースを指定します。
システムステータス
イベント履歴（表示する行数: 25）
グラフ（グラフ名: zabbix-agent: CPU load/usage、幅: 500、高さ: 200）
保存 (Save) をクリックします。
作成したスクリーンを表示するには、[監視データ]([Monitoring]) → [スクリーン]([Screens])を選択し、
右上の「スクリーン」(「Screens」)プルダウンメニューから「My screen」を選択してください。
11. まとめ
今回は、Zabbix のさまざまな監視機能の紹介や、障害の検知と通知の設定方法、
グラフとスクリーンの作成方法について解説しました。
次回は、Zabbix の管理画面上で行う各種操作を自動化できる、Zabbix API について紹介します。
この技術情報は
お役に立ちましたか？
SRA OSS からのお願い
SRA OSS は、日本の IT 業界の発展のため、すべてのエンジニアを応援するべく、積極的に技術情報を公開しています。
もしこの技術情報が、あなたの業務のお役に立ったのであれば、ぜひ左の Facebook の「いいね！」や「シェア」をお願いいたします。
公開した技術情報に対する あなたからのフィードバック が、何よりの励みになります。
よろしくお願いいたします。12802人阅读
##################################
zabbix基本架构
##################################
zabbix系统核心进程，轮询并捕获数据、发送通知等。是zabbix agent和zabbix proxy汇报数据的对象。server自身可远程检测网络服务。所有的前后端配置、统计信息、可操作数据存储于此。包含server、前段界面和后端DB几部分。
部署在被监控主机上用于监控本地资源和应用并向zabbix server汇报结果。使用本地系统调用故非常高效。有主动和被动两种检测模式。被动模式下agent根据server或proxy的具体请求来返回数据。主动模式下先主动由server获取监控项列表在检测并返回新的数据。采用主动或被动检测取决于相应监控项的配置。
可以自由选择部署或者不部署，主要用于分担server的负载。在集中化监控远程位置、分支、网络的场景中是很好的解决方案。可从被监控设备收集数据缓存在proxy本地后传递给其所属的zabbix server。proxy需要单独的数据库。
4.Java gateway
java实现的守护进程用于监控JMX类型的应用程序。
命令行工具zabbix_sender，用于向zabbix server发送性能数据和可用性数据。多用于用户脚本定期向server发送数据。
shell& cd bin
shell& ./zabbix_sender -z zabbix -s &Linux DB3& -k db.connections -o 43
命令行工具zabbix_get，用于同agent通信从agent获取数据。可用于zabbix agents的troubleshooting。
shell& cd bin
shell& ./zabbix_get -s 127.0.0.1 -p 10050 -k &system.cpu.load[all,avg1]&
####################################
#zabbix术语表
####################################
需要被监控的设备，如交换机、路由器、WEB服务器、DB服务器等
host group
被监控设备的逻辑分组，如DB服务器一组、WEB服务器一组等。可包含主机和模板。用于权限控制
需要被监控的项，如CPU空闲率、某一块磁盘的使用率等
用于评估收到的监控值是否超出设定的阈值的逻辑表达式
如trigger状态改变等值得注意的事件
预先定义的响应event的一系列operations
escalation
执行action中的operations的定制场景；一连串的发送通知、执行远程命令
传递notification的方式
notification
通过media发送给用户的关于某个event的消息
remote command
在被监控机器上触发并自动执行的预定义命令
用于简化和加速主机上大规模监控任务的部署。包含一系列项目，如items, triggers, graphs, screens, applications, low-level discovery rules
application
逻辑组中的一组items
web scenario
一个或多个HTTP request用以检查web站点可用性
zabbix的web界面
zabbix api
允许通过JSON RPC 协议创建、更新和获取zabbix对象如，hosts, items, graphs and others。或者执行其他任务
zabbix server
zabbix核心，履行监控，与zabbix proxies、zabbix client交互、计算trigger、发送notification、存储数据等任务
zabbix agent
部署在被监控主机上用于监控本地资源和应用
zabbix proxy
可代zabbix server收集数据分担处理负载
######################################
#zabbix配置
######################################
可通过WEB界面或者模板进行配置
需配置内容包括users、user groups、hosts、host groups、items、Triggers、Events、notification、templates、visualisation等。
最终配置会被存储在后端database中。
/documentation/2.4/manual/config
#####################################
zabbix取数方式
####################################
1.zabbix api
基于WEB的API，通过JSON PRC协议获取或更改zabbix配置，并可用于获取历史监控数据。clients和API间的request和response使用JSON格式。包含一系列可从功能上分为不同组别的方法。
发起HTTP请求的格式类似如下：
POST /zabbix/api_jsonrpc.php HTTP/1.1
Content-Type: application/json-rpc
{&jsonrpc&:&2.0&,&method&:&apiinfo.version&,&id&:1,&auth&:null,&params&:{}}
其中/zabbix/是zabbix前端的地址；Content-Type必须指明且为application/json-rpc, application/json or application/jsonrequest三者之一。{&jsonrpc&:&2.0&,&method&:&apiinfo.version&,&id&:1,&auth&:null,&params&:{}}是请求的具体内容。
一些实例：
& & &jsonrpc&: &2.0&,
& & &method&: &user.login&,
& & &params&: {
& & & & &user&: &Admin&,
& & & & &password&: &zabbix&
& & &id&: 1,
& & &auth&: null
jsonrpc:指明JSON-RPC协议版本，这里是2.0版本
method:指明调用的API方法，这里是用户登录
params:需要传递给API method的参数，这里是用户名和密码
id:本次请求的标识符
auth:用户认证令牌，目前尚无所以为null
若参数无误response将会包含用户认证令牌，如：
& & &jsonrpc&: &2.0&,
& & &result&: &d&,
& & &id&: 1
*获取hosts信息
& & &jsonrpc&: &2.0&,
& & &method&: &host.get&,
& & &params&: {
& & & & &output&: [
& & & & & & &hostid&,
& & & & & & &host&
& & & & ],
& & & & &selectInterfaces&: [
& & & & & & &interfaceid&,
& & & & & & &ip&
& & &id&: 2,
& & &auth&: &d&
本例使用可用的用户认证令牌通过host.get方法获取所配置的主机的ID 、name等信息，返回如下
& & &jsonrpc&: &2.0&,
& & &result&: [
& & & & & & &hostid&: &10084&,
& & & & & & &host&: &Zabbix server&,
& & & & & & &interfaces&: [
& & & & & & & & {
& & & & & & & & & & &interfaceid&: &1&,
& & & & & & & & & & &ip&: &127.0.0.1&
& & & & & & & & }
& & & & & & ]
& & &id&: 2
为了考虑性能影响、尽量仅列出所需项而非返回所有数据
*创建新监控项
例如在上一步获取的host上建立新的监控项、监控/home/joe/目录的剩余空间
& & &jsonrpc&: &2.0&,
& & &method&: &item.create&,
& & &params&: {
& & & & &name&: &Free disk space on $1&,
& & & & &key_&: &vfs.fs.size[/home/joe/,free]&,
& & & & &hostid&: &10084&,
& & & & &type&: 0,
& & & & &value_type&: 3,
& & & & &interfaceid&: &1&,
& & & & &delay&: 30
& & &auth&: &d&,
& & &id&: 3
其中params参数中的几个关键参数含义如下：
name：监控项的名称，这个可以自己灵活定义，其中的$1代表key_中的第一个参数，此处为/home/joe/
key_:预定义的监控项，zabbix提供了一系列此类监控内容，此处需从其中进行选择。
hostid：即上步获得的hostid
value_type:监控数据值的类型，不同的数字代表不同的类型，此处的3代表整型
delay：zabbix取数时间间隔，此处为30秒取一次
返回结果如下：
& & &jsonrpc&: &2.0&,
& & &result&: {
& & & & &itemids&: [
& & & & & & &24759&
& & &id&: 3
itemid为生成的监控项的id
*获取历史数据：
从历史记录表获取itemids为23296的按clock降序排列的十条记录
history参数可能的取值
4 - text.&
& & &jsonrpc&: &2.0&,
& & &method&: &history.get&,
& & &params&: {
& & & & &output&: &extend&,
& & & & &history&: 0,
& & & & &itemids&: &23296&,
& & & & &sortfield&: &clock&,
& & & & &sortorder&: &DESC&,
& & & & &limit&: 10
& & &auth&: &038e1d7b6ee9eae095879e&,
& & &id&: 1
返回结果：
& & &jsonrpc&: &2.0&,
& & &result&: [
& & & & & & &itemid&: &23296&,
& & & & & & &clock&: &&,
& & & & & & &value&: &0.0850&,
& & & & & & &ns&: &&
& & & & },
& & & & & & &itemid&: &23296&,
& & & & & & &clock&: &&,
& & & & & & &value&: &0.1600&,
& & & & & & &ns&: &&
& & & & },
& & & & ...]
下例忘记了groups这个参数
& & &jsonrpc&: &2.0&,
& & &method&: &host.create&,
& & &params&: {
& & & & &host&: &Linux server&,
& & & & &interfaces&: [
& & & & & & {
& & & & & & & & &type&: 1,
& & & & & & & & &main&: 1,
& & & & & & & & &useip&: 1,
& & & & & & & & &ip&: &192.168.3.1&,
& & & & & & & & &dns&: &&,
& & & & & & & & &port&: &10050&
& & & & & & }
& & &id&: 3,
& & &auth&: &d&
返回结果如下，包含的不是result属性而是error属性
& & &jsonrpc&: &2.0&,
& & &error&: {
& & & & &code&: -32602,
& & & & &message&: &Invalid params.&,
& & & & &data&: &No groups for host \&Linux server\&.&
& & &id&: 3
对于获取监控数据来说，比较关心的应该是history.get这个方法。这种方式实际上最终还是由后台数据库获取的。方法提供了丰富的参数，使用非常灵活。但对于一次性大规模的取出大量主机大量监控项的大批数据不太适合。
/documentation/2.4/manual/api
2.zabbix_get:
命令行工具，可从远程的zabbix agent获取数据
zabbix_get [-hV] [-s &host name or IP&] [-p &port number&] [-I &IP address&] [-k &item key&] &
-s, --host &host name or IP&
-p, --port &port number&
-I, --source-address &IP address&
-k, --key &item key&
-h, --help
-V, --version.
如：zabbix_get -s 127.0.0.1 -p 10050 -k system.cpu.load[all,avg1] &
zabbix api获取到的是数据库中的历史数据，zabbix_get可获得实时的数据。可根据工具的特点选择适合的场景。
/documentation/2.4/manpages/zabbix_get
3.zabbix databases:
直接由zabbix后台数据库获取历史数据。适用于一次性大规模的取出大量主机大量监控项的大批数据。
history系列表分别存储不同数据类型的历史数据
表中数据以update interval为时间间隔
zabbix.history & &-numeric(float) &
zabbix.history_log -log
zabbix.history_str -character(up to 255 bytes)
zabbix.history_text -text
zabbix.history_unit -numeric(unsigned intergers)
trends_系列表存储不同类型的历史数据统计结果
表中数据以小时为时间间隔，存储每小时的最小、最大和平均值
zabbix.trends &-numeric(float)
zabbix.trends_unit -numeric(unsigned intergers)
character\log\text\类型无历史统计结果
history系列的表只包含itemid、clock、value等数据
trends系列的表只包含itemid、clock、value_min、value_avg、value_max等数据
history、trends需与items、hosts、hosts_groups、groups表关联来获取item名称、host名称、组别等。
*表及重要的表字段
hosts.hostid &主机id
hosts.host & &主机名
hosts.status &主机状态 0为正常监控，1为关闭，3表示是个Template，5尚不不清楚。
hosts_group
hosts_group.hostid &主机id
hosts_group.groupid 所属组id
groups.groupid &组id
groups.name & & 组名
items.itemid & &监控项id
items.hostid & &监控项所在主机id
items.name & & &监控项别名
items.key_ & & &监控项标准名称
items.value_type值类型
items.delay & & 取数时间间隔
items.history & 历史表数据保留天数
items.trends & &历史统计表数据保留天数
item.units & & &数据单位
items表中value_type与history的对应关系
(主要为了存取效率将不同值类型存在不同的history表中)
value_type &history表
0 & & & & & history
1 & & & & & history_str
2 & & & & & history_log
3 & & & & & history_uint
4 & & & & & history_text
hisrtory.itemid 监控项id
trends.itemid 监控项id
zabbix后台系统的涉及到大量的表，取历史数据的话关心这几个即可
*监控项规则解读
zabbix.items表中存在类似于如下的配置项(如网络网卡监控、磁盘监控等)：
name & & & & & & & & & & & & & &key_
Free disk space on $1 & & & & & & & & & &vfs.fs.size[/,free]
Free disk space on / (percentage) & & vfs.fs.size[/,pfree]
Free disk space on $1 & & & & & & & & & &vfs.fs.size[/boot,free]
Free disk space on /boot (percentage) & &vfs.fs.size[/boot,pfree]
Free disk space on $1 & & & & & & & & & &vfs.fs.size[/data,free]
Free disk space on /data (percentage) & &vfs.fs.size[/data,pfree]
Free disk space on $1 & & & & & & & & & &vfs.fs.size[{#FSNAME},free]
Free disk space on {#FSNAME} (percentage) vfs.fs.size[{#FSNAME},pfree]
其中类似于如下的配置是zabbix提供的low level discovery配置方式，用于自动创建监控项适用于有多块磁盘、多个目录、多块网卡等类型情形下监控项的自动发现
可以把{#FSNAME}看做是模板可以匹配配置好的所有的相关项比如：
Free disk space on {#FSNAME} (percentage) &vfs.fs.size[{#FSNAME},pfree]
Free disk space on /data (percentage) & & & & & & & & & vfs.fs.size[/data,pfree]
Free disk space on /boot (percentage) & & & & & & & & & vfs.fs.size[/boot,pfree]
Free disk space on / (percentage) & & & & & & & & & vfs.fs.size[/,pfree]
类似的还有：
Incoming network traffic on $1 net.if.in[{#IFNAME}]
Outgoing network traffic on $1 &net.if.out[{#IFNAME}]
IO.util.{#DISK_NAME} IO.util[{#DISK_NAME}]
而上边例子中的$1、$2等对应key_的参数位置，例如
Free disk space on $1 vfs.fs.size[/,free]
中$1就代表/ ,Free disk space on $1相当于Free disk space on /依次类推
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1308885次
积分：7568
积分：7568
排名：第1814名
原创：76篇
转载：30篇
译文：31篇
评论：127条
(1)(1)(1)(1)(3)(4)(3)(17)(2)(1)(2)(2)(11)(1)(2)(4)(4)(9)(11)(4)(9)(11)(5)(3)(6)(12)(6)}