Observability - Types Of Vendor Pricing Models

In the last 5 to 10 years, new Observability vendors have entered the market, including Honeycomb, Instana, Lightstep and Datadog. Similarly, traditional APM vendors such as Dynatrace, AppDynamics, and New Relic, as well as SIEM (and log management) vendors such as Splunk and Sumo Logic, have joined them in the Observability space too. Finally, large cloud providers like AWS offer their own observability solution. Each of them is attempting to address the observability issues that modern architecture presents by using Logs, Metrics, Traces, and Events.

One thing that stands out when you look at them is the various pricing models they use for their observability solutions. And if you are not familiar with their pricing structure, it can become a bit confusing and challenging.

This post is not intended to imply that Vendor A is superior to Vendor B. It is meant to be a guide to help you understand the various pricing models you will come across when dealing with observability vendors. The vendor you choose will be determined by your specific use case, tool experience, and budget. So far, I've come across four primary pricing models.

• Charge per Ingestion (event/span/data)

• Charge per Active Service

• Charge per Host

• Charge per User

Charge per Ingestion

Example of vendors that use this type of pricing model are Honeycomb, SumoLogic, and AppDynamics. One of the new ingestion-based pricing models that people will encounter is charges per event or charges per span.

So what is an Event or Span?

A span represents a unit of work, and an event is a structured record of a discrete action that occurs at a specific time. An event is a single operation, such as an HTTP request that was processed by a system. The Lightstep website has a simple representation of span, as shown below. I recommend reading the articles in the appendix to learn more about span, trace, and events to make sure you are comfortable with the concepts.

Source

Charge per active Service

An example of a vendor that uses this type of pricing model is Lightstep. A service is typically a microservice, which relates to a specific functionality. According to this model, you will only be billed for the number of active services. So if you deploy 10 instances of the same service, you will only be billed for one service.

Charge per Host

Examples of vendors that use this type of pricing model are Dynatrace, Datadog, Instana and Splunk. Each vendor defines what they means by a host. However, what I have experienced is that when a vendor says "host," they generally mean a server, VM, node (in the case of Kubernetes), service that reports host name metrics or all of them. Make sure you ask them this question as to what they mean by host.

Charge per User

An example of a vendor that uses this type of pricing model is New Relic. In this type of model, you are charged based on the type and number of users.

A few vendors use a simple pricing model. The majority of them have some variation of the models listed above. For example, some employ both a user- and data-ingested pricing model. As a customer, it pays to make sure you understand and are comfortable with the pricing model.

It is also important to be aware of any potential hidden costs. Some may charge you extra for high cardinality or longer data retention. Find out what the extra costs are to avoid having to explain exorbitantly large bills to your senior management.

Finally, I would advise vendors to keep their pricing models as simple as possible. The market for observability solutions is already overly competitive. Having a complicated pricing model won't help your cause.

Appendix:

• https://www.honeycomb.io/blog/uniting-tracing-logs-open-telemetry-span-events

• https://docs.lightstep.com/docs/understand-distributed-tracing

• https://docs.splunk.com/Observability/gdi/get-data-in/application/span-attributes.html

• https://opentelemetry.io/docs/concepts/observability-primer/