v4.0.5

Bug

• Fix a bug that could result in a never-ending loop

v4.0.4

Bug fixes

• Handle crashes in the batch backend to prevent data loss and add a configurable timeout.

v4.0.3

Fixes

• Removed use_micros, it's not necessary when using protobufs

NOTE: This should not affect those who have put the setting in their config already, the behaviour is exactly the same.

v4.0.2

Performance Enhancement

• The batching module will now aggregate queued events and send them over the network as one unit.

NOTE: The old behaviour was to iterate over the queue sending each event one at a time.

v4.0.1

Fixes

• Fixed a race condition that would cause some tests to fail

v4.0.0

Features

• Added batching support, all connection types now support batching for asynchronous events - the default setting is to use batching with the combined connection module.

• Added support for microsecond time, riemannx will by default set the time_micros field now. It will not overwrite the time field if you have manually given the time. If you are using a version of riemann that doesn't support time_micros (< 0.2.13) you can set the use_micro setting to false.

Fixes / Enhancements

• The API interface for connections has been cleaned up.

• Moved logic outside riemannx.ex to the individual connection backends.

Backwards Compatibility Breakage

• The legacy settings module and all related tests have been removed.

• If you are using a custom connection module in your project the api has changed slightly (mostly just gotten smaller)

v3.1.1

Features

• Added a legacy settings module for backwards compatibility, will be removed in next release.

v3.1.0 - Metrics

Enhancements

• You can now implement a metrics module if you want to send stats from riemannx elsewhere.

Fixes

• Mostly documentation fixes were made in this release, I also cleaned up the code-base a little which was mostly moving existing code around.

v3.0.2 - Split Configuration

Enhancements

• Configuration options are now split out based on connection type giving you more control over your pool sizes especially when it concerns combined connections.

• Custom config modules can now be created allowing you to change where these settings are read from as well as some of the logic behind them (for example if you don't like how we do event_host() then write an extension module that changes it). You might want to store these configuration options in a DB so a front-end can show them, add them to your DB and alter the functions to read the right keys!

Notes

• v3.0.0 and v3.0.1 were development versions and therefore skipped, 2 revisions were required to iron out the split config. These were mostly related to dialyzer and credo, if you are interested the hotfix branches are still visible in the commit history (history is everything!)

• This version is NOT backwards compatible and requires changes in order to upgrade from 2.x.x, information about how to do this is included in the README.md.

Known Issues

• Some of the module documentation is wrong/out of date in this release and the custom config module feature is not documented, this will be addressed in the next release. For now the README.md file should have everything that you need and take the hex docs with a pinch of salt.

2.4.1 (Hotfix)

Bug Fixes

• Time is now put into the event map lazily so you can specify it yourself if required. If you don't set this, be aware that any delays between when you send the event and when riemannx generates the timestamp can be reflected in your graphs hence why this is a bug - you should be allowed to specify your own timestamp instead of the client overwriting it.

Clarification

Imagine you send events to Riemannx with a timestamp and its inbox builds up because somewhere else all the scheduler time is being eaten up - when the scheduler is finally free Riemannx will process all the events as quickly as possible and Riemannx overwrites your timestamps - the timestamps of the events will be very close to each other and not reflect at ALL the time the event was actually sent (the time they sat in the inbox won't be taken into account).

There are other scenarios where the client completely overriding your specified time can cause issues (aside from it just being plain rude!) so you are advised to upgrade if you set the timestamp yourself.