[ZBXNEXT-8541] Support of history.push API method Created: 2023 Jul 04  Updated: 2025 Jan 13  Resolved: 2023 Sep 18

Status: Closed
Project: ZABBIX FEATURE REQUESTS
Component/s: API (A)
Affects Version/s: None
Fix Version/s: 7.0.0alpha4, 7.0 (plan)

Type: Change Request Priority: Major
Reporter: Alexei Vladishev Assignee: Andrejs Griščenko
Resolution: Fixed Votes: 2
Labels: api, history, sender
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Attachments: PNG File image-2023-09-08-10-57-23-848.png    
Issue Links:
Duplicate
is duplicated by ZBXNEXT-7568 Inbound webhook Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
ZBXNEXT-8603 Server changes to support of history.... Specification change (Sub-task) Closed Dmitrijs Goloscapovs  
Epic Link: Zabbix 7.0
Team: Team A
Sprint: Sprint 102 (Jul 2023), Sprint 103 (Aug 2023), Sprint 104 (Sep 2023)
Story Points: 5

 Description   

Zabbix should support ability to receive data sent over HTTP protocol. It will make possible sending data from CLI, simpler integration with 3rd party web hooks and also new widgets with manual data input in the future.

Now the only practical way of pushing data to Zabbix is to use Zabbix Sender utility.



 Comments   
Comment by Andrejs Griščenko [ 2023 Aug 09 ]

Resolved in development branch feature/ZBXNEXT-8541-6.5.

Comment by Andrejs Griščenko [ 2023 Aug 24 ]

Implemented in:

Comment by Arturs Dancis [ 2023 Sep 05 ]

Documentation (7.0) updated:

Comment by dimir [ 2024 Jan 31 ]

Current page that describes history.push method does not say a word about the error field in response. In my understanding:

Zabbix server will only perform validation and set the error in response if validation fails. Validation includes:

Validation Error
User has read permission to item's host. No permissions to referred object or it does not exist.
Get item from configuration cache. No permissions to referred object or it does not exist.
Item status is Enabled. Item is disabled.
Item type is one of trapper or http agent. Unsupported item type.
If item type is http agent trapping is enabled. HTTP agent item trapping is not enabled.
Host status is Monitored. Host is not monitored.
Host status is not In maintenance without data collection. Host is in maintenance without data collection.
If item's Allowed hosts is set the client IP is allowed. Client IP is not in item's allowed hosts list.
There is no item that has values with duplicate timestamps on nanosecond level. Duplicate timestamp found.

No error field in response only means the above mentioned validations succeeded. It might be so that an item will get an error during preprocessing or fail at attempt to save the value to the database later, resulting in an item becoming NOTSUPPORTED. In other words, there is no guarantee that if the response contains no error field, the value is in the database. Instead, it means the value was accepted for processing.

Also, the fact that it is enough to have a "read" permission on a host in order to push values to its items not obvious for everyone. Some would expect the user must have "write" permissions.

Is the above correct? I strongly believe this is valuable information to add to our documentation.

Comment by Arturs Dancis [ 2024 Mar 15 ]

Thank you for pointing this out! Documentation (7.0) updated:

  • Configuration > Items > Item types > Trapper items (added information about errors in response data)
  • Configuration > Items > Item types > HTTP agent (added link to the Trapper items page)
  • API > Method reference > History > history.push (added links to Trapper items and HTTP agent pages)
Generated at Fri Mar 21 04:34:36 EET 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.