Monitoring & Observability
Observability guidance for CARTO Self-Hosted — what to monitor, alert on, and how to integrate with your monitoring stack
This page covers proactive observability for your CARTO Self-Hosted deployment: what signals matter, recommended alerting thresholds, and how to integrate with your monitoring stack.
CARTO Self-Hosted does not ship a bundled monitoring or observability stack. CARTO services emit structured logs (JSON) to stdout/stderr and run as standard Kubernetes workloads, so they integrate with whatever logging, metrics, and alerting tooling you already operate. Collecting those logs and metrics and configuring dashboards and alerting at the infrastructure level is your responsibility — this page describes what to monitor and how to wire it into your stack.
For reactive debugging (checking pod status, enabling debug logs, or collecting a support bundle), see:
Key signals to monitor
CARTO Self-Hosted is a Kubernetes-based platform. The following signals are the most actionable for detecting and diagnosing issues before they affect users.
Recommended alerts
Pod restart count
> 2 restarts in 10 min
OOM, crash loop, failed probe
Check kubectl logs for the affected pod
PostgreSQL CPU
> 80% sustained
Query load, missing indexes
Tune connection pool or scale the DB instance
PostgreSQL storage
> 80% used
Log growth, unvacuumed tables
Scale storage or enable auto-grow
Valkey memory
> 85% of maxmemory
Cache eviction pressure
Increase Valkey memory or review cache policy
API error rate
> 1% of requests
App error, bad config, downstream failure
Check maps-api and workspace-api logs
Node disk usage
> 80%
Image accumulation, log growth
Clean unused images or expand disk
Pod health quick check
A healthy deployment shows all pods in Running state with low restart counts.
Integrating with your monitoring stack
Use your cloud provider's native monitoring or a third-party observability stack to collect and route the alerts above.
Use Cloud Monitoring with GKE system metrics enabled on your cluster. Key resources:
Enable Managed Prometheus for Kubernetes workload metrics
Recommended dashboards: GKE cluster health, PostgreSQL (Cloud SQL), Memorystore.
Use Amazon CloudWatch Container Insights for EKS clusters. Key resources:
Use CloudWatch Logs for pod log aggregation
Recommended dashboards: EKS cluster, RDS PostgreSQL, ElastiCache.
Use Azure Monitor with Container Insights for AKS. Key resources:
Use Log Analytics for log aggregation and alerts
Recommended dashboards: AKS cluster, Azure Database for PostgreSQL, Azure Cache for Redis.
CARTO Self-Hosted pods expose standard Kubernetes metrics. Use the kube-prometheus-stack Helm chart for a full Prometheus + Grafana + Alertmanager setup.
Configure ServiceMonitor resources to scrape CARTO pods, and set up alerting rules for the thresholds in the table above.
Log aggregation
CARTO services write structured logs to stdout/stderr, which Kubernetes captures per pod. Aggregate them with:
GCP: Cloud Logging (automatic with GKE)
AWS: CloudWatch Logs via Container Insights or Fluent Bit
Azure: Log Analytics via Container Insights
Self-managed: Loki + Grafana, ELK stack, or Datadog
For collecting logs from a specific pod or generating a support bundle, see Debug mode and logs.
Last updated
Was this helpful?