topic Re: Skyline metrics for VSX in OpenTelemetry/Skyline

Skyline metrics for VSX

Henrik_Noerr1 — Tue, 11 Jun 2024 12:01:01 GMT

Hey

I am trying to migrate all our snmp polling to Skyline. I see several VSX metrics still unavailable in Skyline.

Could you share a plan for when Skyline will have better feature parity compared to clusterXL gateways.

Specifically I am hurting for the MIB data at: CHECKPOINT-MIB::fwInstancesCPUTable which shows us if a VS thread is saturated

Furthermore I would like the VS name to be more prominent in the labels. Currently VS-ID is used, which generates a lot of unneeded parsing.

Regards,

Henrik

Re: Skyline metrics for VSX

Elad_Chomsky — Tue, 11 Jun 2024 12:30:03 GMT

Hi @Henrik_Noerr1 ,

1) Please open an RFE for CheckPoint regarding the missing metrics, we will take it with the matching R&D owners to see if this information can be added to Skyline, and when. CPU information is available in Skyline, each VS will report it's matching CPU's.

2) Regarding VS-ID - we are using service.namespace label as a general place to specify context, as we want it to be generic to other configuration methods in the future ( Like MDS ) - we used a prefix to identify a VS context.

Re: Skyline metrics for VSX

Henrik_Noerr1 — Tue, 11 Jun 2024 18:19:22 GMT

Hey Elad,

Thanks for the reply. Regarding 2) - I am simply saying that *including* the vs name as a label (which is already done in vsx.overview would really sell this much more. I hope you will consider it.

I will give the following example with snmp polling, graphing CPU load per VS. I am aware I blocked the names out - but replacing names with, vs_id_0, vs_id_1, vs_id_2 etc. will give me absolutely zero traction with our management and customers.

"Ohh vs_id_19 is high today - Hmm wait - Anyone knows what vs_id_19 is????"

This is basically the same for every usecase for skyline graphs. We need logical names for quick references and visual guidance.

Regards,

Henrik

Re: Skyline metrics for VSX

David_Evans — Wed, 12 Jun 2024 12:54:57 GMT

Let me know if you come up with a query to add this field manually with a query within Grafana. I was close to having this working several months ago so it could be easily pulled as an additional field via a transform but never quite got it to work correctly.