Zabbix 的自動監控項目監控Nginx各虛拟主機配置 - Low Level Discovery

Zabbix示範版本：2.4.4

涉及到的腳本語言：PHP

low-level discovery的意思是“低層次的自動發現”，檢查lld。 lld并不是因為功能簡單或者不重要而被稱為“低層次的”，而是因為相對于伺服器的自動發現，low-level discovery是針對伺服器上裝置的自動發現。

Zabbix 原生支援針對三種（檔案系統、網卡、SNMP OIDs）自動發現來配套自動添加Items、Triggers 和 Graphs等。在lld中它們被稱為Item原型、Trigger原型 和 Graph原型。

因為low-level discovery是基于Template或者Host的。一個low-level discovery由以下兩部分組成。

1. 探測部件（檔案系統或者網卡）的Item，比如 net.if.discovery。
2. 基于Item建立的Triggers 和 Graphs。

low-level discovery 的 Item比較特殊，普通的Item傳回的可能是數字、字元串等的監控資料，lld的Item傳回的是一個JSON對象，其中包含了探測到的部件清單。以net.if.discovery為例，它會傳回一些鍵值對，比如"{#IFNAME}" - "lo"，和 "{#IFNAME}" - "eth0"。

lld會發現很多不同的部件，比如多塊網卡，這些變量（網卡名稱，eth0，eth1等）會綁定在宏上。定義Triggers或者Items的時候使用這些宏來代替變量名就行了。針對偵測到的網卡的監控就可以是 net.if.out[{#IFNAME}]。

單擊模闆後面的“Discovery”連結進入Template OS Linux 的 lld界面，接下來可以看到我們想看到的lld。

在顯示的界面中個，每一行裡除了lld的名字外，顯示了Item原型、Trigger原型、Graph原型 和 Host原型，因為作為例子的lld沒有Host原型，是以筆者會在例子後面單獨介紹它。“Key”就是執行lld的Item key（也就是那個需要傳回JSON資料的key）。

其中

1. Type：和配置Item時的Type的含義一緻。
2. Key：和配置Item時的key含義一緻。
3. Update interval (in sec)：表示更新該lld發現規則的間隔時間。
4. Flexible intervals：彈性的間隔時間。
5. Keep lost resources period (in days)：lld偵測到的新部件在各種原型保留多少天。 比如設定為10，那麼在偵測到一塊磁盤後的原型會連續監控10天，如果在10天内這塊硬碟還被偵測到了，那麼這個時間會順延。設定這個參數的目的是當伺服器上的部件發生變化時，能夠将不用的部件禁用。注意，這裡設定為0，并不是永遠不停止，而是立刻删除。 
6. Filter頁籤：lld的Item會傳回JSON對象，其中通常隻有一部分是我們需要的。比如，vfs.fs.discovery傳回的JSON是這樣的：

{"data":[{"{#FSNAME}":"/","{#FSTYPE}":"rootfs"},{"{#FSNAME}":"/proc","{#FSTYPE}":"proc"},{"{#FSNAME}":"/boot","{#FSTYPE}":"ext4"},{"{#FSNAME}":"/data","{#FSTYPE}":"xfs"},{"{#FSNAME}":"/proc/sys/fs/binfmt_misc","{#FSTYPE}":"binfmt_misc"},{"{#FSNAME}":"/nfs","{#FSTYPE}":"nfs"}]}      

    而你隻想要監控nfs的，那麼就需要對{#FSTYPE}進行過濾，簡單來說，需要{#FSTYPE}符合一些條件。這裡所說的條件是在“Administration → General”的Regular Expressions中配置的，它對{#FSTYPE}進行了過濾。

1  ^(btrfs|ext2|ext3|ext4|jfs|reiser|xfs|ffs|ufs|jfs|jfs2|vxfs|hfs|ntfs|fat32|zfs)$[Result is TRUE]      

下面來建立 Item原型：

Item原型的配置和普通的Item是差不多的，唯一不同的就是key中使用了特殊的宏來替代lld發現的部件的變量。 比如圖中的{#FSNAME}就是磁盤路徑。 Trigger原型 和 Graph原型都是類似的情況。

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

實際操作：結合Nginx的兩個第三方子產品實作Nginx單獨虛拟主機的并發監控

第三方子產品1：ngx_req_status GitHub 

第三方子產品2：ngx_realtime_request_module GitHub 

這兩個子產品功能差不多，但還是有那一點小差別。

大緻上分為以下幾個步驟：

• 編譯Nginx 添加支援查詢虛拟主機狀态資料的第三方子產品。
• zabbix agent端添加自定義key
  • 編寫自定義key的資料采集腳本
  • 并且該腳本支援單獨主機的資料抽樣采集
• zabbix 編寫lld模闆配置
• 關聯實體監控主機并測試

首先需要在編譯Nginx的時候添加第三方子產品。（省略）

web通路測試。

realtime_request

req_status

我這裡使用的php寫的兩個簡單的腳本。源碼如下（這裡隻講req_status子產品）

// ngx_req_status 子產品
<?php
/**
 * Created by PhpStorm.
 * User: Eric
 * Date: 2016/09/20
 * Time: 21:20
 */
/** 此子產品适用于 ngx_req_status 統計子產品 */
// bugfix

$URL = 'http://localhost/req_status?l';
$CONTENT = explode("\n", file_get_contents($URL));

function handle_req_status_to_hostArray($subject, $argv) {
    function sub_explode($value) {
        return explode("\t", $value);
    }

    function sub_filter($value) {
        if (is_array($value) && count($value) > 1) {
            return $value;
        }
    }

    function sub_combine($value) {
        $item_name = array('zone', '{#KEY}', 'max_active', 'max_bandwidth', 'traffic', 'request', 'current_active', 'current_bandwidth');
        return array_combine($item_name, $value);
    }

    if (count($argv) == 2) {
        $split = explode(" ", $argv[2]);
        $argv[1] = $split[0];
        $argv[2] = $split[1];
    }

    if (is_array($subject)) {
        $result = array_map('sub_explode', $subject);
        $result = array_filter($result, 'sub_filter');
        $result = array_map('sub_combine', $result);
        array_shift($result);

        if (count($argv) > 1) {
            while ($item = each($result)) {
                if ($item['value']['{#KEY}'] == $argv[1]) {
                    return $item['value'][$argv[2]];
                }
            }
        }
        //return $result;
        return array('data' => $result);
    } else {
        return $subject;
    }
}

if (!isset($argv)) {
    $argv = false;
}
// web浏覽不報錯

$test = handle_req_status_to_hostArray($CONTENT, $argv);
if (count($argv) > 1) {
    echo $test;
} else {
    echo json_encode($test);
}
?>      

req_status子產品的nginx配置如下

http {
    req_status_zone    server_name    "$server_name:$server_port"    256k; // key值是基于server_name和server_port的組合值
    req_status    server_name;
    .....
    
    server {
        .....
        location = /req_status {
            req_status_show  on;
        }
    }
}      

這個就是ngx_req_status傳回的資料格式，然後利用php處理該資料傳回位JSON對象。

而且該腳本也能根據提供兩個參數取出特定的值。如圖

最後做好測試工作（通過zabbix_get方式擷取例如該key的值）。

回到正題，配置 Zabbix 模闆

根據如圖配置新生成一個新的空模闆。

點選模闆的 Discovery rules → Create discovery rules 建立一個新的 lld 發現規則。

如圖，配置好lld發現規則。

這裡的 key 就是需要在zabbix_agentd中配置的自定義key，對應的是那個php腳本。

由于我沒有需要過濾的資料，是以Filter頁面就留白。

點選上面的 Item prototypes 進入到Item原配置界面。

按照如圖，配置好6個根據{#KEY}疊代的key值。（注意區分大小寫，特殊的{#KEY}宏是需要特定的格式，而且全大寫字母）

比如 req_status current Request 這個監控項

然後建立圖形源模闆

比如 Nginx_req_status - {#KEY} - Current Data 這個圖形源的配置

這些都配置好過後，那麼接下來就可以關聯那台nginx主機了。

關聯該模闆過後，大約在lld發現規則周期之内就會根據定義查詢指定主機的 ngx_req_status key值傳回的JSON資料了。

如果配置都正常，那麼就會陸續自動添加很多監控項，然後生成圖形。

注意事項：

1. lld discovery自動發現的key的傳回值必須是指定格式的JSON對象資料。 比如格式為

{"data":[{"{#HOST}":"  "request":"1024", "active":"512"}, {"{#HOST}":"static.bdimg.com", "request":"4051", "active":"2415"}]}      

其中還有一點是需要注意的，稍不注意就容易掉坑裡。作為lld發現key的特殊宏的格式是特定的，上例中的格式中隻有{#HOST}這個特殊宏才能作為lld發現key，而且key的字母必須為全大寫。

B. lld的發現key的間隔時間與該發現規則的 Item原型的間隔時間是不相幹的，前者可以設定的間隔時間稍大，後者就相當于一個普通的Item項，根據你業務的需求設定監控粒度。

C. UserParameter=ngx_req_status[*],php /tmp/req_status.php $1 $2 這樣可以讓php腳本接收兩個指令行參數，但是在zabbix web端配置的時候，有個坑，， 如圖