Skip to main content
An agent with this tool answers a monitoring ticket from your Zabbix data: which host it is about, whether Zabbix can still reach it, which problems are open on it, and what its values looked like when the problem started.
Automatically enabled when you configure Zabbix permissions in your agent workflow. No manual toggle needed.

​
What It Does

  • Find the host by visible or technical name, IP address or DNS name, or among a client’s host groups or tags
  • Read the host’s availability per interface, its open problems with their severity and acknowledgements, and the trigger behind each problem
  • Tell a host that is down from a stopped Zabbix agent or an offline proxy
  • Read any item’s latest value, history and hourly trend, such as CPU, memory, disk and ping
  • Acknowledge, comment on, close, suppress or change the severity of a problem, with the ticket number in the message
  • Put a host or host group in maintenance for planned work
  • Run a script you defined in Zabbix on a host, such as a ping or a service restart
  • Change hosts, host groups, templates, items, triggers, macros, users and other Zabbix settings, with the access and approvals you choose
The agent calls Zabbix through the Vendor API tool, with zabbix as the vendor id. Sandbox scripts can call Zabbix too, under the same permissions.

​
Permission Groups

Every group can be Disabled, Read Only or Read/Write. Neo never sends these methods: user.login, user.logout and user.checkAuthentication (Neo uses the API token), token.create and token.generate (a new token works only once its secret is generated, and Neo never reads a secret), history.clear (it destroys data), and configuration.export, configuration.import and configuration.importcompare (an export can carry passwords, and an import makes many changes at once). Neo removes the fields Zabbix keeps credentials in (passwords, SNMP communities and passphrases, pre-shared keys, credential headers, HTTP request bodies, and the user name and password in a URL) from every answer; text typed elsewhere, such as a script’s command or a text macro, reaches the agent as written.

​
Access Profiles

Every group Read Only. The agent reads, and never changes anything.
Problems and Events is Read/Write without approval. Maintenance and Scripts are Read/Write with technician approval. Everything else is Read Only.
Every group Read/Write. Scripts, Actions and Media Types, Users and Access, and Administration require technician approval, and so does deleting a host.
Every group Read/Write without approval, except the changes below, which still require technician approval.

​
Changes that always ask a technician

These require technician approval under every access profile, whatever the group’s own approval setting:
  • Changing authentication settings (HTTP, LDAP and SAML sign-in, the default sign-in method, the password policy).
  • Creating, changing, testing or deleting an LDAP or SAML user directory.
  • Creating, changing or deleting an MFA method.
  • Creating, changing or deleting a user role or a user group.
  • Creating, deleting or provisioning a user from LDAP, or changing a user’s role, user groups or user directory. Disabling a user means moving them to a disabled user group, so it asks too.
  • Resetting a user’s MFA.
  • Changing or deleting an API token.
  • Deleting a host, which removes its collected history.
  • Any change that stores a credential: a password, a secret macro, a credential header or parameter, the user name and password in a URL, or an HTTP agent’s request body.