使用 ES|QL 优化可观察性:简化 Kubernetes 和 OTel 的 SRE 操作和问题解决

2024-02-24 18:52

本文主要是介绍使用 ES|QL 优化可观察性:简化 Kubernetes 和 OTel 的 SRE 操作和问题解决,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

作者:Bahubali Shetti

作为一名运营工程师(SRE、IT 运营、DevOps),管理技术和数据蔓延是一项持续的挑战。 简单地管理大量高维和高基数数据是令人难以承受的。

作为单一平台,Elastic® 帮助 SRE 将无限的遥测数据(包括指标、日志、跟踪和分析)统一并关联到单一数据存储 — Elasticsearch® 中。 然后,通过应用 Elastic 的高级机器学习 (ML)、AIOps、AI Assistant 和分析的强大功能,你可以打破孤岛并将数据转化为见解。 作为全栈可观测性解决方案,从基础设施监控到日志监控和应用程序性能监控 (APM) 的所有内容都可以在单一、统一的体验中找到。

在 Elastic 8.11 中,Elastic 的新管道查询语言 ES|QL(Elasticsearch 查询语言)现已提供技术预览,它可以转换、丰富和简化数据调查。 在新的查询引擎的支持下,ES|QL 提供了具有并发处理的高级搜索功能,从而提高了速度和效率,而不受数据源和结构的影响。 通过从一个屏幕创建聚合和可视化来加速解决问题,提供迭代、不间断的工作流程。

ES|QL 对于 SRE 的优势

使用 Elastic Observability 的 SRE 可以利用 ES|QL 来分析日志、指标、跟踪和分析数据,使他们能够通过单个查询查明性能瓶颈和系统问题。 在 Elastic Observability 中使用 ES|QL 管理高维和高基数数据时,SRE 具有以下优势:

  • 提高运营效率:通过使用 ES|QL,SRE 可以使用聚合值作为单个查询的阈值来创建更多可操作的通知,这些通知也可以通过 Elastic API 进行管理并集成到 DevOps 流程中。
  • 通过洞察增强分析:ES|QL 可以处理各种可观测数据,包括应用程序、基础设施、业务数据等,无论来源和结构如何。 ES|QL 可以轻松地通过附加字段和上下文丰富数据,从而允许通过单个查询创建仪表板可视化或问题分析。
  • 缩短解决问题的平均时间:ES|QL 与 Elastic Observability 的 AIOps 和 AI Assistant 结合使用,可通过识别趋势、隔离事件和减少误报来提高检测准确性。 这种上下文的改进有助于故障排除以及快速查明和解决问题。

Elastic Observability 中的 ES|QL 不仅增强了 SRE 更有效地管理客户体验、组织收入和 SLO 的能力,而且还通过提供上下文聚合数据来促进与开发人员和 DevOps 的协作。

在本博客中,我们将介绍 SRE 可以利用 ES|QL 的一些关键用例:

  • ES|QL 与 Elastic AI Assistant 集成,使用公共 LLM 和私有数据,增强了 Elastic Observability 中任何地方的分析体验。
  • SRE 可以在单个 ES|QL 查询中分解、分析和可视化来自多个来源和跨任何时间范围的可观察性数据。
  • 可以通过单个 ES|QL 查询轻松创建可操作的警报,从而增强操作。

我将通过展示 SRE 如何解决使用 OpenTelemetry 检测并在 Kubernetes 上运行的应用程序中的问题来完成这些用例。 OpenTelemetry (OTel) 演示位于 Amazon EKS 集群上,并配置了 Elastic Cloud 8.11。

你还可以查看我们的 Elastic Observability ES|QL 演示,该演示演示了可观察性的 ES|QL 功能。

ES|QL 与 AI 助手

作为 SRE,你正在使用 Elastic Observability 监控 OTel 仪表化应用程序,而在 Elastic APM 中,你会注意到 service map 中突出显示的一些问题。

使用 Elastic AI Assistant,你可以轻松要求进行分析,特别是,我们会检查应用程序服务的总体延迟情况。

My APM data is in traces-apm*. What's the average latency per service over the last hour? Use ESQL, the data is mapped to ECS

