Ex_activity - web app logging with Elixir and Ecto

Your Libraries & OS Mentoring Libraries
, ,
1

Repo:

Docs:
https://hexdocs.pm/ex_activity

This is our first stab at a Elixir library and our very first OSS contribution! We hope it can be of use to anyone, we are using it ourselves in production.

We created the lib because after 10 years of developing PHP apps we had settled with a structured way to gather logs from our apps, in a database. We really liked this setup, so we ported it to use in our Elixir/Phoenix apps.

Usage is pretty straightforward, where you want to log, say in an API UserController, you just write:

ExActivity.log(%ExActivity.Log{
  type: "api_call",
  action: "UserController/list" ,
  result: "user_count: 10"
})

It will write the data to the database in a Task.start_link way so it interferes as little as possible with your our ”-second response times. That way, we can log enough data and still get max performance. The first update that is coming is to make the data attribute accept structs to the log entry.

Feedback is welcome!

5 Likes
2

Hello @jeroenbourgois!

Its much easier to get feedback when you provide necessary links to sources and library :wink:

Also it might help to better explain what your app is meant to do and whom you are refering to by “we”.

1 Like
4

@jeroenbourgois: Here are my ideas:

  1. Add Logger backend, see: “Custom backends” section.
  2. Add controller field.
  3. Fetch controller and action name from conn, see: Phoenix.Controller.action_name/1 and Phoenix.Controller.controller_module/1
  4. Fetch header using: Plug.Conn.get_req_header/2 instead change all headers to map.

Note: You could save controller like:

alias Phoenix.Controller
# ...
controller_module = Controller.controller_module(conn)
"Elixir." <> module_string = Atom.to_string(controller_module)
# so we could do something like:
controller = String.to_existing_atom("Elixir." <> ex_activity_log.controller)
# do something with controller ...

Look at this case>
You could change it in to ways:

case headers[header] do
  nil -> ""
  value -> value # note do not call fetch again!
end
# or even simpler:
headers[header] || "" # because nil || "" returns: ""

For more information see: Kernel.||/2

In this line - you should have full call, please see: Avoid needless pipelines like the plague. code style rule by @lexmag.

Funny, but you could add pipe to another line

Here you have credo style guide and here its library that will look at your code with simple mix task.

Let me know what do you think about it. :slight_smile:

3 Likes
5

@Eiji thanks for your input! We are very new to the Elixir game so your styleguide comments are very welcome. I will look into it to make the library better!

3 Likes
6

Just a small reply, your proposals 2, 3 and 4 make a lot of sense. The first one, not so much to is. Here is why: we created the lib just for that specific reason: we did not want to use Logger, we had it at first (logging to a papertrail backend) but while this is great for all the out-of-the-box logs you get with Phoenix, we did not want that for ‘in controller’ logs.

That being said, after looking into the docs for custom backends, it might just be what we wanted in the first place :slight_smile: Do the logs you sent with Logger also happen in a different process, do you know that? If so, it might just be worthwhile to develop it as a custom backend which will make it much more portable and pluggable.

Again: thank you for your input!

PS: just because I am curious, if we were to get more info from the conn that is Phoenix specific, will we have Phoenix as a dependency? Not that it would be a big problem since we are using it in a Phoenix app to start from


2 Likes
7

Uh, why not? You can conditionally log or not based on the metadata about the logging call pretty easily
 o.O

conn is from Plug, not Phoenix, so you’d only need to depend on Plug (and that is only if you wanted to match the Conn directly, otherwise access it like a map and no dependency is needed).

8

@Eiji was also giving an example about getting more info from the controller with Phoenix.Controller.controller_module/1, hence my question about the dependency.

We will look into the logger backend

9

@jeroenbourgois: You could add it as optional dependency. :slight_smile: