DH is point to point key exchange. The best method is to break the encryption and rebuild a different tunnel to the end point of the network. This will cause high load.
Most corporations, as soon the packet enters in their secure network, they are forwarded decrypted to allow analysis without performance impact.
I think most of the devices cannot sniff that type of traffic, só you will need to break the tunnel.
Even if you have the private key, the key pair generated by DH is between the origin and destination, middle systems will not be able to get the key.
What I mean in breaking the tunnel is for your devices to have their own certificates and private keys in the same way as servers and act as endpoint for the communication.
Generate your tool csr and request certificates for each site you have. If you own the sites it won’t be a problem and you will be able to read trafic. Same way as if your appliance was a web server.
Many tools do not allow it. Others allow it but restrict this to a small number of virtual servers hosted.
Collecting the private keys from the web servers might not be sufficient. You have to break the tunnel and not eavesdrop at it.
To get the private keys from each site. The site certificate needs to be exportable, you need to know the password if any and export it to a file(private key), then in your ids you should proceed importing it. But that is probably what you already have done due to the fact that your statement says you can read trafic only some specific DH is not possible... :)
The process of exporting the keys changes a bit if you have a windows or a Linux, easy to find in the internet.
Why you can read TLS_ECDHE_RSA_WITH_AES_256_GCM_S HA384 they are not using Diffie-Hellman Ephemeral (DHE/EDH) or RSA Ephemeral cipher suite to exchange keys but ecliptic curve. if you snif the packets and see if the cipher suite specified begins TLS_DHE or SSL_DHE, you will not be able to decrypt the data.