v0.7.1

Fix

• Sparse customMetrics no longer GC'd: gauges now stay registered as long as at least one SearchRule declares them, regardless of whether the latest sync emitted any samples. Fixes searchrule_akamai_waf_blocked_by_host (and any other low-cardinality / quiet-period metric) disappearing from /metrics after ~5 minutes without buckets.

Full Changelog: v0.7.0...v0.7.1

v0.7.0

What's new

spec.customMetrics — expose aggregation buckets as Prometheus gauges

Until v0.6.1 the only metric the operator exposed per SearchRule was searchrule_value, a single float carrying the resolved conditionField. That works when the value already represents the whole rule, but it loses information when the underlying query is a terms aggregation reduced to a scalar via max_bucket or similar — the auto-generated PrometheusRule fired without any clue about which bucket caused the firing.

spec.customMetrics lets the operator emit one Prometheus sample per bucket of the response, with labels mapped from the bucket fields:

spec:
  # …queryConnectorRef, checkInterval, elasticsearch, condition unchanged…

  customMetrics:
    - name: akamai_5xx_by_host          # exposes searchrule_akamai_5xx_by_host
      help: "Akamai 5xx percentage by host (last 5m)"
      aggregation_map: by_domain.buckets   # relative to the response's `aggregations` block
      labels:
        - { name: host, value: key }
      value: error_percentage.value      # defaults to `doc_count`

  prometheusRule:
    enabled: true
    alertName: Akamai5xxByHostHighRate
    # metricName: akamai_5xx_by_host    # optional selector when several customMetrics
    labels:
      severity: critical
    annotations:
      description: "Host {{ $labels.host }} at {{ $value | humanizePercentage }} 5xx"

What ends up published

searchrule_akamai_5xx_by_host{searchrule_namespace="searchruler",rule="…",host="cp.freepik.com"} 22.43
searchrule_akamai_5xx_by_host{searchrule_namespace="searchruler",rule="…",host="www.freepik.com"} 0.40

The auto-generated PrometheusRule's expr becomes searchrule_akamai_5xx_by_host{searchrule_namespace="…",rule="…"} > 5. Because the metric carries host as a label, Prometheus emits one alert per bucket above threshold, and Alertmanager receives Akamai5xxByHostHighRate{host="cp.freepik.com",…} with the dimension as a first-class label.

Hardening

• Series tracking with end-of-tick diff and DeleteLabelValues on orphans, applied to the legacy gauges too — fixes a long-standing bug where deleted SearchRules left stale searchrule_value series forever.
• Bucket count capped at 1000 per refresh; truncations observable through searchrule_custom_metrics_truncated_total{searchrule_namespace,rule,metric}.
• GaugeVec garbage collection: a metric that publishes zero samples for ~5 min is unregistered so the /metrics endpoint does not advertise stale series indefinitely.
• Custom metric / label names go through validation against the Prometheus identifier grammar, the operator's reserved gauges/labels, and duplicate label names. Failures surface as PrometheusRule.CustomMetricsInvalid in status.conditions; the rest of the reconcile keeps running so the actionRef pipeline and any previously-created PrometheusRule cleanup are not blocked.
• pools.RulesStore.Snapshot() plus value-copy semantics on Get/Set close the torn-read race on the new Aggregations interface{} field.
• prometheusRule.metricName selector picks one entry when several customMetrics are declared. A typo surfaces as PrometheusRule.MetricNameMismatch; the worse PrometheusRule.MetricsNotExposed condition takes precedence when both apply, and the mismatch detail is appended to its message.

Backwards-compat

SearchRules without customMetrics behave exactly as before. The legacy PromQL path on searchrule_value is preserved and the chart consumers do not need to add anything to keep their existing alerts.

Chart

Chart and appVersion bumped to 0.7.0. Helm chart consumers can helm upgrade over 0.6.x without manual steps (the CRD ships through templates/crds/ already since v0.6.0).

Full PR: #20.

searchruler-helm-chart-0.7.1

A Helm chart for SearchRuler, a ruler Engine that allows you to create and manage rules for your search engine.

searchruler-helm-chart-0.7.0

A Helm chart for SearchRuler, a ruler Engine that allows you to create and manage rules for your search engine.

v0.6.1

Patch release

Fixes a release-pipeline bug introduced in v0.6.0 that left
ghcr.io/freepik-company/searchruler:v0.6.0 missing from the registry.

