Response bodies, large objects, and data blobs in logs
Large data blobs embedded in logs. Full HTTP response bodies, entire database records, massive stack traces. Fields that add kilobytes to every log event.One log event with a 10KB response body, fired 100,000 times a day, is 1GB of storage for a single log pattern.
id: remove-response-body-order-servicename: Remove response body from order-servicedescription: Drop full HTTP response body. The order_id is sufficient for lookup.log: match: - resource_attribute: service.name exact: order-service - log_attribute: event exact: order.created transform: remove: - log_attribute: http.response.body
Before
After
Copy
{ "@timestamp": "2024-01-15T10:30:00Z", "service.name": "api-service", "severity_text": "ERROR", "error.message": "Connection refused", "error.stack_trace": "Error: Connection refused\n at Socket.connect (net.js:1141:16)\n at DBClient.connect (db.js:89:12)\n ... 200 more lines ..."}
Unlike infrastructure noise, excessive payloads are usually intentional logging decisions. The right fix is often to log less in the first place. The developer knows whether that response body is actually useful.
Tero flags fields that are obviously too large. Full HTTP response bodies, entire serialized objects, 500-line stack traces. These aren’t borderline cases - they’re kilobytes of data embedded in every log. Obviously wrong.