飞码网-免费源码博客分享网站

点击这里给我发消息

监控Spring Boot微服务|-Java教程

飞码网-免费源码博客分享网站 爱上飞码网—https://www.codefrees.com— 飞码网-matlab-python-C++ 爱上飞码网—https://www.codefrees.com— 飞码网-免费源码博客分享网站

介绍

当使用微服务和事件驱动的体系结构(EDA)样式时,可观察性由监视,日志记录,跟踪和警报方面组成,是一个重要的体系结构关注点,主要是因为:

  • 大量部署需要自动化和集中化监视/可观察性
  • 体系结构的异步和分布式性质导致与关联多个组件产生的度量标准相关的困难

解决此体系结构问题可简化管理并缩短周转时间,以解决运行时问题。它还提供了见解,可以帮助您做出明智的架构,设计,部署和基础架构决策,以改善平台的非功能性特征。此外,可以通过工程发布,收集和可视化自定义指标来获得有用的业务/运营洞察力。

但是,它通常是被忽略的体系结构问题。本教程描述了使用开源工具(例如Micrometer,Prometheus和Grafana)对Java和Spring Boot微服务的可观察性进行监视的准则和最佳实践

先决条件

在开始本教程之前,您需要设置以下环境:

  • 具有Docker Compose的Docker环境
  • 一个Java IDE,用于克隆和编辑git repo中的代码

预计的时间

完成本教程大约需要2个小时。

监控概述

监视工具的主要目标是:

  • 监控应用程序的性能
  • 向利益相关者(开发团队,基础架构团队,运营用户,维护团队和业务用户)提供自助服务
  • 协助执行快速根本原因分析(RCA)
  • 建立应用程序的性能基准
  • 如果使用云,则提供监视云使用成本以及以集成方式监视不同云服务的能力

监视主要包括以下四组活动:

  • 仪表应用(S)的-插装应用程序发出很重要的应用监控和维修队伍,以及针对企业用户的指标。可以采用多种非侵入性的方式来生成指标,最流行的方式是“字节码检测”,“面向方面的编程”和“ JMX”。

  • 指标收集–从应用程序收集指标,并将其持久存储在存储库/数据存储中。然后,存储库提供了一种查询和汇总数据以进行可视化的方法。某些流行的收集器是Prometheus,StatsD和DataDaog。大多数度量收集工具都是时间序列存储库,并提供高级查询功能。

  • 指标可视化–可视化工具查询指标存储库以构建用于最终用户使用的视图和仪表板。它们提供了丰富的用户界面,可以对指标执行各种操作,例如聚合,下钻等。

  • 警报和通知–当指标违反定义的阈值时(例如CPU超过80%的时间超过10分钟),可能需要人工干预。为此,警报和通知很重要。大多数可视化工具都提供警报和通知功能。

有许多开放源代码和商业产品可用于监视。一些著名的商业产品包括:AppDynamics,Dynatrace,DataDog,logdna和sysdig。开源工具通常结合使用。一些非常流行的组合是Prometheus和Grafana,Elastic-Logstash-Kibana(ELK)和StatsD + Graphite。

微服务监控指南

鼓励在所有微服务中收集的指标类型具有统一性。这有助于提高仪表板的可重用性,并简化指标的汇总和下钻,以在不同级别可视化它们。

监控什么

微服务将公开API和/或使用事件和消息。在处理期间,它可能调用自己的业务组件,连接到数据库,调用技术服务(缓存,审计等),调用其他微服务和/或发布事件和消息。在这些不同的处理阶段监视指标是有益的,因为它有助于提供有关性能和异常的详细见解。反过来,这有助于快速分析问题。

通常收集的与事件驱动架构(EDA)和微服务相关的指标包括:

  • 资源利用率指标

    • 资源利用率– CPU,内存,磁盘利用率,网络利用率等
    • JVM堆和GC指标– GC开销,GC时间,堆(及其不同区域)利用率
    • JVM线程利用率–阻塞,可运行,等待连接使用时间
  • 应用指标

    微服务的不同架构层的可用性,延迟,吞吐量,状态,异常等,例如:

    • 控制器层–用于HTTP / REST方法调用,包括
    • 服务层–用于方法调用
    • 数据访问层–用于方法调用
    • 集成层–用于RPC调用,HTTP / REST / API调用,消息发布,消息使用
  • 技术服务利用率指标(特定于技术服务)

    • 缓存–缓存命中,未命中,放置,删除,读取
    • 记录器–每个日志级别的日志事件数
    • 连接池–使用中的连接,连接等待时间,连接创建时间,空闲连接
  • 中间件指标

    • 事件代理指标–可用性,消息输入/输出,字节输入/输出,消耗滞后,(反)序列化异常,集群状态
    • 数据库指标

