R82 ClusterXL - Skyline: context deadline exceeded

[Peter_Gastinger]

Hi, 

After spending a few days with this issue, I need help. I have a R82 clusterxl active-standby cluster and want to send metrics via skyline to a Prometheus remote write container in an Azure container app (with a publicly trusted certificate)

/opt/CPotelcol/CPotelcolCli.sh set_dynamic_config "$(cat /opt/CPotelcol/config.json)"
sklnctl export --set '{
"enabled": true,
"debug": true,
"export-targets": {"add": [
{
"enabled": true,
"type": "prometheus-remote-write",
"url": "https://ugly_containerapp_url.westeurope.azurecontainerapps.io/api/v1/write"
}
]}
}'

I have a fw monitor running for the destination, but I do not see any outgoing packets. I basically only see these messages:

otelcol.log.4:2026-07-02T06:35:02.753+0200 error internal/queue_sender.go:103 Exporting failed. Dropping data. {"kind": "exporter", "data_type": "metrics", "name": "prometheusremotewrite", "error": "Permanent error: Permanent error: context deadline exceeded", "dropped_items": 288}
otelcol.log.4:2026-07-02T06:35:13.878+0200 error internal/queue_sender.go:103 Exporting failed. Dropping data. {"kind": "exporter", "data_type": "metrics", "name": "prometheusremotewrite", "error": "Permanent error: Permanent error: context deadline exceeded", "dropped_items": 386}
otelcol.log.4:2026-07-02T06:35:20.160+0200 error internal/queue_sender.go:103 Exporting failed. Dropping data. {"kind": "exporter", "data_type": "metrics", "name": "prometheusremotewrite", "error": "Permanent error: Permanent error: context deadline exceeded", "dropped_items": 223}

There is definitely connectivity, a curl_cli works. 

In a setup with a single R82 node (same vnet and subnets) it works exactly like that, so I know that the prometheus container works. So far there is no obvious difference between those two. 

Any idea? 

Proven so far:

• Same remote_write target
• Same Skyline JSON
• Same generated exporter configuration
• Same CA bundle contents (ca-bundle.crt)
• Same certificate validation behavior with curl_cli
• R82 single gateway works
• R82 clusterxl does not

Thanks!

regards, 
Peter

cpinfo -y all

This is Check Point CPinfo Build 914000274 for GAIA
[CPshared]
        HOTFIX_R82_JUMBO_HF_MAIN        Take:  107
[IDA]
        No hotfixes..
[CPFC]
        No hotfixes..
[MGMT]
        HOTFIX_R82_JUMBO_HF_MAIN        Take:  107
[FW1]
        HOTFIX_UCA_SSH_TUNNELING_SERVICE_AUTOUPDATE
        HOTFIX_UCA_SSH_TUNNELING_APP_AUTOUPDATE
        HOTFIX_UCA_INFRA_MONITOR_SERVICE_AUTOUPDATE
        HOTFIX_UCA_INFRA_LOG_SERVICE_AUTOUPDATE
        HOTFIX_UCA_INFRA_AUTOUPDATE
        HOTFIX_R80_40_MAAS_TUNNEL_AUTOUPDATE
        HOTFIX_GOT_TPCONF_AUTOUPDATE
        HOTFIX_R82_JUMBO_HF_MAIN        Take:  107
        HOTFIX_PUBLIC_CLOUD_CA_BUNDLE_AUTOUPDATE
        HOTFIX_INEXT_NANO_EGG_AUTOUPDATE

FW1 build number:
This is Check Point's software version R82 - Build 026
kernel: R82 - Build 024
[SecurePlatform]
        HOTFIX_R82_JUMBO_HF_MAIN        Take:  107
[PPACK]
        HOTFIX_R82_JUMBO_HF_MAIN        Take:  107
[CPinfo]
        No hotfixes..
[AutoUpdater]
        HOTFIX_INFRA_CONFIG_AUTOUPDATE
[DIAG]
        No hotfixes..
[CVPN]
        HOTFIX_ESOD_CSHELL_AUTOUPDATE
        HOTFIX_R82_JUMBO_HF_MAIN        Take:  107
[CPUpdates]
        BUNDLE_INFRA_AUTOUPDATE Take:  90
        BUNDLE_DEP_INSTALLER_AUTOUPDATE Take:  31
        BUNDLE_UCA_SSH_TUNNELING_SERVICE_AUTOUPDATE     Take:  32
        BUNDLE_UCA_SSH_TUNNELING_APP_AUTOUPDATE Take:  32
        BUNDLE_UCA_INFRA_MONITOR_SERVICE_AUTOUPDATE     Take:  29
        BUNDLE_UCA_INFRA_LOG_SERVICE_AUTOUPDATE Take:  23
        BUNDLE_UCA_INFRA_AUTOUPDATE     Take:  56
        BUNDLE_CORE_FILE_UPLOADER_AUTOUPDATE    Take:  23
        BUNDLE_R80_40_MAAS_TUNNEL_AUTOUPDATE    Take:  75
        BUNDLE_GOT_TPCONF_AUTOUPDATE    Take:  158
        BUNDLE_ESOD_CSHELL_AUTOUPDATE   Take:  20
        BUNDLE_R82_JUMBO_HF_MAIN        Take:  107
        BUNDLE_INFRA_CONFIG_AUTOUPDATE  Take:  21
        BUNDLE_PUBLIC_CLOUD_CA_BUNDLE_AUTOUPDATE        Take:  21
        BUNDLE_INEXT_NANO_EGG_AUTOUPDATE        Take:  41
        BUNDLE_HCP_AUTOUPDATE   Take:  93
        BUNDLE_CPVIEWEXPORTER_AUTOUPDATE        Take:  88
        BUNDLE_QUID_AUTOUPDATE  Take:  59
        BUNDLE_CPSDC_AUTOUPDATE Take:  43
        BUNDLE_CPOTLPAGENT_AUTOUPDATE   Take:  141
        BUNDLE_CPOTELCOL_AUTOUPDATE     Take:  223
[CPotelcol]
        HOTFIX_OTLP_GA
[CPotlpAgent]
        HOTFIX_OTLP_GA
[cpsdc_wrapper]
        HOTFIX_CPSDC_AUTOUPDATE
[CPquid]
        HOTFIX_QUID_AUTOUPDATE
[CPviewExporter]
        HOTFIX_OTLP_GA
[hcp_wrapper]
        HOTFIX_HCP_AUTOUPDATE
[CPDepInst]
        No hotfixes..
[core_uploader]
        HOTFIX_CHARON_HF

[Peter_Gastinger · Accepted solution]

seems to be solved by sk184347 - Skyline Monitoring does not display some Gateways after applying Open Telemetry Collector...

[JozkoMrkvicka]

Yes, the update of CPotelcol from Take 210 to Take 223 is the root cause. The SK is wrong in regards to which Take is affected. It is Take 223 which is faulty, not Take 210.

You should revert to Take 210 if you need to use proxy:

autoupdatercli revert CPotelcol

That should cause the revert of CPotelcol from Take 223 (broken) to Take 210 (working).