Migrating to the new query syntax

We're about to migrate you to the new query syntax for logging. This will allow you to query your logs more efficiently.

The new query syntax has impact on the following logging areas. Take a look at each of them to see the notable changes:

• Query language
• Saved views
• Log triggers
• Long term storage

Make sure you are aware of all these changes, and contact support to start the migration process.

Query Language

The query language changes in a few significant ways. Here are some of the most notable changes:

1. No more attributes. prefix — Custom attributes can now be queried directly. Instead of attributes.user_id_int=12345, simply use user_id=12345.

2. No more type suffixes — You no longer need to append _int, _string, or _double to attribute names. The query engine automatically determines the correct type based on the operator you use.

3. Nested JSON support — Query nested objects using dot notation: user.email="user@example.com" and array elements by index: user.roles.0=admin.

4. OR logic and parentheses — Build complex queries with explicit OR operators and parentheses for grouping: severity=error AND (hostname=web-1 OR hostname=web-2).

5. List syntax replaced — The field=[value1, value2] syntax is replaced with OR statements, which is more flexible and supports all operators, not just exact matches.

For example:

Old syntax:

message:"API request" attributes.user_id_int=12345 severity=[info, warn]

New syntax:

message:"API request" user.id=12345 (severity=info OR severity=warn)

For complete details on the new syntax, see our query syntax documentation. To reference the old syntax, see the legacy query syntax documentation.

Saved Views

Your saved views will be updated to the new query syntax. After the migration, check the views for any issues.

Log Triggers

Your log triggers will be updated to the new query syntax. After the migration, check the triggers for any issues.

Triggers that were open, will be closed, and you'll get new issues after the migration.

Long Term Storage

We're making a change to the output of the long term storage exports.

Instead of an attributes field that contains a 1-dimensional map of attribute key-values, we'll export a Stringified JSON object with all the attributes.

For example:

Old output:

{
  "timestamp": "1970-01-01 00:04:00.000",
  "source_id": "source-json",
  "hostname": null,
  "group": "group",
  "severity": "info",
  "message": null,
  "attributes": {
    "user.name": "alice",
    "user.id": "123",
    "request_id": "abc-123",
    "status_code": "200",
    "response_time": "45.67",
    "success": "true"
  }
}

New output:

{
  "timestamp": "1970-01-01 00:04:00.000",
  "hostname": null,
  "group": "group",
  "severity": "info",
  "message": null,
  "source_id": "source-json",
  "attributes": "{\"user\": {\"name\":\"alice\", \"id\":\"123\"},\"request_id\":\"abc-123\",\"status_code\":200,\"response_time\":45.67,\"success\":true}"
}