对于应用程序度量标准,理想情况下,应该对微服务的每个体系结构层中的入口和出口点进行检测。

微服务的关键指标特征

监视微服务时,指标的以下三个特征很重要:

  • 维数
  • 时间序列/费率汇总
  • 指标观点

维数

维度控制指标的聚合方式以及特定指标的下钻范围。它是通过将标签添加到度量来实现的。标签是一name=value对信息。标签用于通过对监视系统的查询来限定度量的获取或聚集。由于部署数量众多,它是监视微服务的重要特征。换句话说,在微服务生态系统中,多个微服务(甚至微服务的不同组件)将发出具有相同名称的度量。为了区分它们,您可以使用维度对指标进行限定。

例如,考虑指标http_server_requests_seconds_count如果有多个API端点(在微服务生态系统中就是这种情况),那么如果没有维度,则只能在平台级别查看此指标的汇总值。无法在不同的API端点之间进行分配。uri在发布指标时将其添加到指标将能够获取此分布。看下面的示例,它解释了此特征。

如果http_server_requests_seconds_count发出带有以下标记的If

http_server_requests_seconds_count{appName="samplemicrosvc",env="local",exception="None",instanceId="1",method="GET",outcome="SUCCESS",status="200",uri="/addressDetails/{addressId}",} 67.0
http_server_requests_seconds_count{appName="samplemicrosvc",env="local",exception="InternalServerError",instanceId="1",method="GET",outcome="SERVER_ERROR",status="500",uri="/userInfo/{userId}",} 39.0
http_server_requests_seconds_count{appName="samplemicrosvc",env="local",exception="None",instanceId="1",method="GET",outcome="SUCCESS",status="200",uri="/userInfo/{userId}",} 67.0
http_server_requests_seconds_count{appName="samplemicrosvc",env="local",exception="IllegalArgumentException",instanceId="1",method="GET",outcome="SERVER_ERROR",status="500",uri="/addressDetails/{addressId}",} 13.0
http_server_requests_seconds_count{appName="samplemicrosvc",env="local",exception="IllegalStateException",instanceId="1",method="GET",outcome="SERVER_ERROR",status="500",uri="/addressDetails/{addressId}",} 26.0

然后,http_server_requests_seconds_count可以通过HTTP响应或通过级别appName级别上聚合,如以下查询所示:instanceIdstatusoutcome

# Count distribution by status for a given environment
sum by (status) (http_server_requests_seconds_count{env="$env"})

# Count distribution by uri and status for a given environment
sum by (uri, status) (http_server_requests_seconds_count{env="$env"})

# Count distribution by uri, status and appName for a given environment
sum by (uri, status, appName) (http_server_requests_seconds_count{env="$env"})

标签也可以用作查询条件。注意env标记的用法,其中$env是用户输入“ environment的Grafana仪表板的变量

时间序列/费率汇总

随时间推移聚合指标的能力对于识别应用程序性能中的模式非常重要,例如将性能与负载模式相关联,构建一天/一周/月的性能配置文件以及创建应用程序的性能基准。

指标观点

这是一个派生的特征,并提供了将指标分组在一起的功能,以便于可视化和使用。例如:

  • 仪表板,描述了平台所有微服务的可用性状态
  • 每个微服务的向下钻取(详细)视图以查看微服务的详细指标
  • 视图集群级别和中间件组件(例如事件代理)的度量标准的详细视图

检测Spring Boot微服务

本节介绍微服务及其其余控制器,服务Bean,组件Bean和数据访问对象的检测。本节还介绍卡夫卡消费者,卡夫卡,制片人,和骆驼航线的仪器,如果这是相关的kafkaspring-cloud-streamApache Camel用于整合或EDA。

