Coordimap
Configuration

Metric Trigger Rules

Configure the Coordimap agent to evaluate metric rules and send metric-trigger elements to the backend for Kubernetes and GCP.

The Coordimap agent can evaluate metric rules directly and send metric-trigger elements to the backend. These are sent as regular elements with the type coordimap.metric_trigger and include all matching internal IDs in the element payload, automatically relating alerts to your infrastructure graph.

Metric rules are configured inside each datasource block under data_sources[*].metric_rules.

Currently, metric rules are supported only for the following datasource types:

  • kubernetes
  • gcp

Supported Providers

  • Prometheus: For Kubernetes data sources.
  • GCP Monitoring: For Google Cloud Platform (GCP) data sources.

Configuration Format

Each rule must specify a mode, which can be either:

  • custom: For user-defined provider queries.
  • predefined: For built-in templates.

Example Configuration

coordimap:
  data_sources:
    - type: kubernetes
      id: kube-prod
      config:
        - name: scope_id
          value: your-cluster-uid
        - name: config_file
          value: /path/to/your/kube/config
      metric_rules:
        # Example of a custom Prometheus query
        - id: k8s-high-5xx
          name: Kubernetes Service High 5xx
          provider: prometheus
          mode: custom
          custom:
            query: sum(rate(istio_requests_total{response_code=~"5.."}[5m])) by (destination_workload_namespace, destination_canonical_service)
          lookback: 5m
          threshold:
            operator: ">"
            value: 1
          target:
            resolver: kubernetes_service
            namespace_label: destination_workload_namespace
            name_label: destination_canonical_service

    - type: gcp
      id: gcp-prod
      config:
        - name: scope_id
          value: "123456789012"
        - name: project_id
          value: your-project-id
      metric_rules:
        # Example of a predefined GCP Monitoring template
        - id: cloudsql-high-cpu
          name: CloudSQL High CPU
          provider: gcp_monitoring
          mode: predefined
          predefined:
            name: cloudsql_high_cpu
            params:
              lookback: 5m
              threshold: 0.8

Field Reference

Common Fields

All metric rules share these fields:

  • id: A unique identifier for this rule.
  • name: A human-readable name for the trigger.
  • provider: The monitoring backend (prometheus or gcp_monitoring).
  • lookback: The time window to evaluate (e.g., 5m).
  • threshold.operator and threshold.value: Conditions for triggering the rule (e.g., > and 1).
  • target.resolver: The asset type this rule applies to.

Prometheus-specific Fields

When using mode: custom with the prometheus provider, you must specify:

  • custom.query: The PromQL query to evaluate.

GCP Monitoring-specific Fields

When using mode: custom with the gcp_monitoring provider, you must specify:

  • custom.filter or custom.metric_type: To select the correct GCP metric.
  • Optional fields: alignment_period, per_series_aligner, cross_series_reducer, and group_by_fields to control aggregation.

Predefined Rules

Predefined rules allow you to use built-in templates without writing custom queries.

Prometheus Templates

  • kubernetes_service_high_5xx (Params: window, threshold)
  • kubernetes_deployment_high_5xx (Params: window, threshold)
  • kubernetes_service_high_latency (Params: window, quantile, threshold)
  • kubernetes_pod_high_restart_rate (Params: window, threshold)
  • kubernetes_pod_crashloop_or_imagepull_error (Params: lookback, reason_regex)
  • kubernetes_pod_not_ready (Params: lookback)
  • kubernetes_deployment_unavailable_replicas (Params: threshold)
  • kubernetes_deployment_availability_gap (Params: threshold)
  • kubernetes_pod_high_cpu_usage (Params: window, threshold)
  • kubernetes_pod_high_memory_workingset (Params: threshold)
  • kubernetes_pod_cpu_throttling_high (Params: window, threshold)
  • kubernetes_pod_oom_events (Params: window)
  • kubernetes_pod_unschedulable (Params: lookback)
  • kubernetes_pvc_low_free_space (Params: threshold, namespace, pvc_regex)
  • kubernetes_pvc_free_space_burn_rate (Params: threshold, window, horizon_seconds, namespace, pvc_regex)
  • kubernetes_inode_low_free (Params: threshold, namespace, pvc_regex)
  • kubernetes_statefulset_pvc_low_free_space (Params: threshold, namespace, statefulset, volume_claim_prefix)

GCP Monitoring Templates

  • cloudsql_high_cpu (Params: lookback, threshold)
  • cloudsql_high_connections (Params: lookback, threshold, metric_type, alignment_period, per_series_aligner)
  • vm_high_cpu (Params: lookback, threshold, alignment_period, per_series_aligner)

Target Resolvers

The target.resolver field maps the results of a metric query to specific asset identities within the Coordimap graph.

Available resolvers include:

  • Kubernetes: kubernetes_service, kubernetes_deployment, kubernetes_pod, kubernetes_pvc, kubernetes_statefulset
  • GCP: gcp_cloudsql, gcp_vm_instance
  • Cross data source: external_mapping

When using the external_mapping resolver, if no external_mappings entry matches the emitted target, the target is ignored and nothing is sent for that series.

Source References

FAQ

Which data sources support metric trigger rules?

Metric trigger rules are currently documented for Kubernetes and GCP data sources.

Which providers can metric rules use?

Kubernetes rules can use Prometheus. GCP rules can use GCP Monitoring.

What happens if an external_mapping target cannot be resolved?

If no matching external_mappings entry exists, the target is ignored and no metric-trigger element is emitted for that series.

On this page