Settings and activity
7 results found
-
10 votes
Paweł Bołdyn supported this idea ·
-
5 votes
Paweł Bołdyn supported this idea ·
-
4 votes
Paweł Bołdyn supported this idea ·
-
4 votes
Paweł Bołdyn supported this idea ·
-
10 votes
Paweł Bołdyn supported this idea ·
-
13 votes
Paweł Bołdyn supported this idea ·
-
2 votes
An error occurred while saving the comment Paweł Bołdyn supported this idea ·
Hi,
From an engineering standpoint, having native GCP sensors aligned with Azure functionality would significantly improve consistency and observability across multi-cloud environments.
Specifically, it would be valuable to have first-class sensors for:
Compute Engine – instance state, CPU utilization, disk I/O, network throughput
Cloud Monitoring (Stackdriver) – direct consumption of metrics and alert policies
GKE – node/pod health, cluster state, resource utilization
Cloud SQL – performance metrics, connections, replication status
Load Balancing – backend health, latency, request rates
IAM / quotas / billing – visibility into limits, usage, and cost metrics
Key technical expectations would include:
Native integration with GCP APIs (with proper authentication via service accounts / IAM roles)
Standardized sensor structure similar to Azure sensors (to ensure consistency in dashboards and alerts)
Support for tagging/label-based filtering (common in GCP resource organization)
Efficient polling and rate-limit awareness
Ability to map GCP metrics directly into PRTG channels without custom parsing
Without this, teams operating in GCP are forced to rely on less scalable and harder-to-maintain custom solutions, which reduces the overall effectiveness of PRTG as a unified monitoring platform.
This feature would close a significant gap in multi-cloud monitoring capabilities.