为了帮助监视和管理微服务,请通过添加spring-boot-starter-actuator作为依赖项来启用S​​pring Boot Actuator 现成可用的多个HTTP和JMX端点来监视应用程序,包括对微服务的运行状况,bean,应用程序信息和环境信息的基本监视。

依赖项添加如下:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

开箱即用的度量标准

将Spring Boot Actuator添加到微服务后,即可立即启用以下指标:

  • JVM指标(与GC和线程利用率有关)
  • 资源利用率指标(CPU,线程,文件描述符,JVM堆和垃圾回收指标)
  • 卡夫卡消费者指标
  • 记录器指标(Log4j2,Logback)
  • 可用性指标(流程正常运行时间)
  • 缓存指标(开箱即用的Caffeine,EhCache2,Hazelcast或任何符合JSR-107的缓存)
  • Tomcat指标
  • 春季整合指标

指标终点

执行器还创建度量标准的端点。默认情况下为/actuator/metrics它需要通过Spring配置公开。以下是一个示例配置:

management:
  endpoints:
    web:
      exposure:
        include: ["health", "info", "metrics", "prometheus", "bindings", "beans", "env", "loggers", "streamsbindings"]

千分尺

为了与Metrics Tool集成,Spring Boot Actuator提供了用于测微计的自动配置。千分尺为包括Prometheus在内的众多监控系统提供了立面。本教程假定您对Micrometer概念有一定程度的了解。千分尺提供了三种收集指标的机制:

  • 计数器–通常用于对事件,方法执行,异常等进行计数
  • 计时器–用于测量持续时间和发生次数;通常用于测量延迟
  • 仪表–单点时间指标;例如,线程数

与Prometheus整合

由于Prometheus使用民意调查来收集指标,因此将Prometheus和Micrometer集成起来是相对简单的两步过程。

  1. 添加micrometer-registry-prometheus注册表。

  2. 声明一个类型的Bean MeterRegistryCustomizer<PrometheusMeterRegistry>

    这是一个可选步骤。但是,建议您这样做,因为它提供了自定义的机制MeterRegistry这对于声明将由Micrometer收集的度量标准数据的通用标签(尺寸)很有用这有助于进行指标深入分析。当存在许多微服务和/或每个微服务有多个实例时,此功能特别有用。典型的常用标记可能是applicationNameinstanceNameenvironment这将使您能够跨实例和应用程序构建聚合的可视化效果,并能够深入到特定的实例/应用程序/环境。

配置完成后,Actuator将公开一个终结点/actuator/prometheus,该终结点应在Spring配置中启用。需要通过其配置在Prometheus中添加作业,以便以指定的频率刮擦该端点。

将Prometheus依赖项添加到pom

<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

自定义MetricsRegistry

MetricsRegistryCustomizer可以将声明的配置类编写为框架的一部分,以便所有MicroServices实现都可以重用它。可以使用系统/应用程序属性来提供标签值。

@Configuration
public class MicroSvcMeterRegistryConfig {
    @Value("${spring.application.name}")
    String appName;

    @Value("${env}")
    String environment;

    @Value("${instanceId}")
    String instanceId;

