Chaining issue

[FredGSanford]

Hello Mark, I am trying to get the health message of vRNI datasources using api/ni/data-sources/health.  Below is a sample log.  I can get the FQDN and the health_status fine.

{
  "results": [
    {
      "entity_type": "NSXTManagerDataSource",
      "entity_id": "10599:904:2738279389346719912",
      "fqdn": "vcenter1.test.local",
      "proxy_id": "10599:901:5003294786397150440",
      "nickname": "vcenter1.test.local",
      "enabled": true,
      "health": {
        "health_status": "HEALTHY",
        "health_details": [
          {
            "message": "SUCCEEDED",
            "code": "0"
          }
        ]
      },
      "last_modified_timestamp": 1750344974104,
      "last_activity_timestamp": 1757532140998,
      "last_config_activity_timestamp": 1757532161447
    },
    {
      "entity_type": "NSXTManagerDataSource",
      "entity_id": "10599:904:1621959400663917885",
      "fqdn": "nsxt1.test.local",
      "proxy_id": "10599:901:5003294786397150440",
      "nickname": "nsxt1.test.local",
      "enabled": true,
      "health": {
        "health_status": "UNHEALTHY",
        "health_details": [
          {
            "message": "FAILED_DATASOURCE_OPERATION",
            "code": "-72"
          }
        ]
      },

However when trying to include the message, it only returns the message from the first fqdn in the api call so all data sources show as succeeded even though many have errors.

New object uses message and chains in the FQDN from the results.*

After performing data collection, its returning 68 properties of the message for each data source.  Any thoughts?

End goal is this.

-------------------------------------------

[Zack Kendra]

Hey @FredGSanford, 

The response above contains a health_details list nested inside the results list. This structure makes defining metrics difficult in MP Builder 9.0 and previous versions. It looks like the fqdn(s) are being mapped to every message. There are two things that may help.

1. Chain from the data-sources request to a specific data-source: This would scope the chained parameters to the response of the health request. The chained request would target something like `/api/ni/data-sources/{id}/health` or `/api/ni/data-sources/{id}`. You'll need to adjust to match your specific API - I can see that the NI API supports this functionality per data source type.
2. Add unique identifiers to the health messages: Currently only the FQDN is used as the identifier, which results in multiple messages per object. Since Operations will only use one of these as the 'message' metric, consider adding '@@@id' of the health_details as an identifier. This will keep each health message separate.

Best regards,

Zack

-------------------------------------------

[FredGSanford]

Thanks Zack, the (id)/health isn't available and the @@@id is always zero.  I'll wait until the next version to see if it works better with nested items.

-------------------------------------------

[Zack Kendra]

duplicate reply posted from me, please ignore