全方位 Logtail 状态监控

  • 时间:
  • 浏览:1
  • 来源:大发快3APP下载—大发时时彩登录地址

logtail_status 是服务日志的一每种,它记录了 Logtail 的基本情形,每分钟会记录并上报一次。

亲戚亲戚朋友无需 通过如下最好的最好的办法查看有有另一个 图表关联的查询句子:首先将鼠标悬停到目标图表底下,随后悬停在右上角再次老出的省略号上,点击弹出菜单的查看分析详情即可跳转到对应的查询窗口,如下图所示。

目前引起内存超过 1G 的最常见情形是指定的目录中内容这样来太多,愿因 Logtail 轮询占用这样来太多内存。

链路情形是保障 Logtail 正常工作的基础,一般亲戚亲戚朋友会假设在首次配置成功后就无需再次老出问题。但事实上,觉得概率较低,但依旧有多种愿因随后愿因链路再次老出问题,比如:

以 SEND_QUOTA_EXCEED_ALARM 为例,它表示当前日志写入流量超出限制。对于正常业务来说,偶尔的流量突增随后会带来多量的此错误,之无需 能忽略,随后一旦短时间内此错误数量(alarm_count)超过了一定阈值,则说明当前随后趋于稳定也不的问题,比如:

基于 detail_metric 中的 send-net-bytes-ps 实现。

当控制台提供的功能无法满足需求时,亲戚亲戚朋友还无需 尝试通过自行调用 API 来实现。事实上,日志服务控制台的大每种功能也基于同一套 API 实现。

为了分析重启愿因,无需 在告警触发后,回到 internal-diagnostic_log logstore 的查询控制台,将时间切换到告警对应的范围,执行对应的查询句子来定位引起告警的机器(根据原始日志中的 IP 信息),再具体分析相关的愿因。

无需 看得人,延迟最大的文件达到了 72M,为了进行监控,亲戚亲戚朋友无需 对如上句子进行有有另一个 聚合,比如说监控延迟最大的文件,当它超过 1M 时即进行告警。查询句子如下:

作为日志服务的下发 agent,Logtail 目前已运行于上百万的机器,为万级别的应用提供服务,每天下发的数据已达到 PB 级别,哪几种实战的打磨使得 Logtail 在稳定性和性能上都已非常出色,在机器、网络等环境不变的情形下,配置完成后基本不再前要进行任何运维。但对于也不业务,仍旧趋于稳定着对 Logtail 进行情形监控的需求,以应对随着时间变化所带来的不挑选因素。

在通过查询分析功能提取到所前要的数据后,亲戚亲戚朋友无需 对它们进行持续性地监控,当发现满足也不条件(比如超过或低于期望阈值、变化幅度过大等)时,通过短信、邮件、钉钉等渠道进行通知。

欢迎加入钉钉群进行讨论交流

随后先前随后给出过全版操作步骤的示例,此处亲戚亲戚朋友就不再赘述,只给出用于设置报警的查询句子,如下:

前文在介绍 Logtail 情形层次时所提及的大每种情形由 Logtail 主动下发并上报(不饱含用户数据),对于也不量比较大的情形,它会在发送前进行聚合。为了无需 获取并操作哪几种日志,亲戚亲戚朋友首先前要开通服务日志功能,具体的开通步骤无需 参考此文档。 在开通时,假如有一天不勾选操作日志,则此功能全版免费。

内存

随后在 logtail_alarm 中发现了 LOGTAIL_CRASH_STACK_ALARM,则证明一定是代码不足愿因的崩溃。随后只有 LOGTAIL_CRASH_ALARM,除了则前要排查一下是否运维随后也不线程池误杀。

常用情形监控这种 每种里,亲戚亲戚朋友给亲戚亲戚朋友介绍了各层情形中的也不常用场景,以及何如为它们编写查询句子和设置告警。一般来说,直接按照该每种进行设置就无需 满足大每种的监控告警场景的需求,但亲戚亲戚朋友依旧无需 通过自行编写也不特殊的查询句子来满足业务所需。比如希望有有有另一个 大盘来对业务中使用 Logtail 进行下发的文件情形进行直观地展示,这样自定义也不查询句子、挑选所需的图表来构建有有另一个 仪表盘更能满足所需。

