My personal blog
hauleth.dev
blog
fix: cleanup style
+26
-27
+25
-26
content/post/log-all-the-things.md
+25
-26
content/post/log-all-the-things.md
···
32
32
33
33
<small>* new levels</small>
34
34
35
-
This allow to provide finer graded verbosity control, however due to
36
-
compatibility reasons, in Elixir backends we need to translate these levels back
37
-
to "old" set of 4. The current table looks like:
35
+
This allow to provide finer graded verbosity control, due to compatibility
36
+
reasons, in Elixir backends we need to translate these levels back to "old" set
37
+
of 4. The current table looks like:
38
38
39
39
| Call level | What Elixir backend will see |
40
40
| -- | -- |
···
49
49
50
50
<small>* "translated" messages</small>
51
51
52
-
However we can set verbosity to all levels. This may be confusing during the
53
-
transition period, but we cannot change the behaviour until Elixir 2 (which is
54
-
not happening any time soon).
52
+
We can set verbosity to all levels. This may be confusing during the transition
53
+
period, but we cannot change the behaviour until Elixir 2 (which is not
54
+
happening any time soon).
55
55
56
56
Usage of the new levels is "obvious":
57
57
···
170
170
One of the biggest new features in the Elixir 1.11 is support for structured
171
171
logging. This mean that the log message do not need to be free-form string, but
172
172
instead we can pass structure, that can provide more machine-readable data for
173
-
processing in log aggregators. In Elixir 1.11 is is simple as passing map as a
173
+
processing in log aggregators. In Elixir 1.11 is simple as passing map as a
174
174
first argument to the `Logger` macros:
175
175
176
176
```elixir
···
276
276
}
277
277
```
278
278
279
-
Additionally you can see there that we can have more information available in
280
-
the structured log that would otherwise needed to be crammed somewhere into the
281
-
text message, even if it is not important in "regular" Ops observability.
279
+
You can see there that we can have more information available in the structured
280
+
log that would otherwise needed to be crammed somewhere into the text message,
281
+
even if it is not important in "regular" Ops observability.
282
282
283
283
This can raise a question - why not use metadata for such functionality, like it
284
284
is available in [`LoggerJSON`][] or [`Ink`][]? The reason is that their reason
···
300
300
},
301
301
# Metadata
302
302
%{
303
-
domain: [:otp, :elixir],
304
303
error_logger: %{tag: :error_msg},
305
304
report_cb: &GenServer.format_report/1
306
305
}
···
398
397
that metadata is for filtering?). It supports multiple possible relations
399
398
between the log domain and defined domain.
400
399
- `level` - allow filtering (in or out) messages depending on their level, in
401
-
both directions. So it will allow you to filter messages with higher level for
400
+
both directions. It will allow you to filter messages with higher level for
402
401
some handlers. Just remember, that it will not receive messages that will not
403
402
pass primary/module level.
404
403
- `progress` - filters all reports from `supervisor` and
···
410
409
411
410
### Modifying a message
412
411
413
-
Sometimes (hopefully rarely) there is need to alter messages in the system. For
414
-
example we may need to prevent sensitive information from being logged. When
415
-
using "old" Elixir approach you could abuse translators, but that was error
416
-
prone, as first successful translator was breaking pipeline, so you couldn't
417
-
just smash one on top and then keep rest working as is. With "new" approach and
418
-
structured logging you can just traverse the report and replace all occurences
419
-
of the unsafe data with anonymised data. For example:
412
+
Sometimes there is need to alter messages in the system. For example we may need
413
+
to prevent sensitive information from being logged. When using "old" Elixir
414
+
approach you could abuse translators, but that was error prone, as first
415
+
successful translator was breaking pipeline, so you couldn't just smash one on
416
+
top and then keep rest working as is. With "new" approach and structured logging
417
+
you can just traverse the report and replace all occurences of the unsafe data
418
+
with anonymised data. For example:
420
419
421
420
```elixir
422
421
def filter_out_password(%{msg: {:report, report}} = event, _opts) do
···
454
453
This snippet will replace all occurences of `:password` or `"password"` with
455
454
filtered out value.
456
455
457
-
There is disadvantage of such approach though - it will make all messages with
458
-
such fields allowed in case if your filter has `:filter_default` set to `:stop`.
459
-
That mean, that if you want to make some of them rejected anyway, then you will
460
-
need to manually add additional step to reject messages that do not fit into
461
-
your patterns. Alternatively you can use `filter_default: :log` and then use
462
-
opt-out logging. There currently is no way to alter the message and make other
463
-
filters decide whether log it or not (as of OTP 24).
456
+
The disadvantage of such approach - it will make all messages with such fields
457
+
allowed in case if your filter has `:filter_default` set to `:stop`. That mean,
458
+
that if you want to make some of them rejected anyway, then you will need to
459
+
manually add additional step to reject messages that do not fit into your
460
+
patterns. Alternatively you can use `filter_default: :log` and then use opt-out
461
+
logging. There currently is no way to alter the message and make other filters
462
+
decide whether log it or not (as of OTP 24).
464
463
465
464
## Summary
466
465