Rules
Every event a key accepts is stored. A rule decides which of them also becomes a message.
Each destination has one rule. Its default is the one most teams want: event type error only, every project name.
What a rule filters on
Section titled “What a rule filters on”| Condition | Values |
|---|---|
| Event type | Any of info, error, debug, none. The numeric types from the Events page |
| Project name | An exact ProducerOptions.ProjectName, or blank for all of them |
Two examples of why the project name is there. A producer that reports for several logical projects into one cloud project can route each one to its own channel. And a monolith can send checkout alerts to the payments channel and everything else to the general one, from one key, by giving two destinations two rules.
What a rule does not do
Section titled “What a rule does not do”There is no per-field matching, no text search and no rate limit in a rule. Three reasons, in order of how often they come up:
- The event’s own producer is the cheaper place to decide. An event that should never page anyone should not be an
Error. MergeWindowon the producer already collapses a loop into one message with a count, before it ever leaves your process.- A rule that silently drops events is a rule someone will debug at 3 a.m. Keeping it to two conditions keeps it readable.
Filtering never touches the stored batch
Section titled “Filtering never touches the stored batch”A rule builds a new slice for its destination and leaves the batch alone, which is the library’s read-only batch rule applied on the server side. The event you read in the console is the event your service sent, whatever any rule did with it.
Next: limits.