- 博客(76)
- 收藏
- 关注
RSS订阅原创 APO v1.6.0 更新：告警工作流优化；服务列表排序；故障现场数据关联
本次 APO v1.6.0 版本更新带来了以下内容。注意本次更新存在破坏性变更，请参考官网的“安装手册”-“版本升级手册”进行升级。
2025-03-31 11:37:16
123
原创 试试智能体工作流，自动化搞定运维故障排查
APO 1.5.0版本全新推出的智能体工作流功能，让运维经验不再零散！只需将日常的运维操作和故障排查经验转化为标准化流程，就能一键复用，效率翻倍，从此告别重复劳动，把时间留给更有价值的创新工作。更贴心的是，APO无需改造现有监控系统，轻松对接即可使用，真正实现“开箱即用”。下面带大家快速上手这一功能，先从官方内置的实用工作流开始体验！
2025-03-24 09:24:36
834
原创 APO v1.5.0更新：新增工作流编排、数据接入和告警事件列表；新增Traces数据采样
您可以根据实际环境情况选择数据接入的方式，目前支持安装新的APO探针（基于OpenTelemetry）采集链路追踪数据，也支持对接已有的OpenTelemetry+Jaeger和SkyWalking数据源。本次更新带来了专为可观测性系统设计的Agentic工作流编排功能，通过使用工作流，能将你的专家经验转变为可复用的执行流程，赋予智能体专业决策能力，提高故障排查效率。详细配置方式请参考“文档”-“配置Traces数据采样”。与传统的头采样和尾采样均不同，APO基于分布式采样策略实现了Traces数据采样。
2025-03-17 10:36:49
750
原创 重新认识APO——DeepSeek带来可观性领域革命
Docker通过封装程序执行类库引爆了云原生技术革命，我们相信在人工智能时代，数据结合经验知识封装而成的Agentic workflow将引爆可观测性革命。
2025-03-11 14:23:53
360
原创 APO v1.4.0 更新：新增数据分组和数据权限控制功能
本次更新，APO 为大家带来了“团队”和“数据组”两个概念，让数据管理和团队协作变得更加简单和高效。现在，您可以轻松地将用户组织成不同的团队，并且为每个团队或用户设置个性化的数据访问权限。数据组功能可以将命名空间或服务分组，让不同团队和用户专注于分析他们关心的信息。要使用数据组功能，点击“系统管理”-“数据组管理”，在该页面中您可以新增数据组，通过选择“命名空间”或“服务名”向数据组中添加包含的数据内容。创建数据组后，点击“授权”向用户或团队授予该数据组的访问权限。
2025-02-17 13:49:06
225
原创 基于DeepSeek的可观测性智能体实践
DeepSeek在理解和处理可观测性的各类数据上有着较高的准确率，能够较好地理解专家规则并按照规则分析数据，且具有高性价比的价格，尽管偶尔出现数据幻觉，但经过设计能够达到较高的准确率。这种现象在分析微服务拓扑结构时尤为明显，例如在基于“train-ticket”场景的测试中，简化了复杂的微服务调用关系，仅保留最基本的业务节点进行测试，DeepSeek有时仍会输出一些如“ts-payment-service”这样实际上并不存在于真实数据中的服务名，但这些名称又似乎与“train-ticket”有关。
2025-02-12 17:48:20
952
原创 大语言模型需要的可观测性数据的关联方式
可观测性数据关联是指将系统中不同来源和维度的可观测性数据（如日志、指标、Trace）关联起来，形成一个完整的监控视图。通过这种关联，我们能够更全面地理解系统的行为和性能，尤其在故障排查时，能够实现更加精准的定位。数据关联方式的选择直接影响故障排查的效率、准确性以及可视化效果。随着分布式系统的复杂性增加，合理的数据关联方式在可观测性中变得尤为重要。通过将不同来源和维度的可观测性数据（如日志、指标、链路等）进行有效关联，我们能够更全面地诊断系统故障、提高问题定位的准确性，并减少噪声带来的干扰。
2025-02-07 14:45:31
1243
原创 APO v1.3.0 更新：支持将第三方告警事件接入平台，统一关联分析告警事件
在 APO v1.3.0 版本中，我们引入了对第三方告警事件的全面支持，旨在为用户提供一个更为集成和高效的告警分析平台。此次更新允许用户将来自不同来源的告警信息统一接入APO平台，从而实现告警事件的集中管理和关联分析。目前支持接入Prometheus（AlertManager）、Zabbix 和任意支持以 Webhook 发送的告警事件。告警接入后在服务详情中会自动将相关告警事件关联到服务上。
2025-02-05 10:19:38
267
原创 APO v1.1.0 更新：大模型根因分析支持深入分析；优化数据筛选功能；内置 NGINX 日志分析看板
APO 新版本 v1.1.0 更新发布！
2024-12-19 17:26:10
345
原创 基于APO四步实现炫酷的NGINX请求分析看板
APO 充分利用 Vector + ClickHouse 实现的日志方案，做到了开箱即用、高效、低成本。利用 APO 的日志功能，不仅可以检索日志内容本身，还可以实现很多有意思的功能。本次为大家介绍使用 APO 的日志功能实现炫酷的 NGINX 请求分析看板，只需简单几步即可实现！
2024-12-09 17:23:56
828
1
原创 APO v1.0.0 正式发布！
APO 致力于打造一个一键安装、开箱即用且简单易用的可观测性平台，我们希望每个用户都能够轻松部署并使用我们的工具，无需复杂的配置过程或深厚的技术背景。通过集成 eBPF 技术与 OpenTelemetry 生态，APO 实现了对分布式系统的高效监控，同时保持了较低的数据存储成本。此外，我们提供的向导式排障界面可以帮助用户快速定位问题根源，减少故障排查时间，提高运维效率。为了实现这个愿景，APO 不断迭代和优化，在最新的1.0.0版本中，提供以下亮点功能：一站式可观测：APO 集成了链路、指标、日志和事件等
2024-12-05 11:50:58
837
原创 可以不断演进基于LLM和思维链的故障根因辅助定位
而真实的情况故障传播链路在basic-service这里就可能不再往上传递，ts-travel2-service的告警和ts-route-service是没有关系的，但是传统基于应用服务的拓扑结构是无法区分此种情况。标准化，有价值的数据。这块我们交流下来是用户最有需求的，因为排障的标准化流程缺失，导致严重依赖专家，排障的时间周期并不能如预期完成，也就很难完成业界的1-5-10目标。一条Trace的数据大概2K，也就是几十条的Trace的数据量就将大模型的上下文撑满了，大模型也就没有办法更好的解释数据了。
2024-11-25 14:46:05
774
原创 APO全量日志对接logstash和fluent日志采集生态
采集流程图APO 使用 ilogtail 作为日志采集组件并改造支持额外功能， vector 中进行日志结构化处理。APO 日志功能日志指标统计日志数并生成日志数指标。出现错误日志时，计算日志错误指标故障现场日志应用程序出现慢或者错误trace时，将这段时间内的日志收集并写入clickhouse中。使用 k8s 信息或 pid 信息关联故障链路和故障现场日志全量日志。
2024-11-11 14:01:38
656
1
原创 独立使用 APO 日志模块替代ELK实现日志监控功能
本文将介绍如何基于 APO 的日志监控功能进行日志模块的模块化部署。，配合 APO-server 可以实现快速部署全量日志系统，支持Kubernetes/传统服务器多种业务环境，为开发/运维提供方便快捷的日志查询功能。使用 Clickhouse 列式数据库进一步降低日志系统的运维成本。
2024-10-29 14:26:36
844
原创 APO v0.7.0 更新：日志功能完整版发布！
在 v0.6.0 版本中，APO 发布了基于 ClickHouse 开箱即用的高效日志方案，为用户提供了采集、处理和检索全量日志的基础功能。新版本在此基础上进一步强化了日志处理和检索的能力，提升了用户体验。
2024-10-21 10:30:45
489
原创 告别ELK，APO提供基于ClickHouse开箱即用的高效日志方案——APO 0.6.0发布
ELK一直是日志领域的主流产品，但是ElasticSearch的成本很高，查询效果随着数据量的增加越来越慢。业界已经有很多公司，比如滴滴、B站、Uber、Cloudflare都已经使用ClickHose作为ElasticSearch的替代品，都取得了不错的效果，实现了降本增效，费用节约大多在50%以上。但是目前使用ClickHose作为日志方案，存在以下问题。○强依赖Kafka，对于某些中小用户而言方案不够灵活，不友好。
2024-10-15 10:36:31
1403
原创 仅将 APO 用作采集存储展示 Trace 数据工具
●APO-one-agent 默认开启并支持全量采集多种类型的可观测数据，包括 Trace、Metrics 和 Logs。用户可根据自身需求，灵活配置 APO-one-agent 的数据采集范围，以适应用户环境中现有的数据类型。●APO 监控 Trace 数据相较于传统的 Trace 数据采集监控，可以实现为应用自动注入 Trace 配置，。●本文将介绍 APO 如何独立监控 Trace 数据，并介绍如何配置 APO 独立采集并监控 Trace 数据。
2024-10-10 16:41:29
957
原创 APO v0.5.0 发布：可视化配置告警规则；优化时间筛选器；支持自建的ClickHouse和VictoriaMetrics
APO 新版本 v0.5.0 正式发布！
2024-09-30 13:56:54
1115
原创 APO的告警关联和告警故障影响面功能介绍
告警噪音是很难消除的，而且告警噪音本身也是一种提示告知某些指标有异常。APO承认这个事实，推荐采用如下方式排查告警：重点识别哪些服务端点代表的接口有异常（如果没有接口有异常，说明告警都是告警噪音。当然要对告警分级，比如磁盘满，进程挂掉等场景都是严重告警和接口异常无关）在接口详情中找到有哪些告警判断故障影响面，告警是否很严重？需要拉上哪些人立马排查国内开源首个 OpenTelemetry 结合 eBPF 的向导式可观测性产品。
2024-09-25 14:54:56
997
原创 APO OneAgent 设计思路
APO通过OneAgent中的集成修改的Odigos机制，实现了不同语言的应用程序自动完成OTEL trace探针的安装和环境变量配置，同时通过集成ilogtail采集了日志，并能够实现日志和应用的关联。OneAgent能够在容器环境和传统虚拟机上同样工作。APO介绍：国内开源首个 OpenTelemetry 结合 eBPF 的向导式可观测性产品。
2024-09-19 14:36:47
772
原创 APO使用场景之：统一的指标采集展示
Alloy是Grafana 发布替代之前Grafana Agent的开源产品。“Grafana Alloy 是一个开源的 OpenTelemetry Collector 发行版，内置 Prometheus 管道，并支持度量、日志、追踪和性能剖析。“Alloy 为 OTel、Prometheus、Pyroscope、Loki 以及许多其他指标、日志、追踪和分析工具提供了原生管道。此外，您可以使用 Alloy 管道执行各种任务，例如在 Loki 和 Mimir 中配置警报规则。
2024-09-12 10:10:57
1544
原创 APO v0.3.0 发布：关联告警事件；提升数据筛选效率；优化安装体验
APO 软件的新版本 v0.3.0 已经正式发布了！这次的更新不仅带来了功能上的改进，还有用户体验上的重大升级。
2024-09-10 11:32:52
519
原创 APO与SkyWalking、Signoz等产品的不同设计
Skywalking作为国内用户量最大的APM产品，有着众多的优点。Signoz作为OpenTelemetry的发行版也有着一定的名气。我们为什么还要设计APO项目？谨代表APO团队探讨下团队之前的经验，一家之言，欢迎各位大佬一起探讨。
2024-09-06 13:52:38
783
原创 APO在一个页面整合关联可观测性数据的设计思路
对于错误率上升的问题，通过关联exception和错误日志一般情况下能够实现对错误率上升故障的兜底解决。对于延时同比增加的问题，使用北极星指标一定能回答延时增加是由于什么原因导致的。关于北极星指标是什么，请参考链接 one.kindlingx.com。
2024-09-04 10:58:19
996
原创 APO的接口级拓扑 VS Dynatrace ServiceFlow
GPT介绍应用级别拓扑：应用级别拓扑是一种用于表示应用程序内部及其与其他应用程序或系统之间关系的可视化模型。它描述了应用程序中的各个组件（如服务、数据库、消息队列等）之间的交互方式，包括调用关系、数据流动和依赖关系。应用级别拓扑的目标是帮助开发和运维团队更好地理解和监控应用程序的架构、性能和健康状况。
2024-09-02 13:57:58
876
原创 APO选择ClickHouse存储Trace的考量
自定义ClickHouse的表结构的好处在于，所有的内容完全能够自己掌控，但是坏处是其他生态产品很少会基于该自定义表结构进行演进，从而没有办法与其他生态集成。Span自身花的时间应该如何查找Span的tag应该如何才能查看这对于没有接触过Jaeger的用户而言是可行的，选择Signoz和Uptrace没有太多差别，但对于已经熟悉Jaeger的用户不大友好。
2024-08-28 14:58:04
1131
原创 APO 新发版支持Skywalking Agent接入
自APO开源以来，社区成员询问APO是否支持Skywalking Agent，以避免已使用Skywalking的应用在测试发版过程中需要重新部署探针。APO利用OpenTelemetry生态，通过skywalkingreceiver实现Skywalking Trace到OTEL Trace的转换，为已经使用Skywalking的用户提供无缝体验。
2024-08-26 14:41:53
973
原创 APO 集成生态exporter一键完成指标采集
Metrics 作为可观测性领域的三大支柱之一，Metrics数据采集显得尤为重要。传统的prometheus工具采集指标，需要指定路径抓取，当指标越来越多配置会显得复杂。同时prometheus只能采集指定的指标，当用户需要节点系统相关、中间件等指标还需要引进额外组件。久而久之采集指标配置难以维护。
2024-08-21 16:17:31
1312
原创 APO如何快速判断云环境网络质量是否有问题
使用ping来判断网络质量是大家常用的一个习惯，而对于ping的延时大家在实践中已经形成了一些认知，比如如果ping的延时超过100ms，那么在线网络游戏估计玩不成了。eBPF可以获取到网络rtt以及srtt等指标，这些指标确实能够反应网络质量，但是其实现是有局限性的，在当前绝大多数客户使用场景是不能反映网络质量的。虽然eBPF和ping包的方式都有一定局限性，但是eBPF的局限性受限于内核的实现，该局限没有办法突破的，而ping包的局限是可以突破的。最终效果图，展示srcip到dstip的ping值。
2024-08-16 10:19:37
820
原创 业界首个OpenTelemetry结合eBPF的向导式可观测性平台APO正式开源
APO 致力于提供一键安装、开箱即用的可观测性平台。APO 的 OneAgent 支持一键免配置安装 Tracing 探针，支持采集应用的故障现场日志、基础设施指标、应用和下游依赖的网络指标以及Kubernetes 事件，支持采集基于 eBPF 实现的等数据。支持使用 Jaeger UI 查询 Tracing 数据，使用 PromQL 从 VictoriaMetrics 中查询 Metrics 数据并展示在 Grafana 上。
2024-08-13 14:08:56
1207
原创 Kindling-OriginX 在快手 Staging 环境的异常诊断效果分享
Kindling-OriginX 并不直接提供 Trace 能力，而是采用接入 Trace 数据的形式，即通过接入目前成熟的 Trace 产品与提供标准接入 SDK 方 式，例如 Skywalking、OpenTelemetry、ARMS 等，利用 eBPF 能力将 Trace 数据进行扩展，将其与底层的系统调用相关联，进而实现整 的可观测性，消除程序执行与 Trace 数据中的盲区。假设极端情况，存在故障的实例的请求时延在 24h 内一直都很高，那么后续的请求也会被判断为正常请求，产生漏判。
2024-07-04 14:57:25
756
1
原创 Kubernetes集群中如何利用北极星因果指标设置正确的POD规格——CPU篇
在 Kubernetes 容量规划中，追求的是集群的稳定性和资源使用效率之间的平衡：资源分配过多会造成浪费。资源分配过少则会导致用户请求时延上升，影响集群的稳定性。公众号之前翻译了一篇 Sysdig 的文章，介绍了如何设置合理的资源参数。虽然按照那篇文章设置可以有一定的帮助，但仍然可能存在风险。本文将详细说明这些风险，并介绍如何通过北极星指标对 POD 的规格进行调整，以达到时延和资源的完美平衡。POD 启动时请求的 CPU 资源量。
2024-06-17 10:28:51
716
原创 Kindling-OriginX v1.4.0 发布：开箱即用，无需对接；自动关联故障节点的上下游关系，通过延时曲线辅助判断根因节点
在本次更新中，为了进一步加快排障速度，Kindling-OriginX优化了故障诊断页面，自动将故障节点的上下游关系关联起来，并展示了节点的响应耗时，使故障节点间的依赖关系和耗时相关性一览无余，在多节点发生故障时更容易找到根因；我们还在首页中将SLO状态与请求次数关联在一起，辅助用户判断SLO状态变化的原因。从该版本开始，OriginX安装后开箱即用，无需再对接外部 Tracing 系统，我们大大简化了安装过程，欢迎安装试用！
2024-06-13 09:41:31
868
原创 排障指标革命性新突破，北极星指标让故障无所遁形--北极星因果指标产品正式发布
指请求在CPU上消耗的时间。指请求在网络传输中消耗的时间。指请求在文件系统读写操作中消耗的时间。指请求在内存分配和管理中消耗的时间。指请求在等待锁资源中消耗的时间。指请求在垃圾回收过程中消耗的时间。指请求在执行过程中，由于CPU调度而产生的延时北极星因果指标的引入，彻底改变了故障排查的方式。通过提供因果关系和全面视图，它不仅提升了排障效率，还显著减少了排障过程中的盲目性和试错成本，真正实现了高效、精准的故障排查。永久免费多语言支持：Java、Python、Nodejs、一键安装标准PQL语句查询数据。
2024-06-11 13:39:21
769
原创 Originx创新解法——应用依赖故障篇
依赖故障指应用运行所依赖的环境包括网络、中间件、缓存故障导致应用出现故障。这部分故障的根因并不是应用代码的问题，但是其最终表现形式和应用代码故障表现形式类似，很难区分。本文重点呈现Originx如何针对应用环境所依赖的故障进行根因分析，之前的系列文章请参考：文章中对常见的全栈故障的传统定位方法进行了阐述。文章中呈现了如何利用Originx的功能对应用程序故障的根因定位。
2024-05-22 15:09:14
891
原创 Originx的创新解法之：应用程序故障篇
Originx并不期望做一个完整覆盖全栈的监控体系，而是利用北极星指标体系标准化找出故障方向，然后联动各种成熟的监控数据形成证据链条，并将各种数据融合在一个故障报告之中。更多信息请参考Originx的设计目标是力争实现全栈故障种类的定位，自身的eBPF探针采集北极星排障指标，然后北极星排障指标引导到故障根因，Originx的核心工作原理请参考下方网址，或者扫描下方二维码在已经识别出故障方向之后，利用各种成熟的开源监控作为数据来源，形成完整的证据链条，最终形成用户能够直接使用的故障根因报告。
2024-05-16 11:03:58
1025
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人