From f32e655f6ef90f9aea25f356d7932473592cb41d Mon Sep 17 00:00:00 2001 From: Jagadisha V Date: Thu, 6 Nov 2025 10:41:17 +0530 Subject: [PATCH 01/12] System Limits Visibility --- blog-service/2025-11-14-manage.md | 11 ++ docs/manage/health-events.md | 194 ++++++++++++++++-------------- 2 files changed, 115 insertions(+), 90 deletions(-) create mode 100644 blog-service/2025-11-14-manage.md diff --git a/blog-service/2025-11-14-manage.md b/blog-service/2025-11-14-manage.md new file mode 100644 index 0000000000..5502a03a07 --- /dev/null +++ b/blog-service/2025-11-14-manage.md @@ -0,0 +1,11 @@ +--- +title: System Limits Visibility (Manage) +image: https://assets-www.sumologic.com/company-logos/_800x418_crop_center-center_82_none/SumoLogic_Preview_600x600.jpg?mtime=1617040082 +keywords: + - system-limits-visibility + - manage + - health-events +hide_table_of_contents: true +--- + +We’re excited to announce that Health Events are now automatically generated when 90% credit usage threshold is exceeded for Lookup Tables, Partitions, Fields, or Field Extraction Rules (FERs). These health events can further be configured to receive timely alerts whenever a threshold breach occurs, ensuring that all designated recipients are promptly notified when the health event is triggered everytime. [Learn more](/docs/manage/health-events). \ No newline at end of file diff --git a/docs/manage/health-events.md b/docs/manage/health-events.md index ade43f0fa1..f30eafb96e 100644 --- a/docs/manage/health-events.md +++ b/docs/manage/health-events.md @@ -1,89 +1,35 @@ --- id: health-events title: Health Events -description: Monitor the health of your Collectors and Sources. +description: Monitor the health of your Collectors, Sources, and Log data. --- -## Availability - -| Account Type | Account Level | -|:--------------|:---------------------------------------------------------------------------------| -| CloudFlex | Professional, Enterprise | -| Credits | Trial, Essentials, Enterprise Operations, Enterprise Security, Enterprise Suite | - -Health events allow you to keep track of the health of your Collectors, Sources, and Ingest Budgets. You can use them to find and investigate common errors and warnings that are known to cause collection issues.  - -This framework includes the following: - -* Health event logs indexed in the [System Event Index](/docs/manage/security/audit-indexes/system-event-index). -* A [health events table](#health-events-table) on the Alerts page. -* A health status column on the [Collection page](#collection-page). - -Health events are sent from Installed Collectors on version 19.308-2 and -later. - -## Alerts - -Alerts for specific health events are easy to create in the Health Events Table. The details pane of an event provides a **Create Scheduled Search** button to automatically generate the required query. - -## Health events - -Health events are created when an issue is detected with a Collector or Source. Events are indexed and searchable in a separate partition named **sumologic_system_events** in the [System Event Index](/docs/manage/security/audit-indexes/system-event-index). For details on what information is available in a health event, see the [common parameters](#common-parameters) table. - -### Health events table +import useBaseUrl from '@docusaurus/useBaseUrl'; -The health events table allows you to easily view and investigate problems getting your data to Sumo. +System Health Events are generated automatically when the system detects an issue within a Collector or Source, or when a credit usage threshold is exceeded for Lookup Tables, Partitions, Fields, or Field Extraction Rules (FERs). -On the health events table, you can search, filter, and sort incidents by key aspects like severity, resource name, event name, resource type, and opened since date. +These events provide visibility into the operational health of Collectors, Sources, and Ingest Budgets, enabling administrators to monitor performance and identify potential issues proactively. Health events also help in investigating common errors and warnings known to affect data collection and processing. -[**New UI**](/docs/get-started/sumo-logic-ui/). To access the health events table, in the main Sumo Logic menu select **Data Management**, and then under **Data Collection** select **Health Events**. You can also click the **Go To...** menu at the top of the screen and select **Health Events**. +Additionally, a health event is triggered when any credit limit associated with Lookup Tables, Partitions, Fields, or FERs reaches or exceeds 90% of the allocated capacity, allowing timely action to prevent service disruption. This health event will auto-resolve when the usage falls back below the 90% threshold limit. -[**Classic UI**](/docs/get-started/sumo-logic-ui-classic). To access the health events table, in the main Sumo Logic menu select **Manage Data > Monitoring > Health Events**. - -![health events table.png](/img/health-events/health-events-table.png) - -Click on a row to view the details of a health event. - -![health event detail.png](/img/health-events/health-event-detail.png) - -Click the **Create Scheduled Search** button on the details pane to get alerts for specific health events. The unique identifier of the resource, such as the Source or Collector, is used in the query. See [Schedule a Search](../alerts/scheduled-searches/schedule-search.md) for details. - -Under the **More Actions** menu you can select: - -* **Event History** to run a search against the **sumologic_system_events** partition to view all of the related event logs. -* **View Object** to view the Collector or Source in the Collection page related to the event. - -### Health events severity +:::note +Health events are sent from Installed Collectors of version `19.308-2` and later. +::: -Events are categorized by two severity levels, warning and error. The severity column has color-coded error and warning events so you can quickly determine the severity of a given issue. +## Availability -* ![warning label.png](/img/health-events/warning-label.png) A warning indicates the Collector or Source has a configuration issue or is operating in a degraded state. -* ![Error label.png](/img/health-events/Error-label.png) An error indicates the Collector or Source is unable to collect data as expected. +| Account Type | Account Level | +|:--------------|:---------------------------------------------------------------------------------| +| CloudFlex | Professional, Enterprise | +| Credits | Trial, Essentials, Enterprise Operations, Enterprise Security, Enterprise Suite | -### Common parameters +## Event schema -Each health event log has common keys that categorize it to a product -area and provide details of the event. The following table shows the -common parameters in the order that they are found in health event logs. +This section defines the structure of System Health Events, including all key parameters and their descriptions. The example below illustrates a sample health event in JSON format, followed by a parameter table explaining each field for better understanding and analysis. -| Parameter | Description | Data Type | -|:--|:--|:--| -| status | Either `Healthy` or `Unhealthy` based on the event. | String | -| details | The details of the event include the type as `trackerId`, the `name` of the event, and a `description`. | JSON object of Strings | -| eventType | Health events have a value of `Health-Change`. | String | -| severityLevel | Either `Error` or `Warning` based on the event. | String | -| accountId | The unique identifier of the organization. | String | -| eventId | The unique identifier of the event. | String | -| eventName | The name of the event. | String | -| eventTime | The event timestamp in [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601) format. | String | -| eventFormatVersion | The event log format version. | String | -| operator | Information on who did the operation. If it's missing, the Sumo service was the operator. | JSON object of Strings | -| subsystem | The product area of the event. | String | -| resourceIdentity | This includes any unique identifiers, names, and the type of the object associated with the event. | JSON object of Strings | +### JSON example -### Health event log example - -```json +```json title="Sample Health Event" { "status": "UnHealthy", "details": { @@ -109,10 +55,94 @@ common parameters in the order that they are found in health event logs. } ``` +### Parameters table + +Each health event log has common keys that categorize it to a product area and provide details of the event. The following table shows the common parameters in the order that they are found in health event logs. + +| Parameter | Description | Data type | +|:--|:--|:--| +| status | Either `Healthy` or `Unhealthy` based on the event. | String | +| details | The details of the event include the type as `trackerId`, the `name` of the event, and a `description`. | JSON object of Strings | +| eventType | Health events have a value of `Health-Change`. | String | +| severityLevel | Either `Error` or `Warning` based on the event. | String | +| accountId | The unique identifier of the organization. | String | +| eventId | The unique identifier of the event. | String | +| eventName | The name of the event. | String | +| eventTime | The event timestamp in [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601) format. | String | +| eventFormatVersion | The event log format version. | String | +| operator | Information on who did the operation. If it's missing, the Sumo service was the operator. | JSON object of Strings | +| subsystem | The product area of the event. | String | +| resourceIdentity | This includes any unique identifiers, names, and the type of the object associated with the event. | JSON object of Strings | + +## Configure Scheduled Search + +Configuring the scheduled search for the selected health event will help you with timely alerts to all the recepients when the health event is triggered everytime. To configure, follow the below steps: + +1. [**Classic UI**](/docs/get-started/sumo-logic-ui-classic). Go to **Manage Data > Monitoring > Health Events**.
[**New UI**](/docs/get-started/sumo-logic-ui). In the main Sumo Logic menu select **Data Management**, and then under **Data Collection** select **Health Events**.
health-events-table +1. Click on the required row to view the details of a health event.
health-events-detial +1. Click the **Create Scheduled Search** button and configure it based on your requirement. For more details, refer to [Create a Scheduled Search](/docs/alerts/scheduled-searches/schedule-search/). + :::info + Query will be auto-generated for the selected health event. + ::: + +Use the below scheduled search query to get an alert when 90% threshold is exceeded for Lookup Tables, Partitions, Fields, or Field Extraction Rules (FERs). + +``` sql +_index=sumologic_system_events "0000000007063B25" +| json "eventType", "resourceIdentity.id" as eventType , resourceId +| where eventType = "Health-Change" AND resourceId = "0000000007063B25" +``` + +For specific `eventType`, `resourceId`, `eventName`: + +```sql +_index=sumologic_system_events "0000000007063B25" +| json "eventType", "resourceIdentity.id","eventName" as eventType, resourceId, eventName +| where eventType = "Health-Change" AND resourceId = "0000000007063B25" AND eventName='LookupsLimitApproaching' +``` + +## View Health Events + +The health events table allows you to easily view and investigate problems which occurs while injecting the data to Sumo Logic. On the health events table, you can search, filter, and sort incidents by key aspects like severity, resource name, event name, resource type, and opened since date. + +:::info +It may take up to 15 minutes for a 90% usage breach for Lookup Tables, Partitions, Fields, or Field Extraction Rules (FERs) to reflect on the Health Events page after detection. +::: + +1. [**Classic UI**](/docs/get-started/sumo-logic-ui-classic). Go to **Manage Data > Monitoring > Health Events**.
[**New UI**](/docs/get-started/sumo-logic-ui). In the main Sumo Logic menu select **Data Management**, and then under **Data Collection** select **Health Events**.
health-events-table +1. Click on the required row to view the details of a health event.
health-events-detial + - **Create Scheduled Search**. Click this button to get alerts for specific health events. The unique identifier of the resource type is used in the query. See [Schedule a Search](../alerts/scheduled-searches/schedule-search.md) for details. + - Under the **More Actions** menu you can select: + * **Event History** to run a search against the **sumologic_system_events** partition to view all of the related event logs. + * **View Object** to view the resource in detail related to the event. + - **Description**. Provides the information about the health events error or warning. + - **Severity**. Events are categorized by two severity levels, warning, and error. The severity column has color-coded error and warning events so you can quickly determine the severity of a given issue. + * ![warning label.png](/img/health-events/warning-label.png) A warning indicates the Collector or Source has a configuration issue or is operating in a degraded state. + * ![Error label.png](/img/health-events/Error-label.png) An error indicates the Collector or Source is unable to collect data as expected. + - **Event Name**. The name or type of the health event that occurred. This identifies what kind of issue or status change was detected. + - **Resource Type**. The category or class of resource affected by the event. For example, Collectors, Sources, or Organizations. + - **Resource ID**. A unique identifier for the affected resource. + - **Created At**. The timestamp indicating when the event was generated by the monitoring system. + - **Collector ID**. The unique identifier of the collector that detected and reported the event. This field is only available for *Source* resource type. + - **Collector Name**. The name of the collector associated with the event. This field is only available for *Source* resource type. + - **Error**. A brief summary or title of the detected issue. + - **Service**. Displays the specific resource or service affected by the event. + - **Error Code**. A numeric code associated with the error, that provides a quick reference for troubleshooting or mapping to known issue types. + - **Error Info**. Detailed information about the event. This may include error context and suggested corrective actions. + - **Minutes Since Last Heatbeat**. The number of minutes that have elapsed since the system last received a heartbeat signal from the resource. A higher number may indicate the resource is offline or unresponsive. This field is only available for *Collector* resource type. + +## View Health Events in Collection page + +A **Health** column on the Collection page shows color-coded healthy, error, and warning states for Collectors and Sources to quickly determine the health of your Collectors and Sources.
Collection-health-column + +To view the number of health events associated with the Collector or Source, perform the following steps: + +1. Hover over a **Health** status to view a tooltip that provides the number of health events detected on the selected Collector or Source.
health_tooltip +1. Click on the **Health** status of a Collector or Source to view a pop-up displaying a list of related events.
object_event_details + ## Search health events -To search all health events run a query against the internal partition -named **sumologic_system_events**. For example, +Events are indexed and searchable in a separate partition named **sumologic_system_events** in the [System Event Index](/docs/manage/security/audit-indexes/system-event-index). To search all health events run a query against the internal partition named **sumologic_system_events**. For example, ```sql _index=sumologic_system_events "Health-Change" @@ -130,20 +160,4 @@ Creating a query that defines built-in metadata field values in the scope can he |:--|:--| | _sourceCategory | Value of the [common parameter](#common-parameters), `subsystem`. | | _sourceName | Value of the [common parameter](#common-parameters), `eventName`. | -| _sourceHost | The remote IP address of the host that made the request. If not available the value will be `no_sourceHost`. | - -### Collection page - -A **Health** column on the Collection page shows color-coded healthy, error, and warning states for Collectors and Sources so you can quickly determine the health of your Collectors and Sources. - -The **status** column now shows the status of Sources manually paused by users. - -![Collection health column.png](/img/health-events/Collection-health-column.png) - -* Hover your mouse over a Collector or Source to view a tooltip that provides the number of health events detected on the Collector or Source. - - ![health tooltip.png](/img/health-events/health_tooltip.png) - -* Click on the **Health** status in a row to view a pop-up displaying a list of related events. - - ![object event details.png](/img/health-events/object_event_details.png) +| _sourceHost | The remote IP address of the host that made the request. If not available the value will be `no_sourceHost`. | \ No newline at end of file From a05cf1328abdb9e4f54a0847b3a3fbe1b351c6b2 Mon Sep 17 00:00:00 2001 From: Jagadisha V Date: Thu, 6 Nov 2025 11:09:18 +0530 Subject: [PATCH 02/12] minor fixes --- blog-service/2025-11-14-manage.md | 2 +- docs/manage/health-events.md | 8 ++++---- docs/metrics/introduction/metric-formats.md | 2 +- .../cloud-to-cloud-integration-framework/source-info.md | 2 +- .../sources/streaming-metrics-source.md | 2 +- 5 files changed, 8 insertions(+), 8 deletions(-) diff --git a/blog-service/2025-11-14-manage.md b/blog-service/2025-11-14-manage.md index 5502a03a07..e0fe0426c0 100644 --- a/blog-service/2025-11-14-manage.md +++ b/blog-service/2025-11-14-manage.md @@ -8,4 +8,4 @@ keywords: hide_table_of_contents: true --- -We’re excited to announce that Health Events are now automatically generated when 90% credit usage threshold is exceeded for Lookup Tables, Partitions, Fields, or Field Extraction Rules (FERs). These health events can further be configured to receive timely alerts whenever a threshold breach occurs, ensuring that all designated recipients are promptly notified when the health event is triggered everytime. [Learn more](/docs/manage/health-events). \ No newline at end of file +We’re excited to announce that Health Events are now automatically generated when 90% credit usage threshold is exceeded for Lookup Tables, Partitions, Fields, or Field Extraction Rules (FERs). These health events can further be configured to receive timely alerts whenever a threshold breach occurs, ensuring that all designated recipients are promptly notified when the health event is triggered every time. [Learn more](/docs/manage/health-events). \ No newline at end of file diff --git a/docs/manage/health-events.md b/docs/manage/health-events.md index f30eafb96e..bd23a653f7 100644 --- a/docs/manage/health-events.md +++ b/docs/manage/health-events.md @@ -76,7 +76,7 @@ Each health event log has common keys that categorize it to a product area and p ## Configure Scheduled Search -Configuring the scheduled search for the selected health event will help you with timely alerts to all the recepients when the health event is triggered everytime. To configure, follow the below steps: +Configuring the scheduled search for the selected health event will help you with timely alerts to all the recipients when the health event is triggered every time. To configure, follow the below steps: 1. [**Classic UI**](/docs/get-started/sumo-logic-ui-classic). Go to **Manage Data > Monitoring > Health Events**.
[**New UI**](/docs/get-started/sumo-logic-ui). In the main Sumo Logic menu select **Data Management**, and then under **Data Collection** select **Health Events**.
health-events-table 1. Click on the required row to view the details of a health event.
health-events-detial @@ -129,7 +129,7 @@ It may take up to 15 minutes for a 90% usage breach for Lookup Tables, Partition - **Service**. Displays the specific resource or service affected by the event. - **Error Code**. A numeric code associated with the error, that provides a quick reference for troubleshooting or mapping to known issue types. - **Error Info**. Detailed information about the event. This may include error context and suggested corrective actions. - - **Minutes Since Last Heatbeat**. The number of minutes that have elapsed since the system last received a heartbeat signal from the resource. A higher number may indicate the resource is offline or unresponsive. This field is only available for *Collector* resource type. + - **Minutes Since Last Heartbeat**. The number of minutes that have elapsed since the system last received a heartbeat signal from the resource. A higher number may indicate the resource is offline or unresponsive. This field is only available for *Collector* resource type. ## View Health Events in Collection page @@ -158,6 +158,6 @@ Creating a query that defines built-in metadata field values in the scope can he | **Metadata Field** | **Assignment Description** | |:--|:--| -| _sourceCategory | Value of the [common parameter](#common-parameters), `subsystem`. | -| _sourceName | Value of the [common parameter](#common-parameters), `eventName`. | +| _sourceCategory | Value of the [common parameter](#parameters-table), `subsystem`. | +| _sourceName | Value of the [common parameter](#parameters-table), `eventName`. | | _sourceHost | The remote IP address of the host that made the request. If not available the value will be `no_sourceHost`. | \ No newline at end of file diff --git a/docs/metrics/introduction/metric-formats.md b/docs/metrics/introduction/metric-formats.md index 648b265ffc..f9e471da07 100644 --- a/docs/metrics/introduction/metric-formats.md +++ b/docs/metrics/introduction/metric-formats.md @@ -97,7 +97,7 @@ cluster=cluster-1 node=node-1 cpu=cpu-1 metric=cpu_idle 97.29 1460061337 ### Mandatory metric name -Unlike Prometheus, Carbon 2.0 format doesn't enforce the presence of a metric name. It also cannot be reliably inferred automatically. Therefore, Sumo Logic requires a `metric` key to be present among `intrinsic_tags`. All metrics without a `metric` key specified will not be ingested to Sumo Logic and a `MetricsMetricNameMissing` Health Event for the associated Metric Source will be triggered (for more information on Health Events, see [About Health Events](/docs/manage/health-events#health-events)). +Unlike Prometheus, Carbon 2.0 format doesn't enforce the presence of a metric name. It also cannot be reliably inferred automatically. Therefore, Sumo Logic requires a `metric` key to be present among `intrinsic_tags`. All metrics without a `metric` key specified will not be ingested to Sumo Logic and a `MetricsMetricNameMissing` Health Event for the associated Metric Source will be triggered (for more information on Health Events, see [About Health Events](/docs/manage/health-events)). For example, the following metric will be correctly ingested to Sumo Logic: ``` diff --git a/docs/send-data/hosted-collectors/cloud-to-cloud-integration-framework/source-info.md b/docs/send-data/hosted-collectors/cloud-to-cloud-integration-framework/source-info.md index b139762af4..41c5d498f7 100644 --- a/docs/send-data/hosted-collectors/cloud-to-cloud-integration-framework/source-info.md +++ b/docs/send-data/hosted-collectors/cloud-to-cloud-integration-framework/source-info.md @@ -19,7 +19,7 @@ If the Source has any issues during any one of these states, it is placed in an When you delete the Source, it is placed in a **Stopping** state. When it has successfully stopped, it is deleted from your Hosted Collector. -On the [Collection page](/docs/manage/health-events#collection-page), the Health and Status for Sources is displayed. Use [Health Events](/docs/manage/health-events.md) to investigate issues with collection. +On the [Collection page](/docs/manage/health-events#view-health-events-in-collection-page), the Health and Status for Sources is displayed. Use [Health Events](/docs/manage/health-events) to investigate issues with collection. Hover your mouse over the status icon to view a tooltip with a count of the detected errors and warnings. You can click on the status icon to open a Health Events panel with details on each detected issue. diff --git a/docs/send-data/installed-collectors/sources/streaming-metrics-source.md b/docs/send-data/installed-collectors/sources/streaming-metrics-source.md index 33aaa05337..9bc22db0dd 100644 --- a/docs/send-data/installed-collectors/sources/streaming-metrics-source.md +++ b/docs/send-data/installed-collectors/sources/streaming-metrics-source.md @@ -112,7 +112,7 @@ For example: metric=request_rate site=mydomain mtype=rate unit=Req/s host=web12 agent=statsdaemon1 234 1234567890 ``` -Unlike Prometheus, Carbon 2.0 format doesn't enforce the presence of a metric name. It also cannot be reliably inferred automatically. Therefore, Sumo Logic require a `metric` key to be present among `intrinsic_tags`. All metrics without a `metric` key specified will not be ingested to Sumo and a `MetricsMetricNameMissing` Health Event for the associated Metric Source will be triggered (for more information on Halth Events, see [About Health Events](/docs/manage/health-events#health-events)). +Unlike Prometheus, Carbon 2.0 format doesn't enforce the presence of a metric name. It also cannot be reliably inferred automatically. Therefore, Sumo Logic require a `metric` key to be present among `intrinsic_tags`. All metrics without a `metric` key specified will not be ingested to Sumo and a `MetricsMetricNameMissing` Health Event for the associated Metric Source will be triggered (for more information on Halth Events, see [About Health Events](/docs/manage/health-events)). For example, the following metric will be correctly ingested to Sumo Logic: ``` From 7ddc973fe145b18e75278b276cbc368131f12db4 Mon Sep 17 00:00:00 2001 From: Jagadisha V <129049263+JV0812@users.noreply.github.com> Date: Thu, 20 Nov 2025 15:24:24 +0530 Subject: [PATCH 03/12] Update docs/manage/health-events.md Co-authored-by: John Pipkin (Sumo Logic) --- docs/manage/health-events.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/manage/health-events.md b/docs/manage/health-events.md index bd23a653f7..3f72b0e18d 100644 --- a/docs/manage/health-events.md +++ b/docs/manage/health-events.md @@ -103,7 +103,7 @@ _index=sumologic_system_events "0000000007063B25" ## View Health Events -The health events table allows you to easily view and investigate problems which occurs while injecting the data to Sumo Logic. On the health events table, you can search, filter, and sort incidents by key aspects like severity, resource name, event name, resource type, and opened since date. +The health events table allows you to easily view and investigate problems which occur while injecting the data to Sumo Logic. On the health events table, you can search, filter, and sort incidents by key aspects like severity, resource name, event name, resource type, and opened since date. :::info It may take up to 15 minutes for a 90% usage breach for Lookup Tables, Partitions, Fields, or Field Extraction Rules (FERs) to reflect on the Health Events page after detection. From 685861273d21b24c543383806f7763c3241b6e08 Mon Sep 17 00:00:00 2001 From: Jagadisha V <129049263+JV0812@users.noreply.github.com> Date: Thu, 20 Nov 2025 15:24:35 +0530 Subject: [PATCH 04/12] Update docs/manage/health-events.md Co-authored-by: John Pipkin (Sumo Logic) --- docs/manage/health-events.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/manage/health-events.md b/docs/manage/health-events.md index 3f72b0e18d..e681524f70 100644 --- a/docs/manage/health-events.md +++ b/docs/manage/health-events.md @@ -142,7 +142,7 @@ To view the number of health events associated with the Collector or Source, per ## Search health events -Events are indexed and searchable in a separate partition named **sumologic_system_events** in the [System Event Index](/docs/manage/security/audit-indexes/system-event-index). To search all health events run a query against the internal partition named **sumologic_system_events**. For example, +Events are indexed and searchable in a separate partition named `sumologic_system_events` in the [System Event Index](/docs/manage/security/audit-indexes/system-event-index). To search all health events run a query against the internal partition named `sumologic_system_events`. For example, ```sql _index=sumologic_system_events "Health-Change" From edb4793105b2125e11399bfbdebf9a834bcb8eb3 Mon Sep 17 00:00:00 2001 From: Jagadisha V <129049263+JV0812@users.noreply.github.com> Date: Thu, 20 Nov 2025 15:24:44 +0530 Subject: [PATCH 05/12] Update docs/metrics/introduction/metric-formats.md Co-authored-by: John Pipkin (Sumo Logic) --- docs/metrics/introduction/metric-formats.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/metrics/introduction/metric-formats.md b/docs/metrics/introduction/metric-formats.md index f9e471da07..4b9e4761b8 100644 --- a/docs/metrics/introduction/metric-formats.md +++ b/docs/metrics/introduction/metric-formats.md @@ -97,7 +97,7 @@ cluster=cluster-1 node=node-1 cpu=cpu-1 metric=cpu_idle 97.29 1460061337 ### Mandatory metric name -Unlike Prometheus, Carbon 2.0 format doesn't enforce the presence of a metric name. It also cannot be reliably inferred automatically. Therefore, Sumo Logic requires a `metric` key to be present among `intrinsic_tags`. All metrics without a `metric` key specified will not be ingested to Sumo Logic and a `MetricsMetricNameMissing` Health Event for the associated Metric Source will be triggered (for more information on Health Events, see [About Health Events](/docs/manage/health-events)). +Unlike Prometheus, Carbon 2.0 format doesn't enforce the presence of a metric name. It also cannot be reliably inferred automatically. Therefore, Sumo Logic requires a `metric` key to be present among `intrinsic_tags`. All metrics without a `metric` key specified will not be ingested to Sumo Logic and a `MetricsMetricNameMissing` Health Event for the associated Metric Source will be triggered (for more information on Health Events, see [Health Events](/docs/manage/health-events)). For example, the following metric will be correctly ingested to Sumo Logic: ``` From b4a18711a6204322b1bb9953a697c3a4735d86a2 Mon Sep 17 00:00:00 2001 From: Jagadisha V <129049263+JV0812@users.noreply.github.com> Date: Thu, 20 Nov 2025 15:24:56 +0530 Subject: [PATCH 06/12] Update docs/send-data/installed-collectors/sources/streaming-metrics-source.md Co-authored-by: John Pipkin (Sumo Logic) --- .../installed-collectors/sources/streaming-metrics-source.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/send-data/installed-collectors/sources/streaming-metrics-source.md b/docs/send-data/installed-collectors/sources/streaming-metrics-source.md index 9bc22db0dd..effca6fb30 100644 --- a/docs/send-data/installed-collectors/sources/streaming-metrics-source.md +++ b/docs/send-data/installed-collectors/sources/streaming-metrics-source.md @@ -112,7 +112,7 @@ For example: metric=request_rate site=mydomain mtype=rate unit=Req/s host=web12 agent=statsdaemon1 234 1234567890 ``` -Unlike Prometheus, Carbon 2.0 format doesn't enforce the presence of a metric name. It also cannot be reliably inferred automatically. Therefore, Sumo Logic require a `metric` key to be present among `intrinsic_tags`. All metrics without a `metric` key specified will not be ingested to Sumo and a `MetricsMetricNameMissing` Health Event for the associated Metric Source will be triggered (for more information on Halth Events, see [About Health Events](/docs/manage/health-events)). +Unlike Prometheus, Carbon 2.0 format doesn't enforce the presence of a metric name. It also cannot be reliably inferred automatically. Therefore, Sumo Logic require a `metric` key to be present among `intrinsic_tags`. All metrics without a `metric` key specified will not be ingested to Sumo and a `MetricsMetricNameMissing` Health Event for the associated Metric Source will be triggered (for more information on Halth Events, see [Health Events](/docs/manage/health-events)). For example, the following metric will be correctly ingested to Sumo Logic: ``` From b1602005cf31f30c19d78bae1657eac0c0016315 Mon Sep 17 00:00:00 2001 From: Jagadisha V <129049263+JV0812@users.noreply.github.com> Date: Thu, 20 Nov 2025 15:32:20 +0530 Subject: [PATCH 07/12] Update docs/manage/health-events.md --- docs/manage/health-events.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/manage/health-events.md b/docs/manage/health-events.md index e681524f70..49af2c397e 100644 --- a/docs/manage/health-events.md +++ b/docs/manage/health-events.md @@ -98,7 +98,7 @@ For specific `eventType`, `resourceId`, `eventName`: ```sql _index=sumologic_system_events "0000000007063B25" | json "eventType", "resourceIdentity.id","eventName" as eventType, resourceId, eventName -| where eventType = "Health-Change" AND resourceId = "0000000007063B25" AND eventName='LookupsLimitApproaching' +| where eventType = "Health-Change" AND resourceId = "0000000007063B25" AND eventName="LookupsLimitApproaching" ``` ## View Health Events From 91062cf8b764934dd15a695a59a1daa91c8262eb Mon Sep 17 00:00:00 2001 From: Jagadisha V <129049263+JV0812@users.noreply.github.com> Date: Fri, 21 Nov 2025 09:58:30 +0530 Subject: [PATCH 08/12] Update blog-service/2025-11-14-manage.md --- blog-service/2025-11-14-manage.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/blog-service/2025-11-14-manage.md b/blog-service/2025-11-14-manage.md index e0fe0426c0..9d5252adf3 100644 --- a/blog-service/2025-11-14-manage.md +++ b/blog-service/2025-11-14-manage.md @@ -8,4 +8,4 @@ keywords: hide_table_of_contents: true --- -We’re excited to announce that Health Events are now automatically generated when 90% credit usage threshold is exceeded for Lookup Tables, Partitions, Fields, or Field Extraction Rules (FERs). These health events can further be configured to receive timely alerts whenever a threshold breach occurs, ensuring that all designated recipients are promptly notified when the health event is triggered every time. [Learn more](/docs/manage/health-events). \ No newline at end of file +We’re excited to announce that Health Events are now automatically generated when 90% usage threshold is exceeded for Lookup Tables, Partitions, Fields, or Field Extraction Rules (FERs). These health events can further be configured to receive timely alerts whenever a threshold breach occurs, ensuring that all designated recipients are promptly notified when the health event is triggered every time. [Learn more](/docs/manage/health-events). \ No newline at end of file From e8e054ee9e544d731ee546c09721dfae86f520f7 Mon Sep 17 00:00:00 2001 From: Jagadisha V <129049263+JV0812@users.noreply.github.com> Date: Fri, 21 Nov 2025 09:58:37 +0530 Subject: [PATCH 09/12] Update docs/manage/health-events.md --- docs/manage/health-events.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/manage/health-events.md b/docs/manage/health-events.md index 49af2c397e..c9c5088ff8 100644 --- a/docs/manage/health-events.md +++ b/docs/manage/health-events.md @@ -10,7 +10,7 @@ System Health Events are generated automatically when the system detects an issu These events provide visibility into the operational health of Collectors, Sources, and Ingest Budgets, enabling administrators to monitor performance and identify potential issues proactively. Health events also help in investigating common errors and warnings known to affect data collection and processing. -Additionally, a health event is triggered when any credit limit associated with Lookup Tables, Partitions, Fields, or FERs reaches or exceeds 90% of the allocated capacity, allowing timely action to prevent service disruption. This health event will auto-resolve when the usage falls back below the 90% threshold limit. +Additionally, a health event is triggered when any limit associated with Lookup Tables, Partitions, Fields, or FERs reaches or exceeds 90% of the allocated capacity, allowing timely action to prevent service disruption. This health event will auto-resolve when the usage falls back below the 90% threshold limit. :::note Health events are sent from Installed Collectors of version `19.308-2` and later. From 0e6823a80966f6d01be611aeb9aac22e6f9c14e2 Mon Sep 17 00:00:00 2001 From: John Pipkin Date: Tue, 25 Nov 2025 09:47:18 -0600 Subject: [PATCH 10/12] Change release note date to Nov 25 2025 --- blog-service/{2025-11-14-manage.md => 2025-11-25-manage.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename blog-service/{2025-11-14-manage.md => 2025-11-25-manage.md} (100%) diff --git a/blog-service/2025-11-14-manage.md b/blog-service/2025-11-25-manage.md similarity index 100% rename from blog-service/2025-11-14-manage.md rename to blog-service/2025-11-25-manage.md From b344d59d44bbb5408ec731485bdfe9ab8bd94a55 Mon Sep 17 00:00:00 2001 From: John Pipkin Date: Tue, 25 Nov 2025 09:49:04 -0600 Subject: [PATCH 11/12] Change release note date to Dec 1 2025 --- blog-service/{2025-11-25-manage.md => 2025-12-01-manage.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename blog-service/{2025-11-25-manage.md => 2025-12-01-manage.md} (100%) diff --git a/blog-service/2025-11-25-manage.md b/blog-service/2025-12-01-manage.md similarity index 100% rename from blog-service/2025-11-25-manage.md rename to blog-service/2025-12-01-manage.md From 15bbdb160480dd8e5b431cbb0470dc86f011a691 Mon Sep 17 00:00:00 2001 From: Jagadisha V <129049263+JV0812@users.noreply.github.com> Date: Thu, 27 Nov 2025 09:32:18 +0530 Subject: [PATCH 12/12] Rename 2025-12-01-manage.md to 2025-11-27-manage.md --- blog-service/{2025-12-01-manage.md => 2025-11-27-manage.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename blog-service/{2025-12-01-manage.md => 2025-11-27-manage.md} (91%) diff --git a/blog-service/2025-12-01-manage.md b/blog-service/2025-11-27-manage.md similarity index 91% rename from blog-service/2025-12-01-manage.md rename to blog-service/2025-11-27-manage.md index 9d5252adf3..74efb15665 100644 --- a/blog-service/2025-12-01-manage.md +++ b/blog-service/2025-11-27-manage.md @@ -8,4 +8,4 @@ keywords: hide_table_of_contents: true --- -We’re excited to announce that Health Events are now automatically generated when 90% usage threshold is exceeded for Lookup Tables, Partitions, Fields, or Field Extraction Rules (FERs). These health events can further be configured to receive timely alerts whenever a threshold breach occurs, ensuring that all designated recipients are promptly notified when the health event is triggered every time. [Learn more](/docs/manage/health-events). \ No newline at end of file +We’re excited to announce that Health Events are now automatically generated when 90% usage threshold is exceeded for Lookup Tables, Partitions, Fields, or Field Extraction Rules (FERs). These health events can further be configured to receive timely alerts whenever a threshold breach occurs, ensuring that all designated recipients are promptly notified when the health event is triggered every time. [Learn more](/docs/manage/health-events).