云原生可观测
云原生可观测基于Prometheus、Grafana 、OpenTelemetry 等核心产品， 形成指标、链路存储分析、异构数据源集成的数据层， 通过标准PromQL和SQL提供大盘展示、告警与探索能力。
【Elastic Engineering】添加免费且开放的 Elastic APM 作为 Elastic 可观测性部署的一部分
什么是 APM？ 利用应用程序性能监测，您可以查看应用程序将时间花在哪些地方、在执行哪些操作、在调用哪些其他应用程序或服务，以及遇到了哪些错误或异常情况。
高德打车构建可观测性系统实践
互联网工程的高速发展，分布式、微服务、容器化架构的流行，互联网已全面进入云原生时代。构建系统的方式由最初的单体大应用演变为分布式架构，一台服务器可能仅存几小时甚至几分钟，这种复杂性大大增加了把系统运行状态可视化的难度。
PTS压测问题之下载接口额外收费如何解决
PTS（Performance Testing Service）是一项面向网站、应用等提供的压力测试服务，用于模拟不同场景下的用户访问，评估系统的性能表现；在进行PTS压测时，可能会出现一些异常或报错，本合集将PTS压测中频繁出现的问题及其解决办法进行汇编，旨在帮助用户更有效地进行性能测试和问题定位。
PTS启动问题之启动失败如何解决
PTS（Performance Testing Service）是一项面向网站、应用等提供的压力测试服务，用于模拟不同场景下的用户访问，评估系统的性能表现；在进行PTS压测时，可能会出现一些异常或报错，本合集将PTS压测中频繁出现的问题及其解决办法进行汇编，旨在帮助用户更有效地进行性能测试和问题定位。
PTS压测问题之多账号并发登录配置如何解决
PTS（Performance Testing Service）是一项面向网站、应用等提供的压力测试服务，用于模拟不同场景下的用户访问，评估系统的性能表现；在进行PTS压测时，可能会出现一些异常或报错，本合集将PTS压测中频繁出现的问题及其解决办法进行汇编，旨在帮助用户更有效地进行性能测试和问题定位。
PTS报错问题之并发报错如何解决
PTS（Performance Testing Service）是一项面向网站、应用等提供的压力测试服务，用于模拟不同场景下的用户访问，评估系统的性能表现；在进行PTS压测时，可能会出现一些异常或报错，本合集将PTS压测中频繁出现的问题及其解决办法进行汇编，旨在帮助用户更有效地进行性能测试和问题定位。
PTS压测问题之如何确定压测可以停止
PTS（Performance Testing Service）是一项面向网站、应用等提供的压力测试服务，用于模拟不同场景下的用户访问，评估系统的性能表现；在进行PTS压测时，可能会出现一些异常或报错，本合集将PTS压测中频繁出现的问题及其解决办法进行汇编，旨在帮助用户更有效地进行性能测试和问题定位。
PTS报错问题之脚本报错如何解决
PTS（Performance Testing Service）是一项面向网站、应用等提供的压力测试服务，用于模拟不同场景下的用户访问，评估系统的性能表现；在进行PTS压测时，可能会出现一些异常或报错，本合集将PTS压测中频繁出现的问题及其解决办法进行汇编，旨在帮助用户更有效地进行性能测试和问题定位。
CloudLens for OSS--数据洞察可观测平台发布
日志服务联合阿里云OSS推出CloudLens for OSS，支持Bucket粒度的统一管理视图，支持资源用量、访问分析、异常检测、安全分析等可视化分析能力，提供场景化运维管理，实现Bucket资产的可观测性。
系统架构面临的三大挑战，看 Kubernetes 监控如何解决？
随着 Kubernetes 的不断实践落地，我们经常会遇到负载均衡、集群调度、水平扩展等问题。归根到底，这些问题背后都暴露出流量分布不均的问题。那么，我们该如何发现资源使用，解决流量分布不均问题呢？今天，我们就借助三个具体场景聊聊这一问题以及相应的解决方案。
干货｜后互联网时代，运维工程师的必备性能优化指北
在竞争激烈的后互联网时代，深度挖掘每份流量背后的商业价值成为每个企业的必修课，而网站性能与体验的优化是这一过程中重要环节。 因此，《网站性能与体验优化指北》成为后互联网时代的网站运维的必备电子书。
开源自建/托管与商业化自研 Trace，如何选择？
随着微服务架构的兴起，服务端的调用依赖愈加复杂，为了快速定位异常组件与性能瓶颈，接入分布式链路追踪 Trace 已经成为 IT 运维领域的共识。但是，开源自建、开源托管或商业化自研 Trace 产品之间到底有哪些差异，我该如何选择？这是许多用户在调研 Trace 方案时都会遇到的疑问，也是最容易混淆的误区。
基于日志服务构建业务可观测性系统
根据海恩法则(Heinrich‘s Law)，每一起严重事故背后，必然有29次轻微事故和300起未遂先兆以及1000起事故隐患。如果提前处理那些不那么严重的问题，其实是可以避免后续的严重事故的，也就避免了其带来的巨大压力和损失。
为什么 Agent 的地址不该"分配"，该"派生"
Agent 跨域互调，第一件事是"找到它、认出它"。主流做法是分配地址——DNS、CA、DID 注册表，每次验证一次在线往返。本文讲 RTTP 的另一条路：地址由 SHA-256 派生而非机构分配，验证方本地重算即核对，离线可用。128 位裕量怎么算的、一个 shard 为什么能身兼三职，全部公开可查。已获 IANA 注册（CRI 27）。
真派生、假派生，与我们自己的生日账
给 AI Agent 做身份系统，只需先回答一个问题：验证一份签名，需要去谁家？本文用这一把刀切出三类体制——分配制（地址是租的）、假派生（数学的漆，围墙的实）、真派生（数学自答），并给出三条测试：断网、生存、解释。点名 did:web 与 GitHub "Verified" 两个大规模标本之后，我们按同一把刀解剖自己：把 rttp 地址 128 位截断的生日账（2^64 与 2^128）全部摊开。
128 字节里装下了什么——一份可以离线复核的信任
"可审计、可追责"喊了两年，缺的是一个可离线复核的证据载体。本文拆解 128 字节 IQA 证明信封：固定布局零解析器、地位四态（一态一断言）、撤销不是删记录而是签发新信封、fail-closed 让任何一字节篡改自动 REJECT。附公开一致性向量，逐字节可复现。
四个 MCP 工具，30 秒验证一份密码学证据——iqa-mcp 上手
别信文档——把向量跑一遍。本文带你 30 秒跑通 iqa-mcp（PyPI/npm/crates 三注册表 1.0.1）：published_vector 拿公开向量 → parse_envelope 结构解码 → verify_envelope 得 [PASS] → 翻一个字节得 REJECT。四个 MCP 工具，任何 MCP 兼容客户端可直接调用，无状态、离线、fail-closed。
一个公开挑战：任意语言、完全离线，跑不通算我们的
讲「可信 Agent」的文章很多，交出可证伪实物的很少。我们把协议规范冻结、35 个测试向量公开，并在记分牌上留了两个空位——独立实现数，rttp: 0，iqa: 0，作者自己的实现不算数。规则只有四条：只看规范、任意语言、完全离线、确定性。跑通全部向量，你的名字进规范记录；跑不通，那是我们的 bug，署名致谢并重新发布向量。横竖都是你赢。
为什么信任必须每 120 秒重审一次？
信任该不该有终身制？本文的答案：不该。地址的所有权由派生保证——那是永久产权，房东是数学；而 standing 是一份 120 秒的租约——房东是时间，每过一个窗口自动续租或退租，没有终身荣誉，也没有终身惩罚。该永久的做成永久，该临时的做成临时，恰是分配制种反的两块田。至于第三根柱子——它不长在协议里，长在栈里。
制度可信与数学可信之间，差一个 128 字节
Agent 时代的新问题是：陌生 Agent 替你做完事，能拿出什么证据？本文对比国内外主流平台的信任能力——身份认证有、授权控制有，可移交、可独立验证的证据没有——并给出一个开源的最小可行形态：RTTP 意图寻址（已获 IANA CRI 27）+ 128 字节 IQA 证明信封（已获 IANA CRI 28） + fail-closed 全帧验证，三语言实现可直接接入任何 MCP 栈，发布物逐件密码学密封自证。
第一份证据由谁签发？——给 Agent 信任系统一个不垄断起点的答案
凡是靠证据说话的系统，都躲不开一个问题：第一份证据由谁签发？"谁证明证明者"可以无限回退。中心化的做法是指定一个机构当起点——起点从此成了它的财产。本文给出另一种答案：把信任做成标准件，锚位由规范保证、锚在证据轴之外，嵌进谁家就是谁家的纪元——像 git init，每个项目各有第一笔提交，互不裁判。附后门自检：我们标不了别人的创世纪。
【云故事探索】NO.8：揭秘餐饮行业龙头 SaaS 厂商神州商龙的全栈可观测实践
天津市神州商龙科技股份有限公司成立于1998年，专为餐饮行业提供数字化解决方案。公司服务10万余家知名餐饮企业，确保用餐体验的稳定性至关重要。在业务容器化和微服务化过程中，神州商龙面临技术架构多样性、高可用要求及成本控制等挑战。通过尝试自建Prometheus和SkyWalking监控方案，最终选择阿里云Prometheus和日志服务SLS，实现了统一可观测平台，提升了监控效率、缩短故障排查时间、增强系统稳定性和优化资源利用率。未来，神州商龙计划引入机器学习和AI技术，提升自动化运维水平，并进一步整合业务系统监控数据。
基于 eBPF 技术打造的 LightAPM 应用监控，效果如何
本文介绍如何利用LightAPM解决“古早应用”（如银行老核心、证券交易系统）的监控难题。这些基于C/C++或老旧JDK的系统封闭且难以改造，传统字节码增强技术无法适用。通过部署集成eBPF技术的OneAgent，LightAPM实现无侵入、开箱即用的监控，自动绘制服务拓扑、发现服务并采集应用与基础设施指标，支持多JDK混合环境。结合因果AI，还可智能告警与根因定位，为遗留系统提供高效可观测性方案。
【云故事探索】NO.8：揭秘餐饮行业龙头 SaaS 厂商神州商龙的全栈可观测实践
天津市神州商龙科技股份有限公司成立于1998年，专为餐饮行业提供数字化解决方案。公司服务10万余家知名餐饮企业，确保用餐体验的稳定性至关重要。在业务容器化和微服务化过程中，神州商龙面临技术架构多样性、高可用要求及成本控制等挑战。通过尝试自建Prometheus和SkyWalking监控方案，最终选择阿里云Prometheus和日志服务SLS，实现了统一可观测平台，提升了监控效率、缩短故障排查时间、增强系统稳定性和优化资源利用率。未来，神州商龙计划引入机器学习和AI技术，提升自动化运维水平，并进一步整合业务系统监控数据。
一个协议装不下：语义寻址与信任证明为什么分成两个 scheme
Agent 跨域互调，要同时解决「找到谁、做什么」与「谁授权、凭什么」。本文盘点现有协议栈的缺口——DNS+CA 在线双问、OAuth 回 IdP、DID 解析回网、MCP 不管身份语义——论证语义寻址（锚在哈希）与信任证明（锚在密钥）因信任锚不同源，无法装进同一个 scheme；并给出落地形态：一份合并草案、两个 scheme，在字节层共享同一 16 字节分片完成闭环。
