观测云的博客

如何提升告警的有效性，准确识别问题，同时又不至于淹没在大量的无效告警中，正是本文所探讨的内容。

您可以从三个选项中（快速、便宜或好）选择两个”提出这个问题的人可能不是可观测性工程师。但也可能是，在可观测性方面，决定您是否想要“快速、负担得起或深入的洞察力”传统上是工程团队的首要任务之一。从历史上看，我们所依赖的监控架构和工具并不能让我们拥有一切，至少在分布式云原生应用程序的环境中是这样。幸运的是，至少在可观测性方面通过重新思考监控方法的基本原理，您可以拥有一切。您可以快速获得深入的见解，而无需为监控工作流付出代价。听起来好得令人难以置信？

需要进行软件开发的程序员需要所开发系统进行整体把控的软件工程师。

网络可观测性在此充当了 DevOps 可观测性的关键补充组件。与网络可观测性相比，DevOps 可观测性只关注应用程序的性能。可观测性工具可能非常适合达到其网络监控疲劳极限的网络团队。我还将帮助您理清网络可观测性和 DevOps 可观测性之间的区别。了解可观测性将有助于促进监控，这是将其添加到 IT 工具箱的第一个重要步骤。实施网络可观测性后，您的网络团队将开始看到收益。网络可观测性工具建立在通过网络监控收集的数据之上。网络可观测性和 DevOps 可观测性可以相互补充，但它们仍然明显不同。...

日常生活中，我们会和他人进行交流。有些可能出于习惯和礼貌，或者单纯的闲聊。而我们在与他人发起工作上的沟通时，总是会有一个明确的原因。比如寻求帮助，搜集意见或建议等。因此，不同于日常生活中的交流，工作中的沟通更需要讲究方式和方法，追求沟通背后目标的达成。...

本文主要为需要编写软件设计/开发文档的读者提供一些经验和建议。

大多数人喜欢将数据可观测性视为了解数据状态的窗口。但数据可观测性不是静态的或被动的——它是一个主动的过程。数据质量。您能否确认您所依赖的数据是最新的、准确的且格式正确？数据沿袭。你相信你的数据来源吗？您是否了解它是如何在您的系统中移动的以及它在何时何地被使用？数据监控。每条管道是否24/7全天候运行？管道是否传输了您需要的所有数据，而不仅仅是90%？通知。当出现问题时，您的数据会立即告诉您，还是等到您查看报告或运行诊断时才告诉您——此时已经为时已晚？...

将代码注入 Linux 内核的能力开辟了一个全新的可能性世界。您可以轻松改进很多东西——安全性、网络、可观测性等等。BPF（伯克利包过滤器）使您能够编写可以从内部利用 Linux 内核功能的程序。BPF 传统上用于在将原始网络数据包发送到用户空间之前对其进行过滤，以提高系统的整体安全性。eBPF是 BPF 的扩展版本，具有一系列安全实现，以防止 BPF 程序破坏内核。在本指南中，您将了解如何使用 eBPF 在基于 Kubernetes 的基础架构中实现增强的可观测性。eBPF 代表扩展 BPF。顾名思义，它

2022 年 DevOps 路线图DevOps 成为越来越多的互联网职场人希望了解和学习的话题，他们有兴趣知道 2022 年DevOps要学习什么。DevOps 技能需求量很大，并且需要不断学习需要让自己与市场需求保持同步。这篇文章是为了分享关于DevOps的一些指导。路线图从根本上强大的网络技术了解 HTTP/2、QUIC 或 HTTP3、第 4 层和第 7 层协议、mTLS、代理、DNS、BGP 等概念，负载平衡的工作原理、IP 表、Internet 的工作原理、IP 地址和

nfluxDB 是一个开源分布式时序和指标数据库，使用 Go 语言编写。

