Łukasz Jan Niemier
Łukasz Jan Niemier
Currently almost all metric handlers need to do something like: ```erlang maps:merge(CTags, maps:from_list(lists:zip(Tags, TagsV))) ``` Which is little bit PITA. What I am proposing is to do it for them...
Right now there is no naming unification in the application, traces are in root `oc_` namespace, `oc_span`, and `oc_trace`. At the same time all(?) metrics are under `oc_stat` namespace. This...
As a second parameter for the `ocp:with_span/2-3` we could access the same map as `oc_trace:start_span/2`, which would provide nicer API for setting such values.
While functions are nice, I think that for end user, macros could be more useful, as we could automatically add context information to the span, like: - module name -...
I could count on the fingers of the one had all situations when I have used raw `spawn`, in almost all situations I have encountered it was better to use...
This would be highly useful in situations like sending data through UDP (statsd metrics or HTTP-over-QUIC) or if we would like to utilise HTTP/2 to not open new TCP connection...
This would be simple checks with 4-value (more/less?) logic with values: - ok - warning - critical - unknown This would work similarly to [DataDog checks](https://docs.datadoghq.com/monitors/check_summary/).
- [x] Convert usage of `:error_logger` to `:logger` - [ ] Migrate `:console` backend to be defined as a formatter for `logger_std_h` - this will allow to use the same...
### Environment * Elixir & Erlang/OTP versions (elixir --version): 1.7.2 * Operating system: macOS ### Current behavior I wanted to create macro that would allow me to remove boilerplate over...