Elastic AI Assistant 生成一个 ES|QL 查询,我们在 AI Assistant 中运行该查询以获取所有应用程序服务的平均延迟列表。 我们可以很容易地看到前四名是:

  • load generator
  • front-end proxy
  • frontendservice
  • checkoutservice

通过 AI Assistant 中的简单自然语言查询,它生成了单个 ES|QL 查询,帮助列出跨服务的延迟。

注意到多个服务存在问题,我们决定从前端代理(front-end proxy)开始。 当我们研究细节时,我们看到了重大故障,并且通过 Elastic APM 故障关联,很明显前端代理没有正确完成对下游服务的调用。

Discover 中的 ES|QL 洞察力和上下文分析

了解应用程序在 Kubernetes 上运行后,我们会调查 Kubernetes 中是否存在问题。 我们特别想查看是否有任何服务存在问题。

我们在 Elastic Discover 的 ES|QL 中使用以下查询:

from metrics-* | where kubernetes.container.status.last_terminated_reason != "" and kubernetes.namespace == "default" | stats reason_count=count(kubernetes.container.status.last_terminated_reason) by kubernetes.container.name, kubernetes.container.status.last_terminated_reason | where reason_count > 0

ES|QL 帮助分析来自 Kubernetes 的 1,000 个/10,000 个指标事件,并突出显示由于 OOMKilled 而重新启动的两个服务。

当被问及 OOMKilled 时,Elastic AI Assistant 表示 pod 中的容器由于内存不足而被终止。

我们运行另一个 ES|QL 查询来了解电子邮件服务和产品目录服务的内存使用情况。

ES|QL 很容易发现平均内存使用量相当高。

我们现在可以进一步调查这两个服务的日志、指标和 Kubernetes 相关数据。 然而,在继续之前,我们创建一个警报来跟踪大量内存使用情况。

使用 ES|QL 发出可操作的警报

怀疑可能会再次出现的特定问题,我们只需创建一个警报,引入我们刚刚运行的 ES|QL 查询,该查询将跟踪内存利用率超过 50% 的任何服务。

我们修改最后一个查询以查找内存使用率高的任何服务:

FROM metrics*
| WHERE @timestamp >= NOW() - 1 hours
| STATS avg_memory_usage = AVG(kubernetes.pod.memory.usage.limit.pct) BY kubernetes.deployment.name | where avg_memory_usage > .5

通过该查询,我们创建一个简单的警报。 请注意如何将 ES|QL 查询引入警报中。 我们简单地将其与寻呼机职责联系起来。 但我们可以从多个连接器中进行选择,例如 ServiceNow、Opsgenie、电子邮件等。

通过此警报,我们现在可以轻松监控 pod 中内存利用率超过 50% 的任何服务。

使用 ES|QL 充分利用你的数据

在这篇文章中,我们展示了 ES|QL 为分析、操作和减少 MTTR 带来的强大功能。 综上所述,Elastic Observability 中 ES|QL 的三个用例如下:

  • ES|QL 与 Elastic AI Assistant 集成,使用公共 LLM 和私有数据,增强了 Elastic Observability 中任何地方的分析体验。
  • SRE 可以在单个 ES|QL 查询中分解、分析和可视化来自多个来源和跨任何时间范围的可观察性数据。
  • 可以通过单个 ES|QL 查询轻松创建可操作的警报,从而增强操作。

Elastic 邀请 SRE 和开发人员亲身体验这种变革性语言,并开启数据任务的新视野。 今天就在 https://ela.st/free-Trial上尝试一下,现在处于技术预览版。

本文中描述的任何特性或功能的发布和时间安排均由 Elastic 自行决定。 当前不可用的任何特性或功能可能无法按时交付或根本无法交付。

原文:Optimizing SRE efficiency and issue resolution with ES|QL in Elastic Observability, OTel, and Kubernetes | Elastic Blog

这篇关于使用 ES|QL 优化可观察性:简化 Kubernetes 和 OTel 的 SRE 操作和问题解决的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/743038

相关文章

Vue3 的 shallowRef 和 shallowReactive:优化性能

