-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[PLATFORM-474]: [Auth0Ex] Make observability of cache set errors better #87
[PLATFORM-474]: [Auth0Ex] Make observability of cache set errors better #87
Conversation
I am REALLY unsure about how I introduced statix into the library. |
I would put statix as an optional dependency, with a
Trying it I noted that also the following optional modules should be adapted to prevent unexpected errors during compilation:
|
lib/prima_auth0_ex/token_provider/encrypted_redis_token_cache.ex
Outdated
Show resolved
Hide resolved
I choose to remove
Yes it makes sense, I'll try to fix it |
About this
I am not so sure it makes sense, we could make the server crash but what would be gain? |
It's a good idea to use a generic library like this one, but this is not so convenient for our downstream dependencies.
and remember to configure it at the startup:
If the library adds some metrics, we need to remember to add them to all the clients. |
You are right, I created a module which could serve as a pre-defined statix handler. config :statix, PrimaAuth0Ex.Telemetry.Statix,
enabled: false,
host: "statsd",
prefix: "prima_auth0_ex",
tags: ["env:#{config_env()}"] Edit: reword |
Statix.increment("retrieve_token:success", count, tags: ["audience:#{audience}"]) | ||
end | ||
end | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure.. in this way we need to duplicate the Statix configuration, the application will open another socket for datadog instead of using the existing one, and it still need to call "setup" manually.
I see some options:
- We could make the reporter module configurable in the setup and use it in the handler, example:
def setup do
reporter = Application.get_env(:prima_auth0_ex, :reporter_module)
if reporter != nil do
:ok =
:telemetry.attach_many(
"auth0-handler",
[
[:prima_auth0_ex, :retrieve_token, :failure],
[:prima_auth0_ex, :retrieve_token, :success]
],
&Handler.handle_event/4,
%{reporter: reporter}
)
end
end
and then in the handler:
def handle_event([:prima_auth0_ex, :retrieve_token, :failure], %{count: count}, %{audience: audience}, %{reporter: reporter}) do
reporter.increment("retrieve_token:failure", count, tags: ["audience:#{audience}"])
end
Finally we can call setup
from PrimaAuth0Ex.Application
.
- Instead of Statix, we could use instrument. It stores the reporter module in a genserver and provides a good API, backed by Statix. But then we need to update our projects to use Instrument...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can easily detect the Statix module too, for instance taking the first configured module:
iex> Application.get_all_env(:statix)
[
{Vito.Statix, ...}
]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally, I wouldn't add any "complicated" module detection I like the idea of letting the user provide a telemetry reporter so that they can leverage the pre-defined handler! It seems the simplest thing we can offer to avoid having users write a lot of boiler-plate code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great 👍
I would just document the new telemetry_reporter
settings in the README.
Regarding this I agree with you, having logging and telemetry is enough. |
https://prima-assicurazioni-spa.myjetbrains.com/youtrack/issue/PLATFORM-474
This PR tries to enhance the observability of the library by
Moreover, we are considering the possibility of adding a flag to make the service crash if something goes wrong, which could be used in staging/qa to detect certain errors more easily.