Code Monkey home page Code Monkey logo

telemetry_influxdb's Introduction

telemetry_influxdb

InfluxDB reporter for Telemetry

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:

    TelemetryInfluxDB.start_link(
      events: [
        %{name: [:memory, :usage], metadata_tag_keys: [:host, :ip_address]},
        %{name: [:http, :request]},
      ]
    )

or put it under a supervisor:

children = [
  {TelemetryInfluxDB, [
    events: [
      %{name: [:memory, :usage], metadata_tag_keys: [:host, :ip_address]},
      %{name: [:http, :request]}
  ]}
]

Supervisor.start_link(children, ...)

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

Note that the reporter doesn't aggregate events in-process by default - it sends updates to InfluxDB whenever a relevant Telemetry event is emitted. See the :batch_size option below to configure this behavior.

Run test

Running the tests currently requires jq. Please make sure you have it installed before running the tests.

$ make test

It should setup the latest InfluxDB in docker for both v1 and v2 and runs all the tests against them.

Configuration

Possible options for the reporter:

Options for Any InfluxDB Version

  • :version - :v1 or :v2. The version of InfluxDB to use; defaults to :v1 if not provided
  • :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. InfluxDB v2 only supports :http for now.
  • :host - host, where InfluxDB is running.
  • :port - port, where InfluxDB is running.
  • :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. It is also possible to specify an optional list of metadata keys that will be included in the event body and sent to InfluxDB as tags. The list of metadata keys should be specified in the event data with the field metadata_tag_keys, e.g. %{name: [:sample, :event, :name], metadata_tag_keys: [:sample_meta, sample_meta2]}
  • :batch_size - the maximum number of events to send to InfluxDB at one time. (default 1)
  • :tags - list of global static 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.

V1 Only Options

  • :db - name of the location where time series data is stored in InfluxDB v1
  • :username - username of InfluxDB's user that has writes privileges. Only required in v1.
  • :password - password for the user. Only required for v1.

V2 Only Options

  • :bucket - name of the location where time series data is stored in InfluxDB v2
  • :org - workspace in InfluxDB v2 where a bucket belongs
  • :token - InfluxDB v2 authentication token used for authenticating requests. Must have write privileges to the bucket and org specified.

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).

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.

Events are sent straightaway without any batching techniques by default. If the :batch_size option is set to a value higher than 1, all events received since the previous batch will be sent in the next batch (up to a maximum of :batch_size events).

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

Copyright and License

TelemetryInfluxDB is copyright (c) 2019 Ludwik Bukowski.

TelemetryInfluxDB source code is released under MIT license.

See LICENSE for more information.

telemetry_influxdb's People

Contributors

abbradar avatar ludwikbukowski avatar marcdel avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

telemetry_influxdb's Issues

No metadata passed

Hi,
is there a way to pass telemetry events metadata to influxDB? I need also to gather some data from there and save into InfluxDB.

influxdata example?

Hi,
thanks for the repo.

do you have an example to connect to the influxdata service?

I tried with it

    TelemetryInfluxDB.start_link(
      events: [
        %{name: [:memory, :usage], metadata_tag_keys: [:host, :ip_address]},
        %{name: [:http, :request]},
        %{name: [:phoenix, :endpoint, :stop]}
      ],
      version: :v2,
      protocol: :http,
      org: "[email protected]",
      host: "https://us-west-2-1.aws.cloud2.influxdata.com",
      bucket: "my bucket",
      token:
        "mytoken"
    )

thanks again.

Publish 0.1.2 to hex.pm?

Do you have a timeframe for publishing the tagged 0.1.2 release to hex.pm? We'd like to be able to pull from there rather than GitHub if possible.

Thanks again for working through the big v2 support PR with us and getting that in!

Data aggregation

Hi @ludwikbukowski,

Thank you so much for providing this great library! :)

I would like to ask if there was any specific reason why you decided not to aggregate the data before pushing to InfluxDB?
Did you consider to implement the Telemetry.Metrics interface?

Thanks in advance!

Increase event throughput to InfluxDB

Hi there ๐Ÿ‘‹๐Ÿป,

I'm working with a team over at InfluxData that's using and has contributed to this library in the past. We're at the point now where we're sending so many events that they're stacking up and the workers aren't able to process them quickly enough to get through the whole queue.

I don't know if you had anything in mind around this, but one idea we had was to send events to InfluxDB in batches rather than one at a time. Here's a quick spike on what that batching process could look like: https://github.com/marcdel/batch_reporter_spike/blob/master/lib/batch_reporter.ex

We'd be happy to work on a PR if that's something you're open to!

InfluxDB 2.0 support

Thanks so much for creating this library! Looks like a really nice solution.

We'd like to be able to use it for an internal project that is using InfluxDB 2.0, but it currently supports only the 1.x API. The 2.0 API is a bit different (see https://v2.docs.influxdata.com/v2.0/api/#operation/PostWrite).

Ideally, this reporter would work with both InfluxDB 1.x and 2.0 to make it easier for people to upgrade to 2.0, and we're willing to do the work to make this happen. We'd like some direction from you before we go too far down the wrong road, though.

  1. Is 2.0 support something you're interested in for this library?
  2. If so, do you have any thoughts about what you'd like that to look like or how you'd like it structured?

At a high level, here's what we think needs to be done. There's probably more that we're not thinking of just yet.

  • The v2 API takes a bucket and one of org or orgID as params instead of the db param that 1.x takes. This will affect configuration, validation, and URL construction. The line protocol has not changed, so the payload format should work as-is.

  • UDP support is now done through a Telegraf plugin and does not support binding to a specific bucket/org as near as I can tell. So a UDP request would need to include that information somehow. This looks like the biggest change at first glance.

Disclaimer: I work for InfluxData, but I'm still relatively new and learning the APIs, so I may not have all the details right here.

Dependency Currency Conflict with Telemetry

Is there anything holding telemetry_influxdb back from updating the telemetry dependency to 1.0.0?

โžœ  ex_def git:(main) โœ— mix deps.get
Resolving Hex dependencies...

Failed to use "telemetry" (version 1.0.0) because
  broadway (version 1.0.1) requires ~> 0.4.3 or ~> 1.0
  broadway_rabbitmq (version 0.7.1) requires ~> 0.4.3 or ~> 1.0
  ecto_sql (version 3.7.1) requires ~> 0.4.0 or ~> 1.0
  ex_aws (version 2.2.8) requires ~> 0.4.3 or ~> 1.0
  horde (version 0.8.5) requires ~> 1.0.0 or ~> 0.4.0
  telemetry_influxdb (version 0.2.0) requires ~> 0.4.0
  mix.lock specifies 1.0.0

** (Mix) Hex dependency resolution failed, change the version requirements of your dependencies or unlock them (by using mix deps.update or mix deps.unlock). If you are unable to resolve the conflicts you can try overriding with {:dependency, "~> 1.0", override: true}

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.