    @Bean
    MeterRegistryCustomizer<PrometheusMeterRegistry> configureMetricsRegistry()
    {
        return registry -> registry.config().commonTags("appName", appName, "env", environment, "instanceId", instanceId);
    }

应用程序级指标的检测

一些应用程序级别的度量是开箱即用的,并且对于某些情况,可以采用多种技术。下图总结了这些功能:

指标 控制器 服务层组件 数据访问对象 业务组成 技术组成 卡夫卡消费者 卡夫卡制片人 Spring集成组件 HTTP客户端 骆驼路线
资源利用率(CPU,线程,文件描述符,堆,GC) 微服务实例级别的开箱即用
可用性 微服务实例级别的开箱即用
潜伏 @Timed注释的开箱即用 通过Spring-AOP的自定义可重用方面完成 通过Spring-AOP的自定义可重用方面完成 通过Spring-AOP的自定义可重用方面完成 开箱即用的日志记录,缓存和JDBC连接池 如果使用spring-cloud-stream,则开箱即用 通过自定义的MeterBinder bean完成 盒子外面 盒子外面 提供部分支持。需要自定义路线的仪表。
通量 @Timed注释的开箱即用 通过Spring-AOP的自定义可重用方面完成 通过Spring-AOP的自定义可重用方面完成 通过Spring-AOP的自定义可重用方面完成 开箱即用的日志记录,缓存和JDBC连接池 如果使用spring-cloud-stream,则开箱即用 通过自定义的MeterBinder bean完成 盒子外面 盒子外面 提供部分支持。需要自定义路线的仪表。
例外情况 @Timed注释的开箱即用 通过Spring-AOP的自定义可重用方面完成 通过Spring-AOP的自定义可重用方面完成 通过Spring-AOP的自定义可重用方面完成 开箱即用的日志记录,缓存和JDBC连接池 如果使用spring-cloud-stream,则开箱即用 通过自定义的MeterBinder bean完成 盒子外面 盒子外面 提供部分支持。需要自定义路线的仪表。

检测REST控制器

检测REST控制器的最快,最简单的方法是@Timed在控制器上或控制器的各个方法上使用注释。@Timed会自动将这些标签计时器:exceptionmethodoutcomestatusuri也可以为@Timed注释提供其他标签

检测微服务的不同架构层

微服务通常具有ControllerServiceDAOIntegration层。@Timed注释应用于控制器时,控制器不需要任何其他工具对于Service,DAO和Integration层,开发人员创建带有@Service@Component批注的自定义bean 与延迟,吞吐量和异常相关的指标可以提供重要的见解。使用千分尺TimerCounter度量标准可以轻松收集这些信息但是,需要对代码进行检测以应用这些指标。可以使用来创建用于检测服务和组件的通用可重用类,该类spring-aop可在所有微服务之间重用。使用@Around@AfterThrowing可以生成建议度量标准,而无需在服务/组件类和方法中添加任何代码。考虑以下有关开发此类方面的准则:

  • 创建可重复使用的注释以应用于不同类型的组件/服务。例如,自定义注释,例如@MonitoredService@MonitoredDAO,和@MonitoredIntegrationComponent,可分别施加到服务,数据访问对象,和集成组件。

  • 定义多个切入点,以对不同类型的组件应用建议,并在上面带有上述注释。

  • 将适当的标签应用于量度,以便可以对量度进行下钻或切片。例如,标记,如componentClasscomponentTypemethodName,并且exceptionClass可以使用。使用这些标签和通用标签,可以按以下方式发出度量标准:

     component_invocation_timer_count{env="local", instanceId="1", appName="samplemicrosvc", componentClass="SampleService", componentType="service", methodName="getUserInformation"} 26.0
    

看一下以下示例注释:

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface MonitoredService {
}

下面的代码显示了一个示例可重用的方面,它可以检测Service类:

@Configuration
@EnableAspectJAutoProxy
@Aspect
public class MonitoringAOPConfig {

    @Autowired
    MeterRegistry registry;

    @Pointcut("@target(com.ibm.dip.microsvcengineering.framework.monitoring.MonitoredService) && within(com.ibm.dip..*)")
    public void servicePointcut() {
    }

    @Around("servicePointcut()")
    public Object serviceResponseTimeAdvice(ProceedingJoinPoint pjp) throws Throwable {
        return monitorResponseTime(pjp, TAG_VALUE_SERVICE_TYPE);
    }

    @AfterThrowing(pointcut = "servicePointcut()", throwing = "ex")
    public void serviceExceptionMonitoringAdvice(JoinPoint joinPoint, Exception ex)
    {
        monitorException(joinPoint, ex, TAG_VALUE_SERVICE_TYPE);
    }

    private Object monitorResponseTime(ProceedingJoinPoint pjp, String type) throws Throwable {
        long start = System.currentTimeMillis();
        Object obj = pjp.proceed();
        pjp.getStaticPart();
        long end = System.currentTimeMillis();
        String serviceClass = getClassName(pjp.getThis().getClass().getName());
        String methodName = pjp.getSignature().getName();

        Timer timer = registry.timer(METER_COMPONENT_TIMER,
                TAG_COMPONENTCLASS, serviceClass, TAG_METHODNAME, methodName, TAG_OUTCOME, SUCCESS, TAG_TYPE, type);
        timer.record((end - start), TimeUnit.MILLISECONDS);

        Counter successCounter = registry.counter(METER_COMPONENT_COUNTER,
                TAG_COMPONENTCLASS, serviceClass, TAG_METHODNAME, methodName, TAG_OUTCOME, SUCCESS, TAG_TYPE, type);
        successCounter.increment();
        return obj;
    }

