Nginx load balancer probe is unable to parse config files when using a unix socket path instead of ip/port - Causes misidentification of existing records, and duplicate new records each scan - Known Error

Nginx load balancer probe is unable to parse config files when using a unix socket path instead of ip/port - Causes misidentification of existing records, and duplicate new records each scan Description Nginx load balancer ip-based/horizontal Discovery probe is unable to parse config files when using a Unix socket, instead of the expected ip/port . Without IP and Port entered in the resulting load balancer member records, this causes misidentification of existing records, and duplication and the marking as Absent of those records. The path to the Unix socket is not recorded in the CI, and there is no field to put this data.

The symptom is that cmdb_ci_lb_pool_member records will be created without a IP Address and port entered. On the next discovery scan, these can't be match up with, and new records are created, with the previous ones set as absent. This adds records on each scan, which are never deleted.

Notes: When this probe was first developed, the assumption was that all config files looked like this "full" example: https://www.nginx.com/resources/wiki/start/topics/examples/full/ in which case the upstream sections look something like:

upstream big_server_com { server 127.0.0.3:8000 weight=5; server 127.0.0.3:8001 weight=5; server 192.168.0.1:8000; server 192.168.0.1:8001; }

However it is also valid to configure the load balancer to use unix sockets instead. http://nginx.org/en/docs/stream/ngx_stream_core_module.html http://nginx.org/en/docs/http/ngx_http_upstream_module.html http://nginx.org/en/docs/stream/ngx_stream_core_module.html

upstream backend { hash $remote_addr consistent; server backend1.example.com:12345 weight=5; server 127.0.0.1:12345 max_fails=3 fail_timeout=30s; server unix:/tmp/backend3; }

The probe can parse "server 127.0.0.1:12345", but not "server unix:/tmp/backend3", but even if it could, it will then still try to find existing records using only port and ip address fields, and so will not find these unix socket ones to update.

Steps to Reproduce

In Utah, install Discovery, Discovery and Service Mapping Patterns, CMDB CI Class Models, and ITOM Visibility Content Install a MID Server, add SSH credentials Configure an Nginx load balancer on a Linux host with upstream unix sockets, instead of ip:port Discover the Linux host twice. The ecc_queue input data will look something like this, with "unix:/" in there, instead of the expected "ip:port": {"related_data":{"upstreamList":{"uwsgi":{" servers":["unix:/var/run/tower/uwsgi.sock"] ,"method":"round-robin"},"daphne":{"servers" :["unix:/var/run/tower/daphne.sock"], "method":"round-robin"}},"serverList":[{"locations":[{"url":"/ websocket ","proxyPass":"daphne"}],"names":["_"],"listens":["443","xxx"]}],"hostList":{}}}</output

Expected behaviour: cmdb_ci_lb_pool_member record(s) should be created, with a field to record the Unix socket path information. On subsequent discovery, that information would be used to match existing records.

Actual behaviour: Because no IP address and port information is recorded, when the Nginx sensor is trying to match against existing records, it cannot, so it inserts new duplicate ones, and marks the existing records as install status Absent. The unix socket path information (e.g. unix:/tmp/backend3) is not recorded in the CI.

Workaround This problem has no workaround, is currently under review and targeted to be fixed in a future release. Subscribe to this Known Error article to receive notifications when more information will be available.