虽说监控系统最侧重的功能是指标采集、存储、分析、告警，为了能够快速恢复故障，告警自愈机制也是需要重点投入建设的，所有可以固化为脚本的应急预案都可以使用告警自愈机制来快速驱动。夜莺开源项目从v7版本开始内置了告警自愈模块，本文将详细介绍告警自愈的原理和实现。 夜莺项目介绍 夜莺监控是一款开源云原生观测分析工具，采用All-in-One的设计理念，集数据采集、可视化、监控告警、数据分析于一体，与云原生生态紧密集成，提供开箱即用的企业级监控分析和告警能力。夜莺于2020年3月20日，在github上发布v1版本，已累计迭代100多个版本。 夜莺最初由滴滴开发和开源，并于2022年5月11日，捐赠...

CharityMajors的这句话可能是对科技行业当前可观察性状态的最好总结——完全的、大规模的混乱。大家都很困惑。什么是trace？什么是span？一行日志就是一个span吗？如果我有日志，我还需要trace吗？如果我有很好的metric，为什么还需要trace？诸如此类的问题不胜枚举。Charity与 Honeycomb 可观测系统中的其他杰出人士一起，一直在努力解决这些问题。然而，根据我自己的经验，仍然很难解释Charity所说的“日志是垃圾”是什么意思，更不用说日志和痕迹本质上是同一件事了。为什么大家都这么困惑呢？ 冒一点风险，我要怪罪OpenTelemetry。...

背景 在微服务大行其道的今天，如何观测众多微服务、快速理清服务间的依赖、如何对服务之间的调用性能进行衡量，成了摆在大家面前的难题。对此，Skywalking应运而生，它是托管在Apache基金会下的开源项目，旨在帮助开发者监控分布式程序的性能、了解各个服务的调用关系和运行情况。 Skywalking支持多种语言和框架，包含Java、Golang、Python等，功能强大、界面友好等特点使其迅速成为业界最流行的APM软件之一。然而在运用Skywalking的过程中，我们常常更关注服务之间的调用链路、性能数据，往往会忽略流量入口（网关）到服务之间的Trace串联，导致我们经常在网关层面观测到一个错...

远程操作机器有时会比较麻烦，我写了一个工具，主要功能：1.远程执行命令2.上传下载文件。是一个WebServer，通过HTTP请求来操作机器，类似一个小木马。当然，因为是一个WebServer，所以也提供了打印HTTP请求的能力，方便调试Webhook场景。下面给大家演示一下。 安装 工具代码放到Github上了，感兴趣的朋友可以瞧瞧，没多少行代码。也给大家编译好了，下载地址在这里：https://github.com/UlricQin/gohttpd/releases。提供x86和arm64的Linux版本，下载后解压就可以直接运行。 我是arm64架构的机器，所以下载arm64版本，下载...

经过一个半月的打磨改进，夜莺监控V7第二个beta版本发布了，本次发布的主要亮点是内置集成故障自愈能力，简化架构，同时做了其他19项改进。一些重要的改进如下： feat:集成故障自愈的能力，不需要再单独部署ibex模块了 refactor:内置仪表盘和内置规则页面重构 refactor:业务组树组件展示优化，去除连线以及更新图标 refactor:告警规则等表格页面优化，重新组织表格列 refactor:告警规则等编辑表单页面优化，样式优化、底部悬浮固定按钮组等 refactor:告警规则Prometheus源的预览功能优化，默认强制补全缺点数据 refactor:导入grafana仪表盘优...

问题背景 访问某个HTTP域名接口，偶发性超时，原因可能多种多样，比如DNS解析问题、网络质量问题、对端服务负载问题等，在客户端没有良好埋点的情况下，排查起来比较费劲，只能挨个方向尝试，这里送大家一个小工具，可以快速采样DNS解析延迟，快速确认是否是DNS解析问题。 使用演示 运行工具，传入域名，就开始探测，每秒探测一次，如果想控制频率，也可以传入第二个参数，比如0.2秒探测一次。 ulric@ulric-flashcatdns-lookup-latency%./dns-lookup-latencybaidu.com0.2 Apr709:25:15.414:26.060ms Apr709:2...

稍微有点Linux经验的人一定会遇到过“Toomanyopenfiles”错误，这个错误本质是ulimit设置不合理导致的。关于ulimit设置，有哪些需要注意的点呢？本文给大家做一个介绍，希望对大家有所帮助。 如何确认ulimit设置生效了？ 很多人设置了ulimit最后发现还是报错“Toomanyopenfiles”。先不论如何操作，我们先要知道怎么确认进程的ulimit到底是多少。这不是通过 ulimit-n 来看的，而是找到进程的pid，然后查看 /proc/<进程的PID>/limits 文件，这个文件里面记录了进程的真实ulimi...

