dcdb issueshttps://gitlab.lrz.de/dcdb/dcdb/-/issues2024-02-09T11:08:03+01:00https://gitlab.lrz.de/dcdb/dcdb/-/issues/23Document whitespace insertion in sensor ID naming in Cassandra DB2024-02-09T11:08:03+01:00Philipp Friesephilipp.friese@tum.deDocument whitespace insertion in sensor ID naming in Cassandra DBDirectly querying DCDB-aggregated data from the Cassandra DB shows unexpected sensor ID name padding.
Given a `dcdbpusher` configured only with the `procfs` plugin, and the stock `procfs` plugin configuration present in [`procfs.conf`](h...Directly querying DCDB-aggregated data from the Cassandra DB shows unexpected sensor ID name padding.
Given a `dcdbpusher` configured only with the `procfs` plugin, and the stock `procfs` plugin configuration present in [`procfs.conf`](https://gitlab.lrz.de/dcdb/dcdb/-/blob/development/dcdbpusher/config/procfs.conf), the following sensor IDs are inserted into the database:
```
cassandra@cqlsh> select sid,ws, count(*) from dcdb.sensordata group by sid,ws;
sid | ws | count
------------------------------+------+-------
/test/ctxt | 2821 | 18
/test/meminfo/anonpages | 2821 | 12
/test/vmstat/nr-file-pages | 2821 | 6
/test/col-user | 2821 | 12
/test/vmstat/nr-dirty-thresh | 2821 | 9
/test/cpu36/col-idle | 2821 | 18
/test/col-idle | 2821 | 18
/test/meminfo/memfree | 2821 | 6
```
Since the `sid` values are right-aligned, e.g. sensor ID `/test/col-idle` contains two trailing white-spaces, i.e. `'/test/col-idle '`. This is deliberate behaviour, as stated in a comment in function [`SensorId::mqttTopicConvert`](https://gitlab.lrz.de/dcdb/dcdb/-/blob/development/lib/src/sensorid.cpp?ref_type=heads#L48-59):
```cpp
> lib/src/sensorid.cpp:L48-59
/* Fill string with trailing whitespace to 128bits so Cassandra's ByteOrder
Partitioner creates proper numerically sorted tokens */
if (data.size() < 16) {
data.append(16 - data.size(), ' ');
}
```
I found this after digging through the code for some time in search of an explanation for the trailing whitespaces. It might be helpful to document this so that other users not familiar with these intricacies are not surprised.https://gitlab.lrz.de/dcdb/dcdb/-/issues/21Management of default TTL values2019-12-17T14:08:10+01:00Ghost UserManagement of default TTL valuesAs of now, the values of a sensor always use its own TTL. If this value is defined for the sensor, the data will expire according to it, otherwise a default TTL of 0 is used, and the data never expires. The TTL value defined in the Colle...As of now, the values of a sensor always use its own TTL. If this value is defined for the sensor, the data will expire according to it, otherwise a default TTL of 0 is used, and the data never expires. The TTL value defined in the Collect Agent configurations is used only for sensors which are not published (no entry in the publishedsensors table).
We should evaluate whether it would be convenient or not to use the Collect Agent's TTL value also when a sensor is published, but has no TTL value associated to it, and not only when the sensor is not published at all.https://gitlab.lrz.de/dcdb/dcdb/-/issues/17CI/CD Runners2020-05-02T09:49:09+02:00Ghost UserCI/CD RunnersSet up Runners for dcdb and dcdbpusher CI/CD pipelines.
Pipelines are switched off for the moment until I figured out how to properly set up a runnerSet up Runners for dcdb and dcdbpusher CI/CD pipelines.
Pipelines are switched off for the moment until I figured out how to properly set up a runnerhttps://gitlab.lrz.de/dcdb/dcdb/-/issues/16Automatic tests (Wishlist)2018-12-21T11:19:18+01:00Ghost UserAutomatic tests (Wishlist)Would be nice to have some sort of automatic build checks and test cases to detect errors (also for dcdbpusher). Perhaps we could set up GitLabs CI/CD for this.Would be nice to have some sort of automatic build checks and test cases to detect errors (also for dcdbpusher). Perhaps we could set up GitLabs CI/CD for this.https://gitlab.lrz.de/dcdb/dcdb/-/issues/10DCDB installation with rpm2018-04-26T14:28:05+02:00Daniele TafaniDCDB installation with rpmhttps://gitlab.lrz.de/dcdb/dcdb/-/issues/8Move standard command line arguments in dcdblib2018-04-25T13:36:33+02:00Daniele TafaniMove standard command line arguments in dcdblibStandard command line args (like -h hostname, -u user, -p pass) should be moved to dcdblib and only dedicated ones should remain within respective tools (e.g., sensor names, time ranges).Standard command line args (like -h hostname, -u user, -p pass) should be moved to dcdblib and only dedicated ones should remain within respective tools (e.g., sensor names, time ranges).https://gitlab.lrz.de/dcdb/dcdb/-/issues/3Namespace for sensor names2019-03-26T16:41:23+01:00Ott, MichaelNamespace for sensor namesImplement a namespace for sensor names. This should then allow for using identical sensor names for e.g. different clusters.Implement a namespace for sensor names. This should then allow for using identical sensor names for e.g. different clusters.https://gitlab.lrz.de/dcdb/dcdb/-/issues/2Retrieve earliest and latest timestamps for a sensor2019-03-26T16:41:23+01:00Ott, MichaelRetrieve earliest and latest timestamps for a sensorImplement a function in dcdblib (and probably dcdbquery) to retrieve the earliest and latest timestamp for a given sensor.Implement a function in dcdblib (and probably dcdbquery) to retrieve the earliest and latest timestamp for a given sensor.