Skyline Dashboard Questions

[ptuttle_2]

Hello;

We are testing Skyline in a lab environment and noticed that there are a few items not in the dashboard.

VPN, Routing and Clustering are not displayed.

I looked over the "Skyline Metrics Repository" and went to the explore tab of the Grafana dashboard, and was able to enter some of the items but clustering metric would not take.

Also the VPN metric "VPN_IKE_PEERS"  seems to show the max number of peers the gateway has seen but we are looking for the number of active IKE peers.  Tried a few others in the vpn and blade metric section but no go.

The lab is R81.20 jumbo 10 on both the SMS and the VM gateway.  The site to site VPNs are SMBs.  We understand the SMBs are not supported but was hoping to see the VPN info (number of active peers) on the VM gateway.

We have only been at this Skyline testing for a few days and have allot to learn.

Thanks and appreciate any guidance on this.

-pat

[PhoneBoy]

Do you see the relevant data in cpview?

[ptuttle_2]

Thanks for your response.  Well  yes we do see what we want under "vpn" "Tunnel-Monitoring" "Live Peers"  I get the feeling that this particular metric is not included and I'm thinking that the VPN_IKE_PEERS is actually how many are configured and not how many are actively up.

One of our main objectives of looking at Skyline was to have VPN site to site info displayed.  If this is because of the metric not being there,  are there plans to have more VPN metrics added?

We are rookies with Skyline and it would appear that not everything in CPVIEW is included in the Skyline metrics?

  Thanks

-pat

[Arik_Ovtracht]

Yes, there are plans to add more VPN related data to Skyline soon.

In case you didn't know - every metric which is currently exported by Skyline can be found here: https://sc1.checkpoint.com/documents/Appliances/Skyline/Content/Topics-Skyline-Metrics/Introduction.... 

[ptuttle_2]

Thanks that's good to hear.  How are these updated?  is it thorough a jumbo or some other method?  I thought I read somewhere that if we had auto updates turned on? 

-pat

[Arik_Ovtracht]

Some parts of Skyline require to be updated only via JHFs, but most of it can be updated automatically. 

In this case, I think that the update might require a JHF, but not sure at the moment.

[ptuttle_2]

Sorry for all the questions. We are becoming a Splunk environment and one of the videos mentioned that this would work with Splunk.  I have been asked to look into this as well.  Is there any Check Point info regarding this?   

-pat

[Arik_Ovtracht]

We are planning to work on supporting other 3rd-party monitoring tools (besides Prometheus) soon, and Splunk is one of those. This will also be in the coming months.

[JonasNyquist]

Hello Arik!
So, when you say that you are planning to support other 3rd party monitoring tools besides Prometheus, and then Splunk is mentioned and is the reason for your reply.
My followup question would then be, when you say "support 3rd party monitoring tools", what extends that support then to be?
I'm not up to speed with how all these systems connect to each other, but my perception was that "OpenTelemetry" is "Open" so that specific support isn't necessarily required? And that with the openness it is also up to us as users/customers/partners to "develop" parts of the system ourselves, as in the case of Grafana and the Dashboards.
WHen you say that you will support Splunk, does that mean that Check Point will develop a Splunk App (or if it's called extension or plugin or whatever...), as I believe Check Point has done with the LogExporter API and Splunk, for example?

The reason I ask is because the company I work for are currently building our own, in-house developed "Monitoring and Alert framework", and as one of the supported protocols/methods (what IS OpenTelemetry by the way :-D) will be OpenTelemetry.
So I wonder if I need to start preparing our developers that they need to have a specific "approach" to the OpenTelemetry when it comes to integrating with Check Point devices?

/Jonas

[PhoneBoy]

OpenTelemetry is "open" insofar as it's a standard way to export "telemetry" data from a system.
It's a bit like SNMP, which operates a bit differently than OpenTelemetry, but attempts to achieve a similar result (make data about systems available in a "standard" way).
Similar to how vendors use SNMP, there are some vendor-specific attributes you have to monitor in OpenTelemetry.

Hopefully I explained all that right 🙂

[JonasNyquist]

Thanks Dameon!
Amazing response time as well!
I believe you are located on the West coast, correct?
So you're just about at "afternoon tea" time right now, yes? 😉

Take care, cheers!

/Jonas

[PhoneBoy]

I've moved a couple of timezones over to US/Central from Pacific.
Late dinner time now 😉

[Elad_Chomsky]

Hi @JonasNyquist ,To add on @PhoneBoy answer,

Open Telemetry is a standard and not necessarily a protocol ( So a better example is C++, you have multiple vendor-specific changes on MSVC vs G++, but the basic rules are similar ) , so while CheckPoint commits to adhere to the standard overall, small details on the implementation might change. For example, in SNMP there is a specification in the packet level to how it should look like. while the OTLP protocol is more open and offers various approaches from GRPC to UDP. Our support extends to add means to export the data from the GW, I suggest that in case of a custom third party exporter that is not supported yet - ( Currently supported DataDog, Splunk, VictoriaMetrics, Prometheus , AWS Managed Prometheus ) , an RFE should be summitted to CheckPoint, so we can work with you together to clear the required gaps. Of course, as we adopt the open source tools used externally - I believe the differences are neglectable.

Thanks, Elad.

[Sven_Glock]

Please update this link, it is leading to an dead end, thank you!

[Arik_Ovtracht]

Thanks for notifying me - the link was updated: https://sc1.checkpoint.com/documents/Appliances/Skyline/Content/Topics-Skyline-Metrics/Introduction....