指标、日志、链路是服务可观测性的三大支柱，在服务稳定性保障中，通常指标侧重于发现故障和问题，日志和链路分析侧重于定位和分析问题，其中日志实际上是串联这三大维度的一个良好桥梁。 但日志分析往往面临成本和效果之间的权衡问题，没有完美的方案只有适合的方案，本文将结合实战经验，介绍一种日志分析的实现，分析如何在稳定性保障中用好日志这个维度，以及日志如何与指标、链路相互配合形成故障定位的最佳实践。 日志分析难点 1）规范问题：服务模块的语言和框架各异，日志格式不规范，分析困难；2）管理问题：微服务模块众多，日志收集和管理困难；3）成本问题：日志的保存和计算分析需要消耗大量的资源，主要是存储计算资源，使...

场景再现 你正在午休，正梦见中了彩票，突然收到电话告警，说服务对外接口95分位延迟突增，惊出一身冷汗，睡意全无，抓紧打开监控系统，查看服务的SLI指标，发现确实有问题，已经持续1分钟，这服务我刚接手没多久，怎么办？怎么办？？对了，告警详情里有SOP预案手册，赶紧打开看看。 SOP预案手册里写着： 1.研发运维群里确认是否有人刚有上线，如果有该服务的变更，及时回滚 2.该服务没有多活架构，无法切流，需要找到详细原因再针对性处理 3.登录s链接，可以查看该服务的SLI（ServiceLevelIndicator，反应服务健康状况的最重要的几个黄金指标） 4.登录x系统，找到a索引，可以查看...

据说有些云厂商会超卖，宿主有96个核心，结果卖出去100多个vCPU，如果这些虚机负载都不高，大家相安无事，如果这些虚机同时运行一些高负载的任务，相互之间就会抢占CPU，对应用程序有较大影响，我应该如何查看我的CPU是否被抢占了呢？ 什么是cpustealtime？ 如果你在物理机上查看这个指标，这个指标必然是0，只有虚拟机才需要关注这个指标。我们看一下CPUstealtime的定义（来自 ibm.com）： StealtimeisthepercentageoftimeavirtualCPUwaitsforarealCPUwhilethehypervisorisservic...

需求 我想进入容器中执行curl命令探测某个地址的连通性，但是容器镜像里默认没有curl命令。我这里是一个内网环境不太方便使用yum或者apt安装，怎么办？ 这个需求比较典型，这里教大家一个简单的方法，使用nsenter进入容器的netnamespace，即可使用宿主机的curl、ip、ifconfig等命令，其效果，就跟进入容器中执行是一样的。 原理 容器像是一个轻量级虚拟机，有自己的IP，宿主机如果已经监听了8080端口，容器里的进程仍然可以重复监听8080端口。核心就是因为容器有自己的namespace，和宿主机的netnamespace互不影响。关于容器的namespace相关知识...

作为全球首家以超连接为核心的云服务商，Zenlayer致力于将云计算、内容服务和边缘技术融合，为客户提供全面的解决方案。通过构建可靠的网络架构和高效的数据传输，Zenlayer帮助客户实现更快速、更可靠的连接，提升用户体验和业务效率。Zenlayer在全球范围内运营着超过290个边缘节点，骨干网带宽超过50Tbps，10000+的数据中心接入点，快速连接全球公有云与数据中心。 监控现状 Zenlayer运营着全球数百个边缘机房和庞大的骨干网网络，我们的监控目标主要包括： 各种硬件设备，如交换机、裸金属 超大大规模网络的连通性和质量 Kubernetes云原生技术栈 在Zenlayer...

需求 拿到一个镜像之后，我想知道： 分层查看镜像里都有哪些文件 各层使用了什么命令构建的这个镜像 镜像里比较大的文件有哪些（可能需要优化） dive工具介绍 dive工具可以做这些分析。dive的github地址是 wagoodman/dive，小巧玲珑，MIT开源协议，42.9k的star。它的介绍是这么一句话： Atoolforexploringeachlayerinadockerimage 其分析效果大概如下： 安装dive 可以使用镜像安装： dockerpullwagoodman/dive:latest dockerrun--rm-it-v/var/run/...

