首页
学习
活动
专区
圈层
工具
发布
技术百科首页 >云原生应用 >如何对云原生应用进行监控?

如何对云原生应用进行监控?

词条归属:云原生应用

云原生应用进行监控可从以下几个方面着手:

一、基础设施层面监控

监控容器的资源使用情况,如CPU使用率、内存占用、磁盘I/O和网络带宽等。例如,使用cAdvisor工具,它可以收集、聚合、处理和导出容器的指标数据。

关注容器的运行状态,包括容器的启动、停止、重启次数,以及容器内进程的健康状况。

  • 节点监控

对云原生应用运行的节点(物理机或虚拟机)进行监控。查看节点的CPU、内存、磁盘和网络等硬件资源的整体使用情况。

监控节点的系统服务状态,如操作系统进程、网络服务等是否正常运行。

二、微服务层面监控

  • 服务性能指标监控

针对每个微服务,监测其关键性能指标,如请求响应时间、吞吐量(每秒处理的请求数量)、错误率等。可以使用Prometheus等监控工具来采集这些指标数据。

跟踪微服务的调用链,了解服务之间的调用关系以及每个调用的性能情况。例如,采用Jaeger或Zipkin等分布式链路追踪工具。

  • 微服务健康检查

定期检查微服务的健康状态,包括服务是否能够正常响应请求、内部逻辑是否正常运行等。可以通过HTTP健康检查端点或者自定义的健康检查机制来实现。

三、应用性能监控(APM)​

  • 代码级监控

在应用代码中嵌入监控探针,收集代码执行过程中的性能数据,如函数的执行时间、数据库查询的执行时间等。

分析代码中的性能瓶颈,以便进行针对性的优化。

  • 事务监控

对于业务流程中的事务进行监控,确保事务的完整性和正确性。例如,在电商应用中,对订单创建、支付、发货等事务进行全程监控。

四、日志监控

  • 集中式日志收集

采用集中式日志收集工具,如Elasticsearch、Fluentd、Kibana(EFK)栈,将云原生应用各个组件产生的日志收集到一个集中的存储库中。

对日志进行分类、索引,以便于查询和分析。

通过分析日志中的关键字、错误信息等,及时发现应用中的问题。例如,当日志中出现大量的“500 Internal Server Error”时,触发告警。

根据日志数据生成报表,用于分析应用的运行趋势和性能状况。

五、监控告警设置

  • 阈值设定

针对监控的各项指标,设定合理的阈值。例如,当CPU使用率超过80%时触发告警。

根据业务需求和系统资源情况,动态调整阈值。

  • 告警方式

选择合适的告警方式,如邮件、短信、即时通讯工具(如Slack、钉钉)等通知相关人员。

确保告警的及时性和准确性,避免误报和漏报。

相关文章
容器云环境,你们如何监控应用运行情况? --JFrog 云原生应用监控实践
引言 自从2018年从Cloud Native Computing Foundation(CNCF)出现以来,您可能已经在使用K8操作系统,随着容器云技术的发展以及落地,提高了企业运维的效率和质量,并且降低了企业运营成本,但同时带来的问题是运维的复杂度和难度,举个例子🌰:由于容器的生命周期短,随时可能飘移到其他物理资源上运行,因此日志的采集和运行的监控很难像传统方式登录到服务器上查看,而运营团队需要了解有价值的数据来进行问题定位以及运营数据分析。 为了更广泛地提供这种可观察性,我们需要提
JFrog杰蛙科技
2020-07-20
2.2K0
如何对产品运营情况进行监控
http://groups.google.com/group/dev4server/browse_thread/thread/8a86bb49a561f312
王亚昌
2018-08-03
2.1K0
谈谈对云原生应用的理解
  微服务后时代是什么?炒得最火的就是Cloud Native。顾名思义,云原生就是面向云设计的应用,自从2013年Matt Stine提出概念后,更多是一套技术体系和方法论,官方定义一直在演变,但核心还是通过基础云平台、云中间件、微服务、容器编排调度、Devops的优化整合,来帮助企业提高研发效率,做到业务更快交付。
