telemetry_influxdb v0.1.0 TelemetryInfluxDB View Source

Telemetry reporter for InfluxDB compatible events.

To use it, start the reporter with the start_link/1 function, providing it a list of Telemetry event names:

   TelemetryMetricsInfluxDB.start_link(
     events: [
       %{name: [:memory, :usage]},
       %{name: [:http, :request]},
     ]
   )

Note that in the real project the reporter should be started under a supervisor, e.g. the main supervisor of your application.

By default, the reporter sends events through UDP to localhost:8086.

Note that the reporter doesn't aggregate events in-process - it sends updates to InfluxDB whenever a relevant Telemetry event is emitted.

Configuration

Possible options for the reporter:

  • :reporter_name - unique name for the reporter. The purpose is to distinguish between different reporters running in the system. One can run separate independent InfluxDB reporters, with different configurations and goals.
  • :protocol - :udp or :http. Which protocol to use for connecting to InfluxDB. Default option is :udp.
  • :host - host, where InfluxDB is running.
  • :port - port, where InfluxDB is running.
  • :db - name of InfluxDB's instance.
  • :username - username of InfluxDB's user that has writes privileges.
  • :password - password for the user.
  • :events - list of Telemetry events' names that we want to send to InfluxDB. Each event should be specified by the map with the field name, e.g. %{name: [:sample, :event, :name]}. Event names should be compatible with Telemetry events' format.
  • :tags - list of global tags, that will be attached to each reported event. The format is a map, where the key and the value are tag's name and value, respectively. Both the tag's name and the value could be atoms or binaries.

Notes

For the HTTP protocol, worker_pool is used for sending requests asynchronously. Therefore the HTTP requests are sent in the context of the separate workers' pool, which does not block the client's application (it is not sent in the critical path of the client's process). The events are sent straightaway without any batching techniques. On the other hand, UDP packets are sent in the context of the processes that execute the events. However, the lightweight nature of UDP should not cause any bottlenecks in such a solution.

Once the reporter is started, it is attached to specified Telemetry events. The events are detached when the reporter is shutdown.

Link to this section Summary

Link to this section Types

Link to this type

event_measurements()

View Source
event_measurements() :: map()
Link to this type

event_metadata()

View Source
event_metadata() :: map()
Link to this type

event_name()

View Source
event_name() :: [atom()]
Link to this type

event_spec()

View Source
event_spec() :: map()
Link to this type

handler_id()

View Source
handler_id() :: term()
Link to this type

option()

View Source
option() ::
  {:port, :inet.port_number()}
  | {:host, String.t()}
  | {:protocol, atom()}
  | {:reporter_name, binary()}
  | {:db, String.t()}
  | {:username, String.t()}
  | {:password, String.t()}
  | {:events, [event()]}
  | {:tags, tags()}
Link to this type

options()

View Source
options() :: [option()]

Link to this section Functions