Log Files LogSource Configuration
Last updated - 27 January, 2026
LogSource is a LogicModule that provides templates to help you enable LM Logs and configure log data collection and forwarding. LogSource contains details about which logs to get and where to get them, and which fields should be considered for parsing. LogSource is available for common sources of log data.
Note: Starting with OpenTelemetry Collector version 5.2.0.0, LogicMonitor uses improved log-to-resource mapping to associate logs with the correct cloud resource instead of defaulting them to the Collector host. If logs are not mapped to a resource, they are classified as “deviceless”. To manually associate logs with a resource, set the LM_DEVICE_ATTRIBUTES environment variable using key-value pairs (for example, LM_DEVICE_ATTRIBUTES="key1=value1".)
Requirements for Configuring Log Files LogSource
To configure Log Files LogSources, you must have an OpenTelemetry Collector version 6.00 or later.
For more information, see OpenTelemetry Collector for LogicMonitor Overview.
Configuration Options
The following describes configuration details specific to the Log Files type of LogSource. For more information on how to add a LogSource, see Configuring a LogSource.
Basic Information
Provide the path name for the log file in the Log File Path field.
The following image displays an example of single log file path configured for ingestion.
The following image displays an example of log file path configured with wildcards to capture multiple log files and rollover patterns across directories.
AppliesTo
The AppliesTo Filter (ATF) determines which log data this LogSource applies to.
For Log Files collected through OpenTelemetry, the ATF must match the OpenTelemetry Collector name. Ensure that the ATF expression references the OTEL Collector identifier so that logs are correctly associated with this LogSource. If the ATF does not match the OTEL Collector name, the LogSource does not process the incoming logs.
Filtering Using AND or OR Operator
After the AppliesTo Filter matches, the system evaluates include and exclude filters to determine whether a log is ingested or dropped. You can toggle the AND or OR switch to control how this evaluation occurs. By default, these switches are disabled.
AND—Filters are evaluated using theANDoperator. WhenANDmode is selected, the system evaluates all configured filters together.
A log is ingested only when it satisfies every include filter and does not match any exclude filter. If an include filter does not match, or if an exclude filter matches, the log is dropped.
This mode is best suited for strict filtering scenarios where logs must meet all defined conditions to be ingested.OR—Filters are evaluated using theORoperator. WhenORmode is selected, the system evaluates filters sequentially based on their configured priority.
As soon as a filter matches, evaluation stops and the log outcome is determined by the type of that filter. A matching include filter results in ingestion, while a matching exclude filter results in the log being dropped.
If a log does not match any configured filter, the system determines the outcome based on the overall filter configuration. In general, logs are ingested unless they are explicitly excluded, while environments that rely solely on include filters ingest logs only when a match occurs.
Include Filters
You can add include filters to specify which resources are eligible for log ingestion, such as a specific resource type or application. Logs that match the include filter criteria are forwarded to the log ingestion process.
Exclude Filters
You can add exclude filters to prevent logs from specific resources, resource types, or attributes from being ingested. Logs that match an exclude filter are dropped and are not forwarded to the log ingestion process.
Available parameters
| Attributes | Comparison operator | Value example |
| Message | RegexMatch, RegexNotMatch. | Regular expression |
Log Fields
You can configure Log Fields (tags) to send additional metadata with the logs.
Available parameters
| Method | Key example | Value example | Description |
| Static | “Customer” | “Customer_XYZ” | |
| Dynamic(REGEX) | “Host” | “host=*” | The query will run on the message field. |
| LM Property(Token) | “Device” | “##system.deviceId##” |
Note: You can use the optional resource_type property to define the resource type applied to all ingested logs.
The resource type value that you specify is used for all logs. If the value is not specified, the system assigns a resource type based on the value of the predef.externalResourceType field in the resource settings.
Sensitive Data Masking
Sensitive data masking enables you to mask sensitive information before logs are ingested into LM Logs. This prevents exposure of sensitive data, such as personally identifiable information (PII), while preserving log usability for analysis and alerting.
The Log Files LogSource includes a predefined set of regular expressions that identify common sensitive data patterns. When sensitive data masking toggle switch is enabled, log content that matches these patterns is masked before ingestion.
The following table lists the predefined regular expressions that are masked when sensitive data masking is enabled:
| Description | Data Type | Regex Pattern | Masked Value |
|---|---|---|---|
| Detects and masks email addresses | (?i)([a-z0-9._%+\-]+)@([a-z0-9.\-]+\.[a-z]{2,}) | [REDACTED_EMAIL] | |
| Matches IPv4 addresses (e.g., 192.168.1.1) | ipv4 | \b(?:(?:25[0-5]\|2[0-4]\d\|1?\d?\d)\.){3}(?:25[0-5]\|2[0-4]\d\|1?\d?\d)\b | [REDACTED_IP] |
| Matches IPv6 addresses in various formats | ipv6 | (?i)\b(?:[0-9a-f]{1,4}:){7}[0-9a-f]{1,4}\b\|\b(?:[0-9a-f]{1,4}:){1,7}:[0-9a-f]{1,4}\b\|\b(?:[0-9a-f]{1,4}:){1,7}:\b\|\b::[0-9a-f]{1,4}(?::[0-9a-f]{1,4}){0,6}\b | [REDACTED_IP] |
| Matches IPv4-mapped IPv6 addresses (::ffff:x.x.x.x) | ipv6_ipv4_mapped | (?i)::ffff:(\d{1,3}\.){3}\d{1,3} | [REDACTED_IP] |
| Matches credit card numbers (13-19 digits with optional spaces/dashes) | cc_loose | \b(?:\d[ -]*?){13,19}\b | [REDACTED_CC] |
| Matches common credit card brands (Visa, MasterCard, Amex, Discover) | cc_common_brands | \b(?:4[0-9]{12}(?:[0-9]{3})?\|5[1-5][0-9]{14}\|3[47][0-9]{13}\|6(?:011\|5[0-9]{2})[0-9]{12})\b | [REDACTED_CC] |
| Matches CVV/CVC codes in various formats | cvv | (?i)(?:\b(CVV\|CVC\|CVV2)\b\s*[:=]?\s*\d{3,4}\|”(?:(CVV\|CVC\|CVV2))”\s*:\s*”[0-9]{3,4}”) | [REDACTED_CVV] |
| Matches US Social Security Numbers (xxx-xx-xxxx) | us_ssn | \b\d{3}[- ]?\d{2}[- ]?\d{4}\b | [REDACTED_SSN] |
| Matches International Bank Account Numbers (IBAN) | iban | \b[A-Z]{2}\d{2}[A-Z0-9]{11,30}\b | [REDACTED_IBAN] |
| Matches global phone numbers in E.164-like format | phone_e164 | \b\+?[1-9]\d{9,14}\b | [REDACTED_PHONE] |
| Matches AWS Access Key IDs (AKIA…) | aws_akid | \bAKIA[0-9A-Z]{16}\b | [REDACTED_AWS_KEY_ID] |
| Matches AWS Secret Access Keys (40+ character base64) | aws_secret | \b[A-Za-z0-9\/+=]{40,}\b | [REDACTED_AWS_SECRET] |
| Matches Authorization headers with Bearer tokens | auth_header_bearer | (?i)\bAuthorization\s*:\s*Bearer\s+[A-Za-z0-9\-._~+/=]+ | Authorization: Bearer [REDACTED_TOKEN] |
| Matches Bearer tokens in generic contexts | bearer | (?i)\b(bearer\s+)([A-Za-z0-9\-._~+/=]+) | [REDACTED_TOKEN] |
| Matches JSON Web Tokens (JWT) | jwt | \beyJ[A-Za-z0-9_\-]+\.[A-Za-z0-9_\-]+\.[A-Za-z0-9_\-]*\b | [REDACTED_JWT] |
| Matches Basic Auth credentials embedded in URLs | basic_auth_url | https?:\/\/[^\/\s:@]+:[^@\s]+@ | https://[REDACTED]@ |
| Matches PEM-encoded private keys (multiline) | pem_private_key | (?s)—–BEGIN [A-Z ]*PRIVATE KEY—–[\s\S]*—–END [A-Z ]*PRIVATE KEY—– | [REDACTED_PRIVATE_KEY] |
| Matches Java session IDs (JSESSIONID) | cookie_jsessionid | (?i)\b(JSESSIONID=)([A-Za-z0-9\-]{16,128}) | [REDACTED_SESSION] |
| Matches generic session cookies (SID, SESSIONID, PHPSESSID) | cookie_generic_session | (?i)\b(SID\|SESSIONID\|PHPSESSID)=([A-Za-z0-9\-]{8,128}) | [REDACTED_SESSION] |
| Matches token parameters in query strings or request bodies | generic_token | (?i)\b(token\|id_token\|access_token\|refresh_token)\b\s*=\s*\S+ | [REDACTED] |
| Matches GPS coordinates (latitude, longitude) | gps_coords | \b-?(?:[1-8]?\d(?:\.\d+)?\|90(?:\.0+)?),\s*-?(?:1[0-7]\d(?:\.\d+)?\|[1-9]?\d(?:\.\d+)?\|180(?:\.0+)?)\b | [REDACTED_LATLON] |
| Matches IMEI or device ID numbers (15 digits) | imei | (?i)\b((?:IMEI\|device[_-]?id)\b[^A-Za-z0-9]{0,10})(\d{15}) | [REDACTED_IMEI] |
| Matches unquoted key:value pairs for sensitive keys (password, secret, etc.) | colon_kv_unquoted | (?i)((?:^\|\\n\|\n\|[^a-zA-Z0-9_]))(password\|passwd\|pwd\|pass\|token\|secret\|apikey\|api[_-]?key)\s*:\s*([^\s,}”\\]+) | [REDACTED] |
| Matches password fields in key=value format | kv_password | (?i)\b([A-Za-z0-9._-]*password[A-Za-z0-9._-]*)\b\s*=\s*[^&\s]+ | [REDACTED] |
| Matches API key fields in key=value format | kv_apikey | (?i)\b(api[_-]?key\|apikey)\b\s*=\s*[^&\s]+ | [REDACTED] |
| Matches token fields in key=value format | kv_token | (?i)\b([A-Za-z0-9._-]*token[A-Za-z0-9._-]*)\b\s*=\s*\S+ | [REDACTED] |
| Matches sensitive fields in JSON format (“password”:”…”, etc.) | json_pw | (?i)”(password\|passwd\|pwd\|pass\|token\|secret\|apikey\|api[_-]?key)”\s*:\s*”[^”]*” | [REDACTED] |
