跳转至

按量的商业模式


观测云与市面上绝大多数的商业化产品有一个非常不同的商业模式选择,就是通过按量的方式进行收费。用一句简单的话来说,我们奉行的是功能免费,但基于数据付费的模型。某种程度上我们非常自信的与所有使用我们产品的用户给出了一个承诺,如果我们产品对您没有价值,或者价值小,您可以完全不付费或者付少量的费用。因此这个对我们团队来说最大的压力与动力就是做出让用户满意的产品,让用户体验到数据的价值。

采用按量服务的底层逻辑

观测云希望能够给用户提供一整套的云的服务体系,并且将用户的实际使用与我们的底层成本关联起来,因为时间线,日志都占用了我们的存储空间,而任务调度则占用了我们的计算集群。对于用户来说,这种方式有非常大的好处,如果对于产品的依赖度大,或者所需管理监测的平台规模大,则需要支付更高费用。而对于小型客户来说,则可以非常低的成本拥有一套全功能的现代化可观测性的平台。我们在功能上不限制任何用户,也希望每个用户都能将所有的功能使用其他,这些功能产生了对您有价值的数据,我们协助分析处理和存储这些数据,而您是为这些有价值的数据在付费。与传统的软件付费模式不同,您无需担心花大价钱购买了一个可能最终也没有使用起来的产品,我们确保每一个用户的在观测云上的消费都是值得的。

简化的收费模型

相对于一些云厂商所提供的监控检测可观测性产品,以及国外的 DataDog 之类的按量前辈们来说,观测云最大的特点是一个平台,一个产品,所有功能产生的数据对于观测云来说都是统一存储和使用的,因此我们的计量单位非常简单,我们也选择一种更为简单的按量模型。我们仅仅是基于三个基本的单元进行收费,分别是 DataKit 数量,日志型数据的数量和任务调度数量。

DataKit数量

DataKit 数量代表的是我们的 DataKit 在正确的安装并且成功的启动产生数据的个数,通常是一台物理服务器或者虚拟机都需要一个 DataKit,也有一些特别的情况,如需要实现 DataKit 桥接以实现局域网数据汇聚并上传,或者利用 DataKit 作为实现前端用户行为分析的数据网关。这里有一个潜在的限制,就是增加一个 DataKit 将获得最大不超过 500 条时间线的计数,当超过了所有 DataKit 的时间线计数总和后,我们将每 500 条时间线作为一个新的 DataKit 进行计数。(一般情况下无需考虑这种情况,但是如果用户采取如果 Telegraf 或者自定义的指标采集的情况下,如:通过一个 DataKit 同步采集上万台云主机的指标会出现这种情况)

时间线

时间线是一个内置的概念,即一个物理空间中,唯一确定的连续指标或指标集(包含多个指标)。如:一台主机的 cpu 相关的指标就是一条时间线,如果存在多台主机,那么就会出现多条时间线。但并不一定是一个指标就是一条时间线,如果指标属于同一个指标集则只有一条时间线。所以开启如进程的指标采集会增加非常多的时间线,即每个进程都将拥有一条时间线。

日志数据的数量

日志型数据是指所有以日志形态存储的数据,除非指标类数据以外其他数据都可以成为日志型数据,如日志,拨测数据,安全巡检数据等。与包括 Datadog 在内的其他产品不同,我们不区分这些数据的价格,并且把这些数据的存储时长交给用户自行选择,用存储数据的总量向用户收费。不同的功能产生不同的数据,同时也产生不同的数据量,不同的存储周期也将产生不同的数据量。同时,日志数据我们提供冷模式可以提供超长的保存周期(同时也收取相应较低的费用,相当于标准日志的 1/5 )。

应用性能监测和用户访问监测

应用性能监测与用户访问监测的数据量非常庞大,每一个用户的访问,如果其访问了超过 10 个页面,将产生超过 500 条用户访问监测的数据,且如果页面上如果包含 5 个服务端请求,将产生对应的后端应用性能监测数据超过 500 条链路数据(假设每次链路请求包含 10 个 SPAN )。相对于日志型数据,由于我们并不会对其内容进行全文索引,也会减少对实际存储的消耗,因此我们将以相当于日志型 1/5 的价格对每一条数据进行收取。

任务调度的数量

在观测云中的三种行为会产生任务调度,第一种行为是异常检测,所有定时的异常检测的每一次执行都将产生任务调度。另一种行为就是日志指标生成功能,根据不同的规则和执行周期,后台将自动提取日志数据产生对应的指标集与指标,而这也会产生任务调度的计数。除此之外,如果是独占版的话,在 DataFlux Func 中的自定义 API 或检测函数也将会产生任务调度的计数。