network statistics in "Resources - Hosts Overview" do not separate by interface as they should

[mmguero]

I was looking at the Resources - Hosts Overview dashboard and realized that all of the statistics that are broken out by NIC (inbound/outbound traffic, drops and errors, interfaces by incoming/outgoing traffic) are showing the same stats for all interfaces. This is obviously wrong.

The original structure that comes from netdev-json.sh looks like this:

{
  "interfaces": {
    "enp0s25": {
      "rx_bytes": 41567998635,
      "rx_packets": 32973850,
      "rx_drop": 937050,
      "rx_multicast": 1763303,
      "tx_bytes": 2922109225,
      "tx_packets": 8022167,
      "tx_drop": 17
    },
    "br-dc02e1447c3b": {
      "rx_bytes": 352785510,
      "rx_packets": 3278242,
      "tx_bytes": 37200072449,
      "tx_packets": 12930664,
      "tx_drop": 5
    },
    "wg-oracle-link": {
      "rx_bytes": 389936,
      "rx_packets": 3586,
      "tx_bytes": 1169296,
      "tx_packets": 23640,
      "tx_errs": 820
    },
    "wg-guero-link": {
      "rx_bytes": 544756,
      "rx_packets": 11588,
      "tx_bytes": 800832,
      "tx_packets": 14499,
      "tx_errs": 826
    }
  }
}

I looked at one of the documents (in the malcolm_beats_* index where event.module:network) and see this:

{
  "_index": "malcolm_beats_network_250916",
  "_id": "250916-U2uy8WieHPKGBpqKkQObiQ",
  "_version": 1,
  "_score": null,
  "_source": {
    "@timestamp": "2025-09-16T19:07:06.921Z",
    "log": {
      "file": {
        "path": "netdev-stats.json"
      }
    },
    "host": {
      "name": "malcolm.sgrover"
    },
    "miscbeat": {
      "network": {
        "packets": {
          "rx": 36108282,
          "tx": 20939213,
          "total": 57047495
        },
        "drops": {
          "rx": 937050,
          "tx": 22,
          "total": 937072
        },
        "interface": [
          "enp0s25",
          "wg-guero-link",
          "wg-oracle-link",
          "br-dc02e1447c3b"
        ],
        "bytes": {
          "rx": 41726342635,
          "tx": 40108096359,
          "total": 81834438994
        },
        "errors": {
          "rx": 0,
          "tx": 1646,
          "total": 1646
        }
      }
    },
    "agent": {
      "name": "malcolm.sgrover",
      "type": "filebeat"
    },
    "@version": "1",
    "ecs": {
      "version": "8.0.0"
    },
    "node": "malcolm.sgrover",
    "event": {
      "provider": "malcolm",
      "hash": "U2uy8WieHPKGBpqKkQObiQ",
      "ingested": "2025-09-16T19:07:08.587Z",
      "module": "network"
    },
    "fields": {
      "miscbeat": {}
    },
    "input": {
      "type": "log"
    },
    "tags": []
  },
  "fields": {
    "event.ingested": [
      "2025-09-16T19:07:08.587Z"
    ],
    "@timestamp": [
      "2025-09-16T19:07:06.921Z"
    ]
  },
  "highlight": {
    "event.module": [
      "@opensearch-dashboards-highlighted-field@network@/opensearch-dashboards-highlighted-field@"
    ]
  },
  "sort": [
    1758049626921
  ]
}

Note that we have the interface names, but all we have are the sums, not the values per-interface.

Looking at the code where we do that summation is here. That sum and whatnot is fine, but you'll see then we remove miscbeat.network.details.

I looked at the git blame for that line and can see that removal was done with idaholab@5c3ced4. We removed the miscbeat.network.details field which was previously of type nested. The other field types that were changed at that time were changed from nested to flat_object.

The reasoning for the removal of the nested fields was for #475, which led to the discovery of opensearch-project/security-analytics#1472. The presence of nested fields in the index pattern causes the security analytics plugin to break. So the nested ones were changed to flat_object, except for this one, which was miscbeat.network.details. This was apparently an oversight, because without having the per-interface details we can't run those visualizations correctly.

So we have a few options for if we restore the miscbeat.network.details field:

• make it a flat_object and see if we can get that to work
• see if nested maybe doesn't break security analytics any more
• don't define it in the template at all and just have it get "figured out" by OpenSearch (will result in some "unknown fields" until index-refresh.py runs)

Once we do that, we need to look at the dashboard(s)/visualizations where we're using that data and make sure they do what we want them to do.

not sure what the exact right answer is yet.