Zabbix - マクロ境界の拡張

クライアント向けのソリューションを作成するときに、通常の Zabbix 機能を使用して美しく解決したい 2 つのタスクが発生しました。

タスク1。 Mikrotik ルーターの現在のファームウェア バージョンを追跡します。

このタスクは、HTTP テンプレートにエージェントを追加することで簡単に解決できます。 エージェントは Mikrotik Web サイトから現在のバージョンを受信し、トリガーは現在のバージョンと現在のバージョンを比較し、不一致がある場合にアラートを発行します。

ルーターが 10 台ある場合、そのようなアルゴリズムは重要ではありませんが、ルーターが 3000 台の場合はどうすればよいでしょうか? 3000 件のリクエストをサーバーに送信しますか? もちろん、そのようなスキームは機能しますが、3000件のリクエストというアイデア自体が私には合わなかったので、別の解決策を見つけたかったのです。 さらに、このようなアルゴリズムには依然として欠点がありました。相手側は、XNUMX つの IP からの DoS 攻撃のリクエストの数をカウントでき、単にそれを禁止することができます。

タスク2。 異なる HTTP エージェントでの認可セッションの使用。

エージェントが HTTP 経由で「閉じられた」ページから情報を受信する必要がある場合、認証 Cookie が必要です。 これを行うには、通常、「ログイン/パスワード」のペアと Cookie にセッション ID を設定する標準の認証フォームが必要です。

ただし、問題があります。XNUMX つの HTTP エージェント項目から別の項目のデータにアクセスして、ヘッダー内のこの値を置き換えることは不可能です。

「Web スクリプト」もありますが、これには別の制限があり、分析や保存のためのコンテンツを取得することはできません。 ページ上に必要な変数が存在するかどうかを確認するか、Web スクリプトのステップ間で以前に取得した変数を渡すことのみが可能です。

これらのタスクについて少し考えた後、テンプレート、ホスト、トリガー、アイテムなど、監視システムのどの部分でも完全に表示されるマクロを使用することにしました。 また、Web インターフェイス API を通じてマクロを更新できます。

Zabbix には、優れた詳細な API ドキュメントがあります。 APIによるデータのやり取りにはJsonデータ形式が使用されます。 詳細は次のとおりです。 公式ドキュメント.

必要なデータを取得してマクロに記録する一連のアクションを次の図に示します。

ステップ1

最初のステップは、単一のアクションまたは複数のアクションで構成されます。 すべての主要なロジックは最初のステップに組み込まれており、最後の 3 つのステップが主要なステップです。

私の例では、最初のステップは、最初のタスクのために PBX 上で認証 Cookie を取得することでした。 XNUMX 番目のタスクでは、Mikrotik ファームウェアの現在のバージョンの番号を取得しました。

Mikrotik ファームウェアの現在のバージョンの URL

• upgrade.mikrotik.com/routeros/LATEST.6 - 現在の安定版の URL アドレス
• upgrade.mikrotik.com/routeros/LATEST.6fix — 現在の LTS バージョンの URL アドレス

これらのアドレスは、利用可能な最新のファームウェア バージョンを受信したときに、Mikrotik 機器自体によってアクセスされます。

最初のステップはケースごとに完全に個別であり、その作業のロジックは異なる場合があります。 それはすべてあなたのタスク次第です。

Web スクリプトを使用する場合は、必要な応答メソッドを記録してください。 見出し HTTP 応答または自己 тело ヘッダーのない応答ですか?
認可Cookieが必要な場合は、応答方法を設定します。 見出し アスタリスクの場合のように。

mikrotik サーバーの応答の場合のように、データが必要な場合は、次のように入力します。 ボディ ヘッダーのない応答。

ステップ2

XNUMX番目のステップに進みましょう。 認可セッションを取得します。

POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1
Content-Type: application/json-rpc

