云原生可观测
云原生可观测基于Prometheus、Grafana 、OpenTelemetry 等核心产品， 形成指标、链路存储分析、异构数据源集成的数据层， 通过标准PromQL和SQL提供大盘展示、告警与探索能力。
高德打车构建可观测性系统实践
互联网工程的高速发展，分布式、微服务、容器化架构的流行，互联网已全面进入云原生时代。构建系统的方式由最初的单体大应用演变为分布式架构，一台服务器可能仅存几小时甚至几分钟，这种复杂性大大增加了把系统运行状态可视化的难度。
无感改造，完美监控：Docker 多阶段构建 Go 应用无侵入观测
本文将介绍一种基于 Docker 多阶段构建的无侵入 Golang 应用观测方法，通过此方法用户无需对 Golang 应用源代码或者编译指令做任何改造，即可零成本为 Golang 应用注入可观测能力。
构建超大带宽、超高性能及稳定可观测的全球互联网络
本次课程聚焦构建超大带宽、超高性能及稳定可观测的全球互联网络。首先介绍全球互联网络的功能与应用场景，涵盖云企业网、转发路由器等产品。接着探讨AI时代下全球互联网络面临的挑战，如大规模带宽需求、超低时延、极致稳定性和全面可观测性，并分享相应的解决方案，包括升级转发路由器、基于时延的流量调度和增强网络稳定性。最后宣布降价措施，降低数据与算力连接成本，助力企业全球化发展。
（H5-Web3D-ThreeJS）在网页三维CAD中绘制窗户模型
本文介绍了如何使用mxcad3d在网页中创建一个简单的三维窗户模型。通过官方教程搭建环境，编写绘制窗户模型的代码，并在点击按钮后展示模型效果。最终模型包括窗框和玻璃部分，具备丰富的三维建模功能和便捷的API支持。
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压测中频繁出现的问题及其解决办法进行汇编，旨在帮助用户更有效地进行性能测试和问题定位。
iptables的用法的样例
iptables是Linux系统中用于配置和管理网络包过滤规则的工具。它可以用于设置防火墙、网络地址转换（NAT）以及网络包的源地址、目标地址和端口的过滤等功能。以下是一些iptables的用法示例： 1. 允许特定IP地址的入站连接： ``` iptables -A INPUT -s 192.168.0.1 -j ACCEPT ``` 这条规则将允许来自IP地址为192.168.0.1的主机的所有入站连接。 2. 允许特定端口的入站连接： ``` iptables -A INPUT -p tcp --dport 22 -j ACCEPT ``` 这条规则将允许所有TCP协议的目标端口为2
年度大促将至，企业如何进行性能压测
随着无线设备的普及和 5G 的大力建设，越来越多的线上系统、小程序成为了人们生活中必不可少的工具。与此同时，年底各类大促活动接踵而至，对于这些电商软件而言，都会面对一个问题：系统能承受多少用户同时访问，面对突发的流量洪峰，能否保证系统无故障稳定运行？下文将为你带来解答～
云原生网关的可观测性体系实践
云原生网关是阿里云微服务引擎(MSE)下的一款托管类型网关产品，其将传统的流量网关与微服务网关进行了整合，本文将讲述如何基于云原生网关去搭建网关场景的可观测性体系。
基于 eBPF 的 Kubernetes 可观测实践
阿里云可观测团队构建了 kubernetes 统一监控，无侵入式地提供多语言、应用性能黄金指标，支持多种协议，结合 Kubernetes 管控层与网络系统层监控，提供全栈一体式的可观测体验。通过流量拓扑、链路、资源的关系，可进行关联分析，进一步提升在 Kubernetes 环境下排查问题的效率。
基于eBPF的云原生可观测性开源项目Kindling之慢系统调用
Kindling通过eBPF技术和内核提供的系统调用tracepoint捕获了所有的系统调用数据，然后把系统调用与线程信息做了关联，并在用户空间对系统调用的enter和exit进行了latency的计算以判断是否为慢系统调用。
云杉网络DeepFlow帮助5G核心网和电信云构建可观测性
为什么5G核心网和电信云需要可观测性？在过去的2021年，其实5G核心网在全球发生了多次影响范围大、持续时间长、社会影响广的故障。2021年的4月份加拿大Rogers发生了一次长达26个小时全国范围的移动通信网故障，故障发生后缺乏快速定位手段，导致故障难以在短时间内定位、消除。
运维监控走向数智融合时代，博睿数据发布一体化智能可观测平台 ONE
5 月 20 日，博睿数据正式推出了一体化智能可观测平台 ONE。据介绍，这是业界第一个将所有运维监控需求“All in ONE”的统一平台。
OPLG：新一代云原生可观测最佳实践
OPLG 体系拥有成熟且富有活力的开源社区生态，同时也经过了大量企业生产环境的实践检验，是当下建设新一代云原生统一可观测平台的热门选择。但是，OPLG 只是提供了一个技术体系，如何灵活运用，解决实际问题，沉淀出通用行业或场景的最佳实践，还需要大家一起来探索。
2021云栖大会开源引力峰会重磅发布的战略合作，Grafana服务到底是什么？
这几天关注云栖大会的小伙伴一定会发现阿里巴巴合伙人、阿里云高级研究员蒋江伟（小邪）在云栖大会开源引力峰会的演讲中，特别提到了一个叫 Grafana 服务的产品，并特意花费一页 PPT 介绍了这一次合作。到底是一个什么样的产品值得隆重介绍？
如何发现 Kubernetes 中服务和工作负载的异常
本次分享为Kubernetes 监控公开课的第二节内容：如何发现 Kubernetes 中服务和工作负载的异常。 分享由三个部分组成： 一、Kubernetes 异常定位存在痛点； 二、针对这些痛点，Kubernetes 监控如何更快、更准、更全的发现异常； 三、网络性能监控、中间件监控等典型案例解析。
双十一即将到来，你的网站真的准备好了吗？
每年双 11 前夕，全链路压测成为企业的必备选项，不断地通过压测发现问题进行迭代优化、全方位验证业务的稳定性，而云拨测的出现，是对全链路压测的完美补充，从用户视角全面解析大促场景下的用户体验情况，让用户能够拥有更加优质的购买体验。并且随着业务的发展不断进化，持续发挥着不可替代的作用。
警惕日志采集失败的 6 大经典雷区：从本地管理反模式到 LoongCollector 标准实践
本文总结了日志管理中的六大反模式及优化建议，涵盖日志轮转、存储选择、并发写入等常见问题，帮助提升日志采集的完整性与系统可观测性，适用于运维及开发人员优化日志管理策略。
助力企业高效构建安全、可观测的云上数据中心
本次课程聚焦于助力企业高效构建安全、可观测的云上数据中心，涵盖三大方面：1) 数据中心网络面临的挑战，包括VPC、NAT网关和私网连接等产品的功能与挑战；2) 数据中心网络产品重磅发布，涉及安全设计建议、容灾能力提升及深度可观测能力的增强；3) 用户体验升级，通过VPC IPAM实现高效的网络地址管理和简化的产品体验。整体旨在为企业提供更安全、稳定、高效的云上解决方案。
众览全局，企业级云监控助力构建统一云产品可观测
企业上云已成为共识，但在合理使用和管理云资源方面仍面临诸多挑战。富莱瑞调研显示79%的企业缺乏经验。阿里云2023年推出云监控2.0，通过统一接入、关联分析、数据探索等六大升级，帮助企业应对数据孤岛、关联分析困难、灵活性不足等问题。云监控2.0还引入了CloudLens和AI大模型技术，提供更深入的云产品可观测能力，提升运维效率。实际案例表明，通过建设统一可观测平台，企业的故障排查时间和运营成本显著降低。
grafana展示的CPU利用率与实际不符的问题探究
观察到`mpstat`命令显示单核CPU的`%usr`和`%sys`分别持续在70%和20%，而Grafana监控数据显示较低。问题源于Grafana表达式计算的是CPU时间增量而非利用率。`mpstat`通过`/proc/stat`获取数据并计算CPU利用率，而`node-exporter`直接导出原始数据。调整Grafana表达式以匹配`mpstat`的计算方式后，两者结果一致。解决方案是修正Grafana查询以准确反映CPU占用率。