前言谈到 Service Mesh，人们总是想起微服务和服务治理，从 Dubbo 到 Spring Cloud (2016开始进入国内研发的视野，2017年繁荣)再到 Service Mesh (2018年开始被大家所熟悉)，正所谓长江后浪推前浪，作为后浪，Service Mesh 别无选择，而 Spring Cloud 对 Service Mesh 满怀羡慕，微服务架构的出现与繁荣，是互联网时代架构形式的巨大突破。Service Mesh 具有一定的学习成本，实际上在国内的落地案例不多，大多是云商与头

我们常见 OOM 异常场景堆溢出-java.lang.OutOfMemoryError: Java heap space。 栈溢出-java.lang.OutOfMemorryError。 栈溢出-java.lang.StackOverFlowError。 元信息溢出-java.lang.OutOfMemoryError: Metaspace。 直接内存溢出-java.lang.OutOfMemoryError: Direct buffer memory。 GC超限-java.lang.Out

以产品为主导的增长商业模式创造了大量机会，但要抓住其潜力需要大胆和逆向思维。如果我们要追溯以产品为导向的增长 (PLG) 商业模式的起源，我们将在澳大利亚悉尼开始我们的旅程。许多人认为成立于 2002 年的 Atlassian 是第一家开创 PLG 商业模式的云公司。其创始人认为，无摩擦、以产品为主导的分销流程是加速新技术采用的方式，尤其是在开发人员中。他们决心让 PLG 方法发挥作用，以至于 Atlassian 在成立的头十年里没有雇佣任何销售人员，当华尔街的一家主要银行威胁要在没有企业销售折..

如果您从 DevOps 的定义中去除流行语和 TLA ，您会发现所涉及的角色和任务主要是为了在 SDLC（软件开发生命周期）中获得更多的正常运行时间和更少的停机时间。实现这一目标的第一步是在监控解决方案的帮助下发现停机时间。只有这样，您才能及时响应并解决问题，从而最大限度地减少软件开发团队可怕且代价高昂的停机时间。DevOps 中的可观测性 vs 监控停机成本高确保正常运行时间的重要性不容小觑。这是因为 DevOps 团队在解决关键事件时反应迟缓，成本很高——非常高。北美每张票的平均

在上一篇《运维,放过监控-也放过自己吧》中原作者提出了自己对于可观测性的三个困惑，本文围绕这三个问题展开讨论。1.可观测性解决什么问题？其实可观测性最先解决的就是一个问题：就是监控工具太太太多了，在 Datadog 的招股书上就写得很明白一般企业要部署 5 套监控软件，而大型企业因为各种跨部门甚至要 15+，这种造成了资源浪费，学习曲线，认知成本，协同成本，系统更新等一系列的问题。当然一切整合起来的可观测性，也和原来的监控不同了。其对象瞄准的恰恰是应用系统本身，也就是我们需要将自己所制造的.

根据多年和运维打交道的经历，我发现，运维常常让监控变得无效。。。1.我的监控故事我做过两年多的运维工作，后面就转做运维平台开发了，也一步步看着监控系统越来越没用。1.1 有用的监控当我做运维要负责oncall时，我一直认为监控系统做的还可以，并不是因为做了太多事情，而是因为运维的业务还是单体应用，也没有太多的监控需要加。记得那会公司还是用Nagios(估计新人已经没多少人知道了)，不过监控的维护工作着实费劲。后面我就开始研究zabbix，最大的好处就是它可以disc...

如果您发现难以管理跨越多个云运行不断变化的容器化工作负载的庞大基础架构，那么您并不孤单。根据 Dynatrace 近期发布的一项研究，超过一半的组织的 DevSecOps 团队在可观测性数据方面感到痛苦。多云和混合计算设置的兴起使组织能够灵活地在最适合的地方运行应用程序。通过 Kubernetes 管理容器，可以快速扩展以使计算能力与需求相匹配，然后以同样快的速度将其缩小。所有这些活力正是我们所要求的，但事实证明这是有代价的。根据Dynatrace的说法，其中一个成本是越来越不同的可观测性系统，它迫