...
Why is it important you might say ? It is just that with prometheus simplicity and low resource overhead with have full control plane metrics visibility !
As a side note , this is not a replacement for INT/TELEMETRYTelemetry/NETFLOWNetflow/IPFIX that provide different type of data that are to at the same scale…
People with INT/TELEMETRY/NETFLOW/IPFIX are talking about (disclaimer:buzz word) a "data lake" or "data deluge". Which is correct, if you think about the complexity of resolving a gigantic producer/consumer data problem. This needs the relevant IT infrastructure in order to process all of the data provided by these protocol at the NREN scale.
While in our case, we are just focusing on exposing CONTROL PLANE METRICS (so it is definitely not a lake), but we don’t need a "lake of data" in order to monitor and ensure a router operation.at the network element level. We simply monitor and ensure a router operation by using prometheus metrics
| Warning | ||
|---|---|---|
| ||
While he above might be true, the number of metrics exported from a prometheus target can be very high. Fine tuning might be necessary in order to make sure that all metrics are really necessary for network monitoring purpose. This explosion of metrics exposure can add unnecessary workload at the control plane level. |
Again, kudos to NMaaS team that made this happen so the we can test this on the P4 LAB with — ZERO — effort.
...