此文为可观测白皮书翻译的第二篇，第一篇点此链接原文链接请点此处

关联可观察性信号
- 实现多信号可观测性
- 信号相关性
- 实际应用
- 系统实践
应用案例
- 实施 SLI、SLO 和 SLA
- 可观察性数据告警
- - 告警实践
  - 目标错误率
  - 燃烧率
可观测性的差距
- 多信号关联
参考文献

关联可观察性信号

毫无疑问，可观察性体系是复杂的。正如您从前面的部分中了解到的，为了更多地了解我们运行的软件的状态和行为，我们从不同的角度、不同的时间间隔和管道收集不同的数据类型：

Metrics：一段时间内状态的可聚合数字表示。
Logs：结构化或者可读的离散化事件的详细信息
Traces: 可以绑定到系统中单个实体的生命周期的元数据位（例如请求或事务）。

我们还讨论了不属于上述类别，称之为信号的数据，例如：
可持续Profiling：随着时间的推移，跨不同程序函数的各种资源的代码级消耗数（例如，MEM、CPU）。
我们首先想到的疑问是，为什么要创建这么多的种类？难道我们不能只有一个“包罗万象”的东西吗？答案是不能，类似的，我们不能拥有一辆在柏油路和越野路都有效工作的自行车。每种类型的信号都针对其用途高度专业化。 Metrics以实时、可靠和廉价的监控为中心，支持响应告警 - 可靠系统的基础。我们收集log lines，让我们更深入地了解有关正在运行的系统的较小细节，以获得更多上下文。在某些时候，详细信息会形成一个请求树，因此distributed tracing通过其spans和跨进程上下文传播发挥作用。有时我们需要更深入地研究，我们会转向performance application profiles以检查哪些代码效率低下并使用了意外数量的资源。
正如您可能已经注意到的那样，对于一个完整、方便的可观察性系统来说，只有一个信号是不够的。例如，将太多细节放入metrics（基数）中的成本太高，而以警报所需的近实时延迟可靠地trace每个可能的操作也太昂贵。这就是为什么我们看到许多组织旨在为他们的可观察性系统安装和利用多个信号。

实现多信号可观测性

多信号可观测性是可行的，而且许多人已经做到了。但是当您退后一步，看看为实现这一目标必须构建什么时，您会发现一些主要挑战、错失的机会或效率低下：

不同操作的努力
除非您愿意花钱购买 SaaS 解决方案，它会为您完成一些工作，否则现在很难让一个团队管理所有可观察性系统。拥有一个单独的专门团队来安装、管理和维护每个可观察性信号的情况并不少见，例如一个用于metrics系统，一个用于logs记录技术栈，一个用于trace。这是由于每个系统需要不同的设计模式、技术、存储系统和安装方法。这里边的细枝末节的工作是巨大的。这就是我们的目标是通过开源计划来改进，例如用于检测和转发部件的 OpenTelemetry以及用于可扩展多信号后端的 Obsevatorium。
重复劳动
当我们查看上述可观察性信号时，发现信号之间都会有明显的重叠。例如，让我们看一下上图。我们看到关于“数据在哪里”（通常称为“目标元数据”）的上下文对于每个信号都是相同的。然而，因为对于每种信号，都有一个独立的系统，我们会经常发现这些信息，通常是不一致的，保存在多个地方，并且（更糟！）多次索引和查询它。它不仅适用于目标元数据。许多事件会产生多个信号：增加指标、触发日志线和开始跟踪跨度。这意味着与此特定事件相关的元数据和上下文在整个系统中重复。在开源中，有一些尝试来减轻这种影响，但是进度缓慢，例如 Tempo。
采集时集成多种信号。
鉴于多信号管道，通常需要用另一个信号的附加数据来补充每个系统。比如用metrics协议（例如 OpenMetrics/Prometheus）兼容特定traces和logs 集合创建metrics或类似地将logs组合到traces等功能。诸如 OpenTelemetry 收集器的处理器（从trace spans生成 RED metrics）和 Loki 将logs转换为metrics的功能等举措是该领域的一些现有尝试。
使用时集成多种信号
类似地，在“阅读”级别，快速导航到表示相同或相关事件的另一个可观察性信号将非常有用。这就是我们所说的信号相关性。让我们详细关注这个机会。现在有什么可以实现的？

