Key-value attributes

[felixbarny]

Hi,

I just learned about Chronix, so dare with me if I have overlooked that but is it possible to add key value metadata to the measurements like host:myhost, application:myapp? Like the InfluxDB format or the format described here: https://www.elastic.co/blog/elasticsearch-as-a-time-series-data-store.

Also it would be nice to have documentation about the http ingestion protocol and format, if available as well as the query api and aggregation functions.

[FlorianLautenschlager]

Hi,

it is possible to add arbitrary metadata (or as we call them: attributes) to a time series as well as to the measurements (by concept) . But currently the default time series implementation does not provide the opportunity to add metadata to single points. It only allows to add arbitrary metadata to a time series record (The key idea is to group single points into chunks and store them with the describing attributes in one record.)

An example could look like this:

time series record
{
host:myhost
application:myapp
arbitraryMetadata:"Every type supported by solr"

start:t1
end:tn
data:[(t1,v1),(t2,v2),..., (tn,vn)]
}

I will take a look at this (https://www.elastic.co/de/blog/elasticsearch-as-a-time-series-data-store) and post my thoughts here.

Also it would be nice to have documentation about the http ingestion protocol and format, if available as well as the query api and aggregation functions.

I agree. It's on my list.

[felixbarny]

That data model looks reasonable. I suppose the end timestamp does not have to be set when creating the record, or does it? Aggregations also work across records so it's possible to aggregate all response_time metrics on host A which have the instance tag A,B or C, right?

What is the state of the grafana integration? I'm thinking about integrating ChronixDB to stagemonitor if the data model is compatible. Is there a lightweight client for ChronixDB? If not, the HTTP API documentation would be really helpful!

[FlorianLautenschlager]

The end timstamp is used when a query asks for time series e.g.

q=host:myhost AND metric:CPU AND start:NOW-1WEEK AND end:NOW-1DAY

Aggregations work across multiple records.

q=host:myhost AND metric:CPU AND start:NOW-1WEEK AND end:NOW-1DAY
//used to join the multiple records into a time series
fq=join=host,metric
//get the maximum, minimum, amount and signed difference per time series
fq=function=max;min;count;sdiff

What is the state of the grafana integration?

We will release a version within the next few days.

I'm thinking about integrating ChronixDB to stagemonitor

That's great!

Is there a lightweight client for ChronixDB?

What is a lightweight client in your mind?

[felixbarny]

The end timstamp is used when a query asks for time series

Does that mean that you can't query measurements which don't have a end date yet? When monitoring a web application, you typically don't know when the measurement ends until the server is shut down. Also, if the process is killed, you don't have a chance to set the end date.

With lightweight I mean that has no or at least few external dependencies and is relatively small in size. A counter example would be Elasticsearch. The official "client" is the whole >20MB Elasticsearch library + Lucene dependencies.

[felixbarny]

Another question: is Chronix' sum function more usable than the one in Elasticsearch and InfluxDB? See https://blog.raintank.io/how-to-effectively-use-the-elasticsearch-data-source-and-solutions-to-common-pitfalls/#sum

And: Are percentile aggregations supported?

[FlorianLautenschlager]

Does that mean that you can't query measurements which don't have a end date yet? When monitoring a web application, you typically don't know when the measurement ends until the server is shut down. Also, if the process is killed, you don't have a chance to set the end date.

I don't know if i get you right. A measurement is a pair of timestamp and value. Hence a measurement always has a timestamp.

There is already a client (currently only java) that has only a few external dependencies (5).

Chronix' sum function currently works for a single time series. It easily sum up all values, e.g. total time of single executions. We have some code snippets that handle the problem non equal distance time series, e.g. sum up different time series. Sadly this is currently not released.

[felixbarny]

I'm refering to the end: tn timestamp of a time series record. I'm a bit confused about when I have to set the value. When initially creating the time series record I don't know when the series will end.

[FlorianLautenschlager]

Ah i understand. No there is not just one record per time series there are multiple. Image you have a process that collects metrics (every second) and sends them every 5 minutes to Chronix. Than you will have records with time series chunks of size 5 minutes (300 Points). And this records have a start and end.

[felixbarny]

I see. But when you want live metrics, most of the time you probably will send one data point per time series record. Does Chronix merge those individual records of a series or does sending single data points have negative impacts like requiring more disk space, slower queries etc.?

[FlorianLautenschlager]

You are right. Records with small chunks lead to a higher storage demand but in some cases faster queries except tiny chunks (only a few points). Records with larger chunks lead to a higher compression rate but some queries might be slower.

Currently the logic for storing records with ideal chunks is outside of Chronix. But a feature (like OpenTSDBs compaction) is planned for release 0.3.

[felixbarny]

I think hiding this implementation detail would be a really big step. I think Chronix can make better decisions about how large chunks should be than the client and you would not have to choose between either better performance via chunks or live data wich only one data point per record. Also it would greatly improve usability as users would not have to know about the relatively uncommon attributes

start:t1
end:tn
data:[(t1,v1),(t2,v2),..., (tn,vn)]

You could even implement an API which mimics OpenTSDB's and/or InfluxDB's ingestion format which would make switching to Chronix very easy as all tools which can report to those DBs would automatically also be compatible with Chronix.

Just ideas :)