CN111782345A - 容器云平台日志收集及分析告警方法 - Google Patents
容器云平台日志收集及分析告警方法 Download PDFInfo
- Publication number
- CN111782345A CN111782345A CN202010644149.9A CN202010644149A CN111782345A CN 111782345 A CN111782345 A CN 111782345A CN 202010644149 A CN202010644149 A CN 202010644149A CN 111782345 A CN111782345 A CN 111782345A
- Authority
- CN
- China
- Prior art keywords
- log
- container
- alarm
- cloud platform
- fault
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
- G06F11/324—Display of status information
- G06F11/327—Alarm or error message display
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45595—Network integration; Enabling network access in virtual machine instances
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Debugging And Monitoring (AREA)
Abstract
本发明涉及一种容器云平台日志收集及分析告警方法,该方法基于Kubernetes容器云平台,编写Elasticseach配置文件,通过有状态副本集StatefulSets部署Elasticseach,使用存储类Storageclass进行日志存储的挂载实现对集群日志、容器日志和应用日志的收集;对日志数据进行处理并通过数据接口传送至容器云平台,容器云平台依据所建立的日志特征库对容器日志和应用日志做关联分析,当达到告警条件时,在前端界面展示报表的功能、告警通知和策略配置;该方法可及时发送报警信息给报警接收人和用户,简化了日志分析的难度,降低了***运维成本,提高了开发运维人员对日志的可读性。
Description
(一)、技术领域:
本发明涉及一种云平台日志收集及分析告警方法,特别涉及一种容器云平台日志收集及分析告警方法。
(二)、背景技术:
Kubernetes简称K8s,已经成为容器编排调度的实际标准,Docker官方和Mesos都已经支持Kubernetes,Kubernetes也已经在大量的企业中落地,一些重量级的平台客户如GitHub、eBay和彭博社等已宣布将服务迁移到Kubernetes上。K8s的广泛应用,使其相应的功能需求开发变得日益重要,如应用监控、日志分析等,这些功能均影响着每一个项目在云计算中的落地。
应用容器化的快速发展,使得在容器平台中产生了大量的需求分析、日志整理,以满足开发运维人员在使用容器化技术进行作业时的需求。但是传统的基于Kubernetes集群的管理和运维是一项繁琐复杂的工作,对海量的容器云平台日志数据收集及分析需要一定的时间成本和技术门槛。传统的容器化平台的日志分析通常只关注项目应用的容器日志展示,往往忽略容器日志与应用日志之间的关联性,面对海量的日志数据,开发运维人员很难在第一时间获取有用的数据,以解决生产测试环境中的各种问题。
(三)、发明内容:
本发明要解决的技术问题是:提供一种容器云平台日志收集及分析告警方法,容器云平台日志收集方法可对集群日志、容器日志和应用日志进行收集,容器云平台日志分析告警方法可及时发送报警信息给运维管理员﹑项目开发人员和平台管理员及用户,简化了日志分析的难度,降低了***运维成本,提高了开发运维人员对日志的可读性。
本发明的技术方案:
一种容器云平台日志收集方法,基于Kubernetes容器云平台,含有以下步骤:
步骤1.1、编写Elasticseach(基于Lucene的搜索服务器)配置文件,通过有状态副本集StatefulSets部署Elasticseach,使用存储类Storageclass进行日志存储的挂载,存储类Storageclass生成PVC (Persistent Volume Claim,持久化存储声明),Elasticseach生成域名地址便于引用;
步骤1.2、集群日志的收集:编写Filebeat(使用Golang实现的轻量型日志采集器)的配置文件,将该配置文件部署到守护进程集DaemonSet,收集每一个节点的/var/log/messages日志数据;
步骤1.3、容器日志的收集:首先编写eventrouter(路由和筛选事件的库)容器配置文件,挂载/data/log/eventrouter目录;然后启动一个Filebeat容器挂载/data/log/eventrouter目录,使用Filebeat收集该/data/log/eventrouter目录下的日志数据;
步骤1.4、应用日志的收集:在应用部署容器中,另启动一个Filebeat容器挂载应用日志目录,使用Filebeat收集应用项目目录下的日志数据。
步骤1.1中,PVC为基于nfs和cephfs等类的PVC。
一种容器云平台日志分析告警方法,首先执行上述容器云平台日志收集方法,然后进行以下步骤:
步骤2、对收集到的日志数据进行处理;
步骤3、将处理过的日志数据通过数据接口传送至容器云平台;
步骤4、建立日志特征库;
步骤5、容器云平台依据日志特征库对容器日志和应用日志做关联分析;
步骤6、关联分析结果达到告警条件时,在前端界面展示报表的功能(如报表的生成、导入和导出)、告警通知和策略配置。
步骤2含有以下步骤:
步骤2.1、配置多个Logstash(Logstash是一个应用程序日志、事件的传输、处理、管理和搜索的平台)节点并行,将集群日志、容器日志和应用日志上传至Logstash;
步骤2.2、Logstash对集群日志、容器日志和应用日志的数据分别进行过滤处理,并将过滤处理后的日志数据上传至Elasticseach,Elasticseach对过滤处理后的日志数据进行索引和存储。
步骤2.2具体为:
步骤2.2.1,编写Logstash配置文件,对收集来的集群日志、容器日志和应用日志的数据分别进行清洗处理,形成规范化的日志记录格式;规范化字段包括日志时间戳、pod ip地址、pod名称、关联标签label、类型、message、error类型等;
步骤2.2.2,Elasticseach对外提供http api接口,用户可以根据自己的需求,对清洗好的日志数据进行搜索查询,包括设定关键词(比如关联标签label、时间、error类型等),并快速定位到相对应的日志所属应用及***上。
步骤3中的数据接口为http api接口。
步骤4中,为实现对日志类型的精准定位,对日志类别进行故障分级,建立日志特征库,日志特征库含有一级故障日志特征库、二级故障日志特征库和三级故障日志特征库;
一级故障日志,主要是指kubernetes组件服务故障及集群故障日志,包括:节点状态NotReady、关键组件Unhealthy;
二级故障日志,主要是指pod状态故障日志,包括:一直处于Pending、一直处于Waiting、一直处于ContainerCreating、处于ImagePullBackOff、处于CrashLoopBackOff、处于Error、一直处于Terminating和处于Unknown;
***检测到event事件报警关键词后,输出告警日志数据信息,并在警告信息栏给出故障等级、具体原因及处理反馈:
(1)涉及关键词 %Pending% :意味着Pod的YAML文件已经提交给Kubernetes,API对象已经被创建并保存在Etcd当中。但是,这个Pod里有些容器因为某种原因而不能被顺利创建,比如调度不成功。可能原因是:资源不足(集群内所有的Node都不满足该Pod请求的CPU、内存和GPU等资源);HostPort已被占用(通常推荐使用Service对外开放服务端口)。
(2)涉及关键词 %Waiting% 或 %ContainerCreating% :根据日志输出数据信息,自动匹配对应以下原因:
a. 镜像拉取失败,比如镜像地址配置错误、拉取不了国外镜像源(gcr.io)、私有镜像密钥配置错误、镜像太大导致拉取超时(可以适当调整kubelet的-image-pull-progress-deadline和-runtime-request-timeout选项)等。
b. CNI网络错误,一般需要检查CNI网络插件的配置,比如:无法配置Pod网络、无法分配IP地址。
c. 容器无法启动,需要检查是否打包了正确的镜像或者是否配置了正确的容器参数。
d. Failed create pod sandbox,查看kubelet日志,原因可能是磁盘坏道(input/output error)。
(3)涉及关键词 %ImagePullBackOff% ,意味着镜像名称配置错误或私有镜像的密钥配置错误导致。
(4)涉及关键词 %CrashLoopBackOff% ,意味着容器曾经启动了,但又异常退出。原因可能是,容器进程退出、健康检查失败退出等。
(5)涉及关键词 %Error% ,说明Pod启动过程中发生了错误。常见的原因是:依赖的ConfigMap、Secret或PV等不存在;请求的资源超过了管理员设置的限制,比如超过了LimitRange等;违反集群的安全策略,比如违反了PodSecurityPolicy等;容器无法操作集群内的资源,比如开启RDAC后,需要为ServiceAccount配置角色绑定。
(6)涉及关键词 %Terminating% 或 %Unknown% 状态,通常是由于Node失联而没有删除其上正在运行的Pod。Unknown这个异常状态意味着Pod的状态不能持续地被kubelet汇报给kube-apiserver,这很有可能是主从节点(Master和 Kubelet)间的通信出现了问题。
三级故障日志:主要针对业务日志,当业务日志中出现ERROR条数超过预设值时,触发三级故障报警机制,ERROR状态通常意味着上线业务出现大的bug,需要开发人员进行有针对性的解决。
使用所述日志特征库对容器日志和应用日志筛查后,会自动生成故障列表,容器云平台根据故障等级发送报警信息给报警接收人和用户,报警接收人可以在平台上通过时间戳或精确值进行全文检索,获取详细日志信息。
报警接收人分为三种:运维管理员﹑项目开发人员和平台管理员;平台管理员功能权限为创建(姓名、电话号码、邮箱)、修改、删除,分配告警级别对应的告警接收人,并获取告警任务的抄送信息。
当一级故障告警触发时,容器云平台以短信或者邮件的形式通知运维管理员,并抄送给平台管理员;
当二级故障告警触发时,容器云平台以短信或者邮件的形式通知项目开发人员,并抄送给运维管理员和平台管理员;
当三级故障告警触发时,由于上线业务日志的不断更新,其报警及接收采用服务器后台执行报警脚本的方式,通常当ERROR条数超过20条时,容器云平台会立即第一时间发出第一个报警,以短信或者邮件的形式通知项目开发人员并抄送给平台管理员;然后根据脚本中的sleep进行报警频率调整,确保监控报警的时效性。
用户在容器云平台上的预览界面可实时查看错误日志,方便用户及时对业务故障形式进行辨别,更快做出解决方案,保持业务上线的稳定性。
本发明的有益效果:
1、本发明对集群日志、容器日志和应用日志进行收集,容器云平台依据日志特征库对容器日志和应用日志做关联分析和展示,并根据故障等级及时发送报警信息给运维管理员﹑项目开发人员和平台管理员及用户,开发运维人员可以在第一时间获取有用的数据,及时解决生产测试环境中出现的各种问题。
2、本发明建立了日志特征库,对日志类别进行了故障分级,实现了容器云平台的半自动运维及管理,简化了日志分析的难度,降低了日志数据分析及***运维成本。
3、本发明对集群日志、容器日志和应用日志数据进行全面收集,容器云平台依据日志特征库对日志做关联分析和展示,提高了开发运维人员对日志的可读性。
(四)、具体实施方式:
容器云平台日志收集方法基于Kubernetes容器云平台,该日志收集方法含有以下步骤:
步骤1.1、编写Elasticseach(基于Lucene的搜索服务器)配置文件,通过有状态副本集StatefulSets部署Elasticseach,使用存储类Storageclass进行日志存储的挂载,存储类Storageclass生成PVC (Persistent Volume Claim,持久化存储声明),Elasticseach生成域名地址便于引用;
步骤1.2、集群日志的收集:编写Filebeat(使用Golang实现的轻量型日志采集器)的配置文件,将该配置文件部署到守护进程集DaemonSet,收集每一个节点的/var/log/messages日志数据;
步骤1.3、容器日志的收集:首先编写eventrouter(路由和筛选事件的库)容器配置文件,挂载/data/log/eventrouter目录;然后启动一个Filebeat容器挂载/data/log/eventrouter目录,使用Filebeat收集该/data/log/eventrouter目录下的日志数据;
步骤1.4、应用日志的收集:在应用部署容器中,另启动一个Filebeat容器挂载应用日志目录,使用Filebeat收集应用项目目录下的日志数据。
步骤1.1中,PVC为基于nfs和cephfs等类的PVC。
容器云平台日志分析告警方法含有以下步骤:
步骤1、执行上述容器云平台日志收集方法;
步骤2、对收集到的日志数据进行处理;
步骤3、将处理过的日志数据通过数据接口传送至容器云平台;
步骤4、建立日志特征库;
步骤5、容器云平台依据日志特征库对容器日志和应用日志做关联分析;
步骤6、关联分析结果达到告警条件时,在前端界面展示报表的功能(如报表的生成、导入和导出)、告警通知和策略配置。
步骤2含有以下步骤:
步骤2.1、配置多个Logstash(Logstash是一个应用程序日志、事件的传输、处理、管理和搜索的平台)节点并行,将集群日志、容器日志和应用日志上传至Logstash;
步骤2.2、Logstash对集群日志、容器日志和应用日志的数据分别进行过滤处理,并将过滤处理后的日志数据上传至Elasticseach,Elasticseach对过滤处理后的日志数据进行索引和存储。
步骤2.2具体为:
步骤2.2.1,编写Logstash配置文件,对收集来的集群日志、容器日志和应用日志的数据分别进行清洗处理,形成规范化的日志记录格式;规范化字段包括日志时间戳、pod ip地址、pod名称、关联标签label、类型、message、error类型等;
步骤2.2.2,Elasticseach对外提供http api接口,用户可以根据自己的需求,对清洗好的日志数据进行搜索查询,包括设定关键词(比如关联标签label、时间、error类型等),并快速定位到相对应的日志所属应用及***上。
步骤3中的数据接口为http api接口。
步骤4中,为实现对日志类型的精准定位,对日志类别进行故障分级,建立日志特征库,日志特征库含有一级故障日志特征库、二级故障日志特征库和三级故障日志特征库;
一级故障日志,主要是指kubernetes组件服务故障及集群故障日志,包括:节点状态NotReady、关键组件Unhealthy;
二级故障日志,主要是指pod状态故障日志,包括:一直处于Pending、一直处于Waiting、一直处于ContainerCreating、处于ImagePullBackOff、处于CrashLoopBackOff、处于Error、一直处于Terminating和处于Unknown;
***检测到event事件报警关键词后,输出告警日志数据信息,并在警告信息栏给出故障等级、具体原因及处理反馈:
(1)涉及关键词 %Pending% :意味着Pod的YAML文件已经提交给Kubernetes,API对象已经被创建并保存在Etcd当中。但是,这个Pod里有些容器因为某种原因而不能被顺利创建,比如调度不成功。可能原因是:资源不足(集群内所有的Node都不满足该Pod请求的CPU、内存和GPU等资源);HostPort已被占用(通常推荐使用Service对外开放服务端口)。
(2)涉及关键词 %Waiting% 或 %ContainerCreating% :根据日志输出数据信息,自动匹配对应以下原因:
a. 镜像拉取失败,比如镜像地址配置错误、拉取不了国外镜像源(gcr.io)、私有镜像密钥配置错误、镜像太大导致拉取超时(可以适当调整kubelet的-image-pull-progress-deadline和-runtime-request-timeout选项)等。
. CNI网络错误,一般需要检查CNI网络插件的配置,比如:无法配置Pod网络、无法分配IP地址。
. 容器无法启动,需要检查是否打包了正确的镜像或者是否配置了正确的容器参数。
. Failed create pod sandbox,查看kubelet日志,原因可能是磁盘坏道(input/output error)。
(3)涉及关键词 % ImagePullBackOff% ,意味着镜像名称配置错误或私有镜像的密钥配置错误导致。
(4)涉及关键词 % CrashLoopBackOff% ,意味着容器曾经启动了,但又异常退出。原因可能是,容器进程退出、健康检查失败退出等。
(5)涉及关键词 %Error% ,说明Pod启动过程中发生了错误。常见的原因是:依赖的ConfigMap、Secret或PV等不存在;请求的资源超过了管理员设置的限制,比如超过了LimitRange等;违反集群的安全策略,比如违反了PodSecurityPolicy等;容器无法操作集群内的资源,比如开启RDAC后,需要为ServiceAccount配置角色绑定。
(6)涉及关键词 %Terminating% 或 %Unknown% 状态,通常是由于Node失联而没有删除其上正在运行的Pod。Unknown这个异常状态意味着Pod的状态不能持续地被kubelet汇报给kube-apiserver,这很有可能是主从节点(Master 和 Kubelet)间的通信出现了问题。
三级故障日志:主要针对业务日志,当业务日志中出现ERROR条数超过预设值时,触发三级故障报警机制,ERROR状态通常意味着上线业务出现大的bug,需要开发人员进行有针对性的解决。
使用所述日志特征库对容器日志和应用日志筛查后,会自动生成故障列表,容器云平台根据故障等级发送报警信息给报警接收人和用户,报警接收人可以在平台上通过时间戳或精确值进行全文检索,获取详细日志信息。
报警接收人分为三种:运维管理员﹑项目开发人员和平台管理员;平台管理员功能权限为创建(姓名、电话号码、邮箱)、修改、删除,分配告警级别对应的告警接收人,并获取告警任务的抄送信息。
当一级故障告警触发时,容器云平台以短信或者邮件的形式通知运维管理员,并抄送给平台管理员;
当二级故障告警触发时,容器云平台以短信或者邮件的形式通知项目开发人员,并抄送给运维管理员和平台管理员;
当三级故障告警触发时,由于上线业务日志的不断更新,其报警及接收采用服务器后台执行报警脚本的方式,通常当ERROR条数超过20条时,容器云平台会立即第一时间发出第一个报警,以短信或者邮件的形式通知项目开发人员并抄送给平台管理员;然后根据脚本中的sleep进行报警频率调整,确保监控报警的时效性。
用户在容器云平台上的预览界面可实时查看错误日志,方便用户及时对业务故障形式进行辨别,更快做出解决方案,保持业务上线的稳定性。
Claims (9)
1.一种容器云平台日志收集方法,其特征是:基于Kubernetes容器云平台,含有以下步骤:
步骤1.1、编写Elasticseach配置文件,通过有状态副本集StatefulSets部署Elasticseach,使用存储类Storageclass进行日志存储的挂载,存储类Storageclass生成PVC,Elasticseach生成域名地址;
步骤1.2、集群日志的收集:编写Filebeat的配置文件,将该配置文件部署到守护进程集DaemonSet,收集每一个节点的/var/log/messages日志数据;
步骤1.3、容器日志的收集:首先编写eventrouter容器配置文件,挂载/data/log/eventrouter目录;然后启动一个Filebeat容器挂载/data/log/eventrouter目录,使用Filebeat收集该/data/log/eventrouter目录下的日志数据;
步骤1.4、应用日志的收集:在应用部署容器中,另启动一个Filebeat容器挂载应用日志目录,使用Filebeat收集应用项目目录下的日志数据。
2.根据权利要求1所述的容器云平台日志收集方法,其特征是:所述步骤1.1中,PVC为基于nfs和cephfs的PVC。
3.一种含有权利要求1或2所述的容器云平台日志收集方法的容器云平台日志分析告警方法,其特征是:首先执行所述容器云平台日志收集方法,然后进行以下步骤:
步骤2、对收集到的日志数据进行处理;
步骤3、将处理过的日志数据通过数据接口传送至容器云平台;
步骤4、建立日志特征库;
步骤5、容器云平台依据日志特征库对容器日志和应用日志做关联分析;
步骤6、关联分析结果达到告警条件时,在前端界面展示报表的功能、告警通知和策略配置。
4.根据权利要求3所述的容器云平台日志分析告警方法,其特征是:所述步骤2含有以下步骤:
步骤2.1、配置多个Logstash节点并行,将集群日志、容器日志和应用日志上传至Logstash;
步骤2.2、Logstash对集群日志、容器日志和应用日志的数据分别进行过滤处理,并将过滤处理后的日志数据上传至Elasticseach,Elasticseach对过滤处理后的日志数据进行索引和存储。
5.根据权利要求4所述的容器云平台日志分析告警方法,其特征是:所述步骤2.2具体为:
步骤2.2.1,编写Logstash配置文件,对收集来的集群日志、容器日志和应用日志的数据分别进行清洗处理,形成规范化的日志记录格式;
步骤2.2.2,Elasticseach对外提供http api接口,用户根据自己的需求,对清洗好的日志数据进行搜索查询,并快速定位到相对应的日志所属应用及***上。
6.根据权利要求3所述的容器云平台日志分析告警方法,其特征是:所述步骤3中的数据接口为http api接口。
7.根据权利要求3所述的容器云平台日志分析告警方法,其特征是:所述步骤4中,对日志类别进行故障分级,建立日志特征库,日志特征库含有一级故障日志特征库、二级故障日志特征库和三级故障日志特征库;
一级故障日志,是指kubernetes组件服务故障及集群故障日志;
二级故障日志,是指pod状态故障日志;
三级故障日志:当业务日志中出现ERROR条数超过预设值时,触发三级故障报警机制。
8.根据权利要求7所述的容器云平台日志分析告警方法,其特征是:使用所述日志特征库对容器日志和应用日志筛查后,自动生成故障列表,容器云平台根据故障等级发送报警信息给报警接收人和用户,报警接收人在平台上通过时间戳或精确值进行全文检索,获取详细日志信息。
9.根据权利要求8所述的容器云平台日志分析告警方法,其特征是:所述
报警接收人分为三种:运维管理员﹑项目开发人员和平台管理员;
当一级故障告警触发时,容器云平台以短信或者邮件的形式通知运维管理员,并抄送给平台管理员;
当二级故障告警触发时,容器云平台以短信或者邮件的形式通知项目开发人员,并抄送给运维管理员和平台管理员;
当三级故障告警触发时,报警及接收采用服务器后台执行报警脚本的方式,当ERROR条数超过20条时,容器云平台立即发出第一个报警,以短信或者邮件的形式通知项目开发人员并抄送给平台管理员。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010644149.9A CN111782345B (zh) | 2020-07-07 | 2020-07-07 | 容器云平台日志收集及分析告警方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010644149.9A CN111782345B (zh) | 2020-07-07 | 2020-07-07 | 容器云平台日志收集及分析告警方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111782345A true CN111782345A (zh) | 2020-10-16 |
CN111782345B CN111782345B (zh) | 2022-10-28 |
Family
ID=72757862
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010644149.9A Active CN111782345B (zh) | 2020-07-07 | 2020-07-07 | 容器云平台日志收集及分析告警方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111782345B (zh) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112527459A (zh) * | 2020-12-16 | 2021-03-19 | 新浪网技术(中国)有限公司 | 一种基于Kubernetes集群的日志分析方法及装置 |
CN113535519A (zh) * | 2021-07-27 | 2021-10-22 | 浪潮软件科技有限公司 | 一种监控告警方法 |
CN114500249A (zh) * | 2022-04-18 | 2022-05-13 | 中国工商银行股份有限公司 | 一种根因定位方法和装置 |
US11860752B2 (en) * | 2021-12-15 | 2024-01-02 | Bionic Stork Ltd. | Agentless system and method for discovering and inspecting applications and services in compute environments |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2009054847A1 (en) * | 2007-10-23 | 2009-04-30 | Qualcomm Incorporated | Management of failures in wireless field devices |
US20170111241A1 (en) * | 2015-10-19 | 2017-04-20 | Draios Inc. | Automated service-oriented performance management |
CN108572907A (zh) * | 2018-01-25 | 2018-09-25 | 北京金山云网络技术有限公司 | 一种告警方法、装置、电子设备及计算机可读存储介质 |
CN109245931A (zh) * | 2018-09-19 | 2019-01-18 | 四川长虹电器股份有限公司 | 基于kubernetes的容器云平台的日志管理和监控报警的实现方法 |
CN110545195A (zh) * | 2018-05-29 | 2019-12-06 | 华为技术有限公司 | 网络故障分析方法及装置 |
-
2020
- 2020-07-07 CN CN202010644149.9A patent/CN111782345B/zh active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2009054847A1 (en) * | 2007-10-23 | 2009-04-30 | Qualcomm Incorporated | Management of failures in wireless field devices |
US20170111241A1 (en) * | 2015-10-19 | 2017-04-20 | Draios Inc. | Automated service-oriented performance management |
CN108572907A (zh) * | 2018-01-25 | 2018-09-25 | 北京金山云网络技术有限公司 | 一种告警方法、装置、电子设备及计算机可读存储介质 |
CN110545195A (zh) * | 2018-05-29 | 2019-12-06 | 华为技术有限公司 | 网络故障分析方法及装置 |
CN109245931A (zh) * | 2018-09-19 | 2019-01-18 | 四川长虹电器股份有限公司 | 基于kubernetes的容器云平台的日志管理和监控报警的实现方法 |
Non-Patent Citations (7)
Title |
---|
D V UDAY: "An Analysis of Health System Log Files using ELK Stack", 《2019 4TH INTERNATIONAL CONFERENCE ON RECENT TRENDS ON ELECTRONICS, INFORMATION, COMMUNICATION & TECHNOLOGY (RTEICT)》 * |
D V UDAY: "An Analysis of Health System Log Files using ELK Stack", 《2019 4TH INTERNATIONAL CONFERENCE ON RECENT TRENDS ON ELECTRONICS, INFORMATION, COMMUNICATION & TECHNOLOGY (RTEICT)》, 2 March 2020 (2020-03-02) * |
罗学贯: "基于ELK的Web日志分析***的设计与实现", 《中国优秀硕士学位论文全文数据库信息科技辑》 * |
罗学贯: "基于ELK的Web日志分析***的设计与实现", 《中国优秀硕士学位论文全文数据库信息科技辑》, vol. 2019, no. 5, 15 May 2019 (2019-05-15) * |
翟雅荣: "基于Filebeat自动收集Kubernetes日志的分析***", 《计算机***应用》, vol. 27, no. 9, 16 August 2018 (2018-08-16), pages 81 - 86 * |
阮晓龙等: "基于ELK+Kafka的智慧运维大数据分析平台研究与实现", 《软件导刊》 * |
阮晓龙等: "基于ELK+Kafka的智慧运维大数据分析平台研究与实现", 《软件导刊》, no. 06, 15 June 2020 (2020-06-15) * |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112527459A (zh) * | 2020-12-16 | 2021-03-19 | 新浪网技术(中国)有限公司 | 一种基于Kubernetes集群的日志分析方法及装置 |
CN112527459B (zh) * | 2020-12-16 | 2024-03-26 | 新浪技术(中国)有限公司 | 一种基于Kubernetes集群的日志分析方法及装置 |
CN113535519A (zh) * | 2021-07-27 | 2021-10-22 | 浪潮软件科技有限公司 | 一种监控告警方法 |
CN113535519B (zh) * | 2021-07-27 | 2024-01-30 | 浪潮软件科技有限公司 | 一种监控告警方法 |
US11860752B2 (en) * | 2021-12-15 | 2024-01-02 | Bionic Stork Ltd. | Agentless system and method for discovering and inspecting applications and services in compute environments |
CN114500249A (zh) * | 2022-04-18 | 2022-05-13 | 中国工商银行股份有限公司 | 一种根因定位方法和装置 |
CN114500249B (zh) * | 2022-04-18 | 2022-07-08 | 中国工商银行股份有限公司 | 一种根因定位方法和装置 |
Also Published As
Publication number | Publication date |
---|---|
CN111782345B (zh) | 2022-10-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN111782345B (zh) | 容器云平台日志收集及分析告警方法 | |
US10122575B2 (en) | Log collection, structuring and processing | |
US9940373B2 (en) | Method and system for implementing an operating system hook in a log analytics system | |
US10810074B2 (en) | Unified error monitoring, alerting, and debugging of distributed systems | |
US20110314148A1 (en) | Log collection, structuring and processing | |
US20120246303A1 (en) | Log collection, structuring and processing | |
US8631283B1 (en) | Monitoring and automated recovery of data instances | |
US8032489B2 (en) | Log collection, structuring and processing | |
CA2629279C (en) | Log collection, structuring and processing | |
US8863224B2 (en) | System and method of managing data protection resources | |
CN111046011B (zh) | 日志收集方法、***、装置、电子设备及可读存储介质 | |
US9411969B2 (en) | System and method of assessing data protection status of data protection resources | |
CN106407030A (zh) | 一种存储集群***故障处理方法及*** | |
CN110209518A (zh) | 一种多数据源日志数据集中收集存储方法及装置 | |
US20200293310A1 (en) | Software development tool integration and monitoring | |
WO2019047070A1 (zh) | 一种数据库维护方法及其*** | |
US9922539B1 (en) | System and method of telecommunication network infrastructure alarms queuing and multi-threading | |
CN108173711B (zh) | 企业内部***数据交换监控方法 | |
CN108156061B (zh) | esb监控服务平台 | |
JP4102592B2 (ja) | 集約機能付障害情報通知システム及びマシンを集約機能付障害情報通知手段として機能させるためのプログラム | |
US11805146B2 (en) | System and method for detection promotion | |
WO2014196982A1 (en) | Identifying log messages | |
WO2019241199A1 (en) | System and method for predictive maintenance of networked devices | |
CN112685486B (zh) | 数据库集群的数据管理方法、装置、电子设备及存储介质 | |
CN113821412A (zh) | 一种设备运维管理方法及装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |