-
[NA] [BE/FE] feat: guardrails improvements — CPU image, dashboard breakdown, alert type filter (#7506)
frostbyte_neo 发布于
2026-07-23 14:58:55 +00:00 - [NA] [BE] feat: add CPU guardrails image and --guardrails-cpu deploy mode
Split the guardrails backend into a GPU Dockerfile (unchanged, NVIDIA CUDA
base) and a new CPU Dockerfile.cpu (slim, multi-arch, no GPU/NVIDIA toolkit),
so the service builds and runs on CPU-only and arm64 hosts.Docker Compose now supports both modes: guardrails-backend (GPU, with an
NVIDIA device reservation) under the guardrails profile, and a new
guardrails-backend-cpu service under the guardrails-cpu profile. opik.sh
gains a --guardrails-cpu flag alongside --guardrails.Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
- feat(metrics): add group-by-guardrail-name breakdown to failed guardrails chart
Add a GUARDRAIL_NAME breakdown field, compatible only with the existing
GUARDRAILS_FAILED_COUNT metric, so the "Failed guardrails" chart can be
grouped into one series per guardrail name (PII, Topic, ...). The trace-scoped
breakdown query already joins the guardrails table, so grouping maps to
ifNull(g.name, 'Unknown') with no query changes.Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
- feat(alerts): filter guardrail alerts by guardrail type
Add a filter:guardrail_type trigger config to the guardrails alert so an
alert can target specific guardrail types (PII, Topic) instead of firing on
any failure. Empty selection preserves the current "fire on any type" behavior.Backend: new AlertTriggerConfigType.FILTER_GUARDRAIL_TYPE + config-type enum
migration; AlertEventEvaluationService matches the failed-guardrail payload
against the configured types (OR; empty = all).
Frontend (v2): guardrail-type multiselect on the guardrails trigger, wired
through the form/payload mapping and schema.Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
- feat(guardrails): auto-detect GPU/CPU for --guardrails and add dev-runner support
opik.sh: --guardrails now auto-detects an NVIDIA GPU via nvidia-smi and uses the
GPU image when present, otherwise the CPU image. --guardrails-cpu still forces CPU.dev-runner.sh: add --guardrails and --guardrails-cpu modifier flags (previously
no guardrails support). Detection is delegated to opik.sh; dev-runner forwards the
flag to every opik.sh call and prints the OPIK_GUARDRAILS_URL_OVERRIDE for the
directly-published :5000 endpoint.Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
- fix(guardrails): restore default --guardrails behavior (no GPU requirement)
The nvidia device reservation and nvidia-smi auto-detection changed how
./opik.sh --guardrailsbehaves: it began requiring a GPU (device reservation)
or switching to a CPU source-build (auto-detect), which broke the E2E CI flow
that runs./opik.sh --backend --port-mapping --guardrailson GPU-less runners.Restore the original behavior: --guardrails runs the published GPU-capable image
on CPU fallback (works everywhere, as before). --guardrails-cpu remains the
explicit slim CPU-only image. dev-runner keeps both flags as simple forwards.Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
- fix(guardrails): address PR review comments
- alerts (BE): evaluate the guardrail-type filter per trigger with anyMatch,
so an unfiltered TRACE_GUARDRAILS_TRIGGERED trigger is no longer narrowed by a
sibling filtered trigger; fail open on unexpected payload shape - alerts (FE): collect every filter:guardrail_type config (dedup via Set) instead
of reading only the first, matching the BE OR semantics on reopen/save - metrics (test): assert the GUARDRAIL_NAME breakdown returns exactly {TOPIC, PII}
with deterministic fixture data instead of per-item membership - migration 000090: forward-only rollback note (enum value cannot be reverted once
rows use it), consistent with 000033/000035 - opik.sh: centralize GUARDRAILS_MODE -> profile/flag/container mapping in helpers
- dev-runner.sh: derive the guardrails URL hint from OPIK_GUARDRAILS_PORT
- sdk: log guardrail results to the trace's project so project-scoped reads
(traces list) match them
Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
- feat(guardrails): always enable guardrails FE features
The guardrails traces column and alert triggers only read already-logged
guardrail data — they don't require the guardrails validation service to be
deployed. Force GUARDRAILS_ENABLED on in the FE regardless of the backend
feature-toggle config so the features are available in every deployment.Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
- fix(guardrails): entrypoint exec bit for non-root user + migration trailing newline
Address PR #7506 review:
- Dockerfile.cpu: chmod 755 (not u+x) so entrypoint.sh stays executable for
USER 1001:1001 (it is mode 644 in git); u+x only granted execute to the
root owner. - migration 000090: end file with a trailing blank line per the convention
in 000035.
Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
- fix(migration): renumber guardrail_type migration 000090 -> 000091
main merged 000090_add_trigger_scope_to_automation_rules, colliding with this
PR's 000090 and failing the migration-prefix CI check. Renumber to 000091
(next free prefix) and sync the changeset id.Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
- fix(test): use time-ordered secondary id for guardrail batch in PR tests
main tightened GuardrailsService to validateIdNotInFuture on the guardrail
secondaryId (span id). The PR's new tests passed UUID.randomUUID() (v4) there,
which the merged-with-main build now rejects with 400. Use
idGenerator.generateId() (v7, time-ordered) to match main's guardrail tests.Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
Co-authored-by: Claude Opus 4.8 (1M context) noreply@anthropic.com
下载附件