fixes

Author: kimsauce

blog-service/2024/12-31.md

@@ -827,7 +827,7 @@ For information, see [Metrics Explorer](/docs/metrics/metrics-queries/metrics-ex
 
 As part of our ongoing evaluation of the Sumo Logic service, we have decided to deprecate Real-Time Scheduled Searches. In particular, we will remove the option to create new Real-Time Scheduled Searches on May 15, 2024. Existing Real-Time Scheduled Searches will continue to function until May 15, 2025. We believe many use cases for Real-Time Scheduled Searches can be met by [Monitors](/docs/alerts/monitors/overview). Any remaining use cases can be met by executing these searches at 15m intervals.
 
-In 2020, Sumo Logic released Monitors, which provided a new framework to trigger alerts on both metrics and log data in real time and send notifications. Real-Time Scheduled Searches provided a much more limited version of this functionality. Monitors will continue to be the focus area for our Product and Engineering Teams for features and enhancements regarding alerting. Learn more [here](/docs/alerts/scheduled-searches/deprecation).
+In 2020, Sumo Logic released Monitors, which provided a new framework to trigger alerts on both metrics and log data in real time and send notifications. Real-Time Scheduled Searches provided a much more limited version of this functionality. Monitors will continue to be the focus area for our Product and Engineering Teams for features and enhancements regarding alerting.
 
 ### April 26, 2024 (Apps)
 

docs/alerts/difference-from-scheduled-searches.md

@@ -31,7 +31,7 @@ Beyond the differences in use cases, there are distinct feature differences betw
 | Alert disablement | No | Yes*<br/>(Disable is a manual operation. We do not support scheduled disabling of alerts.) |
 | API support | Partial*<br/>(Supported via content sync API) | Yes |
 | Terraform support | Yes<br/>(see [content API resource](https://registry.terraform.io/providers/SumoLogic/sumologic/latest/docs/resources/content)) | Yes |
-| Log Search operator support | Yes*<br/>(Some operators are not supported for real-time alerts) | Yes |
+| Log Search operator support | Yes | Yes |
 | Outlier-based alerts | Yes | Yes |
 | Access control | Object-Level Access Control | Object-Level Access Control (Per request - limited availability) |
 | Audit logs for CRUD and system events (e.g., notifications sent, failures) | Yes | Yes |

docs/alerts/scheduled-searches/faq.md

@@ -128,27 +128,6 @@ Additional consideration for performance tests:
 * If the data you are testing against is not reflective of the actual volume you’ll be scanning on a recurring basis, then the test itself should be considered invalid. Similarly, avoid scheduling searches preemptively. Wait until you get a good sample size and make sure your live streaming is completely set up.
 * If there are plans to add more data to your account in the near future, keep that in mind in your testing and include a buffer to make sure that your increased data volume won’t cause your scheduled search to time out.
 
-
-## How do I set a real-time alert with more than 1,000 results?
-
-Scheduled Search alert condition thresholds are based on the number of rows returned in your search results. It does not consider any values that may be present within a column of those rows.
-
-If your query does not perform any aggregations the Scheduled Search threshold will apply to the number of raw messages returned with a query, as seen under the **Messages** tab of the search. If a query contains an aggregate operation - for example, `count`, `sum`, `min`, `max` - the Scheduled Search threshold will be applied to the number of aggregate rows returned by the query, as seen within the **Aggregate** tab of the results.
-
-When performing an aggregation as part of a query, and wanting to alert when a specific aggregate value meets a threshold, the threshold for that field value will need to be included as part of the query itself. This can typically be done by providing a [`where`](/docs/search/search-query-language/search-operators/where) condition after the aggregation within the query. For example:
-
-```sql
-_sourceCategory=aws/prod
-| json "message","logStream","logGroup"
-| parse field=message "* * * * * * * * * * * * * *" as version,accountID,interfaceID,src_ip,dest_ip,src_port,dest_port,Protocol,Packets,bytes,StartSample,EndSample,Action,status
-| timeslice 1m
-| where action="REJECT"
-| count as drops by _timeslice
-| where drops > 1000
-```
-
-This will ensure results are only returned when the field value meets the threshold provided within the query. The threshold set within the Scheduled Search would then be set to alert based on the resulting number of rows that met the threshold set within the query. For example: `Greater than\> 0`
-
  
 ## Why have I received a "Scheduled Search Email Quota Reached" notification?
 

docs/alerts/scheduled-searches/schedule-search.md

@@ -74,7 +74,7 @@ Under **Send Notification**, select the condition for when you want an alert to
 
 * **Every time a search is complete**. Select this option if you want an email with search results every time the search is run (depending on the frequency, you could get an email every 15 minutes, every hour, or once a day).
 * **If the following condition is met**. Select this option if you'd like to set up a Scheduled Search that alerts you to specific events.
-   * **Number of results.** Depending on the search, set a condition to receive an email by the number of results. If your saved search returns log messages, then the alert will use the number of messages you specify. If your query produces aggregate results, the alert will use the number of rows or aggregates (or groups) and will not trigger on the number of raw results. For more control of your query, you can build in a threshold (for example `| where _count\> 30`) into the Search itself and set the alerts condition here to Greater than 0. That way the query will generate results if the expected condition is met. See this [FAQ](/docs/alerts/scheduled-searches/faq/#how-do-i-set-a-real-time-alert-with-more-than-1000-results) for an example.
+   * **Number of results.** Depending on the search, set a condition to receive an email by the number of results. If your saved search returns log messages, then the alert will use the number of messages you specify. If your query produces aggregate results, the alert will use the number of rows or aggregates (or groups) and will not trigger on the number of raw results. For more control of your query, you can build in a threshold (for example `| where _count\> 30`) into the Search itself and set the alerts condition here to Greater than 0. That way the query will generate results if the expected condition is met.
       * **Equal to.** Choose if there is an exact number of records in a search result at which you want to be notified.
       * **Greater than.** Choose if you want to be notified only if the search results include greater than the number of messages or groups you set in the text box.
       * **Greater than or equal to.** Choose if you want to be notified only if the search results include greater than or equal to that number of messages or groups you set in the text box. For example, to ensure you're notified only when the specific query conditions are met, set the **Number of results** condition to greater than 0.

docs/alerts/webhook-connections/schedule-searches-webhook-connections.md

@@ -31,8 +31,7 @@ To set up a scheduled search for a Webhook Connection:
 1. Select a **Webhook** from the **Connection** list.
    * (Optional) Select the checkbox if you want a **separate alert sent for each search result**. You can set up to a maximum of 100 alerts. Any results that exceed the configured maximum do not generate an alert. For example, if your scheduled search is configured to send a maximum of 50 alerts and generates 60 results only the first 50 results will generate an alert, all subsequent results will not generate an alert.
       :::note
-      - This may generate duplicate alerts for non-real-time schedules. If your search time range is longer than the search frequency (like a window of 60 minutes, but the frequency of 15 minutes) duplicate alerts are sent since there is an overlap of 45 minutes between each search and all results are sent, not just the difference.
-      - If the alert condition is: Number of results equal to 0 and "Send a separate alert for each search result" checkbox is selected, it would not trigger any alerts when the alert threshold matches since there are no results to itemize.
+      If the alert condition is: Number of results equal to 0 and "Send a separate alert for each search result" checkbox is selected, it would not trigger any alerts when the alert threshold matches since there are no results to itemize.
       :::
    * [Webhook payload variables](set-up-webhook-connections.md) will have values generated for each result. For example, a payload defined as:
         ```

docs/dashboards/share-dashboard-outside-org.md

@@ -89,13 +89,6 @@ When someone views a dashboard without signing in, Sumo Logic logs the following
 
 You can use [Scheduled Searches](/docs/alerts/scheduled-searches) to create alerts and reports on sharing dashboards outside your organization.
 
-```sql title="Real-time alert when a user shares a dashboard"
-_index=sumologic_audit and _sourceName=REPORT "Published REPORT"
-| parse "Published REPORT Name=*, UserName=* UserEmail=*} PublisherName=* PublisherEmail=*} Visibility=* URL=*" as dashboardName,userName,userEmail,publisherName,publisherEmail,visibility, URL
-| count by dashboardName, userName, userEmail, visibility, URL
-| fields -_count
-```
-
 ```sql title="Scheduled search report of dashboard views"
 _index=sumologic_audit and _sourceName=REPORT "Viewed Report"
 | parse "Name=*, Id=Some(*)," as dashboardName,dashboardId

i18n/ja/alerts/alerts/scheduled-searches/create-real-time-alert.md

@@ -80,14 +80,6 @@ When you create a Scheduled Search, you can save the results to a [Lookup Table]
 
 For instructions, see [Save to Lookup](save-to-lookup.md).
 
-### Real Time Alerts
-
-Real Time Alerts are scheduled searches that run nearly continuously. That means that you're informed in real time when error conditions exist.
-
-When an alert condition is satisfied, Sumo Logic sends an email (or triggers a script action). Sumo Logic examines ingested data in a rolling window using the Time Range you define. Any time a new result is found, another email is sent. 
-
-For instructions, see [Create a Alert](create-real-time-alert.md).
-
 ### Cloud SIEM Signal
 
 You can trigger the creation of a Cloud SIEM Signal with a scheduled search. Signals are otherwise generated when the conditions of a Cloud SIEM rule are satisfied by a Record. Signals are correlated with other Signals to create a [Cloud SIEM Insight](/docs/cse/get-started-with-cloud-siem/insight-generation-process/).

i18n/ja/alerts/alerts/scheduled-searches/faqs/real-time-alert-with-greater-than-results.md

@@ -19,8 +19,6 @@ There are three ways to receive the results of scheduled searches in email:
 
     You can be very specific with the alert condition—you can even set an exact number of results that triggers the email. Results can either be the number of log messages *OR* the number of aggregates returned by the saved search. If your saved search returns log messages, then the alert will use the number of messages you specify. If your query produces aggregate results, the alert will use the number of aggregates (or groups).
 
-* **Real Time Alerts.** (Not available to Sumo Logic Free accounts.) Real Time Alerts continuously monitor your Sumo Logic deployment, and return alert emails whenever conditions are met. You can learn more in [Create a Real Time Alert](create-real-time-alert.md).
-
 :::important
 Scheduled searches are run according to the time zone of an individual's computer and browser, not according to the time zone of logs.
 :::