   the time you will want to define (at least) two separate clauses for each
   event callback, one for the "before" and one for the "after" callbacks.
 
-  All event callbacks are run in the same process that calls the `instrument/3`
+  All event callbacks are run in the same process that calls the `c:instrument/3`
   macro; hence, instrumenters should be careful to avoid performing blocking actions.
   If an event callback fails in any way (exits, throws, or raises), it won't
   affect anything as the error is caught, but the failure will be logged. Note

  called like this:

      require MyApp.Endpoint
      MyApp.Endpoint.instrument :render_view, %{view: "index.html"}, fn ->
        # actual view rendering
      end

  All the instrumenter modules that export a `render_view/3` function will be
  notified of the event so that they can perform their respective actions.


  ## Endpoint API

  In the previous section, we have used the `c:config/2` function that is
  automatically generated in your endpoint. Here's a list of all the functions
  that are automatically defined in your endpoint:

    * for handling paths and URLs: `c:struct_url/0`, `c:url/0`, `c:path/1`,
      `c:static_url/0`, and `c:static_path/1`;
    * for handling channel subscriptions: `c:subscribe/2` and `c:unsubscribe/1`;
    * for broadcasting to channels: `c:broadcast/3`, `c:broadcast!/3`,
      `c:broadcast_from/4`, and `c:broadcast_from!/4`
    * for configuration: `c:start_link/0`, `c:config/2`, and `c:config_change/2`;
    * for instrumentation: `c:instrument/3`;
    * as required by the `Plug` behaviour: `c:Plug.init/1` and `c:Plug.call/2`.

  ## Instrumentation

  Phoenix supports instrumentation through an extensible API. Each endpoint
  defines an `c:instrument/3` macro that both users and Phoenix internals can call
  to instrument generic events. This macro is responsible for measuring the time
  it takes for the event to be processed and for notifying a list of interested
  instrumenter modules of this measurement.
