LogDNA can intelligently detects log types, parse them to display optimally, and more importantly index them in a way that makes keyword search fast and easy to use. Custom parsing rules can be configured for any proprietary formats as well.
LogDNA automatically parses the following log line types:
- Apache Common Log Format
- Apache Combined Log Format
- AWS CloudFront
- AWS CloudWatch
- AWS ELB
- AWS ECS
- AWS S3
- Docker Swarm
- Docker Cloud/Compose
- IIS Log
- Nginx Error Log Format
- Windows Events
As long as the log message ends in a }, your JSON object will be parsed, even if the JSON object does not span the entire message. If do not want your JSON object to be parsed, you can simply append an additional character after the ending } such as . a period.
If your JSON contains a
message field, that field will be used for display and search in the log viewer. We also parse out (and override any existing) log levels if you include a level field.
For JSON parsed lines, LogDNA uses a number of reserved fields to keep track of specific types of data. Please note that using the following reserved fields in your root JSON object will result in an underscore (_) prepended to those fields inside the context menu (e.g. internally status is stored as _status). However, you can still search normally inside our web app without being aware of this storage behavior (e.g. you can still just search status:200 as we will automatically search both status and _status). For reference, common reserved fields can be found below:
If you are custom log formats, you can create a custom parsing template to tell LogDNA's parsing engine how to parse your log lines. Refer to the documentation to learn more.
Nearly all log line strings contain the three components below.
Timestamp is required for all ingested log lines. As a general rule, if a timestamp follows the ISO 8601 format, it will be parsed correctly. LogDNA also accepts most other timestamp formats, but if your timestamp is not picked up correctly, let us know and we'll see what we can do.
Log level typically follows timestamp and is automatically parsed. We look for common formats, such as a timestamp followed by a separator followed by the log level. Common log levels include:
Message is a string that represents the core descriptive component of a log line and is usually preceded by timestamp and level. A message typically contains a mixture of static and variable substrings and allows for easy human interpretation. For example:
User [email protected] requested /API/accountdetails/
Source information metadata is also ingested alongside the log line and is displayed in the All Sources menu in the web app.
A hostname is the name of the source of the log line, and is automatically picked up by the LogDNA agent as well as syslog-based ingestion. However, a host must be specified when submitting lines via the REST API or code libraries.
A tag can be used to group lines and more than one tag can be applied to a given line. Tags show up under the All Tags menu in the web app. Tagging is supported by both the LogDNA agent as well as custom-template supported syslog-based ingestion, such as rsyslog or syslog-ng. At the time of writing, only source tags are currently supported, but more types are planned.
Other optional source information can be specified, such as
- IP address
- MAC address
In addition to source information, app information is also ingested. The LogDNA agent automatically parses the app name as the filename (e.g. error.log) while syslog-based ingestion uses the syslog-generated APP-NAME tag. For the REST API and code libraries, the app name must be specified.
Updated 3 months ago