Log data auto-mapping and mapping
Summarize
Summary of Log Data Auto-Mapping and Mapping
The Health Log Analytics AI engine in ServiceNow automatically maps incoming log lines to specific tags: application service, component, and source type. This functionality enhances the organization of log data and supports effective monitoring and analysis. Customers can customize this auto-mapping by defining JavaScript functions to refine the mapping process according to their needs.
Show less
Key Features
- Auto-Mapping: Automatically assigns tags based on data input setup and specific log fields such as source and path.
- Manual Mapping: Users can override automatic mapping results by creating JavaScript functions, allowing for tailored data organization.
- Test Mode: Activating Test mode prevents excessive data from being stored in Elasticsearch while enabling users to preview and refine mapping scripts.
- Source Limits: Configure warning and critical limits for the number of sources created per data input to manage potential excesses effectively.
- Binding Data: Log data can be bound to Configuration Items (CIs) in the CMDB for enhanced root cause analysis.
- Header Properties Detection: Automatically separates the transport header from the actual log data to ensure only relevant information is processed.
Key Outcomes
By utilizing log data auto-mapping and manual mapping capabilities, customers can achieve a more organized log structure, streamline the monitoring process, and enhance root cause analysis. Additionally, the ability to manage source limits and utilize Test mode helps prevent unnecessary data storage and ensures optimal performance of the Health Log Analytics engine.
By default, the Health Log Analytics AI engine tries to auto-map every incoming log line to the correct tags. You can change automatic mapping results manually by defining a JavaScript function.
Auto-mapping incoming log lines
Health Log Analytics auto-mapping assigns log samples and metadata to three tags: application service, component, and source type. The application service assignment is based on the application service specified in the data input setup. The remaining tags are assigned automatically.
For example, in the following example log line, Health Log Analytics uses the "source" field to find the component and source type.
{"beat":{"version":"6.8","name":"abc3.prd.acme.com","hostname":"abc3.prd.acme.com"},"@timestamp":"2020-08-27T10:12:24.792Z","prospector":{"type":"log"},"message":"**** User null is requesting the following page http://www.acme.com PROPS:{"subcategory1":"home pages","httpStatus":"200","loginLevel":"Anonymous","userAgent":"Mozilla5.0", ("pageUrl":\"http://www.acme.com","host":"abc3.prd.acme.com","@version":"1","source":"/opt/oracle/weblogic/abc/online_store3/logs/online_store3.out","offset":3951550786} In the example, Health Log Analytics extracts the string "online_store". It analyzes the following fields if they exist in the log line: source, path, channel, namespace_name, name, pod_name, source_name, and aws_lambda_name. When data is sent over Syslog, it also analyzes the syslog tag.
- Stop extraction of unneeded data
- If an extracted string is not descriptive enough or contains redundant text or information, you can stop extracting such expendable data. For more information, see Stop extraction of unneeded log data.
- Ensuring extraction of specific data
- You can make sure that Health Log Analytics extracts specific desired terms. For more information, see Ensure extraction of specific log data.
Mapping data input sources
You can change automatic mapping results manually by defining a JavaScript function. Data input mapping enables you to organize your log data by application service and by availability zone. A single application service can include multiple components, and a component can receive logs from many different source types. An application service-component pair, however, is unique. Source types are based on a specific log structure and format. Application services and components are defined more broadly and are therefore used mainly for logical mapping.
Activating Test mode avoids blowing up Elasticsearch storage with sample data that is used only for perfecting the log data mapping. When the data input is in Test mode, Health Log Analytics doesn’t create the source types, sources, or any other objects it creates in the standard flow. It saves the streamed data in dedicated temporary Elasticsearch indices that appear as components in the Log viewer. When you publish the script and exit Test mode, these temporary indices are deleted to minimize storage space consumption.
| System property | Description | Default |
|---|---|---|
| log_source.sources_warning_limit | The warning limit for the number of sources created per data input. | 500 |
| log_source.sources_critical_limit | The critical limit for the number of sources created per data input. | 600 |
Binding log data
Binding log data to Configuration Items (CIs) in the Configuration Management Database (CMDB) enables you to search the CMDB for endpoints that match a log. When you configure a data input, you bind log entries to an application service that is bound to a CI in the CMDB. Binding log entries, application services, and CIs enables the Health Log Analytics AI engine to correlate them for use in root cause analysis (RCA). For more information, see Configure data inputs (Rsyslog, Filebeat, or Winlogbeat) or Configure data inputs (Elasticsearch).