Skip to main content

​
Before you start

  • Neo needs Zabbix 6.4 or later, the first release that accepts an API token in the Authorization header.
  • Neo reaches your Zabbix frontend over the internet. It must answer on HTTPS with a certificate from a public certificate authority, at a public address. If a firewall or reverse proxy limits who can reach it, allow Neo’s addresses to reach api_jsonrpc.php.

​
1. Prepare a Zabbix user and token

1

Create a user for Neo

In Zabbix, open Users → Users and create a user for Neo. Its role decides which API methods Neo may call: on the role, keep Access to API on. Its user groups decide which host groups Neo can read or change, so give the groups read access to the clients’ host groups, or read-write where you want agents to make changes.A User role reads hosts and problems and acknowledges problems. Maintenance and configuration changes need an Admin role, and users, roles and global settings need Super admin.
2

Create the API token

Open Users → API tokens, click Create API token, choose Neo’s user, and set an expiry date if your policy needs one. Copy the token: Zabbix shows it once.
If the token expires, or you disable the token or its user, Neo loses access until you save a new token here.

​
2. Add the token in Neo

1

Open Integrations

In the Neo Dashboard, open Integrations → Zabbix, under Networking.
2

Save the address and token

Enter the address you open Zabbix at, including a path such as /zabbix if it has one (for example https://monitor.example.com/zabbix), and the API token, then click Save settings. Neo reads your Zabbix version and checks the token before saving, so a wrong address, an older Zabbix or a refused token is rejected straight away.

​
3. Turn Zabbix on per agent

Open the agent, go to the Integrations section, and configure the Zabbix block. Agents see only what Neo’s Zabbix user can see.

​
Pick an access profile

Read Only

Read hosts, problems, latest data, history and configuration. Nothing is changed.

Helpdesk

Acknowledge, comment on and close problems without approval. Maintenance and running a script wait on a technician. Everything else is read only.

IT Admin

Problems, hosts, maintenance, items, triggers and templates change without approval, except deleting a host. Scripts, actions and media types, users and access, and administration wait on a technician.

Full Automation

Every change runs without approval, except the changes that always ask a technician.

​
Or set each area by hand

Each area can be Disabled, Read Only or Read/Write, and has its own technician approval setting.

​
Changes that always ask a technician

These wait on a technician under every profile, whatever the area’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.

​
Troubleshooting