How to understand dimensions in Amberflo
Amberflo Metering Cloud allows you to ask and answer the following question in realtime with guaranteed accuracy --
What was used, by whom, when, where, and how much?
The flexible meter data structure in Amberflo accomplishes this in the following way:
What = Meter name and API
Whom = Customer-id
When = Timestamp
How much = Meter value
Where = Dimensions
As part of your meter definition you can add dimensions (custom key-value pairs) to enrich meter records with additional custom metadata.
You might have one or more attributes related to the "where" aspect of the meter event. For example:
where did this meter originate at (e.g. cloud provider, region, zone, etc.)
who, in addition to the customer ID should I attribute this meter to (e.g. cluster name, project, department, etc.)
state of the event
Amberflo automatically groups and filters the meter events by Dimensions. For example, if you create a Dimension name called 'Cloud_Provider' and send values ranging from (AWS, Azure, Google, ...), Amberflo automatically sorts, groups and filters meter events by these dimension values.
You can use dimensions to correlate a set of meter events together. Say you would like to like event e1 from meter A with event e2 from meter B. You should create a shared credential which will be used to associate the two meters together (ie. a session-id). Pass this session-id as a dimension value for both event e1 and event e2. Now when you search data by dimension, you can filter by session-id to see correlated events.
Some important things to note about dimension values:
Dimension values are always stored as strings. Numerical values would not make sense to use as dimensions; if you are looking to aggregate these values then these would be their own meters. Boolean values can be handled by passing strings of "true" or "false" as needed.
If you need to use a URL as a dimension value, the convention is to use -- "url": "https:_segment.com". Since you are altering the value of the URL it would ahve to be transformed to its original state before being used downstream.
We can also encode the URL like so - https://abc.com -> https%3A%2F%2Fabc.com.
This would also need to be decoded on the client side for viewing.
See related from Metering and Event Ingestion:
- How to measure a multi-step process using a duration meter
- How to track seat-based objects in Amberflo
- How to meter the number of active seats or users for a customer
- How to verify the accuracy of meter data
- How to track and bill for "high watermark" usage
- How to handle erroneous or incorrect meters sent to Amberflo
- How to find the meter-id for retrieving and deleting a specific meter
- How to delete meters that are no longer in use
- How to handle high volume high cardinality event streams