いくつかのスクリプトを使用して、そのうちの1つをサーバーに配置し、2つ目のスクリプトをクライアントに分散させることで、nginx、mongod、rabbitmq、mysql、postgresqlおよびその他のサービスの低レベルの自動検出を行うことができます。
もちろん、この実装の私のバージョンには欠点がないわけではなく、ほとんどの場合、教祖は私にトマトを投げかけるでしょう！ 建設的な批判と助言に非常に感謝します。
アクションのコース、機能の説明、および動作原理
「テンプレートサービス自動検出」自動/検出テンプレートをホストに追加します。テンプレート内または既にホスト上にあり、検出および監視する必要があるマクロ「{$ SERVICES}」にサービスのリスト（スペースで区切る）を追加します。
マクロコンボ画像 
必要なサービスがインストールされて実行されている場合（「nginx」など）、データ要素「SERVICE_AUTO_DISCOVERY：detected_and_run_nginx」がホストに表示されます
SERVICE_AUTO_DISCOVERYをトリガーします：trigger_detected_and_run_nginx、
30秒後にトリガーがトリガーされ、トリガーされたトリガーでアクションがトリガーされます。
アクション説明画像 
アクションは、zabbixサーバー上の「auto-discovery.py」スクリプト（スクリプトでログイン「zabbixapi_API_user」とパスワード「password」を自分のものに変更することを忘れないでください）によって実行されます。
アクションがトリガーされたときの操作を説明する画像 
スクリプトは、zabbix APIを介して、対応するトリガーを無効にし、このサービスに必要なテンプレートをマウントします。
トリガーされたトリガー 
クライアントから直接APIにアクセスすることは可能ですが、その場合はクライアント上にこのスクリプトを保持する必要があります。 あまり安全ではないので APIからのパスワードはホスト上に保持する必要があります。 スクリプトで。 ところで、NATの背後にzabbixサーバーがあります。
動作していないソフトウェア（多くのアラート、パニック、通話など）を監視しても意味がないため、実行中のソフトウェアを検出することにしました。
要約すると：
任意のテンプレートを使用して、任意のサービスを監視できます。 これを行うには、テンプレートの名前を変更してビューの名前を付けます。
「テンプレート_ <マクロからのサービス名>」。
つまり、mongoデータベースを監視するには、mongodをマクロ{$ SERVICES}に追加し、mongaを監視するためのテンプレートの名前をTemplate_mongodに変更する必要があります。
PS
テンプレートの名前の下線に注意してください。スクリプトを使用すると、適切なテンプレートが検索されます。 テンプレートの名前とトリガーの名前は、「_」の後に「絶対に」同じでなければなりません。そうしないと、テンプレートがスローされないか、トリガーが機能しません。
サンプルテンプレート 
スクリプトとテンプレート自体は、autodiscoveryフォルダーのgithubにあります。
高度なホストスクリプト機能
ホスト上のスクリプトも「systemctl」サービスを検出するようにトレーニングされました。 当社の開発者はしばしばサービスを作成しますが、サービスはオフ/オンで監視する必要があります。 サービスが有効な場合、これらのサービスの自動検出が発生します。
このマクロは{$ SERVICE}と呼ばれ、サービスの名前で「.service」を省略したり、スペースでリストしたりできます。
ここにはテンプレートは追加されませんが、サービスの監視に必要なデータ要素とトリガーが作成されることに注意してください。
このマクロは{$ SERVICE}と呼ばれ、サービスの名前で「.service」を省略したり、スペースでリストしたりできます。
ここにはテンプレートは追加されませんが、サービスの監視に必要なデータ要素とトリガーが作成されることに注意してください。
デバッグについて少し：
ホストで、自動検出スクリプトがどのように機能するかを確認します。
つまり、サービスが見つからない場合、スクリプトは空のJSONを返します。
ほとんどの場合、スクリプトはzabbix APIに接続できません。 何が起こるか確認してください：
zabbixサーバー側からスクリプトを実行し、2つのパラメーターを渡しますか？ 最初はホスト名で、2番目はトリガーの名前です。 「webmord」zabbixaからホスト名とトリガーの名前を取得し、ホスト内のトリガーの名前からトリガーの名前を取得します。
サービスが検出されない場合、つまり トリガーは作成されません：
ホストで、自動検出スクリプトがどのように機能するかを確認します。
/etc/zabbix/scripts/run_service.sh mongo {"data":[{"{#SERVICE}":"mongo"}]}root@bla_bla_bla:/tmp# _______________________________________________________________________ /etc/zabbix/scripts/run_service.sh mongo nginx supervisor {"data":[{"{#SERVICE}":"mongo"},{"{#SERVICE}":"nginx"},{"{#SERVICE}":"supervisor"}]}root@bla_bla_bla:/tmp# _______________________________________________________________________ /etc/zabbix/scripts/run_service.sh mongodb {"data":[]}root@bla_bla_bla:/tmp#
つまり、サービスが見つからない場合、スクリプトは空のJSONを返します。
サービスは検出されたが、トリガーが無効になっていない場合：
ほとんどの場合、スクリプトはzabbix APIに接続できません。 何が起こるか確認してください：
zabbixサーバー側からスクリプトを実行し、2つのパラメーターを渡しますか？ 最初はホスト名で、2番目はトリガーの名前です。 「webmord」zabbixaからホスト名とトリガーの名前を取得し、ホスト内のトリガーの名前からトリガーの名前を取得します。
/usr/bin/python3 /lib/zabbix/externalscripts/api/auto-discovery.py {HOST.NAME} {TRIGGER.NAME}
鶏肉か卵？
次のステップは、Ansibleとの統合を完了することです。
しかし、ここで疑問が生じます：最初のzabbixまたはansibleはどうあるべきですか？
zabbixの場合、監視システムでの誤ったアクションは、不要なソフトウェアの不要なインストールにつながります。
最初のものが可能であれば、zabbixはすべてを検出して監視し、playbookの展開中にzabbix-agentに必要なスクリプトと設定をスローするため、zabbixとの統合は不要です。
3番目のオプションは、ホストで自動検出（標準サービスがマクロにリストされている）を含むテンプレートをスローすると、zabbizはスクリプトとzabbix-agentの構成を展開するためのプレイブックを同時に起動します。 ただし、サービスが標準の場合は、ホスト上で、少なくともこれらの標準サービスを展開するときには、監視用の役割を展開する必要があります。
しかし、ここで疑問が生じます：最初のzabbixまたはansibleはどうあるべきですか？
zabbixの場合、監視システムでの誤ったアクションは、不要なソフトウェアの不要なインストールにつながります。
最初のものが可能であれば、zabbixはすべてを検出して監視し、playbookの展開中にzabbix-agentに必要なスクリプトと設定をスローするため、zabbixとの統合は不要です。
3番目のオプションは、ホストで自動検出（標準サービスがマクロにリストされている）を含むテンプレートをスローすると、zabbizはスクリプトとzabbix-agentの構成を展開するためのプレイブックを同時に起動します。 ただし、サービスが標準の場合は、ホスト上で、少なくともこれらの標準サービスを展開するときには、監視用の役割を展開する必要があります。