SpringBoot服务监控

SpringBoot服务监控分为客户端和服务端,即服务端是监控方,客户端为被监控方。

例如需要对线上的SpringBoot服务project-A进行监控,则project-A 为客户端。而监控的服务project-B则为服务端。客户端将被监控的数据信息发送到服务端进行UI展示。

客户端project-A依赖的jar:

     <!--应用监控-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>

        <dependency>
            <groupId>de.codecentric</groupId>
            <artifactId>spring-boot-admin-starter-client</artifactId>
            <version>1.5.6</version>
        </dependency>

 在配置文件中添加配置:

spring.application.name=project-A
server.port=5566
#将该服务的各指标监控信息在app-monitor服务上展示
spring.boot.admin.url=http://xxxx.xxxx.xxx.com:8056/app-monitor
#关闭安全校验
management.security.enabled=false

服务端project-B依赖的jar:

      <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>
        <dependency>
            <groupId>de.codecentric</groupId>
            <artifactId>spring-boot-admin-server</artifactId>
            <version>1.5.6</version>
        </dependency>
        <dependency>
            <groupId>de.codecentric</groupId>
            <artifactId>spring-boot-admin-server-ui</artifactId>
            <version>1.5.6</version>
        </dependency>

 配置文件的配置:

spring.application.name=app-monitor
server.port=8056
server.context-path=/app-monitor

  然后启动这两个服务,打开project-B服务的url

http://xxxx.xxxx.xxx.com:8056/app-monitor看到如下的界面:

                                                                                                                                     

原文地址:https://www.cnblogs.com/wrong5566/p/9548731.html

时间: 2024-11-02 13:50:29

SpringBoot服务监控的相关文章

Spring Boot 服务监控,健康检查,线程信息,JVM堆信息,指标收集,运行情况监控等!

前言 去年我们项目做了微服务1.0的架构转型,但是服务监控这块却没有跟上.这不,最近我就被分配了要将我们核心的微服务应用全部监控起来的任务.我们的微服务应用都是SpringBoot 应用,因此就自然而然的想到了借助Spring Boot 的Actuator 模块. 本篇是我在完成这个工单之后,对Spring Boot Actuator模块 学习应用的总结.在本篇文章中,你可以学习到: 1.Spring Boot Actuator 的快速使用入门2.Spring Boot Actuator 的一些

微服务监控和报警(二)-Prometheus简介及环境搭建

1.Prometheus简介 Prometheus是具有活跃生态系统的开源系统监视和警报工具包.下图是Prometheus的体系结构及其某些生态系统组件.最核心的位置就是Prometheus server,主要的作用就是根据我们的配置去用于收集和存储时间序列数据.Service discovery服务的发现,通过Service discovery,Prometheus server就会知道去哪里采集数据,有两种方式,一种是静态的,通过文件去配:另外一种是动态的,可以通过zookeeper或者其他

后端线上服务监控与报警方案

一.背景 1.上线期间服务稳定性观察较困难 一个功能上线后,其实研发心里根本没底儿,不知道这个功能上线以后是不是真的没问题:有经验一些老同学还知道直接登录线上机器去tail -f php.error.log,但是对于新同学来说,基本就只能等着被通知服务故障. 退一步说,即便是能去线上去tail -f查看错误日志,但是线上是多集群部署的,服务器都特别多,研发不可能在每一台机器上都能看到日志:即便是有日志收集机器,也得在各个集群下分别tail -f,定位问题很不方便! 再退一步说,即便是在线上机器看

二、业务服务监控

二.业务服务监控 1.文件内容差异对比方法 difflib模块实现文件内容差异对比,difflib作为python的标准库模块,无需安装,作用是对比文本之间的差异,且支持输出可读性比较强的HTML文档,与linux下的diff命令相似.我们可以使用difflib对比代码,配置文件的差别,在版本控制方面是非常有用. (1)示例:两个字符串的差异对比 通过使用difflib模块实现两个字符串的差异对比,然后以版本控制风格进行输出 [/root/text1_lines.py] #! /usr/bin/

利用 perf4j 做服务监控

perf4j 是什么 -------------------- perf4j 是一套简单的服务监控框架,可以用来做一些系统常需要的监控,比如实时系统吞吐量,系统响应时间 perf4j生成监控图表 ---------------------------- pef4j可以生成的图表支持 Mean, Min, Max, StdDev, Count and TPS Mean 平均响应时间 Min 最小响应时间 Max 最大响应时间 Count 总数统计 TPS  吞吐量 监控图表样式如下 perf4j

微服务监控案例之一

     首先,您需要了解什么是微服务架构设计,同时了解相关微服务与Docker介绍, 微服务架构的本质,是把整体的业务拆分成很多有特定明确功能的服务,通过很多分散的小服务之间的配合,去解决更大,更复杂的问题.对被拆分后的服务进行分类和管理,彼此之间使用统一的接口来进行交互.      微服务的特点决定了功能模块的部署是分布式的,以往在单应用环境下,所有的业务都在同一个服务器上,如果服务器出现错误和异常,我们只要盯住一个点,就可以快速定位和处理问题,但是在微服务的架构下,大部分功能模块都是单独部

使用360网站服务监控体验报告

作为一家上千个站点的运维屌丝,最头痛的莫非是向领导汇报工作时,领导需要各种报告,其中包含网站的监控数据,在cacti+nagios平台能对服务器的网络流量.系统负载.主机硬资源.服务监控,其中nagios只能监控服务器服务是否正常,重点并不在图形化的监控,但用360网站服务监控平台可以完善这项,尤其对于中小型站点来说,省去搭建监控平台,省下硬件资源,而且用起来非常方便易配置. 如下图,可以查看监控项概述有HTTP.DNS.PING.SNMP的各项数据及正常还是异常,这里根据官方把各项做下说明:

Linux下搭建springboot服务(不借助tomcat启动)

本文介绍如何在Linux服务器下配置springboot项目服务 1.新建一个.service文件(我这边命名为test.service,其中test为服务名) 内容如下 [Unit]Description=testAfter=syslog.target [Service]ExecStart=/home/java/jdk/jdk1.8.0_144/bin/java -jar /root/project/test.jar --server.port=9185SuccessExitStatus=14

SpringCloud系列七:Hystrix 熔断机制(Hystrix基本配置、服务降级、HystrixDashboard服务监控、Turbine聚合监控)

1.概念:Hystrix 熔断机制 2.具体内容 所谓的熔断机制和日常生活中见到电路保险丝是非常相似的,当出现了问题之后,保险丝会自动烧断,以保护我们的电器, 那么如果换到了程序之中呢? 当现在服务的提供方出现了问题之后整个的程序将出现错误的信息显示,而这个时候如果不想出现这样的错误信息,而希望替换为一个错误时的内容. 一个服务挂了后续的服务跟着不能用了,这就是雪崩效应 对于熔断技术的实现需要考虑以下几种情况: · 出现错误之后可以 fallback 错误的处理信息: · 如果要结合 Feign