LogDNA is now Mezmo!
LogDNA has recently become Mezmo. As you access technical resources like our API, Code Libraries, and GitHub repositories, you will continue to see references to LogDNA for a short time as we update our new name across all our resource channels.
As Mezmo ingests your logs, it automatically parses information from your log lines, including string components, source information, application information, JSON objects, and user-specified metadata. This topic describes the various types of information that Mezmo parses, along with notes on how it is parsed.
Consistent Value Types Expected
If your parsed fields contain inconsistent value types, field parsing may fail, but the line will be preserved if possible. For example, if a line is passed with a
metaobject, such as
String, any subsequent lines with
meta.myfieldmust have `
Stringas the value type. This applies to all parsed fields, including JSON.
Most log line strings contain three components: Message, Timestamp, and Log Level.
Message is a string that represents the core descriptive component of a log line. It is usually preceded by timestamp and log level. A message typically contains a mixture of static and variable substrings, and is human-readable. For example:
User [email protected] requested /API/accountdetails/
Timestamp is required for all ingested log lines. For Mezmo log ingestion to correctly parse a timestamp, it should follow the ISO 8601 format.
Log level typically follows timestamp and is automatically parsed. Mezmo log ingestion parses common log level formats, such as a timestamp followed by a separator followed by the log level. Common log levels include:
* CRITICAL * DEBUG * EMERGENCY * ERROR * FATAL * INFO * SEVERE * TRACE * WARN * ALERT
Mezmo also parses source information metadata from loglines, which is listed in the All Sources menu in the web app. The only required parameter is hostname.
A hostname is the name of the log line source, and is automatically parsed by [the Mezmo Agent](doc:introducing-the-agent}, as well as Syslog-based ingestion. However, when you are sending log lines for ingestion with the REST API or a code library , you must specify the host name.
You can use a tag to group lines, and more than one tag can be applied to a single line. Tags are listed in the All Tags menu in the web app. Tagging is supported by both the [the Mezmo Agent](doc:introducing-the-agent} as well as custom-template supported Syslog-based ingestion, such as rsyslog or syslog-ng.
Other optional source information includes:
* IP address * MAC address
In addition to source information, LogDNA can also parse application information from log lines. The [Mezmo Agent](doc:introducing-the-agent} automatically parses the application name as the filename (for example:
error.log) while Syslog-based ingestion uses the syslog-generated
APP-NAME tag. For the REST API and code libraries, you must specify the app name.
Mezmo automatically parses certain types of log lines that enable the use of field search for those lines. For a list of supported log types, check out the topic for Auto-Parsing Logs, while Custom Parsing & How to Parse Logs provides more information about custom configurations.
Data Size Measurement for JSON Parsing
Be aware that the size of sent log data can increase after the JSON string is parsed in Node.js. Measurement is based on how much data is ingested into Mezmo, after it is parsed as JSON, and not how much data is sent in a line.
As long as the log message ends with a right curly-brace character,
} , Mezmo will parse your last JSON object in the log message, even if the JSON object does not span the entire message. If you don’t want Mezmo to parse your JSON object, you can append an additional character after the right curly brace, such as a period:
If your JSON contains a
message field, Mezmo will use that field for display and search in the log viewer. If you include a
level field, Mezmo will also parse out, and override any existing, log levels.
For JSON parsed lines, Mezmo uses a number of reserved fields to keep track of specific types of data. Using the reserved fields in your root JSON object will result in an underscore,
_ , prepended to those fields inside the context menu. For example,
status is stored as
_status. However, for the purpose of searching in the Mezmo web app, you don’t need to include the underscore character to search for these fields. For example, if you search for
status:200, this will return results for both
status and ``_status```.
These are common reserved fields:
* _source * _type * auth * bytes * connect * method * namespace * path * pod * request * response * service * space * status * timestamp * user
Protected field names cannot be used in your object, and are removed by Mezmo when encountered. The protected field names are:
* _account * _retention
Updated 13 days ago