    private void monitorException(JoinPoint joinPoint, Exception ex, String type)
    {
        String serviceClass = getClassName(joinPoint.getThis().getClass().getName());
        String methodName = joinPoint.getSignature().getName();
        Counter failureCounter = registry.counter(METER_COMPONENT_EXCEPTION_COUNTER, TAG_EXCEPTIONCLASS,
                ex.getClass().getName(), TAG_COMPONENTCLASS, serviceClass, TAG_METHODNAME, methodName, TAG_OUTCOME, ERROR,
                TAG_TYPE, type);
        failureCounter.increment();
    }
}

这会将所有服务逻辑从微服务抽象为一组可重用的方面和注释。微服务开发人员只需要在他或她的课程上应用相应的注释即可。

一个示例检测的Service类将在其上具有以下注释。自动地,此Service类中的所有方法将成为应用serviceResponseTimeAdvice和的候选方法serviceExceptionMonitoringAdvice

@Service
@MonitoredService
public class SampleService {
   ...
}

检测出站HTTP / REST调用

开箱即用提供了出站HTTP / REST调用的工具spring-actuator但是,要使其正常工作,RestTemplate应从bean获得RestTemplateBuilder此外,如果RestTemplateExchangeTagsProvider提供了类型的自定义bean,则可以将自定义标签添加到度量标准

以下配置类对此进行了说明:

    @Bean
    public RestTemplate restTemplate(RestTemplateBuilder templateBuilder)
    {
        templateBuilder = templateBuilder.messageConverters(new MappingJackson2HttpMessageConverter())
                .requestFactory(this::getClientHttpRequestFactory);
        return templateBuilder.build();
    }

    @Bean
    public RestTemplateExchangeTagsProvider restTemplateExchangeTagsProvider()
    {
        return new RestTemplateExchangeTagsProvider() {
            @Override
            public Iterable<Tag> getTags(String urlTemplate, HttpRequest request, ClientHttpResponse response) {
                Tag uriTag = (StringUtils.hasText(urlTemplate) ? RestTemplateExchangeTags.uri(urlTemplate)
                        : RestTemplateExchangeTags.uri(request));
                return Arrays.asList(RestTemplateExchangeTags.method(request), uriTag,
                        RestTemplateExchangeTags.status(response), RestTemplateExchangeTags.clientName(request),
                        Tag.of("componentClass", "httpClient"),
                        Tag.of("componentType", "integration"),
                        Tag.of("methodName", uriTag.getValue()));
            }
        };
    }

仪表卡夫卡消费者

默认情况下,Actuator对Kafka Consumers进行检测。执行器和千分尺收集了30多个与Kafka消费者有关的指标。通用标签也适用于Kafka消费者。一些显着的指标是kafka_consumer_records_consumed_total_records_totalkafka_consumer_bytes_consumed_total_bytes_totalkafka_consumer_records_lag_avg_records然后,使用维度,可以按Kafka-Topics,Kafka分区等对它们进行分组。

仪表卡夫卡生产者

卡夫卡生产者通过执行器默认仪表。Kafka Producer有自己的Metrics实现。要向Micrometer注册这些指标,请MeterBinder为每个定义一个类型的bean KafkaProducer<?,?>MeterBinder将创建并向GaugesMicrometer注册Registry通过这种方法,可以收集50多个Kafka Producer指标。通用标签和其他标签(在建立仪表时)将为这些指标提供多个维度。

以下代码显示了MeterBinder的典型实现是什么样的:

public class KafkaProducerMonitor implements MeterBinder {

    //Filter out metrics that don't produce a double
    private Set<String> filterOutMetrics;
    //Need to store the reference of the metric - else it might get garbage collected. KafkaMetric is a custom implementation that holds reference to the MetricName and KafkaProducer
    private Set<KafkaMetric> bindedMetrics;
    private KafkaProducer<?,?> kafkaProducer;
    private Iterable<Tag> tags;

