Officially, we do not support this distribution of MySQL and cannot consider it as a bug report. I'm moving this to the ZBXNEXT project.

Just to provide more context, we have 2 ZBX infrastructures in AWS (PROD & DEV) that are composed by:

ZBX FE: Running in ECS (Prod & Dev)

ZBX Server: Running in EC2 (Prod & Dev - c4.xlarge RH  7.9)

ZBX DB: Running in Aurora MySQL:

• Prod: 5.7.mysql_aurora.2.11.5 - Size: 3.5TB
• Dev: 8.0.mysql_aurora.3.06.0 - Size: 6 TB

probably depends on ZBXNEXT-1390

It was 2017. No OAuth support.

It was 2018. Private aerospace companies launches heavy reusable rockets with electrovehicles to Mars orbit. And... Still no OAuth support.

https://gist.github.com/sergeyignatov/0228aa61e808bd830e63076e273e9fc9

Guys,

Any plans to support oauth in general and google auth in particular? I used the link above to implement a workaround. It's really a workaround since there is no auto sign up of authenticated users. Also it took literally days to understand and implement it properly. Something that I did in Grafana in a matter of minutes.
Zabbix starts to look "dated"  

+1

Related issue ZBX-21187

looking for an update about oauth authentication, it´s been 7 years since this request was created and seems no plans to implement this feature...

Deprecation of Basic authentication in Exchange Online is comming!

October 1, 2022

(tick tock, tick tock)  Since this appears to be less of a feature request and more of a "misery loves company" thread, I'd be interested to know if anyone else has devised a workaround for this, or did you just say to heck with it and deploy your own postfix server?

Between zabbix and oauth provider you can install keycloak. This solution some users already described. Or use self created api-gateway for auth.

Media types are also depended on the oAuth support being added, as such I would like to bump this ticket and I have provided some additional info here: ZBX-21187

Implemented in development branch feature/ZBXNEXT-6983-5.5.

Resolved in development branch feature/ZBXNEXT-6987-5.5.

Great feature to 5.0 maybe?

Awesome to have yet very important for different zabbix deployments.

Really useful resource, mainly to quickly duplicate and make mass changes like hostnames , items ... 

We have tons of dashboards and Zabbix instances. This feature would be ideal to import them in various instances at once and maintain them in an automated way.

Agreed - We install new Zabbix instances quite often. Dashboards are one of the main entry points for Zabbix users and one of the things users interact with most.

It would be very neat to have our set of carefully crafted Dashboads available for import on other instances - including being able to use things like versioning for our dashboards.

Maybe in the future that paves the way for something like dashboard sharing (analog to template sharing)?

Is there any recent information available regarding the potential inclusion of this feature in Zabbix's next release?

We are aware of this issue and we'd like to implement it as soon as possible but currently the closest that might get this in is 7.2 . Please stay tuned.

Until then, one alternative to handle dashboards is (very high-level overview) creating an export script that would perform the following via Zabbix API:

• get dashboard
• get all IDs
• map them to names

and an import script that would:

• get all IDs (by using names)
• create dashboard

Working with dashboards via Zabbix API:

• Dashboards: https://www.zabbix.com/documentation/current/en/manual/api/reference/dashboard
• Dashboard widgets: https://www.zabbix.com/documentation/current/en/manual/api/reference/dashboard/widget_fields

My humble investigation :
http://osdir.com/ml/network.net-snmp.user/2003-05/msg00360.html
http://www.net-snmp.org/dev/agent/structsnmp__session.html#a6651007c1d156f67f99d54d84aac09b9

Zabbix (code checks_snmp.c:snmp_session) for IPv6 - UDP specified explicitly, for IPv4 - by default:

#ifdef HAVE_IPV6
	if (SUCCEED != get_address_family(item->interface.addr, &family, err, MAX_STRING_LEN))
		goto end;

	if (family == PF_INET)
		zbx_snprintf(addr, sizeof(addr), "%s:%d", item->interface.addr, (int)item->interface.port);
	else
	{
		if (item->interface.useip)
			zbx_snprintf(addr, sizeof(addr), "udp6:[%s]:%d", item->interface.addr, (int)item->interface.port);
		else
			zbx_snprintf(addr, sizeof(addr), "udp6:%s:%d", item->interface.addr, (int)item->interface.port);
	}
#else
	zbx_snprintf(addr, sizeof(addr), "%s:%d", item->interface.addr, (int)item->interface.port);
#endif	/* HAVE_IPV6 */
	session.peername = addr;

# man snmpcmd

...
AGENT SPECIFICATION
The string AGENT in the SYNOPSIS above specifies the remote SNMP entity with which to communicate. This specification takes the form:

[<transport-specifier>:]<transport-address>

At its simplest, the AGENT specification may consist of a hostname, or an IPv4 address in the standard "dotted quad" notation. In this case,
communication will be attempted using UDP/IPv4 to port 161 of the given host. Otherwise, the <transport-address> part of the specification is
parsed according to the following table:

<transport-specifier> <transport-address> format

udp hostname[:port] or IPv4-address[:port]

tcp hostname[:port] or IPv4-address[:port]

unix pathname

ipx [network]:node[/port]

aal5pvc or pvc [interface.][VPI.]VCI

udp6 or udpv6 or udpipv6 hostname[:port] or IPv6-address:port or
'['IPv6-address']'[:port]

tcp6 or tcpv6 or tcpipv6 hostname[:port] or IPv6-address:port or
'['IPv6-address']'[:port]

Note that <transport-specifier> strings are case-insensitive so that, for example, "tcp" and "TCP" are equivalent. Here are some examples, along
with their interpretation:

hostname:161 perform query using UDP/IPv4 datagrams to hostname on port 161. The ":161" is redundant here since that is the default
SNMP port in any case.

udp:hostname identical to the previous specification. The "udp:" is redundant here since UDP/IPv4 is the default transport.
...

Conclusion:
zabbix uses only UDP transport by default.

Thanks, Oleksiy,

Do you know when TCP transport will be released for Zabbix?