大家对 Vue3 的 ref 和 reactive 都很熟悉,那么对 shallowRef 和 shallowReactive 是否了解呢? 在编程和数据结构中,“shallow”(浅层)通常指对数据结构的最外层进行操作,而不递归地处理其内部或嵌套的数据。这种处理方式关注的是数据结构的第一层属性或元素,而忽略更深层次的嵌套内容。 1. 浅层与深层的对比 1.1 浅层(Shallow) 定义

中文分词jieba库的使用与实景应用(一)

知识星球:https://articles.zsxq.com/id_fxvgc803qmr2.html 目录 一.定义: 精确模式(默认模式): 全模式: 搜索引擎模式: paddle 模式(基于深度学习的分词模式): 二 自定义词典 三.文本解析   调整词出现的频率 四. 关键词提取 A. 基于TF-IDF算法的关键词提取 B. 基于TextRank算法的关键词提取

使用SecondaryNameNode恢复NameNode的数据

1)需求: NameNode进程挂了并且存储的数据也丢失了,如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2)故障模拟 (1)kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 (2)删除NameNode存储的数据(/opt/module/hadoop-3.1.4/data/tmp/dfs/na

HDFS—存储优化(纠删码)

纠删码原理 HDFS 默认情况下,一个文件有3个副本,这样提高了数据的可靠性,但也带来了2倍的冗余开销。 Hadoop3.x 引入了纠删码,采用计算的方式,可以节省约50%左右的存储空间。 此种方式节约了空间,但是会增加 cpu 的计算。 纠删码策略是给具体一个路径设置。所有往此路径下存储的文件,都会执行此策略。 默认只开启对 RS-6-3-1024k

Hadoop数据压缩使用介绍

一、压缩原则 (1)运算密集型的Job,少用压缩 (2)IO密集型的Job,多用压缩 二、压缩算法比较 三、压缩位置选择 四、压缩参数配置 1)为了支持多种压缩/解压缩算法,Hadoop引入了编码/解码器 2)要在Hadoop中启用压缩,可以配置如下参数

Makefile简明使用教程

文章目录 规则makefile文件的基本语法:加在命令前的特殊符号:.PHONY伪目标: Makefilev1 直观写法v2 加上中间过程v3 伪目标v4 变量 make 选项-f-n-C Make 是一种流行的构建工具,常用于将源代码转换成可执行文件或者其他形式的输出文件(如库文件、文档等)。Make 可以自动化地执行编译、链接等一系列操作。 规则 makefile文件

好题——hdu2522(小数问题:求1/n的第一个循环节)

好喜欢这题,第一次做小数问题,一开始真心没思路,然后参考了网上的一些资料。 知识点***********************************无限不循环小数即无理数,不能写作两整数之比*****************************(一开始没想到,小学没学好) 此题1/n肯定是一个有限循环小数,了解这些后就能做此题了。 按照除法的机制,用一个函数表示出来就可以了,代码如下

hdu1043(八数码问题,广搜 + hash(实现状态压缩) )

利用康拓展开将一个排列映射成一个自然数,然后就变成了普通的广搜题。 #include<iostream>#include<algorithm>#include<string>#include<stack>#include<queue>#include<map>#include<stdio.h>#include<stdlib.h>#include<ctype.h>#inclu

使用opencv优化图片(画面变清晰)

文章目录 需求影响照片清晰度的因素 实现降噪测试代码 锐化空间锐化Unsharp Masking频率域锐化对比测试 对比度增强常用算法对比测试 需求 对图像进行优化,使其看起来更清晰,同时保持尺寸不变,通常涉及到图像处理技术如锐化、降噪、对比度增强等 影响照片清晰度的因素 影响照片清晰度的因素有很多,主要可以从以下几个方面来分析 1. 拍摄设备 相机传感器:相机传

如何解决线上平台抽佣高 线下门店客流少的痛点!

目前,许多传统零售店铺正遭遇客源下降的难题。尽管广告推广能带来一定的客流,但其费用昂贵。鉴于此,众多零售商纷纷选择加入像美团、饿了么和抖音这样的大型在线平台,但这些平台的高佣金率导致了利润的大幅缩水。在这样的市场环境下,商家之间的合作网络逐渐成为一种有效的解决方案,通过资源和客户基础的共享,实现共同的利益增长。 以最近在上海兴起的一个跨行业合作平台为例,该平台融合了环保消费积分系统,在短