目前业界的日志生态，最常用的是ELK，其次就是ClickHouse，本文会演示如何使用Vector+ClickHouse来采集Nginx日志并做清洗，最终写入ClickHouse。至于日志的可视化，后面再单独介绍，后面夜莺会把日志可视化能力下放到开源版本，之前跟映客的兄弟们交流准备一起搞，可惜迟迟没有抽出时间。别急，会有的，本文先把前半段完成，即日志的收集+传输+清洗+存储。存储显然是ClickHouse，前面三个环节，使用Vector来完成。之前有一篇文章对Vector做过简单介绍，大家可以参考：《可观测性数据收集集大成者：Vector》。 配置Nginxlog 我们可以直接采集默认的Ngi...

当前架构 某出行科技企业从单个公有云往多云转型，依托于国内领先的公有云提供商，采用多云架构，在可用性、弹性、成本、供应商依赖方面，拥有了显著的优势。 相应的，多云架构也给技术团队带来了一定的复杂度和技术挑战，最显著的就是如何高效的构建跨云的可观测性体系，提升故障发现、问题排查、性能分析等方面的能力。 跨云使用多个云监控工具，具体而言，存在以下痛点： 工具多，体验不一致，技术团队学习成本很高 仪表盘和告警策略的配置维护工作量大，需要在多平台重复配置 数据孤岛现象严重，关联分析成本高，效率低 需要为所有研发人员开通公有云控制台权限，管理维护成本高，存在信息安全隐患 特别的，当故障不可避免...

引言 在现代的IT技术环境中，新的监控系统通常都支持非常丰富的通知媒介，比如电话、短信、钉钉、飞书、Slack等，非常灵活。但是一些老旧的系统，不提供指标暴露方式，无法和监控系统良好对接，这些老古董通常只内置提供邮件告警这一种方式。这给整个分发和自动化都带来了挑战。通常来讲，邮件告警方式有以下问题： 使用邮件告警有哪些问题？ 1.容易被忽视：邮件告警往往淹没在日常工作邮件中，容易被忽视或误判为普通邮件，导致告警未能及时处理，增加了业务风险和损失； 2.信息不全面和直观：邮件告警的内容可能过于冗长、繁琐，或者缺乏关键的上下文信息，使得处理人员难以快速理解和判断问题的严重性和紧急程度； 3.自动...

Log是最常用、最自然的监控数据类型之一，具有以下的优点： 日志的内容比指标更加丰富，可以提供更多的细节信息，帮助开发人员和运维人员更好地理解应用程序的运行状况，通过日志几乎可以重现、还原系统的完整工作过程。 日志的格式灵活，可以方便的记录多样化的事件，包括错误、异常和警告等，而指标通常只能提供统计数据，无法直接反映系统中的具体事件。 日志为文本格式，便于技术人员理解，同时可以被各种文本处理工具、文本搜索工具高效的处理。 现实情况中，logs、traces、metrics在收集、传输、存储整个链条上，存在相互割裂的情况，导致在对可观测性数据进行统一分析的时候，难以打通。  在可观...

背景 当今的数字化世界离不开无处不在的网络连接。无论是日常生活中的社交媒体、电子商务，还是企业级应用程序和云服务，我们对网络的依赖程度越来越高。然而，网络的可靠性和性能往往是一个复杂的问题，尤其是在具有大规模分布式架构的系统中。 在过去，网络监控主要依赖于传统的点对点（point-to-point）方式，通过单独的监控工具对网络路径进行测试。然而，这种方法往往只能提供有限的信息，并且无法全面评估整个网络的健康状况。为了更好地了解网络的运行情况以及及时发现潜在的问题，Pingmesh技术应运而生。 Pingmesh的提出最初是来自微软，在微软内部Pingmesh每天会记录24TB数据，进行200...

前言 对于数据库、中间件的监控，目前社区里最为完善的就是Prometheus生态的各个Exporter，不过这些Exporter比较分散，不好管理，如果有很多目标实例需要监控，就要部署很多个Exporter，要是能有一个大一统的Exporter，具备所有这些Exporter的能力就好了。还真有，而且还不止一个，一个是 Grafana-agent，一个是 Cprobe，Grafana-agent整合这些Exporter相对比较生硬而且缺少了目标实例自动发现机制，好处是Grafana-agent不止是整合了常见的Exporter，还整合了Promtail和OTELCollect...

夜莺社区的朋友如果问时序库的选型，我一般都会推荐VictoriaMetrics，除了其性能、稳定性、集群扩展能力之外，VictoriaMetrics还扩展了PromQL，提供了MetricsQL，即增强了PromQL的能力。比如下面介绍的场景，就很适合用MetricsQL来解决。 需求 某个指标（假设指标名字是interface_status）每分钟上报一次，如果5分钟内有3次大于x的值，就报警。 解法 如果使用PromQL，就比较难写了，而MetricsQL就很简单，如下： count_gt_over_time(interface_status[5m],x)>=3 看到这个写法，基...