理想情形下,文件新增的数据应该在它被更新时就下发并发送到日志服务,但随后网络、CPU 资源限制等愿因,随后会再次老出一定的延迟,但延迟随后超过一定阈值句子,则说明随后趋于稳定也不问题。随后,亲戚亲戚朋友前要对文件下发延迟进行监控。

除了检查以外,亲戚亲戚朋友还前要在发现失败机器时进行通知告警。对于这种 需求,亲戚亲戚朋友无需自行构建一套告警系统和通知渠道,可直接通过以下步骤复用日志服务的告警功能:

设置告警时可使用此表达式: pf > 0 || sf > 0 || r > 1024*1024

如下是 Logtail运行监控 仪表盘的截图。

在开通服务日志的过后 ,会共同创建有有另一个 名为 Logtail下发统计Logtail运行监控 的仪表盘,其饱含高了一系列的预设图表,亲戚亲戚朋友无需 以它们为参考(包括所使用的查询句子、图表配置等),根据自身业务前要,进行相应的修改。

日志服务的告警功能即可满足此需求。基于查询分析句子的结果,设置所需的告警表达式和触发间隔等参数后,即可实现对数据的持续监控,日志服务将在结果满足所设置的表达式时进行告警通知,支持短信、邮件、钉钉、WebHook 等通知最好的最好的办法。

对于此问题,前要根据引起超限的资源类型来区分对待:

logtail_profile 也是服务日志的一每种,它记录了 Logtail 的文件下发统计信息,每 10 分钟上报一次。基于它无需 实现也不对文件下发情形的细节监控,以下亲戚亲戚朋友简单地介绍也不常用场景。

实现上无需 借助机器组相关 API,基本思路如下:

以下亲戚亲戚朋友将分别介绍何如利用 logtail_status 日志来实现对 CPU、内存、网络流量进行监控。出于篇幅,亲戚亲戚朋友将直接给出查询句子,不再赘述也不的步骤。

以下亲戚亲戚朋友简单地介绍几条比较重要以及常用的下发错误(随后愿因和处置最好的最好的办法可参考文档),建议为它们均设置上相应的监控:

在 logtail_alarm 日志中,有有有另一个 alarm_count 字段,它表示在时间窗口(即相邻两次上报之间)内该类型错误的数量,亲戚亲戚朋友无需 基于它进行也不监控。

通过上述的也不场景无需 发现,链路情形再次老出问题的概率很低,随后一旦再次老出问题,将愿因 Logtail 无法下发任何数据。随后,随后有条件句子,亲戚亲戚朋友建议亲戚亲戚朋友均对此情形进行监控。

以下是基于 CLI 的 Python 实现。

以网络协议栈来做有有另一个 随后不太恰当的比喻,过后 所属的三层就像是应用层以下,而数据下发情形则是应用层。在前三层情形正常的情形下,数据下发情形饱含 Logtail 根据用户配置去执行数据下发、数据解析、数据发送等过程中,所产生的统计、错误等信息。

对于链路情形异常的排查,在一定程度等价于 Logtail 心跳异常的排查,无需 参考此文档进行排查。

本文将从多个层次对 Logtail 的情形进行分析,罗列各个层次所前要的也不常用监控场景,共同,亲戚亲戚朋友将介绍何如通过服务日志、查询分析、告警、API 等日志服务的功能,来实现对哪几种场景的监控和告警。

如上图所示,Logtail 情形在大体上可分为另一个层次,一般来说,只有在下层情形正常时,对上层情形的监控才会更有意义。这另一个层次自底向上分别为:

通过上述的介绍无需 发现,通过此功能获取的日志在本质上和用户日志这样区别,随后,亲戚亲戚朋友无需 利用日志服务的查询分析功能从中挖掘亲戚亲戚朋友所前要的信息。

Logtail 线程池的意外崩溃重启有随后会引起数据丢失、数据重复(checkpoint)等问题,随后亲戚亲戚朋友也建议有条件就对此进行监控。

CPU

参考以上代码,根据前要配置合理的阈值(公有云上 Logtail 默认心跳周期为 100s 左右,可适当增大阈值至 1-3 分钟),随后定期执行即可实现对机器组情形的监控。对于定期执行的环境,无需 使用函数计算的定时触发进行构建。

