老张,你的服务是不是挂了?论全局 SLI 的重要性
作为研发运维人员,经常碰到这种情况,自己的服务依赖别人的服务,某一天自己的服务故障了,此时我很想知道依赖的下游服务当前是否健康,但是这些下游服务的 SLI 却没有地方查看,困扰不已。
围绕可观测性、AI SRE、告警治理、On-call、Nightingale、Categraf、Prometheus、Kubernetes、Zabbix、用户案例和产品更新,沉淀一线工程实践、选型参考和稳定性治理方法。
作为研发运维人员,经常碰到这种情况,自己的服务依赖别人的服务,某一天自己的服务故障了,此时我很想知道依赖的下游服务当前是否健康,但是这些下游服务的 SLI 却没有地方查看,困扰不已。
本文通过讲解 cpu steal time 的概念,来告诉大家如何查看云厂商是否超卖,如果一旦超卖,该如何应对。
有些团队声称自己是 DevOps 团队,全员 OnCall,结果最后就是最好欺负的那些人干活最多,这不,我这个前同事就是因为这个原因,要离职了
作为全球首家以超连接为核心的云服务商,Zenlayer 致力于将云计算、内容服务和边缘技术融合,为客户提供全面的解决方案。通过构建可靠的网络架构和高效的数据传输,Zenlayer 帮助客户实现更快速、更可靠的连接,提升用户体验和业务效率。Zenlayer 在全球范围内运营着超过 290 个边缘节点, 骨干网带宽超过 50Tbps, 10000+ 的数据中心接入点,快速连接全球公有云与数据中心。
dive 是一个用于分析 docker 镜像的工具,可以帮助你快速了解镜像的构成和大小,以及优化镜像大小。
演示如何用 Vector 读取 Nginx 日志、用 VRL 清洗字段,并把结构化日志写入 ClickHouse,完整走通采集、处理与存储链路。
某出行科技企业从单个公有云往多云转型,依托于国内领先的公有云提供商,采用多云架构,在可用性、弹性、成本、供应商依赖方面,拥有了显著的优势。相应的,多云架构也给技术团队带来了一定的复杂度和技术挑战,最显著的就是如何高效的构建跨云的可观测性体系,提升故障发现、问题排查、性能分析等方面的能力。
在现代的 IT 技术环境中,新的监控系统通常都支持非常丰富的通知媒介,比如电话、短信、钉钉、飞书、Slack 等,非常灵活。但是一些老旧的系统,不提供指标暴露方式,无法和监控系统良好对接,这些老古董通常只内置提供邮件告警这一种方式。这种情况应该如何处理呢?
当我们在制作仪表盘或其他数据可视化时离不开对图表的选择,不同的数据信息该怎么选择图表?
Logs 是“可观测性三支柱”中历史包袱最重的监控数据类型,日志的格式更随意,缺乏标准和规范。推荐在应用研发阶段,按照 OTel Logs 规范打印日志。
相较于传统的单体应用,以及过去相对静态化的基础设施,现代的应用架构,是一种松耦合的、动态变化的、数量巨大的微服务构成的网络。为了看清楚网络中众多不同的服务之间的依赖关系,以及看清楚一次请求经过的路径上各个节点之间的耗时等信息,传统监控,已经无力应对了。这个网络的每个节点,都有可能是出问题的风险点,tracing 能够追踪每个请求在全生命周期过程中所经过的每个节点的信息,成为了云原生时代和微服务架构下构建可观测体系的关键一环。
我想进入容器中执行 curl 命令探测某个地址的连通性,但是容器镜像里默认没有 curl 命令。我这里是一个内网环境不太方便使用 yum 或者 apt 安装,怎么办?这个需求比较典型,这里教大家一个简单的方法,使用 nsenter 进入容器的 net namespace,即可使用宿主机的 curl、ip、ifconfig 等命令,其效果,就跟进入容器中执行是一样的。
大规模网络环境下,有不同的数据中心、不同的机柜、不同的交换机,遇到问题排查起来相对比较费劲,本文介绍通过 Pingmesh 方案来解决这个问题。Pingmesh 的提出最初是来自微软,在微软内部 Pingmesh 每天会记录 24TB 数据,进行 2000 亿次 ping 探测,通过这些数据,微软可以很好的进行网络故障判定和及时的修复。
全程不超过5分钟,快速上手免费使用Flashduty的消息通知能力,支持电话、微信机器人、企业微信、钉钉、飞书、短信、邮件、Slack、Zoom。
夜莺社区的朋友如果问时序库的选型,我一般都会推荐 VictoriaMetrics,除了其性能、稳定性、集群扩展能力之外,VictoriaMetrics 还扩展了 PromQL,提供了 MetricsQL,即增强了 PromQL 的能力。比如下面介绍的场景,就很适合用 MetricsQL 来解决。
笔者从 14 年做开源软件以来,接触了众多 Linux 新手用户,这里我为这类用户总结了一些常见的问题排查方法,希望能帮助到大家。如果你已经工作多年,对于下面提到的思路和方法应该非常熟悉,如果对某一条感到陌生,咳咳,真的不太应该,赶紧补补吧。
如果你在意生产环境的稳定性,希望自己的服务出问题时及时发现,大概率就有日志监控告警的需求,比如发现日志中有 Error 或 Exception 关键字就告警,比如通过日志统计某个服务的 95 分位延迟数据,延迟过高就告警,比如通过日志统计某个服务的 status code,出现多个 5xx 就告警,等等。日志可能存储在 ElasticSearch、Loki、ClickHouse 等系统中,告警系统的核心逻辑也比较清晰,就是根据用户配置的查询语句,周期性查询这些存储,并对查询结果做阈值判定,如果达到阈值就触发告警。比如统计 5 分钟内出现的 Error 数量,如果大于 10 就告警。
在夜莺新版本中,告警规则直接使用 promql 来配置,阈值就包含在 promql 里面,所以恢复时是无法拿到当前值的,因为恢复时监控数据不达阈值,不达阈值就不会返回数据,所以也就无法拿到当前值。Prometheus 也是类似的问题,不过可以通过 go template 中的 query 函数曲线救国,但是不够直观,学习曲线较高。今天给大家介绍两种实现思路来解决这个问题。
使用漫画的方式虚拟一个咖啡馆的点餐场景,来讲解 Go Channel 的原理和使用。
这是《手把手构建生产级监控系统》专栏第二篇,演示如何快速监控常见的数据库、中间件,如何配置仪表盘以及告警规则。方便各位看官能够快速上手,本文重视实操,至于具体每个中间件的关键指标我们留待后面专栏介绍