kindlingx的博客

Docker通过封装程序执行类库引爆了云原生技术革命，我们相信在人工智能时代，数据结合经验知识封装而成的Agentic workflow将引爆可观测性革命。

APO 充分利用 Vector + ClickHouse 实现的日志方案，做到了开箱即用、高效、低成本。利用 APO 的日志功能，不仅可以检索日志内容本身，还可以实现很多有意思的功能。本次为大家介绍使用 APO 的日志功能实现炫酷的 NGINX 请求分析看板，只需简单几步即可实现！

而真实的情况故障传播链路在basic-service这里就可能不再往上传递，ts-travel2-service的告警和ts-route-service是没有关系的，但是传统基于应用服务的拓扑结构是无法区分此种情况。标准化，有价值的数据。这块我们交流下来是用户最有需求的，因为排障的标准化流程缺失，导致严重依赖专家，排障的时间周期并不能如预期完成，也就很难完成业界的1-5-10目标。一条Trace的数据大概2K，也就是几十条的Trace的数据量就将大模型的上下文撑满了，大模型也就没有办法更好的解释数据了。

采集流程图APO 使用 ilogtail 作为日志采集组件并改造支持额外功能， vector 中进行日志结构化处理。APO 日志功能日志指标统计日志数并生成日志数指标。出现错误日志时，计算日志错误指标故障现场日志应用程序出现慢或者错误trace时，将这段时间内的日志收集并写入clickhouse中。使用 k8s 信息或 pid 信息关联故障链路和故障现场日志全量日志。

本次更新，APO 带来了一些新功能，并对若干问题进行了修复。

本文将介绍如何基于 APO 的日志监控功能进行日志模块的模块化部署。，配合 APO-server 可以实现快速部署全量日志系统，支持Kubernetes/传统服务器多种业务环境，为开发/运维提供方便快捷的日志查询功能。使用 Clickhouse 列式数据库进一步降低日志系统的运维成本。

ELK一直是日志领域的主流产品，但是ElasticSearch的成本很高，查询效果随着数据量的增加越来越慢。业界已经有很多公司，比如滴滴、B站、Uber、Cloudflare都已经使用ClickHose作为ElasticSearch的替代品，都取得了不错的效果，实现了降本增效，费用节约大多在50%以上。但是目前使用ClickHose作为日志方案，存在以下问题。○强依赖Kafka，对于某些中小用户而言方案不够灵活，不友好。

APO 新版本 v0.5.0 正式发布！

APO通过OneAgent中的集成修改的Odigos机制，实现了不同语言的应用程序自动完成OTEL trace探针的安装和环境变量配置，同时通过集成ilogtail采集了日志，并能够实现日志和应用的关联。OneAgent能够在容器环境和传统虚拟机上同样工作。APO介绍：国内开源首个 OpenTelemetry 结合 eBPF 的向导式可观测性产品。

APO 新版本 v0.4.0 正式发布！

Alloy是Grafana 发布替代之前Grafana Agent的开源产品。“Grafana Alloy 是一个开源的 OpenTelemetry Collector 发行版，内置 Prometheus 管道，并支持度量、日志、追踪和性能剖析。“Alloy 为 OTel、Prometheus、Pyroscope、Loki 以及许多其他指标、日志、追踪和分析工具提供了原生管道。此外，您可以使用 Alloy 管道执行各种任务，例如在 Loki 和 Mimir 中配置警报规则。

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

APO 软件的新版本 v0.3.0 已经正式发布了！这次的更新不仅带来了功能上的改进，还有用户体验上的重大升级。

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

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

自定义ClickHouse的表结构的好处在于，所有的内容完全能够自己掌控，但是坏处是其他生态产品很少会基于该自定义表结构进行演进，从而没有办法与其他生态集成。Span自身花的时间应该如何查找Span的tag应该如何才能查看这对于没有接触过Jaeger的用户而言是可行的，选择Signoz和Uptrace没有太多差别，但对于已经熟悉Jaeger的用户不大友好。

APO 致力于提供一键安装、开箱即用的可观测性平台。APO 的 OneAgent 支持一键免配置安装 Tracing 探针，支持采集应用的故障现场日志、基础设施指标、应用和下游依赖的网络指标以及Kubernetes 事件，支持采集基于 eBPF 实现的等数据。支持使用 Jaeger UI 查询 Tracing 数据，使用 PromQL 从 VictoriaMetrics 中查询 Metrics 数据并展示在 Grafana 上。

使用ping来判断网络质量是大家常用的一个习惯，而对于ping的延时大家在实践中已经形成了一些认知，比如如果ping的延时超过100ms，那么在线网络游戏估计玩不成了。eBPF可以获取到网络rtt以及srtt等指标，这些指标确实能够反应网络质量，但是其实现是有局限性的，在当前绝大多数客户使用场景是不能反映网络质量的。虽然eBPF和ping包的方式都有一定局限性，但是eBPF的局限性受限于内核的实现，该局限没有办法突破的，而ping包的局限是可以突破的。最终效果图，展示srcip到dstip的ping值。

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

自APO开源以来，社区成员询问APO是否支持Skywalking Agent，以避免已使用Skywalking的应用在测试发版过程中需要重新部署探针。APO利用OpenTelemetry生态，通过skywalkingreceiver实现Skywalking Trace到OTEL Trace的转换，为已经使用Skywalking的用户提供无缝体验。