对于也不资源比较紧张的节点,亲戚亲戚朋友只有够让 Logtail 占用这样来太多的宿主机资源以处置影响到业务的正常运行,随后,亲戚亲戚朋友前要对哪几种资源情形进行监控。

事实上,服务日志还提供了不少的字段,前一每种中提及的查询句子并这样全版的覆盖。通过阅读文档,利用哪几种字段,无需 更好地实现亲戚亲戚朋友的需求。

开通时请注意所挑选的存储位置(project),日志服务会将 Logtail 相关的情形信息下发到名为 internal-diagnostic_log 的 logstore(开通时自动创建),其饱含高了多种类型的日志。为了处置混淆,不类式型的日志具有不同的主题(__topic__ 字段)。在本文中,亲戚亲戚朋友仅关注其中的有三种数据,它们的主题分别是 logtail_statuslogtail_profile 以及 logtail_alarm

当下发对应的文件很敏感时,亲戚亲戚朋友无需 为它建立单独监控,当发现任何的解析失败、发送失败以及过大的延迟时,进行告警。查询句子如下:

登录 Logtail 所在机器,查看 Logtail 安装目录(比如 /usr/local/ilogtail)下的 ilogtail.LOG 以及其轮转文件,以关键词 [error](大小写不敏感)进行搜索,随后发现重启时间点付进 有如下日志即说明是资源超限引起的重启。

以下亲戚亲戚朋友简单地举也不使用哪几种日志字段的例子。

除了 logtail_status 以外,亲戚亲戚朋友还无需 通过 logtail_alarm 来每种实现这种 需求(随后资源超限场景无需产生 alarm)。logtail_alarm 也是服务日志的一每种,它记录了 Logtail 上报的错误日志,每 100 秒记录并上报一次,100 秒内重复再次老出的错误类型只记录错误总和,错误消息则随机挑选第十根。

日志服务提供大规模日志实时查询与分析能力(LogSearch/Analytics,简称查询分析),该功能提供了简单的查询语法并复合上了符合 SQL92 标准的分析语法,随后,亲戚亲戚朋友无需 像操作关系数据库那样通过 SQL 来对数据进行查询分析。

日志下发错误类型中的大每种错误都与数据下发情形相关,对错误情形的及时告警和处置利于亲戚亲戚朋友修复日志下发中潜在的错误。

Logtail 的情形监控会使用到日志服务的一系列功能,包括服务日志、查询分析、告警、API 等,也不在开始英语 了了前,亲戚亲戚朋友先简单地概述一下哪几种功能的作用。

效果如下所示:

除链路情形以外,Logtail 自身情形的正常也是保证数据下发正确的必要条件。此处的自身情形正常是指 Logtail 持续运行,未趋于稳定任何的意外退出以及重启等情形,哪几种情形主要由以下几种场景引起(本节不讨论 Logtail 全版退出的情形,它属于链路情形的范畴):

以下亲戚亲戚朋友将分别介绍何如对各个层次的相关情形进行监控以及告警。

在本文中,亲戚亲戚朋友首先按照分层的思想对 Logtail 情形进行了划分,并对各层的情形内容进行了分析和简要介绍。接着,亲戚亲戚朋友自底向上地介绍了各层中也不常用的情形监控场景,并给出了配置它们所前要的代码、查询句子以及操作的步骤,方便亲戚亲戚朋友无需 直接构建出所需的监控和告警。最后,亲戚亲戚朋友简单地说明了一下何如利用预设的仪表盘以及服务日志的也不字段来进行也不自定义的需求配置。

注意: 上述代码的前提是监控的目标为 IP 类型的机器组,对于自定义标识类型的机器组,GetMachineGroup 无法获取到 IP 列表,从而无法判断 ListMachines 返回的 IP 列表是否全版。不过随后机器的 IP 无需趋于稳定变化句子,无需 直接基于 ListMachines 返回的结果进行判断(即忽略代码中的 len(machineStatusList) != len(configMachineIPs))。

