Sorry for the late reply. Dimensionality is just the number of dimensions a given record has.
For example, if you have a log line to represent an HTTP request completing it might have a server hostname that processed it, a path, and a request duration – 3 dimensions. High dimensionality is just having lots of dimensions.
Most monitoring systems aren't great at correlating between lots of dimensions, or cost a lot if you want to high cardinality, which high dimensionality contributes to. The cardinality is how many possible options there are for all of the dimensions together (so if you have 3 paths and 2 servers, those two fields have a cardinality of 6, or 6 different places you need to store your request duration for).
When you start getting lots of dimensions and lots of values for each dimension, things start getting expensive and you have to be quite restrained about what you choose to monitor. Maybe you decide not to track duration per server because you hope your servers are roughly the same, whereas you know that URL paths perform differently much of the time.
Honeycomb's great advantage is that they support this high dimensionality/cardinality really well. Not only do they not cost a lot to do it, but they also have a really nice UI for exploring this data and how different bits correlate together, without you having to know up-front what you want to look for. Honeycomb is expensive, but not prohibitively so for some engineering teams.
I'd still recommend Datadog _first_ because it does a lot more for a little less money, but if you're pushing the boundaries of what Datadog is capable of with tracing through distributed systems then Honeycomb enables the next step.
For example, if you have a log line to represent an HTTP request completing it might have a server hostname that processed it, a path, and a request duration – 3 dimensions. High dimensionality is just having lots of dimensions.
Most monitoring systems aren't great at correlating between lots of dimensions, or cost a lot if you want to high cardinality, which high dimensionality contributes to. The cardinality is how many possible options there are for all of the dimensions together (so if you have 3 paths and 2 servers, those two fields have a cardinality of 6, or 6 different places you need to store your request duration for).
When you start getting lots of dimensions and lots of values for each dimension, things start getting expensive and you have to be quite restrained about what you choose to monitor. Maybe you decide not to track duration per server because you hope your servers are roughly the same, whereas you know that URL paths perform differently much of the time.
Honeycomb's great advantage is that they support this high dimensionality/cardinality really well. Not only do they not cost a lot to do it, but they also have a really nice UI for exploring this data and how different bits correlate together, without you having to know up-front what you want to look for. Honeycomb is expensive, but not prohibitively so for some engineering teams.
I'd still recommend Datadog _first_ because it does a lot more for a little less money, but if you're pushing the boundaries of what Datadog is capable of with tracing through distributed systems then Honeycomb enables the next step.