• Dockerfile: bumped builder from golang:1.24.2 to golang:1.25.0. The go.mod directive was raised to 1.25.0 when prometheus-operator/pkg/apis/monitoring/v1 was added in v0.6.0 (k8s.io/api v0.31.2 transitive deps require it), so cross-builds inside buildx failed at go mod download with go.mod requires go >= 1.25.0.
• Makefile: removed the leading hyphen from the buildx build --push line in the docker-buildx target. Make was treating the failure as Error 1 (ignored) and continuing, so the workflow exited 0 even though no image was pushed.
• Chart and image versions bumped to 0.6.1.

No functional changes vs. v0.6.0; same spec.prometheusRule feature, same Helm chart layout, same searchrule_namespace metric label. Use this release in place of v0.6.0.

v0.6.0

What's new

Features

• Auto-generate PrometheusRule from SearchRule (#18) — new optional spec.prometheusRule field that materializes a monitoring.coreos.com/v1 PrometheusRule mirroring the SearchRule's condition. Lets users with a Prometheus + Alertmanager stack route alerts without configuring a separate RulerAction. The generated resource is owned by the SearchRule (auto-GC), uses PromQL derived from the existing searchrule_value metric, and supports custom alertName, labels, and annotations.

spec:
  prometheusRule:
    enabled: true
    alertName: HighErrorRate          # optional
    labels:
      severity: warning
    annotations:
      runbook_url: "https://..."

• actionRef is now optional: a SearchRule can ship with only spec.prometheusRule.enabled: true. Existing manifests continue working unchanged. At least one of actionRef or prometheusRule must be set; otherwise the SearchRule is rejected with a MissingOutput condition.

Helm chart

• CRDs moved from charts/searchruler/crds/ to charts/searchruler/templates/crds/ (toggle: crds.install, default true). This makes helm upgrade update the CRDs — Helm never updated CRDs in the legacy crds/ directory.
• A helm.sh/resource-policy: keep annotation is applied by default (toggle: crds.keep) so helm uninstall does not cascade-delete user data (SearchRule, QueryConnector, etc.).
• New make helm-sync-crds target keeps the chart in sync with config/crd/bases/ after a make manifests run.

⚠️ Existing chart users must adopt the CRDs into the Helm release before the first upgrade, otherwise it fails with Error: rendered manifests contain a resource that already exists:

RELEASE=searchruler
NS=searchruler-system
for crd in clusterqueryconnectors clusterruleractions queryconnectors ruleractions searchrules; do
  kubectl annotate crd "$crd.searchruler.freepik.com" \
    meta.helm.sh/release-name="$RELEASE" \
    meta.helm.sh/release-namespace="$NS" --overwrite
  kubectl label crd "$crd.searchruler.freepik.com" \
    app.kubernetes.io/managed-by=Helm --overwrite
done

Metrics

• New label searchrule_namespace on searchrule_value and searchrule_state, so SearchRules with the same name in different namespaces remain distinguishable. The label is intentionally not called namespace to avoid colliding with the target label Prometheus injects when scraping via ServiceMonitor.

Capability detection

The operator detects at startup whether the monitoring.coreos.com/v1 PrometheusRule CRD is installed and whether --rules-metrics-bind-address is set. SearchRules that opt into prometheusRule get explicit status.conditions:

Condition	Meaning
PrometheusRule.Synced	Resource created and metric is exposed
PrometheusRule.Unsupported	CRD not installed at startup; install it and restart the operator
PrometheusRule.MetricsNotExposed	PrometheusRule created but --rules-metrics-bind-address=0
PrometheusRule.PrometheusRuleError	API error or name conflict (e.g. existing PrometheusRule not owned by this SearchRule)

Safety

• The operator never adopts or deletes a PrometheusRule it does not own (verified via controller OwnerReference).
• condition.threshold is parsed and re-rendered as a float before being interpolated into PromQL, preventing accidental or malicious injection.
• actionRef and prometheusRule outputs are independent — a transient PrometheusRule API error no longer blocks the actionRef path.

searchruler-helm-chart-0.6.1

A Helm chart for SearchRuler, a ruler Engine that allows you to create and manage rules for your search engine.

searchruler-helm-chart-0.6.0

A Helm chart for SearchRuler, a ruler Engine that allows you to create and manage rules for your search engine.

v0.5.2

Fix

• Fixed elasticsearch connection pooling

Contributors

@dfradehubs

v0.5.1

🆕 SearchRuler v0.5.1

This release brings key improvements to alerting, a cleaner codebase, and updated documentation.

✅ Highlights

• Added mode, labels, and annotations to ActionRef, supporting both raw and alertmanager modes.
• Removed customMetrics to simplify the CRD and codebase.
• Updated README with mode examples and removed outdated sections.
• Bumped Helm chart version to 0.5.1.
• Sample manifest now includes mode: raw by default.

Contributors

@dfradehubs