Hi,
I do get a 502 on multiple environments for multiple customers one customer when staging data from the BMC Discovery API. Customers have migrated BMC Discovery to version 12.1 (20.08). I contacted a customer's BMC team, but am still waiting for their feedback.
I commented the specific staging step (DiscoveredService Nodes) out as a workaround and staging seems to work again.
Does anyone see the the same? Is an update in the reader necessary as this data no longer seems to be available?
Best regards,
Markward
Edit: The second customer was an an authentication issue, that leaves me with one customer, 2 environments accesseing a patched BMC Discovery.
‎May 19, 2021 05:22 AM - edited ‎May 19, 2021 06:32 AM
I searched through reported problem records and couldn't find anything that sounds similar to this related to the "DiscoveredService Nodes" query. Does the extractor log show any more details - such as a more specific error message?
Executing some PowerShell statements like the following may help to reproduce the failure for further analysis:
$q = "SEARCH Host TRAVERSE InferredElement:Inference:Associate:DiscoveryAccess WHERE end_state = 'GoodAccess' TRAVERSE DiscoveryAccess:DiscoveryAccessResult:DiscoveryResult:ServiceList TRAVERSE List:List:Member:DiscoveredService WHERE name = 'vmms' SHOW name AS 'Name', #Member:List:List:ServiceList.#DiscoveryResult:DiscoveryAccessResult:DiscoveryAccess:DiscoveryAccess.#Associate:Inference:InferredElement:Host.key AS 'HostKey'"
Invoke-WebRequest -Uri "https://your-addm-server/ui/api/XmlApi?query=$q&username=***&password=***" -timeOut 3600 -OutFile QueryResult.xml
‎May 23, 2021 08:35 PM
Hi Chris,
The error doesn't give much of a hint.
2021-05-17 3:20:21.955 : INFO : ======== DiscoveredService Nodes
2021-05-17 3:24:22.147 : ERROR : *** ERROR: Received a failed response from the ADDM web service at '***': The remote server returned an error: (502) Bad Gateway.
2021-05-17 3:24:22.147 : INFO : Retrying query with 4 attempts remaining for this mapping.
2021-05-17 3:24:22.147 : INFO : Import completed in 240,189 seconds
The interesting part is that this always fails after 240 seconds while the configured timeout is set to different values, like '3600'. Also steps successfully run, took more than these 240 seconds.
I wonder if there could be a different timeout, not for the API but for the actual DB? Searching for Service names sounds like an expensive query.
I wasn't able to run your PS code, do the spaces in the query need to be escaped with '%20' or '+'?
Best regards,
Markward
‎May 25, 2021 02:15 AM
A consistent 240 seconds does feel like a timeout somewhere, doesn't it?
I don't think the spaces will need to be encoded differently in the URL, but if it isn't working as-is then it wouldn't hurt to try that. But I've just noticed the query does contain "#" characters that would likely need to be encoded. Try this:
$q = "SEARCH Host TRAVERSE InferredElement:Inference:Associate:DiscoveryAccess WHERE end_state = 'GoodAccess' TRAVERSE DiscoveryAccess:DiscoveryAccessResult:DiscoveryResult:ServiceList TRAVERSE List:List:Member:DiscoveredService WHERE name = 'vmms' SHOW name AS 'Name', #Member:List:List:ServiceList.#DiscoveryResult:DiscoveryAccessResult:DiscoveryAccess:DiscoveryAccess.#Associate:Inference:InferredElement:Host.key AS 'HostKey'"
Invoke-WebRequest -Uri "https://your-addm-server/ui/api/XmlApi?query=$([Uri]::EscapeDataString($q))&username=***&password=***" -timeOut 3600 -OutFile QueryResult.xml
‎May 25, 2021 02:46 AM
Hi Chris,
This worked, additionally I had to force TLS 1.2 and ignore certificate checking. Here's what I got:
As all other staging queries work, maybe this one is just more taxing on their system? I forwarded the findings to their BMC team, maybe they can confirm something.
Best regards,
Markward
‎May 25, 2021 03:42 AM