Did anything ever come of this?  I've got a platform that can only be talked to via TCP.  I can query it fine using snmpwalk tcp:ipaddress, but haven't found a way to get zabbix to talk to it, so I'm thinking I've run into this issue.

I've started to run into this. I'm starting to see SNMP error statuses (via Wireshark) of "tooBig (1)". When I went to look at how to get the queries sent over TCP instead of UDP, I came across this.

Something like this can introduce tcp support:

diff --git a/src/zabbix_server/poller/checks_snmp.c b/src/zabbix_server/poller/checks_snmp.c
index f80b592ef99..452214eb295 100644
--- a/src/zabbix_server/poller/checks_snmp.c
+++ b/src/zabbix_server/poller/checks_snmp.c
@@ -616,7 +616,7 @@ static zbx_snmp_sess_t      zbx_snmp_open_session(unsigned char snmp_version, const c
        session.timeout = config_timeout * 1000 * 1000; /* timeout of one attempt in microseconds */
                                                        /* (net-snmp default = 1 second) */
        if (SUCCEED == zbx_is_ip4(ip))
-               zbx_snprintf(addr, sizeof(addr), "%s:%hu", ip, port);
+               zbx_snprintf(addr, sizeof(addr), "tcp:%s:%hu", ip, port);
        else
                zbx_snprintf(addr, sizeof(addr), "udp6:[%s]:%hu", ip, port); 

Moved this to feature requests.

So you think this is a cool feature instead of a performance bug?

Well... I think it works "as designed". If we think, that the design can be better, that's a feature request... in my opinion.

Then is it a good design to return in the background lots of data which is not even displayed by the web interface in any way?

Not to get into discussion about good or bad design, but as most designs - it can be improved.

I'm not sure I'm right, maybe there where reasons I'm not aware of, why it was created as is. So I see it as a design that works, but can/should be improved.

A bug in my opinion is something that doesn't work as designed.

From such perspective we can treat any bug reports as feature requests because regardless of the problem Zabbix as such is working, isn't it? 

I can clearly imagine that no one ever thought about this particular problem for a second before it was designed and implemented. 

On one hand Zabbix is putting serious efforts to improve the performance on large scale. Take ZBXNEXT-4108 as example. Off the topic but even ZBXNEXT-4820 requesting for better sounds gets turned down because of the increase in the file size. Then how is this my request considered as a feature when useless data is returned by a page request causing considerable load on all components of Zabbix?

Were you actually able to reproduce it?

Hello Ingus, thanks for the valuable opinion, you might be right. But I'm not the person to make the decision, but I will forward this ticket, so that appropriate decision can be made. Maybe it will be moved back to ZBX.

Yes, I was able to reproduce the error, it's easy on a host with one trigger.

Thank you very much!

With one trigger it is not a big problem, I agree there, but when there are thousands of triggers in mixed order on multiple hosts then the slowdown is significant. 

Thanks to aleksejs.petrovs, who pointed out that api output should match that what you see in frontend, so moving this back to bugs and marking as confirmed.

Sorry for the confusion.

While I can understand the confusion, that problem.get is returning more problems, than displayed, in Problem list it was done on purpose.
Currently the steps are:

1. select number of problems, with any matching filters applied.
2. get triggerids, that matches them.
3. select triggers, with any matching filters applied (including 'monitored' => true)
4. remove from list the problems without related triggers
5. repeat from step 1, if not enough problems are selected
   (Note: data for any trigger is requested only once)

What is requested by this task, is to add "monitored" filter for event.get and problem.get.
'monitored' filter implies adding NOT EXISTS check, which will look for data in tables functions, items, hosts and triggers, to the SQL.
This is quiet heavy check. In current implementation it is done only for triggers request, and is checked only once for any trigger. Adding it in problem.get and event.get, will require to do this check for every problem or event, which is way more times, than it is currently done.

With this, I have strong grounds to doubt that this change will be beneficial to the performance of Problem list page.

Also I will insist, that this is Feature request and not a bug, because

1. currently the pages are displaying correct data
2. problem.get and event.get was made without 'monitored' on purpose as very heavy operations. (same as history.get)
   And implementing such option should be considered as feature request.

I am not closing the task, as proper performance comparison still can be done.

vmurzins EDIT: It can be considered as feature request to add API parameter, that will be used only by users. (Zabbix frontend has no need for such parameter).

Looks like moving to bugs was not successful, still a ZBXNEXT.

Hello colleagues. This is NOT just "Preaty to have" feature. This is real fail of design.

One of Zabbix development direction - service based monitoring. Am I correct? A lot of changes was made for this and we are using this structure for more than 300 service trees. 

Problem described here is one of the most critical issue:

You have service tree with more than 50 services, 300 hosts and 5000 triggers.

You need add one more host - you can't predict that triggers will not generate problems.

Problem generated by template trigger -> Service status changed.

You have no way to change service status back!

You can't change template because a lot of hosts use this template. You can not delete trigger or item because problem will not disapper. You can not delete host - problem will not desappear also plus this will be impossible to resolve this problem at all. Only via database request. 

Only one option - allow manual close from  template -> manual close -> fast disable trigger before item will data. Is this really "Target design"?

This problem exist in 7.0.0 unfortunatelly.

If you are using "service oriented" monitoring and accidentally deleted host (operator mistake for example) - nightmare for big and 24/7 environments.

only delete FROM events where eventid = '';

Same request here

https://support.zabbix.com/browse/ZBX-21994?jql=reporter%20%3D%20%22Egor%20T.%22

http://zabbix.org/wiki/Docs/howto/Nested_LLD

i have an other example: to monitor Dell Equallogic Disks i need 2Querys, for example:
snmpwalk -v2c -c public 192.168.1.1 .1.3.6.1.4.1.12740.2.1.1.1.9.1
iso.3.6.1.4.1.12740.2.1.1.1.9.1.563984362 = STRING: "foo"
so this number is need to get the disks:
snmpwalk -v2c -c public 192.168.1.1 .1.3.6.1.4.1.12740.3.1.1.1.8.1
iso.3.6.1.4.1.12740.3.1.1.1.8.1.563984362.1 = INTEGER: 1
iso.3.6.1.4.1.12740.3.1.1.1.8.1.563984362.2 = INTEGER: 1
iso.3.6.1.4.1.12740.3.1.1.1.8.1.563984362.3 = INTEGER: 1
iso.3.6.1.4.1.12740.3.1.1.1.8.1.563984362.4 = INTEGER: 1
iso.3.6.1.4.1.12740.3.1.1.1.8.1.563984362.5 = INTEGER: 1
iso.3.6.1.4.1.12740.3.1.1.1.8.1.563984362.6 = INTEGER: 1
iso.3.6.1.4.1.12740.3.1.1.1.8.1.563984362.7 = INTEGER: 1
iso.3.6.1.4.1.12740.3.1.1.1.8.1.563984362.8 = INTEGER: 1
iso.3.6.1.4.1.12740.3.1.1.1.8.1.563984362.9 = INTEGER: 1
iso.3.6.1.4.1.12740.3.1.1.1.8.1.563984362.10 = INTEGER: 1
iso.3.6.1.4.1.12740.3.1.1.1.8.1.563984362.11 = INTEGER: 1
iso.3.6.1.4.1.12740.3.1.1.1.8.1.563984362.12 = INTEGER: 2

actually i can only use SNMPINDEX and i get 563984362, but i need the last number too. so i must use .1.3.6.1.4.1.12740.3.1.1.1.8.1.{#SNMPINDEX}.1, a better will be .1.3.6.1.4.1.12740.3.1.1.1.8.1.{#SNMPINDEX1}.{#SNMPINDEX2} to get the second one, or other idea {#SNMPINDEX(2)} to get the last 2 numbers (563984362.1), or {#SNMPINDEX(#7)} to get a specific number (for #7 i will get 12740)

Should this be closed? It's supported now.

It is supported now? How? Can't find it in the documentation.

Stefan Krügers approach above (.1.3.6.1.4.1.12740.3.1.1.1.8.1.

.

) is the way to go in my opinion. It is the most intuitive solution from a users perspective....

We are touching two different topics here, one is the built-in "discovery" keys, and another is the support for custom LLD rules.

As Volker pointed out, custom nested LLD's are somehow already supported: http://zabbix.org/wiki/Docs/howto/Nested_LLD

well, technically, the method you are using is nice & it works, but it is still a hack and not officially supported, so it would still be more like "adding support for nested lld"

The complete structure of the discovered nested values is defined by the user on the template.
Asking the user to define that structure again on the JSON code is redundant and an open door to many problems; it's complicated and overloaded.

Think in folders and labels. They are two different approaches. Gmail uses labels, no hierarchy. Filesystems use directories, that's a hierarchy.

When you have already defined the hierarchy on the template side (for example, I'll use the "#DATABASE" macro for zabbix Applications, and "#TBL" for item names), there is no need to define the same hierarchy again on the JSON making side. Therefore the "labels" approach is the right approach.

Each line of the JSON code must represent a combination of labels.

But there is a problem with the current implementation of this feature.
For example, we'll suppose that I am Zabbix Server and I receive this JSON:

{
 "data":[
   { "{#INSTANCE}" : "MSSQL$TEST_INST", "{#DATABASE}" : "DBA" },
   { "{#INSTANCE}" : "MSSQL$TEST_INST", "{#DATABASE}" : "DBA2" },
   { "{#INSTANCE}" : "SQLServer", "{#DATABASE}" : "SQL_SERVER_MONITORING" },
   { "{#INSTANCE}" : "SQLServer", "{#DATABASE}" : "ORACLE_MONITORING" },
   { "{#INSTANCE}" : "SQLServer", "{#DATABASE}" : "DBA" },
 ]
}

• Ok, now I know that I have to create items for a prototype that is referring to "#DATABASE" macro/label only. I'll create 4 items, one for each "#DATABASE" value: "DBA", "DBA2", "SQL_SERVER_MONITORING" and "ORACLE_MONITORING"; and I'll rise an error, because the fifth value is repeated ("DBA"). OK, it is not possible, and the request is not normal, I mean, why should I want a list of all databases, when I know that I could have the same name in multiple instances (by coincidence)?, it's weird. So, ok, next prototype.

• It turns out that I've been asked to create items for another prototype, referring to both "#INSTANCE" and "#DATABASE". I will create 5 items:
  MSSQL$TEST_INST - DBA
  MSSQL$TEST_INST - DBA2
  SQLServer - SQL_SERVER_MONITORING
  SQLServer - ORACLE_MONITORING
  SQLServer - DBA
  And no error. OK. This request is normal.

• Great, now I'm being asked to create items for another prototype, this time referring to "#INSTANCE" only. It's normal! I want to refer to instances, completely normal request! However I, Zabbix, throw errors for lines 2, 4 and 5, because I'm blindly trying to create an item for each JSON line.

How I see the solution to this problem? Simple, we don't need errors here; the user knows what he's doing; just don't try to create an item that is already created, in the first place. I can admit that that first request was weird, I know it, but it could be useful in some scenarios, having a list of unique values across many "containers".
Now, the third request, it's 100% normal, and wanted, and useful.

The question is, what is the purpose of attempting to create something that was already created? There was already an item created for "SQLServer", then why is Zabbix trying to perform the same action again? It makes no sense.

i wouldn't say this is supported.
host prototypes sort of provide one extra level, but only if you want separate hosts.
the hack with the somewhat duplicate entries is mostly working, and it might even end up being the supported method, but until it does become one, this issue still tracking that

Hi, richlv, I know, right, that's why I'm opening this discussion about this feature, it's in an inconsistent state right now. It doesn't work well in one way or another. We need to define this, right now. What is the way to go, and how.

To me, it's pretty clear and easy. Just read my comment above, as I said there, labels is the way to go, and no hierarchy. Let the hierarchy in the user's mind, he knows what he's doing.

Otherwise you'll end up having to give support to things like this:

{
	"data": [
		{ "{#INS}": "MSSQL$TESTE_INST", "{#INL}": "TESTE_INST", "data": [
			{ "{#DBS}": "DBA" }, 
			{ "{#DBS}": "DBA2" }
	    ]},
	  	{ "{#INS}": "SQLServer", "{#INL}": "SQL Server", "data": [
			{ "{#DBS}": "SQL_SERVER_MONITORING" }, 
			{ "{#DBS}": "ORACLE_MONITORING" }, 
			{ "{#DBS}": "DBA" }
	   ]}
	]
}

Which is a pain in the butt, for both, the user and the developer.

Here's a usecase where the current hacks fall short.

A script discovers JMX ports on a box and creates JMX items for each found JVM. Now, on each JVM one might want to have another level of LLD, but that is not possible - the JMX discovery would have to stem from the discovered items.

The problem is that not all information can be gathered in one script and then sent to an LLD rule, different discovery methods/types have to be used.

Hi.

I'm trying to understand the following sentence from https://www.zabbix.org/wiki/Docs/howto/Nested_LLD:

"In a single go: You can implement the secondary rule with a trapper item of your choice, if possible connectivity-wise. Just invoke the trapping from your script"

For me, trapper items have to be created so you can use zabbix_sender to send values.

I don't see how to implement the second discovery rule with a trapper.

Thx

My interpretation:
The first method uses two LLD rules that separately gather information about the two levels (using the example from the wiki page, one to collect list of databases, and one to collect list of db:tables). The second method collects information on databases and tables in one go, and sends data to both LLD rules.

There is one problem with a big json file which includes dbs and tables. ie:

{
  "data": [
    { "#DBNAME": "db01", "#TBLNAME": "tbl01" },
    { "#DBNAME": "db01", "#TBLNAME": "tbl02" },
    { "#DBNAME": "db02", "#TBLNAME": "tbl01" },
    { "#DBNAME": "db02", "#TBLNAME": "tbl02" }
  ]
}

if you have an item property named db.size[#DBNAME] in your db LLD, you'll get duplicate keys.

That's why i was not sure to have properly understood the sentence

The script would send two different JSONs to two different rules, it's just that the data collection would happen once.

Data collection for both discovery rules would happen only once if you don't use "Zabbix agent" or "Zabbix agent (active)" as type for them else the script will be called twice.

Here's another use case that really would make a nested LLD w/ host prototypes powerful.

I'm managing a large Meraki installation on 3 continents.  The only way to properly get data from devices is to use Meraki's API (snmpwalk wont scale and cant see devices behind a meraki appliance).  Meraki devices are configured hierarchically --> Org/Network/Device.

My Org discovery returns this:

]

I then want to discover networks so I create a host from the 'name' key and use it to discover networks.  Once those networks are discovered I'd like to create hosts for those and start to discover devices.

I can write an external script to do this but I'd like to do this natively within Zabbix and not have to shell out every time I discover.  Nested LLD is about the only practical way to discover large groups of devices.  

jackvalko, you might be interested in voting and following ZBXNEXT-6844 then.

Sorry, but no we are not interested in other features we want this

I outlined another use case for nested LLD here: https://www.zabbix.com/forum/zabbix-help/433212-cascading-lld-building-juniper-cos-items-on-interface-and-queue-indexes

@palivoda can we get this request assigned to someone for review?

The link https://www.zabbix.org/wiki/Docs/howto/Nested_LLD in pointing to https://www.zabbix.com/community, not to a particular doc, so I did not read it (sorry if Im saying something that is explained in that article)
There are many situations where the LLD should iterate, when adding tags to items or tirgger prototypes, when an entity has sub-entitys and you need to relate triggers (no trigger in sub-entity if the master entity is offline)

This would also make it possible to more easily monitor nginx JSON status.

The open module's format is here, it's an upstream/server nesting: https://github.com/nginx-modules/ngx_http_json_status_module

And the commercial official API module also has some nesting: https://nginx.org/en/docs/http/ngx_http_api_module.html

The Solr cluster status response is also a nested json: https://solr.apache.org/guide/6_6/collections-api.html#CollectionsAPI-clusterstatus

$.collections.{collection}.{shard}.replicas.{replica}

That's 3 levels of nesting. Without this feature, enterprises using solr cannot really utilize zabbix. It's pretty much like ZBXNEXT-1, when people need a template generator specific for their setup, due to a lack of a well needed feature in zabbix.

maybe this feature can be funded by the community via https://bountysource.com/ ?

Improved filtering is another possible use case for this feature.

For example, you would like to monitor SFP transceiver power status for a Cisco device. You can get all SFP modules via SNMP, e.g. port, serial, model, etc.:

.1.3.6.1.2.1.47.1.1.1.1.2.311 = STRING: "Transceiver (slot:11-port:11)"
.1.3.6.1.2.1.47.1.1.1.1.12.311 = STRING: "CISCO-AVAGO"
.1.3.6.1.2.1.47.1.1.1.1.13.311 = STRING: "SFP-10G"

Each module has different sensors, e.g. receive power, transmit power, etc. SFP module with 311 index has 5 different sensors:

.1.3.6.1.2.1.47.1.1.1.1.4.10001 = INTEGER: 311
.1.3.6.1.2.1.47.1.1.1.1.4.10002 = INTEGER: 311
.1.3.6.1.2.1.47.1.1.1.1.4.10003 = INTEGER: 311
.1.3.6.1.2.1.47.1.1.1.1.4.10004 = INTEGER: 311
.1.3.6.1.2.1.47.1.1.1.1.4.10005 = INTEGER: 311

Sensor data (e.g. name, status, etc.)

.1.3.6.1.2.1.47.1.1.1.1.2.10001 = STRING: "Ethernet11/11 Lane 1 Transceiver Receive Power Sensor"
.1.3.6.1.4.1.9.9.91.1.2.1.1.3.10001.1 = INTEGER: 3

At the moment, you can discover sensors but can't use module related information as a filter. I.e. you can't monitor power sensors for "SFP-10G" modules only.

"Improved filtering is another possible use case for this feature"

This is my motivator as well, though with a configuration/design use case rather than hardware discovery.

We utilize Cisco gear and do port discovery of all of our switches.  I currently filter based on port type and up/down status.  There is an SNMP OID that uses the interface index that will report CDP neighbor name(s) (.1.3.6.1.4.1.9.9.23.1.2.1.1.6.{IFINDEX}.#) .  Unfortunately, it has a trailing number after the index, and it also is only populated if a value is present.  If the LLD could include this OID in discovery, then I could create one discovery rule for ports with a neighbor based on device name prefix, and a second for everything else.  This would allow me to automatically assign triggers based on expected port type (uplink vs device, etc).

So, the ability to include {IFINDEX} in a discovery label would be helpful.

Might be related.  Using SNMP discovery to generate monitoring items based on a storage type.  Presently I can have several discoveries run the same SNMP walk, each with a different discovery filter by storage type (scheduled to avoid concurrency that causes the discovery to time out).  Seems to me this would be better with a master discovery (with no item prototypes) that is run once to return all storage types, then run dependent discoveries with preprocessing to match the storage type and generate the items.  The dependent discoveries do not have to repeat the SNMP walk.

This is similar to the existing feature where a Master Item run a command that returns multiple values and dependent items can preprocess those results without having to run the command again.  

ZBXNEXT-7527 asks to host prototypes nesting, which is very related to current case, but still a little bit specific.

Nested LLD would definitely be useful for multi-lane optics. The OID looks like

SNMPv2-SMI::enterprises.2636.3.60.1.2.1.1.6.{PORTINDEX}.{LANE}

but there's no way currently (that I can find) within Zabbix to support this.

Where the info at http://zabbix.org/wiki/Docs/howto/Nested_LLD go?

https://web.archive.org/web/20171115143613/http://zabbix.org/wiki/Docs/howto/Nested_LLD

The wiki is no more.

Another case for cascaded LLD is redfish API:

/redfish/v1/Chassis/<ID>/Power/PowerSupplies/<ID>

Currently, there is no way to enumerate Chassis and then Power Supplies within one template and http-agent.

Supermicro:

{
    "@odata.context": "/redfish/v1/$metadata#ChassisCollection.ChassisCollection",
    "@odata.type": "#ChassisCollection.ChassisCollection",
    "@odata.id": "/redfish/v1/Chassis",
    "Name": "Chassis Collection",
    "Members": [
        {
            "@odata.id": "/redfish/v1/Chassis/1"
        },
        {
            "@odata.id": "/redfish/v1/Chassis/HA-RAID.0.StorageEnclosure.0"
        }
    ],
    "[email protected]": 2
}

Lenovo:

{
    "@odata.type": "#ChassisCollection.ChassisCollection",
    "@odata.id": "/redfish/v1/Chassis",
    "Members": [
        {
            "@odata.id": "/redfish/v1/Chassis/1"
        },
        {
            "@odata.id": "/redfish/v1/Chassis/3"
        },
        {
            "@odata.id": "/redfish/v1/Chassis/4"
        }
    ],
    "@odata.etag": "\"2b1611aac39424e542c\"",
    "@odata.context": "/redfish/v1/$metadata#ChassisCollection.ChassisCollection",
    "Description": "A collection of Chassis resource instances.",
    "[email protected]": 3,
    "Name": "ChassisCollection"
}

Dell:

{
    "@odata.context": "/redfish/v1/$metadata#ChassisCollection.ChassisCollection",
    "@odata.id": "/redfish/v1/Chassis",
    "@odata.type": "#ChassisCollection.ChassisCollection",
    "Description": "Collection of Chassis",
    "Members": [
        {
            "@odata.id": "/redfish/v1/Chassis/System.Embedded.1"
        },
        {
            "@odata.id": "/redfish/v1/Chassis/Enclosure.Internal.0-1:RAID.SL.3-1"
        }
    ],
    "[email protected]": 2,
    "Name": "Chassis Collection"
}

ZBXNEXT-3643

Some interesting links for agent-less WMI monitoring solutions:
http://honglus.blogspot.com/2010/12/zabbix-vs-zenoss.html
http://www.mikepalmer.net/tag/wmi/
http://pkgs.org/centos-6-rhel-6/atomic-x86_64/wmi-1.3.14-2.el6.art.x86_64.rpm.html
http://www.zabbix.com/forum/showthread.php?t=10770

http://semafour.wordpress.com/2010/02/17/compiling-wmic-for-linux-without-installing-samba/
add "ZENHOME= /usr"
comment "USE_BREAKPAD = 1"

http://pzolee.blogs.balabit.com/2010/09/wmi-client-for-linux/

Hello,

Another updated solution https://github.com/greenbone/openvas-smb/tree/main/wmi

See:

ZBXNEXT-1414

ZBXNEXT-1475

ZBXNEXT-8609

See:

https://web.archive.org/web/20210615190540/http://www.zabbixbook.com/2016/10/24/using-the-zabbixtiny-to-change-an-item-interval-based-on-a-trigger/

This was very easy to add because the DBselect() function already supportes an offset parameter.

See also ZBXNEXT-1503

support offset parameter history.get() for zabbix-3.0.2

Useful offset parameter.
Original attached patch for only zabix-2.2, and not fail patch for zabbix-3.0.2.

I rewrote the patch for zabbix-3.0.2. see attached file.
Please import this patch and support offset parameter.

Adding offset could lead to changing "Search/Filter elements limit" GUI configuration option to "Maximum rows per page".

Having pagenation support will help for other system integrations. When the historyget or items.get has more results its throwing 500 internal error. Pagination helps in api calls usecases

+1 It would also be useful in PowerShell to paging/piping the results in small badges. For example, we use PowerShell to synchronize the inventory data of all hosts with our CMDB via the API. But when you have 10,000 hosts, this can quickly lead to problems. Something like in SQL with offsets and limits would be great.

Are there any news regarding this feature? 
we are having troubles to sync zabbix hosts with our cmdb. Paging would be useful.

It's possible that the cause of this feature missing was support of things like "limit, offset" back in the days when we supported more database backends (like IBM DB2) which either don't have it or didn't have it back then. We now do not support IBM DB2 so the only question is Oracle.

According to this support for limiting and specifying offset was added to Oracle 12c. This should be fine since we require at least version 19c at this point.

I'll try to get more information.

simkimdm While this is still not implemented, would it work for you if you'd fetch the list of all hostids first and then go on handling them by smaller batches? Have you tried it?

@dimir works better than fetching all at once. thank you.
here is a small python snippet how i implemented it.

from zabbix_utils import ZabbixAPI
// ... login stuff
def get_zabbix_hosts():
    zabbix_hosts_ids = zabbix.host.get(
                                    output="hostid",
                                    evaltype=0,
                                    tags=[
                                       {
                                           "tag": "cmdb_id",
                                           "operator": 4
                                       }
                                    ]
    )
    chunk_size = 1000
    chunks = [chunk['hostid'] for chunk in zabbix_hosts_ids]
    zabbix_hosts = []
    for i in range(0, len(chunks), chunk_size):
        chunk = chunks[i:i + chunk_size]
        zabbix_hosts += zabbix.host.get(hostids=chunk,
                                        selectMacros="extend",
                                        selectTags="extend",
                                        selectHostGroups="extend",
                                        selectParentTemplates="extend",
                                        selectInterfaces="extend")
    return zabbix_hosts 

Nice. And nice to see you use our zabbix_utils and it works for you.

Hello, I strongly support this feature: it's very valuable to asses whether an item has disappeared because of LLD.

tried internal cheks?

internal items/events won't help.

another idea - a new trigger function lldwilldeletein() or better named
would return 0 if an item is still discovered and time in seconds until the item would be deleted.

Appliying the same rules applied with services in network discovery will be nice.
Discovered, Up, Lost, Down (don´t know if with the same names)
Also the deletion of the item/trigger etc can be done by the same rules, you decide when an item will be deleted depending on certain rules, not the same keep lost resource for every resource discovered.

Very similar

https://support.zabbix.com/browse/ZBXNEXT-8711

Hi, has anyone found a workaround?

I'm looking for a way to identify when a discovered item stops to be discovered... 
I need to trigger and create an event about this situation.
Trying to figure out if a trigger prototype with nodata() function does the job.

Hi Ceasar, here's what I've done:

Create a user parameter file for zabbix agent on the zabbix server:

/etc/zabbix/zabbix_agent2.d/userparameter_pgsql.conf

The file contains the following line:

UserParameter=zabbix.undiscovered,psql -d zabbix -U zabbix -c "select count(item_discovery.ts_delete) from item_discovery where item_discovery.ts_delete <> 0 and item_discovery.key_ not like 'exclude%';" -qt

Note that I'm using a PostgreSQL database, so I also need a .pgpass file for the zabbix user:

/var/lib/zabbix/.pgpass

That file contains the password for the zabbix dabase user:

localhost:*:*:zabbix:passwordhere

Then create a new check item for the zabbix server:

Name: Zabbix Server dropped from discovery
Type: Zabbix agent
Key: zabbix.undiscovered
Type: Numeric

Then create a new trigger:

Name: Count of items dropped from discovery: {ITEM.VALUE}
Expression: last(/Zabbix Server/zabbix.undiscovered)<>0
Severity: Whatever you like.

This produces an alert with the count of dropped discovery items.

To find the specific items that were dropped, I then SSH into the zabbix server and execute the following query against the pgsql database:

select hosts.name, items.name, items.status, to_timestamp(item_discovery.lastcheck) as lastcheck, to_timestamp(item_discovery.ts_delete) as ts_delete
from items
left join hosts on items.hostid = hosts.hostid
left join item_discovery on items.itemid = item_discovery.itemid
where item_discovery.ts_delete <> 0
and item_discovery.key_ not like 'exclude%'
order by hosts.host;

Note that I ignore certain dropped discovery items in both cases with the "and item_discovery.key_ not like 'exclude%'" syntax. If you don't need that, don't use it.

Hi Peter , 

Thank you for your suggestion, however, they don't apply to my environment. 

I need something that shows exactly to our support team what is missing. 
Need to be simple like any other event.

Play around with the userparameter query and you can get the full list dumped to the item and handle the trigger based on that.

A work arround could be done by an script item that uses de API and reports  the not dicovered itms. 

Whith the new history.push you can fire a trigger.

RHEL 7.5 kernal version 3.10.0-862.14.4 e17 x86_64

It reminds me ZBXNEXT-5712. Is support of host groups in graph widget what you are looking for?

you can use grafana for this. just a couple of hours to configure

Host group filtering would probably be an easy addition and it makes it so the widget doesn't need to be updated in environments where the hosts change. 

Maybe in a similar way conditions are defined for actions.
d) AND/OR

<richlv> hmm, in action conditions we have condition types that can be used to determine and/or. how should it work in trigger deps ?

Loosely connected to ZBXNEXT-1461

I would like to have this feature implemente too.
I would be very usefull.

yes it would be very useful to have the possibility to configure relationships between dependancy.

I would love this to be implemented on priority. There are several instances in my networking infrastructure where this would provide greater monitoring flexibility.

Today if a host depends on two hosts, but only if botth are down, we have to generate a third trigger.
It will be nice if we could configure dependency between hosts as
https://support.zabbix.com/browse/ZBXNEXT-46

I've attached that partially implement this.

Included:

• Server side changes to check the dependency relationship
• Frontend-changes to change the relationship

Missing:

• API changes to take the relationship into account for the front-end. The current code is not recursive, making it harder to check this relationship recursively.
• Setting the amount of dependencies. Only AND/OR.

Feedback would be appreciated.

Thanks for the patch! I like the functionality however it's not clear if it will be integrated into Zabbix or not. We are evaluating different options of simplifying management of dependencies and still not sure what might be the best implementation.

Thanks. I'm curious to see any improvements to dependency management.

I'm not sure wether Clickhouse or InfluxDB (or another TSDB) is more appropriate to store the historical data.

Clickhouse is an opensource solution. https://clickhouse.yandex . The authors of the patch made a report at Zabbix summit 2018 - https://www.zabbix.com/zabbix_summit2018_agenda#day1_1325 advantages over elasticsearch are obvious.
Now many projects choose Clickhouse to store time series, as it is a very effective (if not the most) solution on the market.

the bigest advantage of clickhouse.... is sql database ... outher timeseries or elasticsearch had her proper query language/api/interface...

the advantage of clickhouse over the other solution is that very near to the original zabbix storage solution... sql...

but with performance of a columnar database... and scalability (distributed and replicated)... and compression...

they are coded in C++...

are very fast in injection...

the only difficulty is that not originaly support sql delete/update, work only on insertion and deleting partition to purge historical...

but now it's possible https://www.altinity.com/blog/2018/10/16/updates-in-clickhouse

What is the status for this? Waiting for clickhouse support in Zabbix to use it in a new project!

Actually the creator of the patch launched a new fork of zabbix

https://glaber.io/

It would be great for Zabbix to adopt at least some of those principles (from glaber), to get some serious performance improvement and scale natively. Their presentation at 2018 summit was great and they archieved some great numbers. If only that could go back into Zabbix..

This sounds like a good plan for Zabbix 5.0 https://www.zabbix.com/roadmap#v5_0

Support for TimescaleDB shows, that developers are open for better alternatives - it will be a very good step to let users choose their storage tec and support clickhouse or other systems! Do it, this will be a huge win for Zabbix!

https://habr.com/ru/company/ua-hosting/blog/486540/

https://habr.com/ru/company/ua-hosting/blog/485470/

This is a must have for large setups.

we use clickhouse for netflow collection and is superfast.

I think we give a try to glaber

I'm not sure but ZBX-4744 looks a bit related.

I disagree, Volker is suggesting a fundamental change in handling trigger dependencies in actions and maps.

Related to ZBXNEXT-1333

Loosely connected to ZBXNEXT-1547

>all necessary information already exists in the Zabbix database. Zabbix knows about the whole dependency chain.

imho, in current state, zabbix does not know about dependencies. Firstly, it should create a network tree. i think it should discover who is host, who is switch, router etc and who of this at righ side and at left side for topology compilation and relations between devices. Also, it should to know who is Port for root cause discovery and port to port mappings. This mechanism is requires model-oriented approach. And, since, all of network devices are typically SNMP-based, so, discovery should rely on SNMP.
Examples.
Our topology: ZABBIX-switch_port11-SWITCH1-switch_port12router_port1-ROUTER1-router_port2switch_port21-SWITCH2-switch_port22-HOST1
Scenario:
If switch_port21 is disconnected (we are receive router_port2 LinkUp/Down SNMP Trap, we can use this info in correlation).
Remark: Zabbix DB may contain info: router_port2 connected to switch_port21 (based on mac address table info while topology discovery), or on upper level relation: ROUTER1 at left side has SWITCH1, and ROUTER1 at right side has SWITCH2.
When HOST1 is unreachable, zabbix poll by icmp or snmp or tcp the SWITCH2: hey, are you OK? No answer. Next step - zabbix poll ROUTER2: he is replay via icmp for example, it worked and router_port2 status is Down.
So, HOST1 unreachable - is secondary issue and should be suppressed (suppresed message should be emailed to SA with root cause "SWITCH2 is down"), and root cause - "SWITCH2 is down" (this message to NA with affected devices for example. What if 400 hosts is connected to SWITCH2, cisco 6513? NA should know a scale of trouble ).

This is my reflections about network topology discovery and dependencies and about some implementations.
imho, just templates with dependencies is not enough today. It creates human errors, complexity of maintenance and tight monitoring.

"Connection failed: WRONGPASS invalid username-password pair."
Nice error message from the Redis item, but it is not yet possible to automatically save and add it to the ticket to help administrators quickly find where the error is.

description for :

• global regexps ZBXNEXT-597
• graphs ZBXNEXT-716
• host groups ZBXNEXT-2408
• maintenance subperiods ZBXNEXT-2770
• users ZBXNEXT-2825

This is definitely a nice quick easy addition!

It looks trivial to add a description field, with minimal impact on database and other features.

In large installations, it's necessary to document the purpose of each usergroup and some users: why was it created for? permissions? alerting? dashboards? api access?.

Zabbix configuration should allow for some kind of auto-documenting, it'd make the life of Zabbix administrators easier.

if not a description field, then a tags field. this would allow to add tags for short description, expiration dates, a temp flag, etc.

Any Zabbix Version

Hello David,
currently you can't manipulate with global expressions through the API.

Indeed an "httpstepitem" table could be used to get and include actual items to API response.
As the response contains only steps, but each has 3 items and there are also items for scenario - to resolve this request the method should support something like selectItems, which would include items for steps and scenario.

As a workaround, having scenario and step names it's possible to construct item keys https://www.zabbix.com/documentation/2.4/manual/web_monitoring/items and then using hostid get items using item.get with filtering by key.

Should we move it to ZBXNEXT ?

Or close it as a duplicate of ZBX-9649

Well, indeed worth to close.

i'd suggest moving to zbxnext instead. ZBX-9649 was about getting those items, this issue is about getting their ids in the first place.
while constructing item keys might work, it is fragile - what if an upcoming zabbix version changes the keys ?
being able to properly get the associated ids would be quite useful.

Good point, moved.

It does not seem possible via API how we can get the relations between httptestid > httpstepid > itemsid.

Using httptest.get($hostid) we can get httptest.httptestid, httptest.hostid, httpstep.httpstepid and httpstep.httptestid - but we cannot get items.itemid

Using item.get($hostid,webitems) we can get items.itemid and items.hostid - but we cannot get httpstep.httpstepid or httptest.httptestid

The httpstepitem table contains httpstepitemid, httpstepid, itemid, type and is necessary to link the two above; but does not appear exposed in API

It seems the following changes may address this:

a) have httptest.get when during selectSteps return the list of steps including the itemid and type from httpstepitem as an array

and/or

b) have item.get when during webitems=true return the httptestid, httpstepid and type from httpstepitem.

I wrote the above before I found this unresolved item of 7 years ago.

It seems like I am the first to vote on the issue, but is there any likelihood this shortcoming will be addressed?

Hi,
you are right that there is no parameter to change the output, but it can't be defined as a bug as it is by design. I will go to close this one. You can create ZBXNEXT request with your vision on how it should be.

Regards, Elina

Zabbix Version: All

What 'Zabbix ID: NMR' means?

NMR = Needs More Research

Since the current work-around to get the graphs involves faking a POST form submit to the frontpage and re-using that sessionID to get the graph itself is pretty annoying, a simple PNG return of the image would be much welcomed as an API request.

NMR = Needs More Research
NMR = Need Major Release

Hi
will it be included in the 2.2 ?
thanks

Yo can directly convert images url to png format using the Perl Zabbix::API.
See https://metacpan.org/module/Zabbix::API::Graph for example.

Thierry Sallé: I don't see a point in implementing the whole graph drawing as Zabbix is able to do it very fine.

Well, there is a point here. It would be super handy if we can retrieve graph images from the api for automated reporting features

The point of implementing in this in the API rather than accessing the php-pages is that the API is a stable and documented interface. The chart2.php is an internal implementation that should not be used by external resources.

Hi all, since the last comment in 2014, has this been resolved? I/we would greatly appreciate it.

Yes, is there any update on the request?

Maybe in delayed 4.0?

It will be nice if there is an official statement.

my solution:

...

use strict;
use warnings;
use LWP::UserAgent;
use HTTP::Request;
use MIME::Lite;
use MIME::Base64;

...

sub zabbix_get_graph
{
    my ($graphid, $period) = @_;

    my $ua = create_ua();

    my $url = "$ZABBIX_SERVER/chart2.php?graphid=$graphid&period=$period&isNow=1&width=" . IMAGE_WIDTH;

    my $req = HTTP::Request->new('POST' => $url);
    $req->content_type('image/png');
    $req->header('Cookie' => "tab=0; zbx_sessionid=$ZABBIX_AUTH_ID");

    my $res = $ua->request($req);
    my $tmp = substr($res->content, 1, 4);

    #The first eight bytes of a PNG file always contain the following values:
    #(decimal)              137  80  78  71  13  10  26  10
    #(hexadecimal)           89  50  4e  47  0d  0a  1a  0a
    #(ASCII C notation)    \211   P   N   G  \r  \n \032 \n
    #https://www.w3.org/TR/PNG-Rationale.html#R.PNG-file-signature
    if ($tmp =~ m/PNG/)
    {
        return $res->content;
    }
    return;
}

...

sub send_email
{
    my ($email_body, $subject, $smtp, $email_from, $email_to) = @_;
 
    my $msg = MIME::Lite->new(
                                From    => $email_from,
                                To      => $email_to,
                                Subject => $subject,
                                Type    => 'multipart/related'
                           );
    $msg->attach(Type => 'text/html', Data => $email_body);
    $msg->attach(Type => 'image/png', Filename => 'graph.png', Id => 'graph.png', Data => $DATA_GRAPH) if defined($DATA_GRAPH);
    $msg->attach(Type => 'image/png', Filename => 'logo.png', Id => 'logo.png', Data => decode_base64($LOGO));
    $msg->replace('X-Mailer' => 'Zabbix');
    $msg->add('X-Priority' => $PRIORITY{'Highest'});
    $msg->send('smtp', $smtp, Debug => $DEBUG);
}

@Alexander: Your solution is based on the old graphs or for the new vector graphs?
Thanks

for the old (classic) graphs

@Alexander: Ok Thanks

@ZabbixTeam: I will suggest to bring this improvement (RestAPI for Graphs) as soon as possible with the new Vector Graphs thanks

@Dimitri: You can also use http request, I think so

@Alexander: Yes! We have create a simple reporting tool for Zabbix and at the monent is based with the old graphs style...

As this request is running for a very long time, I've decided to code and release a beta version of a Media type that is capable of presenting a graph embedded in an e-mail message while adding TWIG template facilities to allow for some nice customization of the outgoing message (including IF statements for example) and adding some smart way finding the direct or indirectly associated graphs to a trigger (from API perspective).

Note that Chart2 only has the capability to present 'Normal' graphs - I'm also working to support the other types as well (scattered across the other chartX.php).

Have a look at: https://github.com/moudsen/mailGraph

Once the API extension is there, my code will be fully API based (currently logging in to Zabbix to use chartX.php with CURL).

Official request to Zabbix developers to add my Media type to their repository: ZBXNEXT-6534 (declined politely but I guess that when more people want to see this feature instanciated after 6 years that will change ... ).

any news?

I have developed code to pick up graphs from Zabbix. Recently split the "get image" from my mail code and can make this available beginning of next month.
Not integrated to Zabbix API but has proven to work very well already ...
https://github.com/moudsen/mailGraph
If you are interested let me knowon GitHub (please raise an issue for it).

Hi,
is there any update in the lates version 6.2 that it makes easier to use?

Or when it will be natively added?
Thanks.

This is nice feature, but why this is not implamented yet? 

image.get method have a nice solution for this which returning "image" attribute with base64 encoded image.  

I setted up the priority by looking at the "?" if it is not the correct one you can change it !

Sorry, could you please elaborate what exactly is asked here and provide a complete use case.

Hi,

Sorry, English is not my main language so I might be unclear.

The goal here is to automatically add templates to a server when specifics packages are detected.

Currently (well in 6.0, I didn't work on this since) auto-registration does not give a way to simply add templates to a server whithout manual actions or specific API scripts (I might be wrong but this is what I concluded after some research)

We can simply use a variable to get the OS type (Linux/Windows) and add the server to the correct group with auto-registration.

It could be nice to add a way to filter on system.sw.packages and with autoregister rules, add templates to a server when a packages is detected.

Simple example :

Installing zabbix active agent with auto-registration on nginx server :

• Zabbix active agent do the registration process
• Zabbix server get the OS metadata and add the server to linux group
• Zabbix server get the packages list, find nginx -> Add server into nginx group and add nginx template

Is this easier to understand ?

Host Discovery, Auto Registration, Host Prototypes