Tag Rules

Back to Settings Help
Tag rules are evaluated at ingest time. Matching records automatically receive the configured tag, stored in sobs_record_tags for use in filtering and anomaly correlation. Tags follow OTEL attribute conventions: key=value pairs with one effective value per key per record.

Generate baseline tag rules from recent logs, traces, errors, AI spans, and RUM events. Existing rules are skipped automatically. Create is capped at 200 rules per run.

Create Tag Rule
Leave all unchecked or check all to match every record type.
For composite rules add multiple conditions — all must match for the tag to be applied.
No tag rules yet. Use the form above to create your first rule.
How Auto-Tagging Works

When a new record is ingested (log, trace span, error, AI call, or RUM event), all active tag rules are evaluated against it. Each matching rule writes a tag row into sobs_record_tags with IsAuto=1.

If multiple rules match the same tag_key for one record, the last matching rule wins for that key (deterministic evaluation order).

Composite rules contain multiple conditions that must all match for the tag to be applied (AND logic). For example, you can require both severity = ERROR and service_name contains payment to apply the tag tier=critical. Simple (single-condition) rules continue to work as before.

  • service_name — matches against the record's service name.
  • severity — matches against the log severity level (e.g. ERROR, WARN).
  • body — matches against the log body or span name text.
  • span_name — matches against the OTEL span name (trace records only).
  • event_type — matches against the event/log type name.
  • attribute — matches against a specific OTEL attribute key's value.

You can also add tags manually to individual records via the POST /api/tags/<type>/<record_id> API. Record IDs are MD5 hashes of key fields and are shown in the record detail views.

Deleting via DELETE /api/tags/<type>/<record_id>/<tag_key> removes all active values for that key on the record.

Best practice: keep tag keys low-cardinality and bounded (for example env, tier, team). Avoid highly dynamic values like request IDs or user IDs as tag values.