    public KafkaProducerMonitor(KafkaProducer kafkaProducer, MeterRegistry registry, Iterable<Tag> tags)
    {
       ...
    }

    @Override
    public void bindTo(MeterRegistry registry) {
        Map<MetricName, ? extends Metric> metrics = kafkaProducer.metrics();
        if (MapUtils.isNotEmpty(metrics))
        {
            metrics.keySet().stream().filter(metricName -> !filterOutMetrics.contains(metricName.name()))
                    .forEach(metricName -> {
                        logger.debug("Registering Kafka Producer Metric: {}", metricName);
                        KafkaMetric metric = new KafkaMetric(metricName, kafkaProducer);
                        bindedMetrics.add(metric);
                        Gauge.builder("kafka-producer-" + metricName.name(), metric, KafkaMetric::getMetricValue)
                                .tags(tags)
                                .register(registry);
                    });
        }
    }
}

注意: 还有其他一些第三方组件可以发出度量标准,但未与Micrometer集成在一起。在这种情况下,可以利用上述模式。一个例子是Apache Ignite

骆驼整合

如果将Apache Camel用于集成,则Routes应用程序中将进行集成和处理在“路由”级别也具有指标很有意义。骆驼通过其camel-micrometer组件为千分尺提供端点camel-micrometer在应用程序的pom中添加依赖项,可使Micrometer端点启动/停止计时器和递增计数器。这些可用于收集路由级指标。org.apache.camel.Processor可以使用前面描述的AOP方法来检测其他骆驼类专用豆,例如类型的豆

要启用千分尺端点,请添加camel-micrometer依赖项,如下所示:

<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-micrometer</artifactId>
</dependency>

要发布路线的度量,RouteBuilder应将消息发送到Micrometer,如以下代码所示:

@Override
public void configure() throws Exception {
     from(inputEndpoints).
       routeId(routeId).
       to("micrometer:timer:route_timer" + "?" + "action=start" + "&" + "routeName=<routeId>").
       to("micrometer:counter:route_counter" + "?" + "routeName=<routeId>")
       ... //other route components
       ... //and finally
       to("micrometer:timer:route_timer" + "?" + "action=stop" + "&" + "routeName=<routeId>");

}

仪器摘要

如您所见,可以使用以下方法收集大量指标并将其推送到Prometheus:

  • Actuator提供的即用型指标。
  • 通过使用AOP和标记代码来定制指标MeterBinder所有这些自定义工具代码都是可重用的,并且可以将其构建为库,所有微服务实现都将使用该库。

两种方法都提供了一种一致的,侵入性最小的方式来跨多个微服务及其多个实例收集指标。

Prometheus与其他第三方系统的集成

普罗米修斯拥有健康的发展生态系统。有多个库和服务器可用于将第三方系统的指标导出到Prometheus,这些库和服务器已在Prometheus Exporters中进行了分类。例如,mongodb_exporter可以用于将MongoDB指标导出到Prometheus。

Apache Kafka使它的指标可用于JMX。可以按照以下各节中的说明将它们导出到Prometheus。

将Kafka与Prometheus集成

如果您将Kafka用作消息/事件代理,则Kafka度量标准与Prometheus的集成并不是开箱即用的。jmx_exporter需要使用A。需要在Kafka代理上进行配置,然后代理将开始通过HTTP公开指标。jmx_exporter需要配置文件(.yml)。存储库examples文件夹中提供了一个示例配置jmx_exporter

对于本教程,我们仅出于演示目的构建自定义的Kafka图像。jmx_exporter代码库的README.md中提供了用于构建自定义Kafka图像的说明。

在Grafana中建立仪表板

一旦在Prometheus Meter Registry中注册了度量并且Prometheus已启动并正在运行,它将开始收集度量。这些指标现在可用于在Grafana中构建不同的监视仪表板。对于不同的观点,需要多个仪表板。拥有以下仪表板是一个好习惯:

  • 平台概述仪表板,它提供平台的每个微服务和其他软件组件(例如,Kafka)的可用性状态。这种类型的信息中心还可以报告平台级别的汇总指标,包括request-rates(HTTP请求率,Kafka消耗请求率等)和exception counts

  • 微服务细分仪表板,提供微服务实例的详细指标。variables在Grafana中进行声明非常重要,该声明对应于度量中使用的不同标签。例如appNameenvinstanceId,和更多。

  • 中间件监视仪表板,它提供了中间件组件的详细钻取视图。这些特定于中间件(例如,Kafka仪表板)。同样,在这里声明也很重要,variables以便可以在各个cluster级别以及各个级别观察度量instance

使用维度进行向下钻取和聚合

在报告指标时,会将标记添加到指标。这些标签可用于Prometheus查询中,以汇总或深入了解指标。例如,在平台概述级别,您想查看平台中的异常总数。使用以下查询可以轻松完成此操作:

sum(component_invocation_exception_counter_total{env="$env"})

这将显示为:

汇总错误计数

现在,要在方法和异常类型级别上挖掘相同的度量标准,Prometheus查询将如下所示:

sum by(appName, instanceId, componentClass, methodName, exceptionClass)(component_invocation_exception_counter_total{env="$env", appName="$application", instance="$instance"})

它将产生如下详细信息:

错误详情

注意$变量。这些在仪表板中定义为变量。Grafana将根据Prometheus中可用的不同指标来填充它们。仪表板的用户可以选择各自的值,这些值可用于动态更改度量可视化,而无需在Grafana中创建新的可视化。

作为另一个示例,请考虑下面的方法查询,以可视化特定微服务实例中服务Bean的吞吐量。

rate(component_invocation_timer_seconds_count{instance="$instance", appName="$application", componentType="service"}[1m])",

样例平台概述仪表板

以下仪表板在平台级别可视化指标:

示例微服务平台概述仪表板

它提供:

  • 所有REST Controller方法和Kafka使用者的HTTP请求率和Kafka消耗率

  • 所有微服务实例和Kafka集群的可用性状态。

    请注意,此视图中的每个可视化对象都是特定微服务实例的超链接,该超链接提供了导航到该微服务实例的详细的向下钻取仪表板。

  • 所有微服务实例的HTTP请求失败和服务错误。

  • 所有微服务实例的异常细分。

示例微服务深入仪表板

该仪表板分为多个部分,在Grafana中称为“行”。该仪表板提供了微服务特定实例的所有指标。请注意,它是一个单一的仪表板,具有环境,微服务,instanceId等的用户输入。通过更改这些用户输入中的值,可以查看平台的任何微服务的指标。

注意: 有多个屏幕截图,因为已经可视化了许多指标以进行演示。

不同的指标部分

不同的指标部分

微服务实例级别指标

微服务实例级别指标

HTTP控制器指标

HTTP控制器指标

服务指标

服务指标

HTTP客户端指标

HTTP客户端指标

Kafka Producer指标

Kafka Producer指标

JDBC连接池指标

JDBC连接池指标

示例Kafka监控仪表板

卡夫卡经纪人指标

Kafka Broker指标

Kafka消息统计

Kafka消息统计

结论

春季启动微服务的监控变得容易和简单的使用spring-boot-actuatormicrometerspring-aop组合这些强大的框架提供了一种构建针对微服务的全面监视功能的方法。

监视的一个重要方面是跨多个微服务及其多个实例的指标的一致性,即使在有数百个微服务的情况下,监视和故障排除也变得容易且直观。

监视的另一个重要方面是不同的观点。这可以通过使用度量的维数和速率聚合特性来实现。Prometheus和Grafana之类的工具开箱即用地支持此功能。开发人员只需要确保发出的指标上具有正确的标签集即可(这反过来可以通过可重用和常见的方面以及Spring配置轻松实现)。

通过应用此指南,可以使用零到最少的侵入式粘合代码对所有微服务进行一致且全面的监视。

飞码网-免费源码博客分享网站 爱上飞码网—https://www.codefrees.com— 飞码网-matlab-python-C++ 爱上飞码网—https://www.codefrees.com— 飞码网-免费源码博客分享网站
赞 ()
内容页底部广告位3
留言与评论(共有 0 条评论)
   
验证码: