跳到主要内容

APO 集成生态exporter一键完成指标采集

· 阅读需 8 分钟
Kindling-OriginX
故障根因推理引擎

Cover 图

Metrics 作为可观测性领域的三大支柱之一,Metrics数据采集显得尤为重要。传统的prometheus工具采集指标,需要指定路径抓取,当指标越来越多配置会显得复杂。同时prometheus只能采集指定的指标,当用户需要节点系统相关、中间件等指标还需要引进额外组件。久而久之采集指标配置难以维护。

APO 为了用户更好地一键采集各类指标,选择 Grafana-Alloy 作为APO的指标采集器,兼容OpenTelemtry生态,集成到 APO OneAgent之中,APO OneAgent负责采集所有指标,发送至APO-Server,存储至Victoria-Metrics, APO-front负责展示所有指标。当需要额外采集数据,只需配置OneAgent中Alloy数据采集源,无需更改其他组件,配置灵活,简单易懂。

图 1


APO 指标采集配置步骤

安装APO-Agent之时,已经安装自带安装了grafana-Alloy。APO启动之后 APO Server并对外提供服务,OneAgent抓取指标,然后发送到 Server,可以在APO Front中的Grafana查看数据。

当用户想要修改指标采集配置,修改 apo-grafana-alloy-config ConfigMap即可(虚机环境下修改apo配置文件config/grafana-alloy/config.alloy)

采集的配置步骤如下:

  1. 配置APO-server地址
  2. 配置apo-grafana-alloy-config文件
  3. grafana查询指标

APO server地址配置

首先需要配置APO Server地址,OneAgent采集指标后将数据发送到APO Server

    otelcol.receiver.prometheus "default" {
output {
metrics = [otelcol.exporter.otlp.default.input]
}
}

otelcol.exporter.otlp "default" {
client {
endpoint = "<host-ip>:<port>"
tls {
insecure = true
insecure_skip_verify = true
}
}
}

配置说明:其中 receiver 接收 prometheus 指标,转换成 otel 格式,然后exporter导出发送至APO-Server

APO缺采集配置

以kubernetes环境为例,通常一个集群可能存在如下指标需要采集

  • node metrics 节点机器系统相关指标 (磁盘,cpu等信息)
  • kubelet metrics 提供 node 和 Pod 的基本运行状态和资源使用情况
  • cadvisor metrics container相关的详细资源使用和性能指标数据

机器相关指标采集

    jsprometheus.exporter.unix "local_system" {
}

prometheus.scrape "scrape_metrics" {
targets = prometheus.exporter.unix.local_system.targets
forward_to = [otelcol.receiver.prometheus.default.receiver]
scrape_interval = "10s"
}

该组件会采集机器上的各种资源指标

kubernetes 指标采集

其中 discovery.kubernetes 组件负责获取kubernetes信息, APO 这里选择获取node相关的信息

之后采集 kubelet和 cadvisor相关的指标,由于是k8s集群,还需要配置 scheme, bearer_token_file等权限相关信息

discovery.kubernetes "nodes" {
role = "node"
}

prometheus.scrape "kubelet" {
targets = discovery.kubernetes.nodes.targets
scheme = "https"
scrape_interval = "60s"
bearer_token_file = "/var/run/secrets/kubernetes.io/serviceaccount/token"
tls_config {
insecure_skip_verify = true
}
clustering {
enabled = true
}
forward_to = [otelcol.receiver.prometheus.default.receiver]
job_name = "integrations/kubernetes/kubelet"
}

prometheus.scrape "cadvisor" {
targets = discovery.kubernetes.nodes.targets
scheme = "https"
scrape_interval = "60s"
bearer_token_file = "/var/run/secrets/kubernetes.io/serviceaccount/token"
tls_config {
insecure_skip_verify = true
}
clustering {
enabled = true
}
forward_to = [otelcol.receiver.prometheus.default.receiver]
job_name = "integrations/kubernetes/cadvisor"
metrics_path = "/metrics/cadvisor"
}

scrape指标采集

通常用户还会部署一些自定义的探针程序,用于自定义一些监控指标

只需指定 targets 下的 addres 用于指定采集URL, __metrics__path__自定义采集路径,默认为/metircs

prometheus.scrape "agent_metrics" {
targets = [
{
__address__ = "<scrape-path-1>:<port>",
},
{
__address__ = "<scrape-path-2>:<port>",
__metrics__path__ = "/metrics/agent"
},
{
__address__ = "<scrape-path-3>:<port>",
},
]
forward_to = [otelcol.receiver.prometheus.default.receiver]
scrape_interval = "10s"
}

如采集APO node-agent 指标

APO node-agent 用于采集上下游网络指标和进程启动时间指标,路径为 localhost:9500/metrics

prometheus.scrape "agent_metrics" {
targets = [
{
__address__ = "localhost:9408",
}
]
forward_to = [otelcol.receiver.prometheus.default.receiver]
scrape_interval = "10s"
}

一键采集中间件指标

除了采集基本指标外,用户使用APO还可以根据自己的需求额外配置其他指标采集。

如采集各类 中间件指标 (kafka, redis, mysql, elasticsearch等)

图 2

监控 MySQL

1.OneAgent 的 alloy 配置文件添加如下内容,然后重启 OneAgent

# 采集 mysql指标
prometheus.exporter.mysql "example" {
data_source_name = "username:password@(<mysql-url>:3306)/"
enable_collectors = ["heartbeat", "mysql.user"]
}

prometheus.scrape "mysql" {
targets = prometheus.exporter.mysql.example.targets
forward_to = [otelcol.receiver.prometheus.default.receiver]
}

2.APO Front 的 Grafana 中导入 MySQL 模版

图 3

3.验证是否有MySQL指标数据

图 4

监控 ElasticSearch

1.OneAgent 的 alloy 配置文件添加如下内容,然后重启 OneAgent

# 采集 elasticsearch指标
prometheus.exporter.elasticsearch "example" {
address = "http://<elasticsearch-url>:9200"
basic_auth {
username = USERNAME
password = PASSWORD
}
}

prometheus.scrape "elasticsearch" {
targets = prometheus.exporter.elasticsearch.example.targets
forward_to = [otelcol.receiver.prometheus.default.receiver]
}

2.APO Front 的 Grafana 中导入 ElasticSearch 模版

3.验证是否有ElasticSearch指标数据

图 5

监控 Redis

1.OneAgent 的 alloy 配置文件添加如下内容,重启OneAgent

# 采集 redis 指标
prometheus.exporter.redis "example" {
address = "<redis-url>:6379"
}

prometheus.scrape "redis" {
targets = prometheus.exporter.redis.example.targets
forward_to = [otelcol.receiver.prometheus.default.receiver]
}

2.APO Front 的 Grafana 导入 Redis 模版

3.验证是否有 Redis 指标数据

图 6

监控 Kafka

1.OneAgent 的 alloy 配置文件添加如下内容,重启OneAgent

# 采集 kafka 指标
prometheus.exporter.kafka "example" {
address = "<kafka-url>:9092"
}

prometheus.scrape "kafka" {
targets = prometheus.exporter.kafka.example.targets
forward_to = [otelcol.receiver.prometheus.default.receiver]
}

2.APO Front 的 Grafana 导入 Kafka 模版

3.验证是否有Kafka 指标数据

图 7


更多指标的采集可以参考Grafana-Alloy的官方文档或者咨询我们

Alloy已经支持如下中间件指标采集:

图8


参考资料

otel-collector

otlp-configgrpc

victora-metrics

Sending data via OpenTelemetry

alloy

discovery.kubernetes

otel.receiver.prometheus

prometheus

样例配置文件

logging {
level = "info"
format = "logfmt"
}


otelcol.receiver.prometheus "default" {
output {
metrics = [otelcol.processor.transform.default.input]
}
}

otelcol.processor.transform "default" {
error_mode = "ignore"
trace_statements {
context = "resource"
statements = [
`replace_all_patterns(attributes, "key", "service\\.instance\\.id", "service_instance_id")`,
`replace_all_patterns(attributes, "key", "service\\.name", "service_name")`,
`replace_all_patterns(attributes, "key", "net\\.host\\.name", "net_host_name")`,
]
}
output {
metrics = [otelcol.exporter.otlp.default.input]
}
}

otelcol.exporter.otlp "default" {
client {
endpoint = "<host-ip>:<port>"
tls {
insecure = true
insecure_skip_verify = true
}
}
}

prometheus.exporter.unix "local_system" {
}

prometheus.scrape "scrape_metrics" {
targets = prometheus.exporter.unix.local_system.targets
forward_to = [otelcol.receiver.prometheus.default.receiver]
scrape_interval = "10s"
}

prometheus.scrape "agent_metrics" {
targets = [
{
__address__ = "<scrape-path-1>",
},
{
__address__ = "<scrape-path-2>",
},
{
__address__ = "<scrape-path-3>",
},
]
forward_to = [otelcol.receiver.prometheus.default.receiver]
scrape_interval = "10s"
}

discovery.kubernetes "nodes" {
role = "node"
}

prometheus.scrape "kubelet" {
targets = discovery.kubernetes.nodes.targets
scheme = "https"
scrape_interval = "60s"
bearer_token_file = "/var/run/secrets/kubernetes.io/serviceaccount/token"
tls_config {
insecure_skip_verify = true
}
clustering {
enabled = true
}
forward_to = [otelcol.receiver.prometheus.default.receiver]
job_name = "integrations/kubernetes/kubelet"
}

prometheus.scrape "cadvisor" {
targets = discovery.kubernetes.nodes.targets
scheme = "https"
scrape_interval = "60s"
bearer_token_file = "/var/run/secrets/kubernetes.io/serviceaccount/token"
tls_config {
insecure_skip_verify = true
}
clustering {
enabled = true
}
forward_to = [otelcol.receiver.prometheus.default.receiver]
job_name = "integrations/kubernetes/cadvisor"
metrics_path = "/metrics/cadvisor"
}


# 采集 mysql指标
prometheus.exporter.mysql "example" {
data_source_name = "username:password@(<mysql-url>:3306)/"
enable_collectors = ["heartbeat", "mysql.user"]
}

// Configure a prometheus.scrape component to send metrics to.
prometheus.scrape "mysql_metrics" {
targets = prometheus.exporter.mysql.example.targets
forward_to = [otelcol.receiver.prometheus.default.receiver]
}

# 采集 elasticsearch指标
prometheus.exporter.elasticsearch "example" {
address = "http://<elasticsearch-url>:9200"
basic_auth {
username = USERNAME
password = PASSWORD
}
}

prometheus.scrape "demo" {
targets = prometheus.exporter.elasticsearch.example.targets
forward_to = [otelcol.receiver.prometheus.default.receiver]
}

APO与SkyWalking、Signoz等产品的不同设计

· 阅读需 10 分钟
Autopilot Observability
APO 向导式可观测性平台

Cover 图

Skywalking作为国内用户量最大的APM产品,有着众多的优点。Signoz作为OpenTelemetry的发行版也有着一定的名气。我们为什么还要设计APO项目?谨代表APO团队探讨下团队之前的经验,一家之言,欢迎各位大佬一起探讨。

APO团队背景

APO团队最先着力的产品是一款商业化的根因推理引擎产品Originx。该产品目标就是对接Skywalking和OpenTelemetry的探针数据,在SLO违约的时候,快速从原始数据之上分析得到故障根因分析报告。

实现根因分析的前提——完备的关联数据

如果业务入口的延时升高或者错误率升高,对于下游依赖众多的服务调用而言,如何判断哪个接口是最可能的“凶犯”呢?我们认为应该要先对每个微服务接口的关联所有故障可能相关的数据。具体根因分析算法和规则就不在这篇文章讨论了。

接口关联数据故障场景
接口自身的告警信息,应用层、资源层告警告警分析
接口的影响业务入口黄金指标影响面分析
接口的下游依赖告警关联级联告警影响分析
接口的实例和节点的资源指标饱和度分析
接口的网络指标网络质量分析
接口的代码Exception,以及含有Exception的日志错误闭环
接口执行的北极星指标延时闭环
接口执行的日志故障佐证
接口执行的trace故障佐证
接口所依赖的容器环境关键事件环境影响

三者在产品设计思路不同

在APO团队看来,从设计思路来看Skywalking和Signoz是同类型的产品,都是以应用和Trace为核心呈现数据。但是APO团队认为可观测性平台不应该是以应用和Trace为核心呈现数据,而应该是以接口为维度呈现数据,因为以接口呈现数据,就可以关联上个章节提到的所有数据。

在应用中去关联上述的数据准确度会有大降低,比如一个应用提供两个接口,两个接口执行延时偏差较大,一旦以应用维度统计黄金指标数据(错误率、延时、吞吐量),就可能将故障隐藏其中。 从Trace出发呈现问题也是Skywalking和Signoz等产品的一个核心功能,在APO中这块通过集成Jaeger的方式来实现的。

最近有些朋友交流他们在自己实现可观测性平台的时候,也想以接口来关联数据,但是感觉计算量太大,资源消耗太大。APO能够实现该功能,主要基于回溯采样,分析的都是回溯采样中的数据,所以计算量是能承受的。

三者在数据采集上的不同

在具体实现上还有以下的不同:

Skywalking

  • log由Skywalking agent自采
  • metrics由Skywalking agent自采
  • Trace由Skywalking agent自采

Signoz

  • log由Signoz openTelemetry collector采集
  • merics由Signoz openTelemetry collector采集
  • Trace由OpenTelemetry agent采集

APO

  • log由ilogtail采集
  • metrics由Alloy采集
  • Trace由OpenTelemetry agent采集,同时也支持Skywalking agent采集
APOSkywalkingSignoz说明
logilogtailSkywalking agentSignoz openTelemetry collector●Skywalking agent采集日志性能开销可能不如单独的探针●OpenTelemetry Collecotor采集日志是一个不错的选择●ilogtail采集日志不仅仅适合容器环境,同时还可以支持虚拟机等其他环境
metricsAlloySkywalking agentSignoz openTelemetry collector●Skywalking agent采集的指标很多应用层指标,需要额外的指标采集工具覆盖主机、容器的指标 ●Signoz OpenTelemetry Collector能够采集主机指标,但是目前支持采集的种类的指标有限 ●Alloy是一款内置多种Prometheus exeporter的产品基于Alloy采集指标,非常容易扩展采集各种中间件等指标,满足更多用户的需求
TraceOpenTelemetry agent或者Skywalking agentSkywalking agentOpenTelemetry agent●由于Skywalking的协议缺少一些关键ID,比如ContainerID等信息,在容器环境,要关联各种指标和日志带来一些问题●OpenTelemetry的OLTP协议中含有ContainerID,关联起来各种数据更加方便

(建议此表格横屏阅读,内容展示更全面)

APO中需要关联eBPF数据和Trace的数据,Skywalking协议由于缺少ContainerID,导致关联出现以下的问题:

  • eBPF数据来源于主机,能够获取到主机层面的PID和ContainerID信息
  • 容器中Skywalking协议只有PID等信息,而容器环境的PID并不是主机层面的PID,导致两者关联起来非常不方便,需要额外做开发完成

三者在数据分析处理上的不同

APO和Signoz的数据分析处理都有各自的OTEL collector发行版,Skywalking主要基于OAP实现数据的分析与处理。

OpenTelemetry 的Collector非常开放,预设了各种插件

  • processor
  • receiver
  • Exporter

通过各种插件的组合能够很快组合成需要满足自己的数据分析处理流程,自动定义开发比较方便。

Skywalking的OAP相对而言比较封闭,没有这套插件体系导致自定义数据分析处理流程相对而言比较困难。所以现在很多公司的Skywalking的使用场景都需要自己构建flink完成数据的分析处理。

三者在数据存储的逻辑不同

Skywalking的Trace是完全插入存储之后,再计算RED值。

Signoz的RED指标在中心侧Collector计算完成,Trace是尾采样存储。

APO的RED指标在探针侧Collector计算完成。Trace是全量存储,处理不过来就丢弃,但是分析的是回溯采样中的逻辑Trace,回溯采样中的逻辑Trace优先级最高,保证存储。

APOSkywalkingSignoz说明
Trace处理时机探针侧Collector存储侧中心侧collector●Skywalking 对存储中间件的计算资源和存储资源要求高,计算都在存储侧计算●Signoz在中心侧collector计算RED指标并执行尾采样,当TPS流量很大之时,尾采样的限制导致其很难支持大流量的Trace计算●APO在探针边缘侧计算RED,计算量分散,能更好支持大流量的场景。采用回溯采样,优先保障回溯采样中的逻辑Trace存储,全量Trace如果超出缓存扔掉
存储中间件ClickHouse VictorioMetricsElasticSearchClickHouse●Skywalking 采用ElasticSearch 需要比较多的机器成本●Signoz 的指标是存储在ClickHouse中,一些现成的PQL查询指标语句用不了●APO的指标存储在VM中,兼容PQL语句,很多已经基于Prometheus的大屏可以直接使用,指标压缩比也更高

(建议此表格横屏阅读,内容展示更全面)

APO使用场景之:统一的指标采集展示

· 阅读需 11 分钟
Autopilot Observability
APO 向导式可观测性平台

Cover 图

可观测性领域中的指标一直都占有非常重要的地位。Prometheus生态目前已经是事实上的标准,但是实际用户在落地Prometheus的时候可能存在以下的问题:

  • 虽然生态中有各种成熟的Exporter,但是各种Exporter的安装配置相对而言比较繁琐,管理比较麻烦
  • 跨集群的指标数据汇聚相对而言比较麻烦,很多时候需要二次开发,没有简单配置即可工作的工具
  • Prometheus 原生数据存储在大数据量时不稳定,业界有着很好的类似VictorioMetrics方案,但是很多人还未尝试使用
  • 业界也存在过万好评的大屏,能够更好体现指标价值,对于很多用户而言可能并不了解

在APO中能够很好的解决以上的问题,已经将指标生态的各种产品进行很好的整合。

Grafana Alloy介绍

Alloy是Grafana 发布替代之前Grafana Agent的开源产品。

简单的官方介绍:

“Grafana Alloy 是一个开源的 OpenTelemetry Collector 发行版,内置 Prometheus 管道,并支持度量、日志、追踪和性能剖析。”

更为详细的官方介绍:

“Alloy 为 OTel、Prometheus、Pyroscope、Loki 以及许多其他指标、日志、追踪和分析工具提供了原生管道。此外,您可以使用 Alloy 管道执行各种任务,例如在 Loki 和 Mimir 中配置警报规则。Alloy 完全兼容 OTel Collector、Prometheus Agent 和 Promtail。您可以将 Alloy 作为这些解决方案的替代方案,或将其与多个收集器和代理结合成混合系统。您可以在 IT 基础设施的任何地方部署 Alloy,并将其与 Grafana LGTM 堆栈、Grafana Cloud 的遥测后端或任何其他供应商的兼容后端配对。Alloy 灵活多变,您可以轻松配置以满足本地部署、仅云部署或两者结合的需求。”

APO是如何使用Grafana Alloy

从Grafana Alloy的官方介绍中可以看出Alloy很强大,但APO并未使用Alloy所有的功能,主要使用以下两个功能:

  • 集成管理各种Prometheus的exporter的功能,有兴趣的朋友可以翻之前文章介绍了如何使用Alloy一键配置完成exporter的指标采集
  • 管道功能:跨云,跨集群,跨网段的指标采集之后要传输到统一可观测性后台展示

集成管理Prometheus各种exporter功能

通过简单配置即可完成exporter的配置、安装部署:比如通过以下的配置,即可实现ElasticSearch 的exporter的部署和采集

# 采集 elasticsearch指标
prometheus.exporter.elasticsearch "example" {
address = "http://<elasticsearch-url>:9200"
basic_auth {
username = USERNAME
password = PASSWORD
}
}

prometheus.scrape "mysql" {
targets = prometheus.exporter.elasticsearch.example.targets
forward_to = [otelcol.receiver.prometheus.default.receiver]
}

数据的管道功能

管道功能,数据可以通过OpenTelemetry的collector完成数据的跨集群、跨网络、跨云的传输。

数据流向:

Alloy(采集指标)-> Otel Collector (网络边界)->(网络边界) Otel Collector -> VictoriaMetric

管道功能核心的逻辑在于通过简单配置OTEL collector

  • recievier
  • exporter

配置示例:

边缘侧 Collector 配置(负责接收指标并发送到中心 Collector):

边缘侧 Collector 将通过 OTLP 接收指标数据,并通过 OTLP 发送到中心侧 Collector。

配置示例(边缘侧 Collector):

receivers:
otlp:
protocols:
grpc: # 支持 gRPC 和 HTTP 协议
http:

exporters:
otlp:
endpoint: "http://center-collector:4317" # 中心 Collector 的接收地址
metrics:
resource_to_telemetry_conversion:
enabled: true # 将资源级信息转换为 Telemetry 数据

service:
pipelines:
metrics:
receivers: [otlp] # 从应用接收 OTLP 格式的指标数据
exporters: [otlp] # 导出到中心 Collector

中心侧 Collector 配置(负责从边缘侧 Collector 接收指标并写入存储系统):

中心侧 Collector 将通过 OTLP 接收边缘侧 Collector 发来的指标数据,并将其导出到最终的存储后端。

配置示例(中心侧 Collector):

yaml


Copy code
receivers:
otlp:
protocols:
grpc:
http:

exporters:
prometheus:
endpoint: "http://prometheus:9090/metrics" # Prometheus 的接收地址
namespace: "otel_metrics"

service:
pipelines:
metrics:
receivers: [otlp] # 从边缘侧 Collector 接收 OTLP 格式的指标数据
exporters: [prometheus] # 导出到 Prometheus

配置说明:

1.边缘侧 Collector:

  • receivers: 使用 otlp 接收应用程序发送的指标数据,支持 gRPC 和 HTTP 协议。
  • exporters: 使用 otlp 导出数据,endpoint 是中心侧 Collector 的接收地址。

2.中心侧 Collector:

  • receivers: 使用 otlp 从边缘侧 Collector 接收指标数据。
  • xporters: 使用 prometheus 将数据导出到VictorioMetrics。

APO如何看待Alloy其它功能

  • Alloy集成Loki而来的日志能力,在实际使用日志场景中可能不够用,实际日志都要完成非结构化转化成结构化这一步骤,但是Loki在此方向并不擅长
  • Pyroscope等Continues Profiling的数据目前在OpenTelemetry生态并未完全成熟,即便能够使用Alloy完成数据的采集,但是如何传输,存储,展示都成为问题,还有很多问题等着解决

Alloy的exporter集成能力是经过grafana agent项目能力沉淀而来,坑相对而言比较少。APO在实际使用Alloy也踩了些坑,通过不断调整配置,相信未来也会越来越稳定。

VictorioMetrics的使用

VM已经成为很多公司存储指标的首选,主要是相比prometheus其它生态产品而言

架构简洁性:

  • VictoriaMetrics: VictoriaMetrics 集群版的架构较为简单,支持单一二进制文件启动,减少了复杂的集群管理工作。它既可以用作单机部署,也可以扩展为分布式集群,支持水平扩展,且维护相对简单。

  • Thanos/Cortex: 这两者的架构相对复杂,通常需要多个组件(如 Querier、Store Gateway、Compactor 等)协同工作,且往往涉及到对象存储(如 S3、GCS 等)来进行长期存储。因此,它们的配置、部署和维护难度较高,适合需要长时间数据保留的大规模集群。

高效存储和压缩:

  • VictoriaMetrics: 其高效的数据压缩和存储引擎使其在处理大量数据时更加节省存储空间。它采用自定义的存储格式和时间序列压缩算法,特别擅长处理大规模高频率的时间序列数据。

  • Thanos/Cortex: 这两者依赖于 Prometheus 的存储块和外部对象存储来处理长时间的数据保留,并通过外部系统进行压缩。虽然通过对象存储解决了长期存储问题,但这种方式带来的延迟和复杂性较高,尤其是在查询大量历史数据时,可能会受到网络和存储系统性能的影响。

性能和查询速度:

  • VictoriaMetrics: 由于其优化的存储引擎和索引机制,VictoriaMetrics 在长时间范围的查询场景中通常表现更好。它可以处理大规模数据的高性能写入和快速查询,即使在单节点场景下也能保持良好的表现。

  • Thanos/Cortex: 这两者的查询性能取决于集群的规模和外部存储的读写性能,尤其在跨多个 Prometheus 实例进行查询时,由于依赖对象存储,查询速度相对较慢。此外,Cortex 使用分区和多租户设计,虽然增强了灵活性,但在某些场景下也会引入查询延迟。

完全兼容 Prometheus API:

VictoriaMetrics 完全兼容 Prometheus 的查询语言(PromQL)和数据采集接口,能够无缝替代 Prometheus,且支持从 Prometheus、Thanos、InfluxDB 等系统中直接导入数据,迁移成本低。

指标的统一展示

当各种prometheus exporter的数据存储在VictorioMetrics之中,可以利用生态已有的Grafana大屏直接展示,感谢StarsLiao的贡献,在其贡献的大屏中,有很多已经成为众多公司的选择,很多大屏有着上万的好评。APO中很多大屏都引入了大佬的作品。

1 图

2 图


总结

APO利用Prometheus和OpenTelemetry的成熟生态成果,快速完成指标的采集、传输和统一展示。虽然这些能力并不是APO的核心价值,但也是可观测性平台的核心支柱能力,也欢迎用户先将APO当成指标的采集、传输和统一展示的工具,当系统越来越复杂,需要集成Trace、日志等能力之时,用户可以不用迁移平台。

APO介绍:

国内开源首个 OpenTelemetry 结合 eBPF 的向导式可观测性产品

apo.kindlingx.com

https://github.com/CloudDetail/apo

APO全量日志对接logstash和fluent日志采集生态

· 阅读需 7 分钟

Cover 图

APO 日志介绍

采集流程图

1 图

APO 使用 ilogtail 作为日志采集组件并改造支持额外功能, 在 vector 中进行日志结构化处理。

APO 日志功能

  • 日志指标

     统计日志数并生成日志数指标。出现错误日志时,计算日志错误指标

  • 故障现场日志

     应用程序出现慢或者错误trace时,将这段时间内的日志收集并写入clickhouse中。使用 k8s 信息或 pid 信息关联故障链路和故障现场日志

  • 全量日志

     1.APO日志界面中提供了为不同应用配置不同的日志解析规则,vector 根据解析规则将日志结构化,解析规则中提取的日志字段会单独成列加快查询

     2.日志库支持全文检索和查看日志上下文

APO 日志中使用logstash或fluent

用户如果已经使用 logstash 或者 fluent 生态的日志采集组件,可直接与APO日志进行对接。但需要注意的是,使用对接日志采集组件可能会导致某些信息的缺失或功能无法使用。

APO 日志仅全量日志功能可用

APO 日志不可用功能

  • 故障现场日志:APO 使用改造后的 ilogtail 添加 K8S 信息或 PID 信息,使用 logstash 或 fluent 替换 ilogtail 会导致在 K8S 和虚机环境中均无法关联链路和日志信息,导致功能缺失
  • 日志指标:APO 使用 ilogtail 统计日志指标,使用 logstash 或 fluent 替换 ilogtail 导致该功能缺失

logstash 或 fluent 需填充 K8S 相关信息

确保在 Kubernetes 环境中部署日志采集组件,同时日志需要填充以下标签信息,同时这些标签信息需要适当的重命名。重命名具体实现可以参考后续提供的 vector 配置示例。

  • container.name -> 容器名
  • container_id -> 容器ID
  • k8s.namespace.name -> Kubernetes 命名空间
  • k8s.pod.name -> Pod 名称
  • host.ip -> 节点 IP
  • host.name -> 节点名称
  • source -> 文件路径
  • content -> 日志内容
  • timestamp -> 日志采集时间

APO 接入日志采集组件示例

当用户在 K8S环境中使用 Logstash 生态(如 filebeat, logstash)或 Fluent 生态(如 fluentd, fluent-bit),可参考如下示例接入 APO 日志。

Logstash 生态示例 - 使用 Filebeat

1.设置 NODE_IPNODE_NAME 环境变量

    env:
- name: NODE_NAME
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: spec.nodeName
- name: NODE_IP
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: status.hostIP

2.配置 Filebeat 

日志采集组件如果和 APO Server 不在同一集群,output.logstash 中的 hosts URL 设置为 Server 所在节点IP,Port 改为 30310

    filebeat.inputs:
- type: filestream
id: kubernetes-container-logs
fields:
host.ip: ${NODE_IP}
fields_under_root: true
paths:
- /var/log/containers/*.log
parsers:
- container: ~
prospector:
scanner:
fingerprint.enabled: true
symlinks: true
file_identity.fingerprint: ~

processors:
- add_kubernetes_metadata:
host: ${NODE_NAME}
matchers:
- logs_path:
logs_path: "/var/log/containers/"


output.logstash:
hosts: ["apo-vector-svc.apo:4310"]

3.更新 apo-vector 的 ConfigMap

    # 替换sources内容
sources:
logstash_log:
type: logstash
address: 0.0.0.0:4310


# 替换 transforms 的 flatten_logs 内容
transforms:
flatten_logs:
type: remap
inputs:
- logstash_log
source: |
."host.name" = .host.name
."host.ip" = .host.ip
.content = .message
."_source_" = .stream
."_container_id_" = .container.id
."k8s.namespace.name" = .kubernetes.namespace
."k8s.pod.name" = .kubernetes.pod.name
."container.name" = .kubernetes.container.name
del(.agent)
del(.log)
del(.message)
del(.kubernetes)
del(.container)
del(.input)
del(.orchestrator)
del(.ecs)
del(.host)
del(.@metadata)
del(.stream)

# 调试日志信息,日志采集对接成功后可移除
sinks:
to_print:
type: console
inputs:
- flatten_logs
encoding:
codec: json
json:
pretty: true

Fluent 生态示例 - 使用 Fluent Bit

1.设置 NODE_IPNODE_NAME 环境变量

    env:
- name: NODE_NAME
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: spec.nodeName
- name: NODE_IP
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: status.hostIP

2.配置 Fluent Bit 的解析、 输入、过滤器和输出配置。日志采集组件如果和 APO Server 不在同一集群,OUTPUT 中的 Host 设置为 Server 所在节点IP,Port 改为 30310

    [Input]
Name tail
Path /var/log/containers/*.log
Refresh_Interval 10
Skip_Long_Lines true
Parser cri
Tag kube.*

[Filter]
Name kubernetes
Match kube.*
Kube_URL https://kubernetes.default.svc:443
Kube_CA_File /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
Kube_Token_File /var/run/secrets/kubernetes.io/serviceaccount/token
Labels false
Annotations false

[FILTER]
Name modify
Match *
Add host_ip ${NODE_IP}

[OUTPUT]
Name forward
Match *
Host apo-vector-svc.apo
Port 4310

3.修改 apo-vector 的 ConfigMap 以匹配 Fluent Bit 输出格式

    # 替换sources内容
sources:
fluent_log:
type: fluent
address: 0.0.0.0:4310

# 替换 transforms 的 flatten_logs 内容
transforms:
flatten_logs:
type: remap
inputs:
- fluent_log
source: |
."host.name" = .kubernetes.host
."host.ip" = .host_ip
."_source_" = .stream
.content = .message
."_container_id_" = .kubernetes.docker_id
."k8s.namespace.name" = .kubernetes.namespace_name
."k8s.pod.name" = .kubernetes.pod_name
."container.name" = .kubernetes.container_name
del(.kubernetes)
del(.stream)
del(.message)
del(.host)
del(.host_ip)

# 调试日志信息,日志采集对接成功后可移除
sinks:
to_print:
type: console
inputs:
- flatten_logs
encoding:
codec: json
json:
pretty: true

APO 日志对接问题排查

配置修改后,如果 APO 日志界面仍未出现日志,需要进行排查

问题1 vector中有日志事件,但APO 界面无日志

需要通过vector日志查看日志事件格式是否正确

vector 配置中添加调试日志信息配置。观察vector日志中事件,通常正确的日志信息包含如下信息。

    {
"_container_id_": "852a7484f030",
"_source_": "stdout",
"container.name": "java-demo-1",
"content": "{\"level\":\"ERROR\",\"method\":\"org.apache.juli.logging.DirectJDKLog.log\",\"msg\":\"Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is org.springframework.web.client.ResourceAccessException: I/O error on GET request for \\\"http://localhost:8082/api/jpa-demo/sleep\\\": Read timed out; nested exception is java.net.SocketTimeoutException: Read timed out] with root cause\",\"thread\":\"http-nio-8081-exec-2\"}",
"host.ip": "192.168.1.69",
"host.name": "node-69",
"k8s.namespace.name": "default",
"k8s.pod.name": "apo-java-demo-b7994cc54-ss58f",
"timestamp": "2024-09-25T07:46:38.146950792Z"
}

如果发现信息缺失,请参考填充 K8S 相关信息确保所有信息填充

问题2 vector日志中未收到任何日志事件

需要排查一下对接采集组件是否可以正常写入vector

请查看filebeat,fluent-bit等采集组件等日志信息


APO介绍:

国内开源首个 OpenTelemetry 结合 eBPF 的向导式可观测性产品

apo.kindlingx.com

https://github.com/CloudDetail/apo

APO在一个页面整合关联可观测性数据的设计思路

· 阅读需 16 分钟
Autopilot Observability
APO 向导式可观测性平台

Cover 图

可观测性能力是系统在运行过程中,通过收集、关联和分析不同类型的数据,来理解和解释系统行为的能力。其目标不仅是发现问题,还要提供足够的信息来分析和解决这些问题,甚至在问题发生之前预见潜在的风险。

划重点:关联分析不同类型的数据,帮助用户理解和解释系统行为的能力是可观测性系统建设的关键目标。

可观测性数据不是简单将Trace、Metric、log,三者数据做在一个产品里面,三者仍然是割裂的数据。OpenTelemetry的出现给三者内在有机关联带来了更多可能性,如何关联这些数据并且呈现仍然有许多挑战。本文探讨APO团队对如何关联可观测性的设计思路,目标是能够在一个页面关联微服务接口所有故障排查需要的相关数据,完成故障的定界定位。

思路一:简单关联独立展示(帮助用户减少了登录次数)

最容易想到的关联方式,就是将三者数据分为三个Tab显示,每个tab只负责展示自身的数据,数据之间仍然缺少关联和提示。

如果用户要做关联查询经常要完成这样的操作:

  1. 在Trace 页中筛选出Trace信息,确认该Trace可能有问题,然后拷贝该TraceID,相关的IP信息,servicename,podname等相关信息也拷贝出来用来查询指标(有时还需要打命令才能查询出pod所对应的node在哪,在虚拟机里面可能还需要在cmdb根据IP查出node的唯一标识)
  2. 在Log页中,如果log已经输出了TraceID,可以通过TraceID搜索到相关的日志,如果日志未输出TraceID,就比较难以查询到日志
  3. 在Metric页面,根据servciename、podname、ip信息、node唯一标识完成指标的查询

思路二:简单关联但是数据串联(帮助用户减少了拷贝TraceID的时间)

在简单关联中,很容易进一步想到,能不能在展示Trace的时候,通过TraceID直接查看日志,而不用去拷贝TraceID至log页中查询。目前很多工具已经做到了这一步的关联,但是很多工具也就停留在这一步,在这个思路上其实还可以进一步关联,也就是将"思路一"所有可能要人为操作的功能,提前帮助用户查询好,用户可以沿着各种链接跳转至不同的数据当中。

很多可观测性平台按照"思路二"完成数据的串联之后就结束了,但是用户在使用过程中会容易出现以下的问题:

  • 缺少全局统计信息,从单个Trace出发,虽然能在不同ROOT SPAN中查看指标、日志等相关信息,但是由于没有统计信息,很容易一叶障目。为了让大家理解更深刻,举例说明即便没有任何故障,延时落在P50的Trace表现和延时落在P99的Trace表现相差很大。

  • 由于没有统计信息导致、确定故障根因节点困难。假设业务操作入口--"下单接口"出现了20%的错误率同比升高,下单接口正常时大概有1%的错误率,现在错误率升高了,仅仅分析出错的Trace可能并不能很好的分析出问题,因为很难确定者错误的Trace是新增错误,还是以往就有的错误。

怎么办?不能从局部去排查问题,而是应该以微服务接口(Service+URL)的方式去查看数据, 因为微服务接口有其黄金指标,可以很快判断微服务接口是否异常,如果异常,接下来需要做的是在关联各种可能需要查看的数据至该微服务接口详情页中,这样就可以有全局信息,快速判断该微服务接口是不是故障根因。


思路三:以微服务接口(Service+URL)为入口,更好统计信息更多的关联数据、减少以偏概全的风险

根据黄金指标的统计信息,可以很快判断哪些微服务接口是有问题的,比如同比延时高,同比错误率高。那接下来的问题就是点击微服务接口(Service+URL)详情之后,如何关联数据。

初步想法:可以将Trace页、Metric页、Log页作为独立tab集成至微服务接口的详情页中,接口层和应用层告警信息也能关联至详情页

这样在详情页中

Log页,可以提前过滤出该微服务接口的日志

Trace页,可以提前过滤出调用过该微服务接口的Trace

Metric页,由于微服务接口缺少实例等相关资源tag元数据,用户需要提前根据service,查出实例信息,然后查出Node信息,将实例和Node信息进行完整的展示

告警信息也可以关联进来,但是只能关联接口层和应用层面告警信息:比如Service实例应用级别的告警,比如延时、错误率、吞吐量、JVM告警等信息

进一步想法:提前将微服务接口的微服务实例和实例所属Node信息查询并关联,实例和Node之间的网络质量也可以关联进来

这样在详情页中,可以进一步显示:

Log页,可以提前过滤出该service+URL的日志

Trace页,可以提前过滤出service+URL的Trace

Metric页,微服务所有实例和所在Node的资源指标信息,所有建连的网络质量指标也可以关联进来

告警信息:除了应用层的告警信息,还可以关联资源层面的告警信息容器实例、node资源级别告警能被关联进来,用户对全局更有掌握

还有没有能够进一步的关联信息呢?能够缩小日志和Trace的排查范围,过滤出更容易让用户一击即中的日志和Trace呢?避免在海量的日志和Trace中不断试错

再进一步想法:分析相关的Trace,并提取Exception,关联时间段内所有Exception的日志信息,并展示Exception的传播链路

 图1

通过提前分析经过该微服务接口的trace,提取出所有的Exception信息,然后展示故障传播链路,并可以根据Exception信息关联含有该Exception的日志。同时提供日志出错的数量变化曲线,帮助用户更好的定位到底要查看哪些Trace和日志。在该tab中,通过时间轴选取的日志信息,全都含有Exception或者错误信息。

 图2 带有Exception的日志

这样用户排查日志和Trace的时候,是可以根据日志错误曲线、Exception种类信息导航至出错的日志和Trace,而不是查看所有的日志,或者搜索有Exception的日志,然后再去关联Trace一个一个查,从而帮助用户对错误有更深入的理解。传播链可以快速导航定位至下游依赖的服务接口。

微服务的接口详情页,还需要什么信息来辅助定界故障呢?

还进一步想法:根据URL级别拓扑,关联业务操作入口-快速实现故障影响面分析

很多可观测性工具只有应用级别的拓扑图,缺少URL级别的拓扑视图。应用级别的拓扑图其实是整个集群的业务执行拓扑,要从完整的拓扑中,区分出不同业务操作接口的执行路径有一定难度。

URL级别的拓扑能够反映某具体业务操作的执行路径。

业界王者Dynatrace的Service Flow本质上实现的就是URL级别的拓扑。

 图3 URL级别拓扑每个节点代表service+URL

 图4 同一个服务不同的URL会作为不同节点出现

URL级别拓扑结构的优势

1.精确的故障定位:

  • URL级别的拓扑结构允许你精确识别某个特定URL或API调用的故障及其在整个系统中的传播路径。这对于识别单个请求路径的性能问题、错误率或流量瓶颈尤其有用。

2.详细的依赖关系分析:

  • 通过URL级别的拓扑图,你可以看到每个请求如何穿过不同的服务和依赖组件。这有助于理解某个URL请求的依赖链条,从而识别哪个具体环节出现了问题。

3.更细粒度的影响分析:

  • URL级别的拓扑结构可以让你评估特定API调用或功能的影响范围,特别是在微服务架构中,不同的URL可能对应不同的服务或操作。这对于分析特定功能或业务逻辑的故障影响尤为关键。

基于URL级别拓扑结构的故障影响面分析

任意微服务接口,都存在于某业务操作的URL级别拓扑结构中,通过微服务接口逆查,就可以快速找到业务操作入口,然后可以根据业务操作入口的延时、错误率、吞吐量等同比指标快速判断业务操作入口有没有受到故障影响。

根据故障影响的严重程度,从而快速判断是否需要紧急介入,以及多少团队介入。(该功能将在APO9月版本迭代中发布)

基于URL级别拓扑结构关联中间件告警

根据URL级别拓扑接口,可以很清楚的判定某些中间件的告警是否和业务操作入口有关联,未来版本APO规划完成中间件指标监控之后,将中间件告警也关联进微服务接口详情页中,这样可以更好的判断微服务接口异常是否由于中间件告警而产生。

基于URL级别拓扑结构关联下游微服务接口告警

根据URL级别拓扑接口,可以很清楚的判定某些中间件的告警是否和业务操作入口有关联,未来版本APO规划关联下游微服务接口告警,这样提供多维信息判断是否需要排查下游接口,同时可以根据具体Trace信息来相互佐证,快速实现故障定界定位。

最后关联北极星指标完成延时问题的兜底

对于错误率上升的问题,通过关联exception和错误日志一般情况下能够实现对错误率上升故障的兜底解决。对于延时同比增加的问题,使用北极星指标一定能回答延时增加是由于什么原因导致的。关于北极星指标是什么,请参考链接 one.kindlingx.com

关联Trace和日志tab,帮助用户通过Trace和日志来佐证故障

当用户排查过以上的数据,基本上能回答告警影响面有多大,错误率上升和延时上升是什么原因了。通过快速查询Trace和日志可以用来佐证故障原因。


总结

APO是向导式可观测性产品,在一个页面关联了接口级的所有故障相关信息。

接口关联数据故障场景
接口自身的告警信息,应用层、资源层告警告警分析
接口的影响业务入口黄金指标影响面分析
接口的下游依赖告警关联级联告警影响分析
接口的实例和节点的资源指标饱和度分析
接口的网络指标网络质量分析
接口的代码Exception,以及含有Exception的日志错误闭环
接口执行的北极星指标延时闭环
接口执行的日志故障佐证
接口执行的trace故障佐证
接口所依赖的容器环境关键事件环境影响

APO介绍:

国内开源首个 OpenTelemetry 结合 eBPF 的向导式可观测性产品

apo.kindlingx.com

https://github.com/CloudDetail/apo

APO的告警关联和告警故障影响面功能介绍

· 阅读需 11 分钟
Autopilot Observability
APO 向导式可观测性平台

Cover 图

一般IT系统都会配置一系列告警来提醒运维或开发人员,系统存在问题。将告警进行分类之后,至少会有以下种类的告警:

  • 系统运行资源告警(CPU、内存、磁盘)
  • 网络质量告警
  • Kubernetes事件告警
  • 应用级别告警(延时、错误率、吞吐量)
  • 中间件告警

可观测性系统比较棘手的问题是告警噪音,告警噪音在某些场景是真实有效的,而在某些场景下又成为了噪音。APO团队认为告警噪音很难避免,但是可以通过在业务接口维度进行区分,快速聚焦到对业务产生影响的告警之上。同时APO还提供了故障影响面功能,用以判断告警到底对用户直接操作的入口业务有没有影响,如果有影响,需要确定什么级别的人员该被叫进来作为主导者,以便更快地调动资源恢复业务。

传统告警的处理方式

运维人员根据其经验设置告警规则,每种告警其实都是有意义的,如果没有意义,完全可以不设置该告警。

但在实际场景中,经常会出现告警噪音,也就是这种本应该产生警示作用的告警,实际上并没有实现其效果,反而成为了噪音。

我们必须要承认一个事实:告警噪音是很难避免的。

告警噪音:通常指的是那些对实际系统健康或业务影响不大的告警

这类告警的出现原因有多种,主要包括以下几方面:

1. 阈值设置不合理(很难设置准确,因为相同阀值情况下,不同业务、相同业务不同压力都可能产生不同的后果)

传统的告警系统依赖于静态阈值,当某些指标(如CPU、内存等)超过预设的阈值时会触发告警。若阈值设定过于严格或不够灵活,就会导致许多不具备实际影响的波动也触发告警。例如,短时间的CPU使用率上升可能只是某个后台任务的正常行为,正常情况下并不会影响系统的稳定性,但如果阈值设置过低,系统仍然会产生告警。但是也有可能某些业务的延时波动就是该波动导致的。

2. 指标波动过大(绝大多数情况下,即便是无效告警,也是一种信息提示)

一些系统和应用在正常运行时,某些指标会有自然的波动。如果这些波动频繁触发告警,但并没有实际问题,这些告警会成为噪音。没有考虑系统的正常波动范围和基线,很容易导致无效告警,但是某些情况下,告警也确实会提醒故障,所以很多时候告警的阀值就会保持不动。

传统告警方式总结

传统告警非基于智能基线的告警有其存在的理由,阀值肯定是针对某些业务有效果的情况下才配置的,指标如果波动过大,也确实需要告警出来,只是作为告警应该分级处理。

如果告警系统没有设置优先级(例如将告警分为“高”、“中”、“低”优先级),那么所有告警都被平等处理,导致一些不重要的告警与关键告警混在一起,无法及时区分真正需要处理的问题。


APO的告警分类展示逻辑

APO的核心页面设计是基于服务端点也就是业务接口来展示的,通过分析业务接口来判断告警是否真的产生了故障影响有助于判断哪些告警是真的告警,而忽略那些告警噪音。

APO的告警排查使用思路:

  1. 重点识别哪些服务端点代表的接口有异常
  2. 在接口详情中找到有哪些告警
  3. 判断故障影响面,告警是否很严重?需要拉上哪些人立马排查

APO首页告知哪些接口产生了异常

1 图

APO首页列出了所有接口的同比影响,并智能排序,只有接口同比有异常的才会排在前面展示,如果接口同比没有异常很可能是排序在下一页中,用户可能都不需要关心。 2 图

告警与接口的影响关系

系统运行资源告警(CPU、内存、磁盘)

系统运行资源告警(CPU、内存、磁盘)在首页中会以基础设施状态告警呈现,只要接口同比有异常且基础设施状态亮红灯,就可以确认基础设施状态影响了该接口的正常执行。

3 图

如果在首页中所有的接口指标变化不大,说明该系统运行资源告警(CPU、内存、磁盘)暂时不需紧急介入,如果有时间可以关注为什么产生该告警。 4 图

网络运行质量告警

网络运行质量告警在首页中会以网络质量状态呈现,只要接口同比有异常且网络质量状态红灯,就可以确认网络质量状态影响了该接口的正常执行。

5 图

如果在首页中所有的接口指标变化不大,说明该网络告警影响面很小,暂时不需紧急介入,如果有时间可以关注为什么产生该告警。 6 图

Kubernetes事件告警

Kubernetes事件告警在首页中会以Kubernetes事件告警状态呈现,只要接口同比有异常且Kubernetes事件红灯,就可以确认K8S事件影响了该接口的正常执行。

7 图

如果在首页中所有的接口指标变化不大,说明该网络告警影响面很小,暂时不需紧急介入,如果有时间可以关注为什么产生该告警。 8 图

应用级别告警

应用级别的告警如果是延时、错误率、吞吐量的同比异常,那可以直接看查看接口详情,排查问题。

APO 的服务详情中的告警tab,列出来所有可能和业务接口有关的告警

例如:ts-travel-service出现了接口的延时同比上升或者错误率同比上升,可以在该服务中,查看所有该接口关联起来的告警信息,从而快速聚焦到这些告警之上。 9 图

告警之后的第一步行为:告警的影响面分析

通过学习SRE相关知识或者告警处理的第一直觉,应该是判断这个告警的影响范围,也就是完成影响面分析,从而快速判断该告警是否会从简单告警演变成P0的故障。

告警的影响面分析不管如何做,最终需要回答以下的问题:

  • 目前告警对哪些接口产生了影响?
  • 这些接口又影响了用户使用哪些业务操作

10 图


总结

告警噪音是很难消除的,而且告警噪音本身也是一种提示告知某些指标有异常。APO承认这个事实,推荐采用如下方式排查告警:

APO的告警排查使用思路:

  1. 重点识别哪些服务端点代表的接口有异常(如果没有接口有异常,说明告警都是告警噪音。当然要对告警分级,比如磁盘满,进程挂掉等场景都是严重告警和接口异常无关)
  2. 在接口详情中找到有哪些告警
  3. 判断故障影响面,告警是否很严重?需要拉上哪些人立马排查

APO介绍:

国内开源首个 OpenTelemetry 结合 eBPF 的向导式可观测性产品

apo.kindlingx.com

https://github.com/CloudDetail/apo

APO的接口级拓扑 VS Dynatrace Service-Flow

· 阅读需 9 分钟
Autopilot Observability
APO 向导式可观测性平台

Cover 图

在可观测性系统中,几乎所有的产品都会提供拓扑功能。大部分用户在初看这个拓扑之时都会觉得非常有用,但是一旦真实落地使用,就感觉这个拓扑比较鸡肋。这篇文章重点探讨APO团队是如何考虑让用户能够更好的使用拓扑,真正发挥出拓扑的价值。

应用级别拓扑定义

GPT介绍应用级别拓扑:

应用级别拓扑是一种用于表示应用程序内部及其与其他应用程序或系统之间关系的可视化模型。它描述了应用程序中的各个组件(如服务、数据库、消息队列等)之间的交互方式,包括调用关系、数据流动和依赖关系。应用级别拓扑的目标是帮助开发和运维团队更好地理解和监控应用程序的架构、性能和健康状况。

应用级别拓扑的关键要素:

  1. 服务或组件:表示应用程序中的各个服务或模块,例如Web服务、数据库服务、缓存服务等。
  2. 依赖关系:显示应用程序对外部系统或资源的依赖,例如第三方API、外部数据库等。
  3. 数据流动:描述数据在应用程序中的流动路径,从数据的输入源到输出目标。
  4. 性能指标:包括延迟、吞吐量、错误率等关键性能指标,帮助监控应用程序的运行状态。

应用级别拓扑有助于在复杂的分布式系统中跟踪请求的执行路径,识别性能问题和瓶颈,并在发生故障时快速定位问题的根源。


提供了应用级别拓扑的产品

常见的开源apm、npm软件都提供了应用级别拓扑

12-1 pinpoint的应用级别拓扑

12-2 skywalking的应用级别拓扑

12-3 deepflow基于流量的应用级别拓扑


应用级别拓扑鸡肋的原因

应用级别拓扑肯定是有用的,但是实际落地比较鸡肋的原因如下:

  • 在小规模环境中比较有用,一旦达到几十个至上百个应用节点,拓扑结构就是一张蜘蛛网要清晰看出某个具体应用服务的依赖关系比较困难。
  • 应用级别拓扑结构粒度较粗,难以精准判断依赖关系影响:应用级别拓扑反应的程序与程序之间的依赖关系,并不是接口层,比如一个应用提供了10个接口,其中某一个接口调用了redis,在应用级别拓扑结构就会依赖redis,但是其余的接口其实并不依赖redis,很难回答以下的问题:
  1. redis有告警了,影响哪些业务操作?根据应用拓扑只能猜测redis告警,可能影响应用,具体是否受影响要在深入人为排查。
  2. 业务操作入口(用户直接使用的接口)执行缓慢,如何找到到底哪个依赖服务导致的呢?在应用拓扑中,得顺着应用拓扑所有路径去排查每个应用(几乎需要排查所有被监控的应用,因为所有的应用最后都可能形成一个拓扑结构)。现在的优化措施是在应用拓扑结构中优先排查应用告警的应用,这样希望能够尽早找到故障节点,但是有时仍然需要排查不少的应用,才能撞到故障根因节点。
  3. 业务操作入口(用户直接使用的接口)执行缓慢的另外一种排查思路,就是查看业务操作入口的Trace,这样看Trace缺失了统计信息,应用级别拓扑本应该发挥统计数据价值无用武之地。

业界王者Dynatrace的ServiceFlow解决了应用拓扑鸡肋的问题

以下是Dynatrace 的Service Flow图

12-4

初看和应用拓扑差不多,反应的也是应用节点直接的依赖调用关系,但是实际上和应用拓扑有以下的不同。

精准反应应用调用关系:相同的应用节点在拓扑中会按照调用顺序出现多次

12-5

ServiceFlow精准的反应应用接口之间的调用关系。相同业务操作入口的拓扑图才会被归属在同一个ServiceFlow中。

基于ServcieFlow 可以精准的找到依赖关系,比如redis告警,到底是如何影响业务调用链的。

基于ServiceFlow可以清晰的看出来业务操作入口的影响是由于下游依赖的哪些应用接口执行导致的。

在大规模业务中,会将对入口业务操作影响贡献不大的应用收缩,从而在一张图中清晰看出调用关系

12-6


APO中的接口URL级别拓扑和ServiceFlow异曲同工

12-7

APO中的URL接口级别拓扑是根据相同业务操作入口的Trace拓扑不断分析统计而成,虽然看上去像应用级别拓扑,但是实际是URL接口级别拓扑,这样可以清楚看出应用为了执行此类业务的调用关系。

如果redis告警,在此拓扑中未发现有redis,说明redis告警不会影响此业务,不需要像应用级别拓扑再次猜测redis告警到底影响了哪些业务。

APO也实现了同样的效果:精准反应应用调用关系------相同的应用节点在拓扑中会按照调用顺序出现多次

12-8

根据业务入口延时相似度对拓扑结构的收缩,保证一张图可以清晰显示业务调用关系

APO利用延时曲线相似度来收缩相似度非常低的接口服务。

业务操作入口的延时曲线与下游依赖的节点延时曲线完全不相似,说明两者应该不是很相关,可以收缩起来。

相似度较高的曲线,比如下图,紫色的延时曲线明显和绿色延时曲线很相似,还有一些曲线是有波动的,但是还有很多曲线是很平稳的。那些曲线平稳的肯定对此业务操作入口的波动贡献很小,所以可以收缩。

12-9

12-10


未来基于URL接口级别拓扑能够实现以下功能

在APO的规划当中会实现以下的功能:

  • 每个微服务接口点击详情之后,自动关联业务操作入口从而快速判断故障影响面
  • 按照URL接口界别拓扑,自动化精准关联下游依赖节点告警

APO介绍:

国内开源首个 OpenTelemetry 结合 eBPF 的向导式可观测性产品

https://apo.kindlingx.com

https://github.com/CloudDetail/apo

APO选择ClickHouse存储Trace的考量

· 阅读需 6 分钟
Autopilot Observability
APO 向导式可观测性平台

Cover 图

OpenTelemetry生态已经很成熟,但对用户而言,选择OpenTelemetry仍然需要考虑以下几个问题:

  • 探针的成熟度
  • 海量Trace数据的存储和展示的问题

本文重点讨论海量Trace数据的存储与展示问题,APO定位是一个OpenTelmetry的发行版,本文将重点讨论APO团队是如何考虑这个问题的。

现有OpenTelemetry的Trace存储方案

OpenTelemetry生态过于灵活,选择众多,这也给用户带来了幸福的烦恼。

直接使用Jaeger+ElasticSearch方案

Jaeger作为老牌的Tracing方案,其使用习惯已经被很多用户所接受,Jaeger与OpenTelemetry同属于CNCF组织下的开源项目,所以两者也是结合最紧密的。

目前使用OpenTelemetry方式最快的方式使用的是Jaeger+ElasticSearch方案,该方案成熟。但是由于ElasticSearch的存储查询效率并不高,当规模较大的时候成本较大,所以很多用户期望有更加高效的存储方案。

新起的开源Signoz与Uptrace的做法

Signoz与Uptrace是近几年OpenTelemetry生态的发行版本,这两者都选择了ClickHouse作为存储方案,ClickHouse由于其强大的压缩和查询能力,成为很多可观测性方案的标准做法。

Signoz与Uptrace做法相同:自定义ClickHouse的表结构

自定义ClickHouse的表结构的好处在于,所有的内容完全能够自己掌控,但是坏处是其他生态产品很少会基于该自定义表结构进行演进,从而没有办法与其他生态集成。

大量已经习惯了使用Jaeger用户的在使用Signoz和Uptrace的时候都有一定的学习成本,比如需要理解:

  • Span自身花的时间应该如何查找
  • Span的tag应该如何才能查看

这对于没有接触过Jaeger的用户而言是可行的,选择Signoz和Uptrace没有太多差别,但对于已经熟悉Jaeger的用户不大友好。

ClickHouse官方的Exporter方式

ClickHouse官方针对OpenTelemetry生态推出了Exporter,解决了Trace如何落地到ClickHouse的问题,但是并未搭配界面使用,这意味着用户使用ClickHouse官方Exporter的用户,需要定制页面完成Trace的展示和分析工作,这对于绝大部分用户而言并不友好。

Jaeger 2.0 基于ClickHouse的实现Tracing存储方案

具体可以参考文章:迈向 Jaeger v2:更多 OpenTelemetry!

虽然当前Jaeger 1.X版本并没有正式支持ClickHouse,而是在1.57之前通过RemoteStorage 的插件方式支持,具体见链接,在最新的1.58之后,RemoteStorage 就不再支持了。


APO对Trace存储的思考

不同表结构对性能影响没有显著差别

我们团队调研过Jaeger官方关于ClickHouse不同表结构对于Trace插入和查询的影响(主要对比Jaeger RemoteStorage 的表结构和ClickHouse的官方exporter表结构),虽然表结构对性能影响有些许差异,但在插入、查询、压缩比方面各有千秋,而且性能差异对大部分用户也是能接受的。具体见链接

用户习惯最重要

由于APO在向导式界面已经屏蔽了Trace的细节,先通过指标和告警引导用户到需要查看的Trace时,用户才通过TraceID查看Trace。此时,我们认为用户能够以最小的成本理解Trace细节最重要,所以我们引入了Jaeger来展示Trace细节,并没有重新开发页面或者选择signoz、uptrace的方案。

APO对Jaeger RemoteStorage的扩展

Jaeger2.0 已经明确会支持ClickHouse了,在Jaeger 2.0发版之前,APO做了Jaeger RemoteStorage的扩展,使其能够支持1.58以后的版本。具体实现项目见链接


总结

ClickHouse不同的表结构对性能会有差异,但是只要使用ClickHouse其存储和查询效率就会比ElasticSearch高很多,所以在这种情况下,用户的体验就是最重要的。

对于用户而言,每天接触的新产品新功能很多,能够在新产品上无缝嫁接其已具备的成熟体验可能是最重要的。

Kindling-OriginX 在快手 Staging 环境的异常诊断效果分享

· 阅读需 13 分钟
Kindling-OriginX
故障根因推理引擎

业务可用性问题的快速诊断,历来是行业互联网公司面临的重大挑战,快手也不外如是。Kindling-OriginX的体系化设计理念快速打动了我们的工程师。快手随即开始了内部真实业务的验证落地;落地过程中,Kindling-OriginX能高效覆盖大部分线上问题的快速定界,其中20%可直接给出根因,缩短业务影响时长。未来,我们希望与Kindling-OriginX在异常场景和诊断效率上继续深度合作,进一步缩短业务异常的恢复时长,以及提升工程师研发幸福感。

---周辉,容器云稳定性团队负责人

Originx注:快手团队对根因的要求比较高,比如一般团队遇到请求被锁住,得到锁的代码堆栈就够了,但是快手团队要求更高,更希望知道为什么代码发生了锁住originx目前还只能给出哪段代码堆栈导致锁住。

目的

愿景:缩短对线上稳定性问题的定位时长,帮助业务快速止损,减轻日常问题排查的人力成本。

1.是否能在在公司落地,给实际的问题诊断带来帮助;

2.为问题诊断提供借鉴思路:通过ebpf采集系统层面指标,打通业务请求链路。

结论

OriginX 诊断能力

结论:能够进行问题的定界。

延时耗时示意图

初步分支定界

可以对问题起到初步分支定界的作用,能初步判断出是问题哪个或哪些类别,即 :

1.CPU 执行(onCPU)

  • 是否能够下钻
  • 对 frequency 问题的判定效果?可以设置 frequency 吗【Originx 目前支持各种频率 CPU 采样,但是需要重启探针】

2.等待调度到 CPU(RUNQ)

  • 较少发生,主机有较高的负载的场景

3.读写文件(VFS 的直接读写关联存储相关问题)

  • 如何确定拿到的文件和请求是相关
  • Originx 通过与请求过程中的系统调用关联,按照时间能精准匹配到请求时的系统调用

4.请求下游节点耗时长(网络调用)

5.锁等待或内存 GC 类型(futex 等)

  • 如何确定拿到的这个锁和这个请求有关
  • Originx 通过与请求过程中的系统调用关联,按照时间能精准匹配到请求时的系统调用

Originx 不擅长的故障种类:

1.对 CPU 算力分层类、夯机类、硬件类等问题的分析 Kindling-OriginX 诊断相对比较薄弱;

2.对Java 类服务的支持友好,接入 Kindling-OriginX 需要适配公司的 “全链路追踪系统”。

Originx 存在优化空间

快手使用的 Originx 版本在确定故障报告时存在多种可能性,需要人为排除噪音干扰因素。

1.由于一个采样报告只能得出一种结论,故障发生所在的时间段内若干采样点产生的多个报告,可能结论不一致,需要自己来判断具体是哪方面原 因占主导,排除干扰因素; 有时会出现----未发现明显异常的结论,如

2.故障分为慢故障和故障两大类。对于慢故障,请求调用时长与历史数据相对比,发现其大于 24h 内历史 P90(或 p99,p95) 数据,将其判定为慢故障。假设极端情况,存在故障的实例的请求时延在 24h 内一直都很高,那么后续的请求也会被判断为正常请求,产生漏判。

3.下钻诊断能力不足,当前除了对网络故障具备更细粒度的诊断(需接入 DeepFlow,在根因报告中对于对外调用网络耗时长的问题,根 因推导能够回答网络耗时分布的根因,例如是客户端网络问题还是服务端网络问题,是 RTT 问题还是丢包重传问题),其他类型问题 有待关联更多数据提供更多的下转能力。


原理

请求故障评估标准

业务请求时延指标大于 P90(或者 P95,P99 阈值),就会判定为慢请求故障。

线程状态分析方法(TSA)

有别于从资源视角的 USE 方法是从整理上找破绽来缩小异常的范围,给出可能性的方向,TSA 是从主体(线程)角度出发进一步明确线程时间消耗在哪里的方式。

http://u6v.cn/5VZWML

TSA 与 Trace 结合

内核视角缺少业务属性,Trace-Profiling 通过 TSA 的方法论产生的数据与 Trace 打通,做到了与业务关联,这样在生产环境就可以做到某个业务因为什么原因卡住了。

skywalking 会给请求打一个 trace id,利用 ebpf 的能力将 trace 通过 PID 和 TID 底层的 syscall 相关联利用

eBPF 技术能够深入内核,拦截线程执行用户代码的关键点位获取信息,在获得线程执行关键信息之后能够还原线程的执行过程。如 果只从线程维度看程序执行过程是很难分析出故障的,因为开发和运维的谈的故障都是 URL 维度的用户请求调用,所以光有线程维度程序 执行过程是不够的,需要和 Tracing 系统关联。当线程执行过程与 Tracing 系统关联之后,即可完整还原用户一次请求的执行过程。TraceProfiling 中关联了可观测性所需要的数据。

指标说明

Kindling-OriginX 并不直接提供 Trace 能力,而是采用接入 Trace 数据的形式,即通过接入目前成熟的 Trace 产品与提供标准接入 SDK 方 式,例如 Skywalking、OpenTelemetry、ARMS 等,利用 eBPF 能力将 Trace 数据进行扩展,将其与底层的系统调用相关联,进而实现整 的可观测性,消除程序执行与 Trace 数据中的盲区。

用决策树结合 TSA 实现对内核事件的自动化翻译

基于内核事件统计分析,可以形成这样的决策树,最终给出故障的根因。

北极星排障指标-CPU 时间程序

在 CPU 资源上所消耗的时间

  • OnCPU

    程序代码执行所消耗的 CPU cycles,可以通过程序火焰图确认代码在 CPU 上执行消耗的时间与代码堆栈。

  • Runqueue

    线程的状态是 Ready,如果 CPU 资源是充分,线程应该被调度到 CPU 上执行,但是由于各种原因,线程并未调度到 CPU 执行,从而产生的等待时间。

北极星排障指标-网络时间

网络时间属于两次 OnCPU 时间之间的 OffCPU 时间

  • 网络时间打标过程

    第一次 OnCPU 最后一个系统调用执行为 sock write 与第二次 OnCPU 第一个系统调用为 sock read,也可以理解为网络包出网卡至网络包从网卡收回的时间。

  • 网络时间分类

    DNS,TCP 建连,常规网络调用。

北极星排障指标-存储时间

属于两次 OnCPU 时间之间的 OffCPU 时间

  • 存储时间打标过程

    第一次 OnCPU 最后一个系统调用执行为 VFS read/write 与第二次 OnCPU 第一个系统调用为 VFS read/wirte。

  • 存储时间真实情况

    存储真实执行情况,由于内核的 pagecache 存在,所以绝大多数 VFS read/write 从程序视 角看:执行时间不超过 1 毫秒。

北极星排障指标-等待时间

  • futex

    通常指的是一个线程在尝试获取一个 futex 锁时因为锁已经被其他线程占用而进入等待状态的时间。在这段时间内,线程不会执行任何操 作,它会被内核挂起。

  • mutex_lock

    线程在尝试获取互斥锁时,因为锁已经被其他线程持有而进入等待状态的时间长度。这段时间对于程序的性能至关重要,因为在等待期 间,线程不能执行任何有用的工作。


实际使用效果

历史稳定性分布问题

效果汇总

故障类型故障案例人工时长使用Oirignx预计定界时长召回率准确率
OnCPU(CPU执行)时间过长代码缺陷,直播服务故障16min(5+位领域专业同学投入)10min80%80%
极高的中断负载4h10min90%80%
等待调度到CPU时间过长宿主机CPU负载过高1h5min90%70%
读写文件耗时长(IO)P2P拉镜像卡死2天(需基础平台多位高级同学参与分析,链路长)8min90%70%
高磁盘读取负载1h5min90%60%
请求下游节点耗时长(网络调用耗时长)网卡时延过长(网卡上tc注入时延)4h5min90%80%
epoll耗时异常4h5min90%70%
调用中间件耗时长4h5min80%70%
锁等待或GC内核osq_lock锁竞争问题1周(基础平台累计10+位领域专业同学投入,蹲守凌晨业务高峰得以查明)10min80%80%
服务异常(内核死锁问题)1周(基础平台累计10+位领域专业同学投入)10min80%80%
Java锁耗时长4h5min80%90%
内存问题虚拟内存压力1h5min70%70%
用户页错误3h5min80%80%

Kindling-OriginX工作原理

· 阅读需 9 分钟

传统可观测性产品在落地过程中的局限性

很多公司已经落地了 Tracing、Metrics、Logging,但是在实际使用中效果不如预期主要由以下几个原因:

  • Tracing、Metrics、Logging 数据之间归属于不同产品,排查问题之时需要再不同产品之间跳转,对于问题排查效率影响较大。
  • Tracing、Metrics 对于开发和运维而言不熟悉,不会使用,对指标代表的技术含义理解不深入,最终排障都是依赖于专家牛人的个人经验。可观测性系统推广之后,业务团队使用起来效果差强人意。
  • 专家排障的时候也受限于已有经验,缺乏标准化流程,在不断猜测验证过程中,容易丢失掉 1-5-10 的目标。
  • 耗费人力和物力资源建设了一系列的可观测性项目,但是最终仍然很难落地1分钟识别故障、5分钟识别故障初因、10分钟回复业务。

什么是 eBPF 技术

eBPF(extended Berkeley Packet Filter)是一种先进的系统内核技术,最初源自于 Berkeley Packet Filter(BPF)。它是一种在 Linux 内核中执行高度优化的程序的框架,允许用户编写并插入小型程序(称为 eBPF 程序)来对系统内核的行为进行扩展和控制。 eBPF 允许用户在不更改内核源代码或重新编译的情况下,通过加载在内核中运行的小型程序来扩展内核功能。这些程序可以捕获和分析系统运行时的事件、执行网络分析、实现安全策略、执行性能调优等操作。 eBPF 的一些关键特性和优势包括:

  • 安全性:eBPF 程序在一个受限的虚拟机中运行,不会影响系统稳定性和安全性。
  • 灵活性:可以动态加载、卸载和更新eBPF程序,无需重新启动系统。
  • 性能:eBPF 程序经过优化,能够在内核中高效执行。
  • 可观察性:能够捕获和分析系统运行时的各种事件,有助于故障排除和性能分析。

eBPF 技术在多个领域得到应用,包括网络编程(例如网络包过滤、路由)、性能分析、安全监控、容器技术等。它已经成为许多现代系统中实现高级功能和控制的重要工具之一。

什么是 TraceProfiling 技术

用户开发的代码都是以线程形式运行在操作系统之上,即便Go语言有协程的概念,go协程在执行过程中仍然绑定在操作系统内核线程上执行。操作系统内核线程的完整运行周期如下图所示。

image.png

利用 eBPF 技术能够深入内核,拦截线程执行用户代码的关键点位获取信息,在获得线程执行关键信息之后能够还原线程的执行过程。 如果只从线程维度看程序执行过程是很难分析出故障的,因为开发和运维的谈的故障都是URL维度的用户请求调用,所以光有线程维度程序执行过程是不够的,需要和 Tracing 系统关联。 当线程执行过程与 Tracing 系统关联之后,即可完整还原用户一次请求的执行过程。 TraceProfiling中关联了可观测性所需要的数据:

  • 指标
  • 日志

北极星排障指标体系(龙蜥社区与 Kindling 社区联合发布了北极星排障指标体系)

通过分析 TraceProfiling 数据,能够得到一次请求在Span中执行具体花了多少时间在CPU、网络、存储、等待。将 TraceProfiling 数据进行聚合可以得到北极星排障指标体系,从而指导标准化的排障过程。 image.png

指标说明

北极星排障指标-CPU时间

程序在CPU资源上所消耗的时间

  • OnCPU

程序代码执行所消耗的CPU cycles,可以通过程序火焰图确认代码在 CPU上执行消耗的时间与代码堆栈.

  • Runqueue

线程的状态是Ready,如果CPU资源是充分,线程应该被调度到 CPU上执行,但是由于各种原因,线程并未调度到CPU执行,从而产生的等待 时间。

北极星排障指标-网络时间

网络时间属于两次OnCPU时间之间的OffCPU时间

  • 网络时间打标过程

第一次OnCPU最后一个系统调用执行为sock write与第二次 OnCPU第一个系统调用为sock read,也可以理解为网络包出网卡至网络包从网卡收回的 时间。

  • 网络时间分类

DNS,TCP建连,常规网络调用

北极星排障指标-存储时间

属于两次OnCPU时间之间的OffCPU时间

  • 存储时间打标过程

第一次OnCPU最后一个系统调用执行为VFS read/write与第二次 OnCPU第一个系统调用为VFS read/wirte。

  • 存储时间真实情况

存储真实执行情况,由于内核的pagecache存在,所以绝大多数VFS read/write从程序视 角看:执行时间不超过1毫秒。

北极星排障指标-等待时间

  • futex

通常指的是一个线程在尝试获取一个futex锁时因为锁已经被其他线程占用而进入等待状态的时间。在这段时间内,线程不会执行任何操作,它会被内核挂起。

  • mutex_lock

线程在尝试获取互斥锁时,因为锁已经被其他线程持有而进入等待状态的时间长度。这段时间对于程序的性能至关重要,因为在等待期间,线程不能执行任何有用的工作。

Kindling-OriginX 的故障根因推导

依据标准北极星排障指标体系,Kindling-OriginX 能够自动化推导出故障根因,从根本上解释一次请求慢的根源是在于CPU、网络、磁盘中的具体哪一部分。 Kindling-OriginX 不仅仅给出依据北极星排障指体系的故障根因,还将整个故障根因的推导过程呈现出来,帮助用户更好的理解系统运行的过程。 Kindling-OriginX 为了能够让结论更有可解释性,Kindling-Originx通过与Skywalking,deepflow, prometheus等数据对接获得更多的指标,并依赖专家经验自动化组织和关联分散的监控指标与日志,用户在一个界面就可以将所需要的指标与日志收集齐全,并确认故障根因是否推导合理。

更多信息参考

KubeCon 2023 中国 :Trace-Profiling: A New Way About How to Track Application Behavior - Cheng Chang

KCD 杭州 :基于 eBPF 采集的排障北极星指标构建故障根因推导流程