You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .clabot
+2-1Lines changed: 2 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -174,7 +174,8 @@
174
174
"darshan-sumo",
175
175
"mahendrak-sumo",
176
176
"chvik",
177
-
"Apoorvkudesia-sumologic"
177
+
"Apoorvkudesia-sumologic",
178
+
"akesle"
178
179
],
179
180
"message": "Thank you for your contribution! As this is an open source project, we require contributors to sign our Contributor License Agreement and do not have yours on file. To proceed with your PR, please [sign your name here](https://forms.gle/YgLddrckeJaCdZYA6) and we will add you to our approved list of contributors.",
Copy file name to clipboardExpand all lines: docs/integrations/databases/opentelemetry/postgresql-opentelemetry.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,7 +19,7 @@ This app supports PostgreSQL version 9.6+.
19
19
20
20
We use the OpenTelemetry collector for PostgreSQL metric collection and for collecting PostgreSQL logs.
21
21
22
-
The diagram below illustrates the components of the PostgreSQL collection for each database server. OpenTelemetry collector runs on the same host as PostgreSQL, and uses the [PostgreSQL receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/postgresqlreceiver) to obtain PostgreSQL metrics, and the [Sumo Logic OpenTelemetry Exporter](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/sumologicexporter) to send the metrics to Sumo Logic. MySQL logs are sent to Sumo Logic through a [filelog receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/filelogreceiver).
22
+
The diagram below illustrates the components of the PostgreSQL collection for each database server. OpenTelemetry collector runs on the same host as PostgreSQL, and uses the [PostgreSQL receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/postgresqlreceiver) to obtain PostgreSQL metrics, and the [Sumo Logic OpenTelemetry Exporter](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/sumologicexporter) to send the metrics to Sumo Logic. PostgreSQL logs are sent to Sumo Logic through a [filelog receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/filelogreceiver).
Copy file name to clipboardExpand all lines: docs/manage/partitions/flex/faq.md
+2-1Lines changed: 2 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -91,8 +91,9 @@ We recommend you configure partitions to have less than 5 TB per day flowing int
91
91
92
92
Default scope allows you to include or exclude the partitions in the search query, helping you to optimize the search cost. For example, if a query needs to run through 10 partitions, which consumes about 10 GB of search data, narrowing the search query using the default scope can improve the query performance and reduce scan cost. You can modify the default scope by selecting or deselecting the **Include this partition in default scope** checkbox when creating/updating your partition. Let's say that out of 10 partitions, you excluded two partitions. Now, when you run a query that does not have `_index`/`_view` term referenced in the query, the search will only consider the included partitions, reducing the amount of data scanned and lowering the cost.
93
93
94
+
If you do not specify a partition name using `_index`or`_view`, or if you do not use metadata fields in your query scope that correspond to the routing expression of a partition, you will be billed for all default scope partitions that are not explicitly excluded. This also includes the `sumologic_default` partition.
94
95
95
-
When partitions are marked as included and`_index`or`_view` is not referenced in the query, all included partitions will be considered by default. Default scope is also useful when `AND`or`OR` conditions are used in the query with `_index`. For example, consider you have three partitions: Partition A (Excluded), Partition B (Included), and Partition C (Included). Below are some scenarios:
96
+
When partitions are marked as included and`_index`or`_view` is not referenced in the query, all partitions part of default scope will be considered by default. Default scope is also useful when `AND`or`OR` conditions are used in the query with `_index`. For example, consider you have three partitions: Partition A (Excluded), Partition B (Included), and Partition C (Included). Below are some scenarios:
96
97
97
98
- When you run the query without referring to `_index`, for example `error | count`, only Partition B and Partition C will be considered for the query, as Partition A is excluded from the default scope.
98
99
- When you run a query referring to an index term, for example `_index="Partition A"`, only Partition A will be considered for the query.
Copy file name to clipboardExpand all lines: docs/search/get-started-with-search/search-page/log-level.md
+3-1Lines changed: 3 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -54,7 +54,9 @@ Sumo Logic detects five log levels out of the box: FATAL, ERROR, WARN, INFO, and
54
54
55
55
Log-Level pattern detection is automatic, meaning you do not need to parse log levels manually or write specific queries to see your distribution of error logs.
56
56
57
-
If the log message is in JSON format, the log level detection method searches for the presence of keys such as "level", "Level", "loglevel", "logLevel", "Loglevel", "LogLevel", "log_level", "log-level", "Log_Level", "Log_level", "severity", or "_loglevel." If any of these keys are identified in the log message, their corresponding values will be considered and displayed in the results. And if the log message is in a non-JSON format, the log level detection method looks for keywords such as "debug", "info/information", "warn/warning", and "error." If any of these keywords are found in the log message, their corresponding values will be considered and displayed in the results.
57
+
If the log message is in JSON format, the log level detection method searches for the presence of keys such as "level", "Level", "loglevel", "logLevel", "Loglevel", "LogLevel", "log_level", "log-level", "Log_Level", "Log_level", "severity", or "_loglevel". If any of these keys are identified in the log message, their corresponding values will be considered and displayed in the results. If any of these specified log level keys are not found in JSON log messages, the log level detection method falls back to a plain text search for terms like "debug", "info/information", "warn/warning", and "error." But this fallback mechanism can result in false positives, especially when these terms appear in other contexts like encoded data fields.
58
+
59
+
And if the log message is in a non-JSON format, the log level detection method looks for keywords such as "debug", "info/information", "warn/warning", and "error". If any of these keywords are found in the log message, their corresponding values will be considered and displayed in the results.
58
60
59
61
:::info
60
62
If multiple log levels are detected in the message, they will be prioritized in the following order: ERROR > WARN > INFO > DEBUG.
0 commit comments