王昂
2019-08-04
4.3K0
如何在云原生中监控JVM指标
尽管 Java 的性能和底层编译型语言没有太大区别,但您可能仍需要调整(Java 虚拟机)JVM 性能以满足应用程序的需求。在可扩展性和性能方面,应用程序的需求和要求可能会有所不同,这时需要持续监控您的 JVM 性能(一些关键指标——内存使用、垃圾收集和线程),以相应地对其进行调整。
用户5166556
2023-03-18
2.2K0
如何对进度进行有效的监控与管理?
项目进度控制是项目 管理 工作中的重要一环,但现在的软件开发项目进度失控的例子却屡见不鲜,甚至进度的延迟总是在快到计划结束的时刻暴露出来,然后谁也不知道到底什么时候才能够结束项目。因此,业内流传着这样一句令人心酸的话:“规划规划全是鬼话,计划计划全是空话”。前不久,我就遇到了这样的一个实际项目。   “当进度报告上显示已完成90%时,项目就像遇到了一个黑洞,不断地吞噬着项目组队的时间。你说这是怎么了?”在A 公司工作的一个好友和我谈起时,话语中露出了深深的不解和抱怨。是呀,问题出在哪呢?根据我的经验,这是经典的“上梁不正下梁歪”问题,我认为要想对项目进度有效的监控与管理,必须抓好以下两个方面:   ◆ 项目计划:计划的可行性和可操作性是进度监控的基础;   ◆ 项目进度度量:对项目进度进行科学的度量,才能够获得项目的真实进展情况,并对项目计划做出相应调整。   首先,我们从90%,这个项目完成百分比的来源说起,项目经理在进度报告中写下这个值的时候,他的依据是什么?在这个项目后来的实际情况来看,当时90%的数字是有误的,其实只有50%左右,说明获取这个进度数字时出现了问题。为了更好地理解这个问题,我们来看一个生活中的实际例子:   假设我们驱车从厦门开往福州,在途中我们如何获得进度信息呢?对于熟悉这一路段的司机来说这个问题很简单,可以从窗外的景象来得知已经开到哪里,从而做出正确的估计。但是对于软件开发项目而言,项目团队就像进入了一个全新的征途,就像一个第一次驶过这一路段的司机一样,很难从“窗外的景象”来判断自己的进度。那对于这样的情况,该采用什么方法呢?对于司机而言,他能够通过路边的里程碑这一个简单工具。   来获知自己的进度信息,那么为什么项目团队不为自己设立一些这样的“里程碑”呢?   从这个简单的故事中,我们似乎已经可以得到一些启示,那么现在问题的关键在于如何合理地设立标识项目进度的“里程碑”,接下来我们来看看具体如何操作。   在一个软件开发项目中,需要完成的事务很多也很复杂,其复杂度足以让任何人无法对其工作量进行有效的估计,因此对工作任务进行分解是十分重要,这也是设定里程碑的基础。但如何进行工作任务分解呢?这也许也是困扰许多人的一个问题。其实工作任务分解可以从两个方面获得帮助:   ◆ 软件开发生命周期:不管你打算采用什么样的软件开发生命周期模型,它都可以帮助你将整个软件开发项目进行阶段性的划分,而这些阶段就可以做你计划中很重要的里程碑。   ◆ 软件开发需求:软件开发生命周期只给你的项目计划提供了一个框架,而软件开发需求才是其中的血肉,因此软件开发需求的整理与规格化,是细化项目计划的基础。也就是说,在制定项目计划时,应该在你选择的软件开发生命周期模型的框架下,结合软件开发需求来细分任务和设定里程碑。   回顾在这个项目中,他们考虑到项目的复杂性,采用了其熟悉的瀑布型(软件开发生命周期),并且在制定计划时,项目经理认真参考了许多经验值,将2个月的时间按照经验值中的百分比给需求分析、系统设计、编码实现、系统测试、部署交付五个阶段分别安排了时间。并且根据软件需求说明书的内容,列出了软件模块,   并根据每个模块细化了系统设计和编码实现的进度安排。一切看起来都很正常,但是为什么还是没有效果呢?我从他们对细节的回顾中发现了一些问题:   ◆ 所有的项目计划均是由项目经理的估计值制定的,也就是说项目经理包办了整个项目计划的制定工作;   ◆ 在项目计划中只是简单地在每个阶段的结束时间上标上了一个里程碑符号;   ◆ 进度报告中的项目完成百分比,是直接通过“已经历的时间(2 个月)”计算得到的;   ◆ 项目过程中,需求在变化,但项目计划却没有跟进;   ◆ 项目延迟的主要原因在于两个方面:项目需求增加,以及系统设计和编码实现的时间都超过了原先的计划。   这一切就是典型的项目进度失控的直接诱因,相信这些项目中都能够发现以上问题的影子。那么如果避免或者解决这些问题呢?在我的资料库中,包括以下几个针对此症的“药方”,在我的实践中收到了良好效果,你也不妨试一试。 第一个药方是以面向客户的角度整理需求。我看到许多软件项目开发团队进入了系统设计和编码实现阶段之后,在整个开发团队之间的交流里充满着计算机领域的东西,却难得见到问题领域的东西,这样很容易造成软件开发与客户需求的脱节。因此,从一开始就以面向客户的角度来整理需求,让这些需求的实现成为项目团队共同的目标,这将容易使项目始终保持正确的方向。UML中的Use Case、特征驱动开发中的Feature、极限编程中的UserStory都是很好的办法,以这些方式组织的需求,作为项目计划中的血肉,将更有利于进度的安排与控制。 第二个药方是项目团队共同完成项目计划。项目计划的一个很重要的前提是项目估算,项目估算最大的基础是经验值,而软件工程书籍中的经验值反应的只
PM吃瓜
2020-07-01
2.7K0
点击加载更多
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
领券