Event Validator for New Relic

The Metrics Validator's question, asked of everything that is not a log, a metric or a trace: which of an account's event types an alert condition, a dashboard widget or a person actually asks for, and what the rest costs a month. Then the same question one level down, for the attributes inside the largest types, because a drop rule can remove an attribute and keep the event.

What it counts

Every event type with data in the last day: APM transactions, mobile and browser events, infrastructure samples, an account's own custom events and New Relic's own account types such as the query log and consumption. Logs, metrics and traces have their own validators and are left out. New Relic's own Nr types are counted and shown, and never offered for dropping. A type too large to read for a whole day is measured over a slice of it and scaled up, and the row says so.

Risk of dropping

Every event type is rated from what asks for it and who queried it.

• In use. A dashboard or a live alert condition in the account asks for it, or ten or more people queried it in the last 30 days. Not offered for dropping.
• Medium risk. No dashboard or alert asks for it, but fewer than ten people queried it. Those people are named, with how often and from where.
• Low risk. Nothing in the account asks for it and nobody queried it. A Drop data rule is offered, one per type, because a rule reads one table.
• Disabled conditions only. The only thing that asks for it is an alert condition that is switched off. No rule is offered.
• New Relic's own. Counted and never dropped.

Attributes

For the largest types the screen lists every attribute with an estimated share of the type's size. New Relic cannot size one attribute, so each share is worked out from how often the attribute is present and how long its values are, then scaled to the size measured for the whole type. It is a good guide to where the weight is, not a billed figure. An attribute is read when a dashboard, an alert condition or a query in the last 14 days names it. The rest are offered as a Drop attributes rule, one per type, which removes them and keeps the event. A type that a dashboard or an alert condition reads whole with SELECT * is marked cannot verify: nothing can be called unread, and only its prefix fragments are offered. People running SELECT * to look at a type is weaker evidence, because that is how a type gets looked at. Those types are marked run by people, and their attribute rules are medium risk, to be checked with the people who explore the type.

Prefix fragments

Some types carry runs of attributes where each name is the front of the next: c, ch, cha, chan and so on to channel. That is the shape an SDK leaves when it writes a new attribute for every prefix of a name it is building. Nothing reads them, and every one is repeated on every record. They are listed on their own with what they cost. The real fix is in the SDK that sends the event; a rule only stops paying for the damage.

The nightly job

Configured under Admin, Event validator config, with its accounts in the Events analysis column of the table under Cache scheduler. The Aurora Retail Prod, Digital Non-Production and Digital Performance Test accounts are chosen to start with, because that is where the event ingest is. It runs at 8am in the application's time zone, an hour after the drop rule test, and shares the one-job-at-a-time rule with the other cache jobs. Reading a month of the query log and every dashboard in an account takes minutes, so Validate now is an admin's.