Examples of log patterns identified and optimized by Nimbus.
Logs with common message patterns
These are high volume log events that repeat most of their content. For most applications most of the time, this will be the primary driver of log volume. Examples include health checks and heart beat notifications.
[ {"ddsource":"nodejs","host":"itemrefresh-0","message":"refresh item catalogue for itemId: ITEM470","path":"/","service":"itemrefresh","status":"info","timestamp":"2023-11-23T00:16:09.970Z" }, {"ddsource":"nodejs","host":"itemrefresh-0","message":"refresh item catalogue for itemId: ITEM8185","path":"/","service":"itemrefresh","status":"info","timestamp":"2023-11-23T00:16:09.997Z" }, {"ddsource":"nodejs","host":"itemrefresh-0","message":"refresh item catalogue for itemId: ITEM7594","path":"/","service":"itemrefresh","status":"info","timestamp":"2023-11-23T00:16:10.010Z" },// 37 more messages ...]
97.5% event volume reduction
79% ingest volume reduction
Logs with common identifiers
These are logs that describe a sequence of related events. These sequences usually have some sort of common identifier like a transactionId or a jobId. Examples include a background job and business specific user flows.
75% reduction in event volume
4% reduction in ingest volume
Multi-Line Logs
Many times, an application will emit a single log across multiple lines such as the case with a JSON log. Unless you specifically account for this, most logging agents will consume each newline as a separate log event. Nimbus can identify when this happens and stitch these logs back together.
- name: checkout
type: reduce
rules:
# process when service is exactly equal to "checkout"
process_when:
- key: service
op: EQUAL
val: checkout
# make sure these fields are still available at the "top level" instead of being nested
pull_up:
- message.transactionId
- message.customerId
# group all logs by the following top level keys
group_by:
- customerId
- transactionId
# specify the message field, the highlighted body of the log
msg_field: message.msg
# remove unecessary timestamp fields
remove:
- timestamp
- message.timestamp
# details how custom top level keys will be merged
merge_strategies:
transactionId: discard
customerId: discard