While metrics are primarily quantitative measurements, dimensions are attributes that describe our data. For example, we following are all valid examples of dimensional data, for CPU usage:
Together these metrics form part of a metric's identity, and the above would be distinct from CPU usage data recorded for another hostname
blackbear, even though the data may have the same unit of measurement and CPU number.
DalmatinerDB allows for these dimensions to be used in queries, typically to refine the number of paths under observation. It is also possible to use wildcards as part of a metric path, in order to expand the number of paths under observation. This is made possible by the metric indexer.
It is the job of the metric indexer to store and maintain these dimensional data attributes. At a conceptual level, the query engine consults the indexer with the specific purpose of reducing a relational query to a more specific query consisting of a list of bucket/value pairs. These are then fetched concurrently from DalmatinerDB, by the query engine.
Delegating all of this responsibility to the indexer allows DalmatinerDB to remain independent from the indexing middleware. This also grants the freedom to choose storage technologies that are optimal for relational dimensional data, such as Postgres.
This indexer is provided out of the box, and is limited in capability.
This indexer is fast and has a broad capability set, however it requires a working Postgres installation and involves more configuration.
CREATE USER ddb WITH PASSWORD 'ddb'; CREATE DATABASE metric_metadata OWNER ddb; GRANT ALL ON DATABASE metric_metadata TO ddb; ALTER ROLE ddb WITH SUPERUSER;
The Postgres indexer requires a database schema consisting of a
metrics table. The schema can be imported as follows:
Consult the section titled
idx.backendin the configuration documentation in order to ensure that the Postgres indexer is used by the
Updated almost 4 years ago