信号相关性

为了将可观察性数据链接在一起，让我们看一下附加到所有信号的常见数据（如前所述，有时是重复的）。

由于收集所有可观察性信号的连续形式，每条数据都加上某个时间戳，这允许我们在特定时间窗口内过滤信号数据，有时可达毫秒。由于上图的情况，在不同的维度上，每个可观察性信号通常都绑定到某个“目标”。要识别目标，必须存在目标元数据，这在理论上允许我们查看来自特定目标的metrics, profiles, traces 以及 log lines。为了进一步缩小范围，在采集模块中有很多向所有信号添加额外的元数据的代码组件，例如 “工厂”。

仅此一项就非常强大，因为它允许我们通过从一种信号中选择项目来快速导航其他信号。例如 Grafana 已经允许创建这样的链接和侧视图。
但这不是全部。我们有时会有更多的细节，这些细节有时会附加到traces和logs中。特别是，分布式跟踪通过将所有spans限制在单个trace ID下。对于同一用户请求，此信息会从一个函数传递到另一个函数、从一个进程传递到另一个进程。在logs分享同样的信息也很常见，有时称为 Request ID 或Operation ID。通过统一这些ID可以实现traces和logs的联动。这使我们能够轻松地在绑定到单个请求的logs、traces和tags之间导航。

虽然对于某些用例来说这样的相关性水平可能已经足够了，但我们可能忽略了一个重要的问题：大规模！如此大的系统中的进程不会处理很少请求，他们为截然不同的目的和效果会执行数万亿次操作。即使我们可以从单个进程中获取所有logs或traces，但是您如何从当时正在处理的数千个并发请求中找到与您的目标相关的request ID、operation ID或trace ID？强大的日志记录语言（例如LogQL)）允许您 grep 日志以获取日志级别、错误状态、消息、代码文件等详细信息。但是，这需要您了解可用字段、它们的格式以及它如何映射。
如果针对某些端点的大量某些错误或高延迟的警报让您知道所有受影响的request ID，那不是更好吗？此类警报可能基于metrics，并且此类metrics在某些请求流中增加，这很可能还产生了log lines或trace，并分配了request ID、operation ID或trace ID，对吗？
这听起来不错，但正如我们所知，这些数据在设计上是聚合的。出于成本和注意力的原因，我们不能传递作为聚合一部分的所有（有时是数千个）requests ID。但是关于我们可以利用的那些请求，在这样一个聚合指标或日志的上下文中，所有相关的请求都是相似的！因此，可能不需要保留所有 ID。我们可以只附上一个，代表一个例子。这就是我们所说的exemplar。
Exemplar: 某事的典型或很好的例子。

理论上，我们也可以将exemplars附加到profiles中，但考虑到它的专业化和用例（进程内性能调试），实际上我们很少需要链接到单个请求跟踪或日志行。

实际应用

我们讨论了在信号之间导航的方法，但它真的有用吗？让我们看两个简单的例子：

我们收到了 SLO 的高错误率的警报。通过metrics发现是请求高峰导致 501 错误。
我们以exemplar导航到示例日志行以了解确切的可读错误消息。日志显示错误来自后端微服务，因此由于存在与request ID
匹配的trace ID，我们导航到traces。最终，我们确切地知道是什么服务/流程导致了问题，并在那里进行了更多的挖掘。
我们调试慢请求。我们通过跟踪采样手动触发请求并获取 trace ID.。
由于跟踪视图的存在，我们可以看到在请求过程中经过了几个进程，这个例子中是 ABC-1 请求的速度非常慢。
根据目标元数据和时间，我们选择了相关的 CPU usage metrics。并发现 CPU 使用率，接近机器限制，表明 CPU 饱和。
要了解 CPU 使用如此频繁的原因（特别是如果它是容器中的唯一进程），我们使用相同的目标元数据和时间选择导航到 CPU profile 。