随后挑选资源超限暂且异常引起随后已无更好的优化最好的最好的办法,则前要上调 Logtail 所使用的资源限制,无需 参考此文档。

过后 提及的三类日志都拥有有有另一个 project 字段,亲戚亲戚朋友无需 利用它来筛选出所关注的 project,比如说有有另一个 Logtail 节点共同下发了多个 project 下的配置,随后也不 project 下的数据重要程度并都是有点硬高,则无需 使用 not project:xxx 从前的查询句子将它们过滤掉。类式地,也不日志提供了 logstore 字段,无需 帮助亲戚亲戚朋友进一步地缩小关注范围。

数据延迟

上一章所提及的资源超限一定程度上限制了 Logtail 的资源使用,随后资源超限前要持续地达到一定的时间(默认 10 分钟)才会触发重启,这期间 Logtail 会持续地占用资源(內部的资源控制无法全版保证其降低),有随后会影响到业务的正常运行。更糟糕的情形是在每个 10 分钟周期内,90% 的时间占用了这样来太多资源,而 10% 的时间恢复正常,这种 情形下,Logtail 将无需超限重启,随后 90% 的时间内占用了这样来太多资源,影响业务。

随后一开始英语 了了觉得我假如有一天知道何如设置句子,无需 先直接监控所有的错误,随后后续再根据前要进行调整(比如过滤掉也不可忽略的错误),如下:

数据丢失

文档日志下发错误类型记录了 Logtail 所上报的所有错误类型,其中与重启相关的错误有 LOGTAIL_CRASH_ALARM 和 LOGTAIL_CRASH_STACK_ALARM 有有另一个 。简单来说,假如有一天趋于稳定了 worker 线程池异常退出,前者就会上报,随后是随后崩溃引起的退出且生成了 coredump,后者就会被上报。

监控下发错误的查询句子非常简单,如下:

为了监控重启,亲戚亲戚朋友前要使用该日志提供的以下字段进行分析:

在 Logtail 正常运行期间,它的 instance_id 将保持不变,随后,所有来自同有有另一个 节点的日志应该具有相同的实例 ID,但随后趋于稳定了重启句子,一段时间内就会再次老出有有另一个 以上的实例 ID。基于此思路,亲戚亲戚朋友无需 使用 hostname+ip 来标识机器(group by),随后统计机器在一段时间内不同的实例 ID 数量。全版地操作步骤如下:

在本章中,亲戚亲戚朋友将分别介绍另一个层次中的也不常用情形监控,并提供为它们配置监控和告警所前要的代码、查询句子、操作步骤等,让我直接根据本章的内容来进行实际的操作。

数据解蒸发错

类式地,memory 字段表示上报此条日志时 Logtail 最近一次的内存占用情形(MB 为单位)。

在 logtail_profile 中,有有有另一个 read_avg_delay,它会在 Logtail 每次读取文件时被更新,记录下当前已读取 offset 和文件大小之间的差距,即当前未读内容的大小,以此来表示 delay。随后,亲戚亲戚朋友无需 使用如下的查询句子来获取最近时间内各个文件的下发延迟:

至此,亲戚亲戚朋友完成了有有另一个 通过 CLI 访问日志服务 API 来实现对链路情形监控的示例,通过简单地修改,即可实现监控特定机器以及多个机器组等需求。

在默认情形下,Logtail 采用的是 daemon/worker 的双线程池模式,daemon 线程池逻辑简单,一般无需再次老出错误,也不在 worker 线程池挂掉过后 ,它无需 重新拉起新的 worker 线程池。随后,对 Logtail 自身情形的监控也就转化为对重启情形的监控,随后再根据额外的信息来分析重启愿因。

以下将介绍何如使用服务日志中的两类主题日志进行重启情形的监控。

显然,此情形异常的情形下,Logtail 无法正常工作甚至无法访问日志服务,随后,通过服务日志只有实现对此情形的监控。对此,目前比较好的最好的最好的办法是基于 Logtail 心跳实现,当心跳正常时,则链路情形一定正常。

CPU 的监控前要使用到 cpu 字段,它表示上报此条日志时 Logtail 最近一次的 CPU 占用情形(目前仅支持 Linux)。基于它亲戚亲戚朋友无需 实现如下的一系列监控需求: