Skip to content
2 changes: 1 addition & 1 deletion docs/alerts/monitors/overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -96,7 +96,7 @@ When a specific alerting condition is met, as defined on the monitor, an inciden

### Monitor

A _Monitor_ creates an _Alert_. Using the options below, you're subscribing to an _Alert's Monitor_.
A Monitor creates an Alert. Using the options below, you're subscribing to an Alert's Monitor.

The monitor is the object that you configure within Sumo Logic that:
* Checks for specific events of interest against a data source, based on your specified conditions. Events of interest are used in a general sense to denote an event that may be of interest to you.
Expand Down
4 changes: 2 additions & 2 deletions docs/alerts/monitors/use-playbooks-with-monitors.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ description: Learn how to use Automation Service playbooks with monitors.
import useBaseUrl from '@docusaurus/useBaseUrl';
import Iframe from 'react-iframe';

This article describes how to configure automated playbooks in monitors. An *automated playbook* is a [playbook in the Automation Service](/docs/platform-services/automation-service/playbooks), and is a predefined set of actions and conditional statements that run in an automated workflow to respond to an event. For example, suppose that a monitor detects suspicious behavior that could indicate a security problem. When the monitor sends the alert, it could also run an automated playbook to respond to the event.
This article describes how to configure automated playbooks in monitors. An automated playbook is a [playbook in the Automation Service](/docs/platform-services/automation-service/playbooks), and is a predefined set of actions and conditional statements that run in an automated workflow to respond to an event. For example, suppose that a monitor detects suspicious behavior that could indicate a security problem. When the monitor sends the alert, it could also run an automated playbook to respond to the event.

To add an automated playbook to a monitor, see [Add an automated playbook to a monitor](#add-an-automated-playbook-to-a-monitor) below.

Expand Down Expand Up @@ -80,7 +80,7 @@ You can create a monitor that triggers an alert that in turn runs an automated p
An anomaly monitor is triggered when unusual conditions are detected. Anomaly monitors leverage a machine learning model to detect anomalies and identify unusual patterns of activity. The output of the machine learning model are baselines for normal behavior, in the form of lower and upper thresholds, so that deviations from baselines signal unusual activity and trigger alerts.

:::note
Weekly seasonality detection is turned off by default to optimize performance. [Contact Sumo Logic Customer Support](https://support.sumologic.com/support/s/contactsupport) to activate it for specific monitors. (*Weekly seasonality detection* is the optimization of baseline calculations to account for the variations of data flow that can occur in a work week.)
Weekly seasonality detection is turned off by default to optimize performance. [Contact Sumo Logic Customer Support](https://support.sumologic.com/support/s/contactsupport) to activate it for specific monitors. (Weekly seasonality detection is the optimization of baseline calculations to account for the variations of data flow that can occur in a work week.)
:::

:::training Micro Lesson
Expand Down
2 changes: 1 addition & 1 deletion docs/alerts/scheduled-searches/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ description: Schedule log searches in Sumo Logic to run continuously and send al

import useBaseUrl from '@docusaurus/useBaseUrl';

A _Scheduled Search_ is a standard [Log Search](/docs/search) that you save and execute to run on a schedule. Once configured, Scheduled Searches run continuously, making them a great tool for continuously monitoring your stack.
A [Scheduled Search](/docs/alerts/scheduled-searches/schedule-search) is a standard [Log Search](/docs/search) that you save and execute to run on a schedule. Once configured, Scheduled Searches run continuously, making them a great tool for continuously monitoring your stack.

<div className="box-wrapper">
<div className="box smallbox card">
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ import useBaseUrl from '@docusaurus/useBaseUrl';
To create a webhook connection, you need the View Connections and Manage Connections [role capabilities](/docs/manage/users-roles/roles/role-capabilities). Contact your org administrator for assistance.
:::

A _webhook_ is an HTTP callback, which is an HTTP POST that occurs when something happens. Webhook connections allow you to send Sumo Logic alerts to third-party applications that accept incoming webhooks.
A webhook is an HTTP callback, which is an HTTP POST that occurs when something happens. Webhook connections allow you to send Sumo Logic alerts to third-party applications that accept incoming webhooks.

For example, once you set up a webhook connection in Sumo Logic and create a scheduled search, you can send an alert from that scheduled search as a post to a Slack channel, or integrate with third-party systems. In addition to an alert, you can include a link directly to a search and even a few search results (depending on the third party tool you're connecting to). There is no limit to the number of webhooks you can send from Sumo Logic, but your third party might impose restrictions. In addition, the payload of a webhook may be restricted by Sumo Logic or the third party.

Expand Down
6 changes: 3 additions & 3 deletions docs/api/about-apis/terraform-with-sumo-logic.md
Original file line number Diff line number Diff line change
Expand Up @@ -210,7 +210,7 @@ Let's look at some examples:

### Terraform providers

A *provider* is a Terraform module or plugin developed by a vendor that defines which vendor resources are available for Terraform to create and manage. For information about the Sumo Logic provider, see the [Sumo Logic Provider documentation](https://registry.terraform.io/providers/SumoLogic/sumologic/latest/docs).
A provider is a Terraform module or plugin developed by a vendor that defines which vendor resources are available for Terraform to create and manage. For information about the Sumo Logic provider, see the [Sumo Logic Provider documentation](https://registry.terraform.io/providers/SumoLogic/sumologic/latest/docs).

Sumo Logic has an established Terraform provider plugin, as does AWS and other major cloud vendors. The Terraform script section defining the provider for resources defined by other parts of the script might look like this:

Expand Down Expand Up @@ -238,7 +238,7 @@ terraform {

### Terraform resources

A *resource* is an infrastructure element that can be defined and created from the available resources produced by the provider. For available resources, see the [Sumo Logic Provider documentation](https://registry.terraform.io/providers/SumoLogic/sumologic/latest/docs).
A resource is an infrastructure element that can be defined and created from the available resources produced by the provider. For available resources, see the [Sumo Logic Provider documentation](https://registry.terraform.io/providers/SumoLogic/sumologic/latest/docs).

A resource definition will look similar in form to the provider definition:

Expand Down Expand Up @@ -352,7 +352,7 @@ data "httpclient_request" "enable_searchaudit_policy" {

### Terraform state files

After running Terraform, there is another file type you should be aware of. A *state file* is a configuration file generated by a Terraform installation that stores the current state of your managed infrastructure and configuration. This state is typically stored in a local file in your terraform working directory named `terraform.tfstate`.
After running Terraform, there is another file type you should be aware of. A state file is a configuration file generated by a Terraform installation that stores the current state of your managed infrastructure and configuration. This state is typically stored in a local file in your terraform working directory named `terraform.tfstate`.

The state file is used by Terraform to track the current infrastructure state in order to properly process updates or deletes. The state file should be kept safe and secure (since it may contain sensitive data such as access keys and secrets) and is not meant to be edited directly, even though it is a simple human-readable JSON text file. An example state file might look like the screenshot below:

Expand Down
Loading