Changes to the Save to Index Alert Type for Scheduled Searches (Alerts)

What's changing

For scheduled searches using the Save to Index alert type, Sumo Logic has made the following related changes:

• The Message (_raw) field will be empty. Previously, for aggregate queries (for example, ... | timeslice 1m | count by batch, parsedfield), the Message (_raw) field was populated with a synthesized, comma-separated string of the row's values (for example, Count=1,batch=3,parsedfield=testlog_HwMoOdtQ00), in addition to the individual named fields.
  Going forward, the _raw field will be empty for these results. No data is lost, and every value remains fully available in its own named field (_count, batch, parsedfield, etc.). Only the synthesized message string is no longer generated. Learn more.
• The 512-result limit is being removed. Previously, no more than 512 results could be saved to a view each time a scheduled search ran. That cap no longer applies and a scheduled search can now save every result it returns on each run.

note

These changes are rolling out to a limited set of accounts and are not yet generally available.

Who is affected

This affects you if you're running scheduled searches with an aggregate query and the Save to Index alert type, saving results to a view (typically a ScheduledSearchView, created when you type a new view name rather than selecting an existing one).

• For the _raw change, you're affected if any search queries or other content reading that view does one of the following:
  • Pulls values out of _raw using parse (or similar).
  • Searches for plain text/keywords that only exist in the message body, not in a named field.
  • Shows or reads the Message column to get field values.
    If your queries already use the named fields directly, you don't need to make any changes for this part.
• For the 512-result limit change, you likely don't need to do anything. It's only worth reviewing if you're concerned about increased data volume. For example, if your scheduled search runs frequently (such as every 15 minutes) and doesn't already cap its results with a limit operator or similar. Without the previous cap, a run like that can now save more results, and more data, than it did before.

What you need to do

• For the _raw change, review your scheduled searches and any downstream content that reads from Save to Index views for reliance on _raw/Message. Update those queries to reference the named fields directly instead of parsing them from the message body. If you're unsure whether a query depends on _raw, check for parse operators run against _raw, or keyword terms in the source expression that aren't tied to a specific field name.
• For the 512-result limit change, no action is required. If you'd rather bound the amount of data a scheduled search saves per run, add a limit operator (or otherwise bound the result set) to that query. Otherwise, keep an eye on your data volume after rollout, since more results may now be saved per run than before.

Contact Sumo Logic Support if you need help identifying or updating affected queries.