系统实践

可观测性可以在实践中实现吗？是的，但是根据我们的经验，大多数人并不知道如何实现。在这个领域有许多的公司和项目分别负责部分领域，正是由于这样导致总体框架比较混乱而且一些简单的解决方案难以发现。幸运的是，开源社区在简化和商品化这些方法方面付出了巨大的努力。让我们看看一些实现这种平滑、多信号相关设置的开源方法。为简单起见，假设您已经选择了一些metrics, logging and tracing技术栈（在实践中，通常会抽样logging or tracing 以降低成本）。
从高层的角度来看，我们需要保证三个要素：

统一所有信号的元数据

这可能已经是一项艰巨的任务，但我们可以做一些捷径。这种捷径称为拉模型。例如，在 Prometheus 系统中，一致的元数据要容易得多，这要归功于单一、集中管理的发现服务。在许多其他好处中，拉模型允许度量客户端（例如您的 Go 或 Python 应用程序）只关心它自己的metric 元数据，完全忽略它运行的环境。相反，这对于推送模型来说很难维护,例如 Logstash、 non-pulling OpenTelemetry receivers、 non-tailing plugins for Fluentd、Fluentbit。想象一下，一个应用程序把所在的节点定义为node，另一个则把它定义为machine，还有一个将它放在 instance标签中。
在实践中有以下几个建议：

假设我们坚持推送模型（对于某些情况，例如强制执行批处理作业），我们需要确保tracing, logging, and metrics添加正确且一致的元数据。在实践中使用我们使用一些跨编程语言的三方软件（例如 Postgres）可以同步元数据，但是同步可能需要数年。或者，可以在代码层面进行同步， Service Meshes 可能对标准的进入/退出可观察性有所帮助，但无法做到开箱观测。实现这一点的另一种方法是使用可以动态重写元数据的插件，例如 OpenTelemetry，然而在实践中这种方案随着时间的推移难以维护。

第二种方案是使用拉去模型，在控制端定义目标的元数据。我们已经在Prometheus 或 Agent的开源中做到了这一点，这要归功于OpenMetrics 不断地抓取metrics，ConProf 对配置文件做同样的事情。同样，已经有许多解决方案可以从标准输出/错误中跟踪您的日志，例如 Promtail 或 OpenTelemetry tailing collector。不幸的是，还没有发现任何实现项目获取traces数据（目前）。

使Operation ID, Request ID or Trace ID统一并附加在日志系统中

这部分必须在仪器级别上得到保证。多亏了 OpenTelemetry 上下文传播和 API，我们可以通过获取trace ID（理想情况下，仅在trace被采样时）并将其添加到与此类请求相关的所有日志行中。使其统一的一种非常好的方法是利用中间件 (HTTP) 和拦截器(gRPC)编码范例。值得注意的是，即使您不想使用tracing系统或非常严格tracing 采样，在日志记录中生成和传播request ID 仍然很有用。这允许将单个请求的日志行关联在一起。

Exemplars

Exemplars在开源空间新出现的，所以让我们来看看目前有什么可能以及如何采用它们。将exemplars添加到您的日志记录系统非常简单。我们可以为聚合多个请求的日志行添加一个简单的 exemplar-request= 键值标签形式的exemplar。
为metric添加exemplars却不太一样。这可能值得我有一天写一篇单独的文章，但正如您想象的那样，我们通常不能将request ID或trace ID 直接添加到metric series元数据（例如 Prometheus 标签）。这是因为它会用一个样本创建另一个一次性的、独特的series（导致无限的“cardinality”）。然而，我们可以使用 OpenMetrics 定义的一种相当新颖的模式，称为Exemplar.。这是附加信息，附加到（任何）series sample，在主要（高度索引）标签之外。这就是它在 OpenMetrics 文本格式中的外观，例如Prometheus：