{
    "jsonrpc": "2.0",
    "method": "user.login",
    "params": {
        "user": "Admin"
        "password": "zabbix"
    },
    "id": 1,
    "auth": null
}

jsonrpc は、使用されている JSON-RPC プロトコルのバージョンです。
Zabbix は JSON-RPC バージョン 2.0 を実装します。

• Method - 呼び出されるメソッド。
• params - メソッドによって渡されるパラメータ。
• id は任意のリクエスト識別子です。
• auth - ユーザー認証キー。 まだ持っていないので、null に設定しましょう。

API を使用するために、権限が制限された別のアカウントを作成しました。 まず、必要のない場所にアクセスを許可する必要はありません。 次に、バージョン 5.0 より前では、マクロによって設定されたパスワードが読み取られる可能性がありました。 したがって、Zabbix 管理者パスワードを使用すると、管理者アカウントが簡単に盗まれます。

これは、サードパーティのスクリプトを介して API を操作し、資格情報を側で保存する場合に特に当てはまります。

バージョン 5.0 以降、マクロに保存されたパスワードを非表示にするオプションがあります。

API経由でデータ更新用のアカウントを別途作成する場合は、必要なデータがWebインターフェース経由で利用可能か、更新可能か必ずご確認ください。 確認しなかったので、必要なマクロがなぜ API に表示されないのか、長い間理解できませんでした。

API で承認を受け取った後、マクロのリストを取得します。

ステップ3

API ではホスト マクロを名前で更新することはできません。最初にマクロ ID を取得する必要があります。 さらに、特定のホストのマクロのリストを取得するには、このホストの ID を知る必要があり、これは追加の要求です。 デフォルトのマクロを使用する {ホストID} リクエストでは許可されません。 次のように制限を回避することにしました。

このホストの ID を使用してローカル マクロを作成しました。 ホスト ID を見つけるのは、Web インターフェイスから非常に簡単です。

特定のホスト上のすべてのマクロのリストを含む応答は、パターンによってフィルターできます。

regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}"

したがって、必要なマクロの ID を取得します。 MIKROTIK_VERSION は、探しているマクロの名前です。 私の場合、マクロが検索されます MIKROTIK_VERSIONホストに割り当てられたもの。

リクエスト自体は次のようになります。

POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1
Content-Type: application/json-rpc

{
    "jsonrpc":"2.0",
    "method":"usermacro.get",
    "params":{
        "output":"extend",
        "hostids":"{$HOST_ID}"
    },
    "auth":"{sid}",
    "id":1
}

可変 {シド} これは XNUMX 番目のステップで取得され、API インターフェースを操作する必要がある場合に常に使用されます。

最後の 4 ステップ - マクロの更新

これで、更新する必要があるマクロ ID、認証 Cookie、またはルーターのファームウェアのバージョンがわかりました。 マクロ自体を更新できます。

POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1
Content-Type: application/json-rpc

{
    "jsonrpc":"2.0",
    "method":"usermacro.update",
    "params":{
        "hostmacroid":"{hostmacroid}",
        "value":"{mikrotik_version}"
    },
    "auth":"{sid}",
    "id":1
}

{mikrotik_version} 最初のステップで取得された値です。 私の例では、現在の mikrotik ファームウェアのバージョン
{ホストマクロ} - 値は XNUMX 番目のステップで取得したものです。 - 更新しているマクロの ID。

所見

標準機能を使用して問題を解決するアプローチは、はるかに複雑で時間がかかります。 特にプログラミングの知識があり、必要なロジックをスクリプトにすぐに追加できる場合は特にそうです。

このアプローチの明らかな利点は、異なるサーバー間でのソリューションの「移植性」です。

私個人としては、HTTP エージェントが別の項目のデータにアクセスできず、それらをリクエスト本文やヘッダーに置き換えることができないのは奇妙です [ ZBXNEXT-5993].

完成したテンプレートは、 GitHub でダウンロードする.

出所： habr.com