# TYPE foo histogram
foo_bucket{le="0.01"} 0
foo_bucket{le="0.1"} 8 # {} 0.054
foo_bucket{le="1"} 11 # {trace_id="KOO5S4vxi0o"} 0.67
foo_bucket{le="10"} 17 # {trace_id="oHg5SJYRHA0"} 9.8 1520879607.789
foo_bucket{le="+Inf"} 17
foo_count 17
foo_sum 324789.3
foo_created 1520430000.123

定义后，它们会被 OpenMetrics 兼容的抓取工具（例如 Prometheus）与metric samples（确保在您的检测客户端中启用 OpenMetrics 格式）一起抓取。完成后，您可以通过 Exemplars API 查询这些示例：

curl -g 'http://localhost:9090/api/v1/query_exemplars?query=test_exemplar_metric_total&start=2020-09-14T15:22:25.479Z&end=020-09-14T15:23:25.479Z'
{
"status": "success",
"data": [
{
"seriesLabels": {
"__name__": "test_exemplar_metric_total",
"instance": "localhost:8090",
"job": "prometheus",
"service": "bar"
},
"exemplars": [
{
"labels": {
"traceID": "EpTxMJ40fUus7aGY"
},
"value": "6",
"timestamp": 1600096945.479,
}
]
},
(...)

请注意，query参数不是专门 ExemplarsQL 设计的，此 API 希望被用在任何 PromQL 查询的地方例如看板、告警或者规则。该仪表支持解析这些query参数以及所有用过这个参数的series，并返回这些series相关的exemplars。
这个 API 很快就被 Grafana 采用了，即使是现在，您也可以在最新版本的 AGPLv3 许可 Grafana 上呈现exemplars并允许快速链接到trace视图。
当然，这只是基础。 Prometheus 中有完整的基础设施和逻辑在 2021 年初完成，以支持在远程写入对examplars进行抓取、存储、查询，备份。Thanos，Grafana也开始支持exemplars 。
还值得一提的是，OpenTelemetry 还继承了 OpenCensus 的某种形式的exemplars。这些与 OpenMetrics 非常相似，只可附加到histogram buckets.。然而，我们不知道有人在任何地方使用或依赖这部分 Otel metric协议，包括 Go 等相关实现。这意味着，如果您想拥有稳定的生态系统，OpenMetrics 可能是首选。另外，OpenTelemetry 也慢慢采用了 OpenMetrics。

应用案例

基于箱体的监控可以分为两种策略

开箱监测
关箱监测

一般而言，关箱监控是指从外部观察系统，操作员无法控制或了解系统的内部运作。另一方面，开箱监控是指更“传统”的监控概念，即监控那些你知道它如何运作并可以控制的系统，因此您能够更好地决定如何通过可观察性的三大支柱去监控它。

实施 SLI、SLO 和 SLA

SLI、SLO 和 SLA 指标可以让您客观地衡量服务质量和客户满意度。更重要的是，它在组织内的业务、产品和工程等不同职能之间提供了一组通用术语。工程时间在任何组织中都是稀缺资源，但每个人都觉得他们的问题是一个紧迫的问题。 SLO 使此类对话更加受数据驱动，因为每个人都了解违反 SLO 的业务后果。在解决内部冲突的同时，它还通过提供有意义的抽象来实现有意义且可操作的告警，从而使您更加专注于客户。
在深入研究实现细节之前，我们应该清楚定义，因为它们可能会相当混乱，有时可以互换使用。

服务水平指标 (SLI)：SLI 是一种服务水平指标——对所提供的服务水平的某些方面进行仔细定义的定量测量。
服务水平目标 (SLO)：SLO 是一个服务水平目标：即您可以承受的失败频率。由 SLI 测量的服务水平的目标值或值范围。
服务水平协议 (SLA)：包含违反 SLO 后果的商业合同。这是一个目标百分比错误预算：SLO 确定的一段时间内失败事件的容差。等于 100% 减去 SLO。

为了使提议的 SLO 有用且有效，您需要让所有利益相关者都同意它。产品经理必须同意这个阈值对用户来说已经足够好了——低于这个值的性能令人无法接受，值得花工程时间来修复。产品开发人员需要同意，如果错误预算已经用尽，他们将采取一些措施来降低用户的风险，直到服务恢复到预算范围内。负责维护此 SLO 的运维的团队已经同意，无需付出巨大的努力、过度劳累和倦怠，否则会损害团队和服务的长期健康。

可观察性数据告警

在广泛采用metrics 收集之前，大多数软件系统仅依靠日志来解决和分类问题并获得对其系统的可见性。除了日志搜索和看板之外，日志还充当许多团队和工具的主要警报源。这种方法今天仍然存在于许多现代可观察性系统中，但通常应避免使用，以支持对时间序列metrics进行警报。更具体点说，我们将研究使用您定义的 SLO 和错误预算来执行可操作的告警。
您的时间序列数据中有许多信号可以提醒您，其中许多可能是特定于应用程序的。推荐的最佳做法是使用团队的 SLO 来驱动告警。如上所述，SLO 是一个服务水平目标，即由服务水平指标衡量的服务水平的目标值或值范围。例如，REST API 的 SLO 可能是“95% 的请求必须在 500 毫秒内得到处理”。为了为您的团队提供有效的警报，您还应该定义错误预算。我们将研究如何结合您的 SLO 和错误预算来推动可操作的告警。

告警实践

构建警报可能非常复杂，很容易被误报淹没并产生警报疲劳。警报应该是可操作的，并指示某人需要采取行动的问题。我们将在下面介绍您可以实施的两种方法，一种是简单的方法，另一种是基于消耗率的方法。

目标错误率

对目标错误率发出警报是您可以采取的最简单的方法。选择一个较小的时间窗口，比如 10 分钟，并在该窗口中的错误率超过您的 SLO 时发出警报。
例如，如果您的 SLO 为 99.9%，则在过去 10 分钟的错误率 >= 0.1% 时发出警报。在 Prometheus 中，这可能看起来像这样（总 HTTP 请求错误除以过去 10 分钟内所有请求的总和）：

(sum(rate(http_requests_total{code=~"5.*"}[10m])) / sum(rate(http_requests_total[10m]))) > 0.001

这样做的优点是可以简单直接地查看警报逻辑中发生的情况，并在遇到错误时快速发送警报。但是，有时在不违反您定义的 SLO 时，也会触发告警。

燃烧率

燃烧率警报是一种更复杂的方法，并且可能会产生更多可操作的警报。首先，让我们更详细地定义消耗率和错误预算。
所有 SLO 定义中固有的是错误预算的概念。通过声明 99.9% 的 SLO，您的意思是在某个预定义的时间量（您的 SLO 窗口）内，0.1% 的故障率（即您的错误预算）是可以接受的。 “燃烧率是相对于 SLO 服务消耗错误预算的速度”。因此，例如，如果“服务使用 1 的消耗率，这意味着它消耗错误预算的速度使您在 SLO 时间窗口结束时的预算正好为 0。一段时间内的 SLO 为 99.9% 30 天的窗口，恒定的 0.1% 错误率完全使用了所有错误预算：消耗率为 1”。

燃烧率	99.9% SLO的错误率	持续时间
1	0.1%	30 days
2	0.2%	15 days
10	1%	3 days
1000	1000%	43 minutes
(Burn rates and time to complete budget exhaustion)

燃烧率将使我们能够减小窗口大小并创建具有良好检测时间和高精度的警报。对于我们的示例，假设将警报窗口固定为一小时并确定 5% 的错误预算支出足以通知某人，您可以推导出用于警报的消耗率。
对于基于燃烧率的警报，发出警报所需的时间为：

(1 - SLO / error ratio) * alerting windows size * burn rate

告警触发时消耗的错误预算为：

(burn rate * alerting window size) / time period

因此，5% 的 30 天错误预算花费，一小时需要燃烧率为 36。告警规则现在变为：

(sum(rate(http_requests_total{code=~"5.*"}[1h])) / sum(rate(http_requests_total[1h]))) > 36 * .001

可观测性的差距

多信号关联

上面的文章很好地解释了可观察性相关性是什么，它意味着什么以及如何实现。这里，让我们快速列举一下当今多信号可观测性关联的缺陷：

元数据不一致
如前所述，即使标签之间存在轻微的不一致，在使用时也可能会很烦人。重新标记技术或默认为拉模型会有所帮助。
在日志系统中缺失request ID 或者其他ID连接到Tracing ID
如前所述，这可以在instrumentation方面解决，这有时很难控制。中间件和service meshes也可以提供帮助。
棘手的tracing采样
收集所有请求的所有traces and spans可能非常昂贵。这就是为什么一个项目定义了不同的采样技术，来sample那些以后可能有用的traces。定义哪些traces是重要的并非易事，因此出现了复杂的抽样。主要问题是确保日志系统中的exemplars或者trace ID 能够链接到采样的trace。如果我们的前端系统会暴露一个无法链接的exemplar（存储中没有可用的trace），那将是一个糟糕的用户体验。
虽然可以在 UI 方面改进这种体验（例如，在呈现exemplar之前预先检查是否存在trace），但它并布容易解决，并且会给系统带来进一步的复杂性。理想情况下，我们可以在将exemplar 注入到metric系统之前检查是否对trace进行了采样。OpenTelemetry 编码 API 允许通过IsSampled获取采样信息。当使用tail-based的采样或分析哪个trace可能是重要的时，就会出现问题。暂时还没有来改善这个小而烦人的问题的方法。如果您进行全采样或基于预先抽样规则（请求比率或用户的选择），这个问题就会消失。
examplars尚未广泛应用
Prometheus 用户体验特别好，因为 Prometheus/OpenMetrics 是事实标准。世界各地的软件都使用这种简单的机制来添加metrics。因为 Prometheus exemplars 是新的，OpenTelemetry tracing 库也是新的，所以广泛通过exemplars 来 “instrumenting their instrumentation”需要时间。
但是！您可以先将 Prometheus exemplars 添加到您的应用程序中。这种联动模式正在成为一种新标准（例如在Thanos进行检测），因此通过将使用这些工具可以帮助您和您的用户，在tracing and metrics之间实现联动。
高级别的metric聚合和降采样
给那些通过汇聚了许多包含exemplars 的metrics 的规则和告警添加exemplars 的能力还没有完成。这项能力已经提上了日程。同样，我需要在后续迭代Prometheus时考虑如何进行exemplars的降采样。
UI 中的本地关联支持。
Grafana 在多信号联动方面处于领先地位，其他联动支持更好的UIs也在本文中分享了。在 Grafana 之前，每个信号通常都有自己的视图，很少考虑其他信号。 Prometheus UI也添加了其他信号的连接或者展示exemplars。

参考文献

HARTMANN, Richard. Talk given at Fosdem (Brussels), Feb 2019. Available at: https://archive.fosdem.org/2019/schedule/event/on_observability_2019/. Accessed on: June 24, 2021.
SRIDHARAN, Cindy. Distributed Systems Observability. Chapter 04, The Three Pillars of Observability. 2018. Available at: https://www.oreilly.com/library/view/distributed-systems-observability/9781492033431/ch04.html. Accessed on: June 24, 2021.
BEYER, Betsy; JONES, Chris; MURPHY, Niall; PETOFF, Jennifer. Site Reliability Engineering. O’Reilly Media, 2016. Available at: https://sre.google/sre-book/table-of-contents/. Accessed on: June 24, 2021.
BEYER, Betsy; MURPHY, Niall; RENSIN, David; KAWAHARA, Kent; THORNE, Stephen. The Site Reliability Workbook. O’Reilly Media, 2018. Available at: https://sre.google/workbook/table-of-contents/. Accessed on: June 24, 2021.
SRIDHARAN, Cindy. Monitoring and Observability. Sep 5, 2017. Available at: https://copyconstruct.medium.com/monitoring-and-observability-8417d1952e1c. Accessed on: June 24, 2011.
MCCARTHY, Kate; FONG-JONES, Liz; FISHER, Danyel; MAHON, Deirdre; PERKINS, Rachel. Observability Maturity: Community Research Findings Q1, 2020. April, 2020. Available at: https://www.honeycomb.io/wp-content/uploads/2020/04/observability-maturity-report-4-3-2020-1-1.pdf. Accessed on: June 24, 2021.
Kalman R. E., On the General Theory of Control Systems, Proc. 1st Int. Cong. of IFAC, Moscow 1960 1481, Butterworth, London 1961. Available at: https://www.sciencedirect.com/science/article/pii/S1474667017700948?via%3Dihub. Accessed on: June 24, 2021.

可观测白皮书 part2/2相关推荐

木瓜移动SaaS平台：木瓜大橙白皮书 Part2 - 管理功能介绍
学习状态通道，Part-1：支付通道
在我的上一篇博文中,我简单地讨论了状态通道,以及为什么我认为它对于开启以太坊的大规模可用性来说,是至关重要的.在此,我打算通过几篇博文来推进一步,这些博文对 L4 团队用 Countfactual 做 ...
【超越白皮书3】DAG技术解析与实测
本报告由火币区块链研究院出品,作者:袁煜明.胡智威.原文地址相关报告: [超越白皮书2]EOS主网上线前夕的实测分析与技术建议 [超越白皮书1]EOSIO程序实测分析与技术建议火币区块链应用研究院 ...
智能网联汽车高精地图白皮书(2020)
1. 前言高精地图的发展与智慧交通.智能网联汽车紧密相关,从智能网联汽车上路伊始,高精地图产业就应势而生并飞速发展.相对于以往的导航地图,高精地图是智能网联汽车交通的共性基础技术,其服务的对象并非仅 ...
重磅丨2018年人工智能标准化白皮书
▌1 前言 1.1 研究背景人工智能概念诞生于 1956 年,在半个多世纪的发展历程中,由于受到智能算法.计算速度.存储水平等多方面因素的影响,人工智能技术和应用发展经历了多次高潮和低谷.200 ...
中国AI应用最新白皮书：四大行业将受AI影响最大，或带来19000亿增益价值
白皮书指出,中国AI企业的发展势头良好,在全球处于优先地位;金融.汽车.医疗和零售将是受AI影响最大.同时最具成熟发展基础与市场应用潜力的传统产业,制造.教育和通信行业也值得关注. 编者按:在第三次人 ...
业界首发｜阿里云重磅发布云原生架构白皮书
2020 年 7 月 21 日,由阿里云 20+ 位云原生技术专家共同编撰的<云原生架构白皮书>正式对外发布.作为业界首本全方位构建云原生架构规划与实践全景图的白皮书,本书在详细阐述云原生 ...
阿里云技术白皮书_对阿里重磅发布的云原生架构白皮书的初步解读
今天准备整理和分享下阿里云发布的云原生架构白皮书.在今年7月份,由阿里云20+位云原生技术专家共同编撰的<云原生架构白皮书>正式对外发布.据官方介绍,本书涵盖了云原生架构的产生缘由.阿里云 ...
云原生时代，阿里云联手博睿数据让IT运维可观测更智能
随着全球信息产业的变革,企业信息化的建设步伐不断加快,企业 IT 系统建设趋于完善,随之而来的是IT 系统日益庞大与复杂化,企业 IT 需求逐渐维护上往 IT 维护倾斜.据中商产业研究院发布的< ...

可观测白皮书 part2/2