java 开发微服务_适用于Java开发人员的微服务：指标

java 开发微服务

1.简介

在本部分的教程中，我们将继续探索可观测土地，并探讨其下一个基础Struts，即指标。 日志是描述性的，而度量则从测量中获得启发。

如果无法衡量，就无法改进。 - 彼得·德鲁克

指标具有多种用途。 首先，它们使您可以快速了解服务或应用程序的当前状态。 其次，度量标准可以帮助将不同应用程序，服务和/或基础架构组件在高负载或中断情况下的行为关联起来。 结果，它们可能导致更快的问题识别和瓶颈检测。 最后但并非最不重要的一点是，度量标准可以帮助主动和有效地缓解潜在问题，将它们发展成严重问题或广泛停机的风险降到最低。

还有更多。 指标最有价值的属性之一就是能够捕获总体系统性能特征，从而建立比较和趋势基线。 在持续集成和交付实践的支持下，它们有助于在潜入生产之前尽早检测出任何不良回归。

听起来确实很有用，但是我们的系统需要什么样的指标？ 我们如何检测我们的应用程序和服务？ 我们到底应该测量什么？ 这些是我们将在本部分教程中尝试解决的难题。

2.仪器，收集，可视化（和警报）

度量标准并非一无是处，应该对应用程序和/或服务进行检测，以揭示相关见解。 幸运的是，JVM生态系统在这里蓬勃发展，这里有一些出色的工具库（特别是Micrometer和Dropwizard Metrics ），并且大多数广泛使用的框架都具有现成的集成，其中至少有一个是集成的。

暴露后，需要收集（推或刮）度量并将其保留在某个地方，以便提供随时间推移和汇总的历史趋势。 通常，这可以通过使用时间序列数据库之一来实现。

专门建立了一个时间序列数据库，用于处理带有时间戳的指标和事件或度量。 TSDB已针对测量随时间的变化进行了优化。 使时间序列数据与其他数据工作负载有很大不同的属性是数据生命周期管理，摘要和许多记录的大范围扫描。 – https://www.influxdata.com/time-series-database/

指标生命周期的最后阶段是可视化，通常是通过使用图表/图形，表格，热图等通过预建的仪表板进行的。从操作的角度来看，这当然是有用的，但指标的真正价值是为实时警报：能够监视趋势并主动通知异常或新出现的问题。 对于现实生产系统而言，它至关重要，因此我们将在本教程的整个部分中专门讨论警报。

3.运营vs应用vs商业

可以收集并采取大量措施。 大致可以将它们分为三类：运营指标，应用程序指标和业务指标。

放眼来看，让我们专注于JCG租车平台，该平台由多个基于HTTP的微服务 ，数据存储和消息代理组成。 这些组件可能在某种虚拟或物理主机上运行，​​很可能在容器内部。 至少，我们希望在每一层上收集有关CPU，内存，磁盘I / O和网络利用率的指标。

对于基于HTTP的微服务 ，我们至少要注意以下几点：

1. 每秒请求数（RPS） 。 这是一个核心指标，指示有多少请求正在通过应用程序或服务传输。
2. 响应时间 。 另一个核心指标显示了应用程序或服务响应请求所花费的时间。
3. 错误 。 此度量标准指示错误的应用程序或服务响应的速率。 对于HTTP协议，我们对5xx错误（服务器端错误）最感兴趣，但是实际上也不应该忽略4xx错误。

这些是操作指标的典型示例，公平地说，有数百个指标。 有些简单明了，有些则不然。 例如，考虑到其体系结构的差异，对于消息代理来说，什么是好的指示性指标？ 幸运的是，在大多数情况下，供应商和维护人员已经负责公开和记录相关指标，甚至还发布了仪表板和模板来简化操作。

那么应用程序指标呢？ 您可能会猜到，它们实际上取决于实现上下文，并且各不相同。 例如，建立在参与者模型之上的应用程序应该公开许多与参与者系统和参与者有关的度量。 同样，基于Tomcat的应用程序可能需要公开与服务器线程池和队列有关的指标。

业务指标本质上是每个系统域所固有的，并且差异很大。 例如，对于JCG租车平台，重要的业务指标可能包括一段时间间隔内的预订数量。

4. JVM的特点

在Java世界中，操作系统和应用程序之间只有一件事：JVM。 这是一项非常棒但同样复杂的技术，必须引起注意：CPU，堆消耗，垃圾回收，元空间，类加载，堆外缓冲区等等。 幸运的是，JVM开箱即用地公开了大量指标，因此正确使用它们就成为问题。

为了概括这一点，请始终了解应用程序和服务在其下运行的运行时，并确保具有正确的指标以了解正在发生的情况。

5.拉还是推？

根据您使用的监视后端，有两种基本策略如何从应用程序或服务中收集指标：定期推送或拉取（刮擦）指标。 这些策略中的每一个都有各自的优缺点 （例如，基于拉动的策略的众所周知的弱点是短暂的和批处理的工作，它们可能存在的时间不够长，无法被废弃），因此请花一些时间来了解哪种策略最适合您的上下文。

6.储存

正如我们已经触及之前，存储和查询指标有效地需要使用专用的时间序列数据库 。 我们将要讨论很多不错的选择。

RRD工具

如果您正在寻找真正基础的东西，则可能需要RRDtool （或更长的版本， Round Robin数据库工具 ）。

RRDtool 是用于时序数据的OpenSource行业标准，高性能数据记录和图形系统。 RRDtool 可以轻松集成到shell脚本，perl，python，ruby，lua或tcl应用程序中。 – https://oss.oetiker.ch/rrdtool/

循环数据库背后的思想非常简单，并且利用了循环缓冲区 s，因此可以使系统存储空间随着时间的推移保持恒定。

神经节

Ganglia一度非常流行，但它可能是最古老的开源监视系统。 尽管您可能会在野外发现有关神经节的信息，但不幸的是，它并没有得到积极发展。

Ganglia 是一个可扩展的分布式监视系统，用于高性能计算系统，例如集群和网格。 – http://ganglia.info/

石墨

石墨是作为成熟的监视工具出现的第一个开源项目之一。 它创建于2006年，但仍在积极维护中。

Graphite 是一种企业就绪的监视工具，可以在廉价的硬件或云基础架构上同样出色地运行。 团队使用Graphite来跟踪其网站，应用程序，业务服务和网络服务器的性能。 它标志着新一代监视工具的开始，它使存储，检索，共享和可视化时序数据变得前所未有的容易。 – https://graphiteapp.org/#overview

有趣的是， Graphite的存储引擎在设计和用途上与轮询数据库（例如RRDTool ）非常相似。

OpenTSDB

一些时间序列数据库建立在更传统的（关系或非关系）数据存储之上，例如依赖于Apache HBase的 OpenTSDB 。

OpenTSDB 是在 HBase 之上编写的分布式可伸缩时间序列数据库（TSDB） 。 OpenTSDB 旨在满足一个普遍的需求：大规模存储，索引和服务从计算机系统（网络设备，操作系统，应用程序）收集的指标，并使这些数据易于访问和可图形化。 – https://github.com/OpenTSDB/opentsdb

时标数据库

TimescaleDB是在经过验证的数据存储（在本例中为PostgreSQL）的基础上构建的开源时间序列数据库的另一个示例。

TimescaleDB 是一个开放源代码的时间序列数据库，已针对快速提取和复杂查询进行了优化。 它讲“完整SQL”，并且像传统的关系数据库一样易于使用，但可以按以前为NoSQL数据库保留的方式进行扩展。 – https://docs.timescale.com/latest/introduction

从开发角度来看， TimescaleDB是作为 PostgreSQL上的扩展实现的，因此它基本上意味着在PostgreSQL实例中运行。

Kairos数据库

KairosDB最初是由OpenTSDB分叉的，但随着时间的发展，它发展成为独立的，有前途的开源时间序列数据库 。

KairosDB是在Cassandra之上编写的快速分布式可伸缩时间序列数据库。 – https://github.com/kairosdb/kairosdb

InfluxDB（和TICK堆栈）

InfluxDB是由InfluxData开发和维护的开源时间序列数据库 。

InfluxDB 是一个时间序列数据库，旨在处理较高的写入和查询负载– https://www.influxdata.com/products/influxdb-overview/

InfluxDB很少单独使用，而是作为更全面的平台（称为TICK堆栈）的一部分使用，该平台包括Telegraf ， Chronograf和Kapacitor 。 目前处于Alpha状态的下一代InfluxDB打算将该时间序列平台统一为一个可再发行的二进制文件。

普罗米修斯

如今，Prometheus已成为度量，监视和警报平台的第一选择。 除了简单和易于部署之外，它还与Kubernetes之类的容器编排器进行了本地集成。

Prometheus 是最初在 SoundCloud上 构建的开源系统监视和警报工具包 。 – https://prometheus.io/docs/introduction/overview/

在2016年， Prometheus加入了Cloud Native Computing Foundation （ CNCF ）。 对于JCG租车平台， Prometheus无疑是收集，存储和查询指标的首选。 如果是简单的静态Prometheus配置（带有静态IP地址），则这是在Targets网页上显示JCG租车平台服务的子集的方式。

普罗米修斯的JCG租车服务

Netflix Atlas

Atlas诞生于Netflix （后来开源），是由于需要应对越来越多的指标（必须由其流媒体平台收集）而引起的。

Atlas 由Netflix开发，用于管理维度时间序列数据，以实现近乎实时的运营洞察。 Atlas 具有内存中数据存储功能，可以快速收集和报告大量指标。 – https://github.com/Netflix/atlas/wiki

这是一个很棒的系统，但是请记住，选择使用内存数据存储是Atlas的痛处之一，可能会产生额外费用 。

7.仪表

框架的选择对于促进应用程序和服务的检测起着重要的作用。 例如，由于Reservation Service使用的是Spring Boot ，因此对由Micrometer烘焙的Web服务器和Web客户端的标准度量标准集提供了现成的支持。

management:
  endpoint:
    prometheus:
      enabled: true
    metrics:
      enabled: true
  metrics:
    distribution:
      percentiles-histogram:
        http.server.requests: true
    export:
      prometheus:
        enabled: true
    web:
      client:
        max-uri-tags: 150
        requests-metric-name: http.client.requests
      server:
        auto-time-requests: true
        requests-metric-name: http.server.requests

甚至更多， Spring Boot附带了方便的定制器，以通过其他配置和元数据（标签或/和标签）来丰富指标。

@Configuration
public class MetricsConfiguration {
    @Bean
    MeterRegistryCustomizer metricsCommonTags(@Value("${spring.application.name}") String application) {
        return registry -> registry.config().commonTags("application", application);
    }
}

JCG租车平台的监控选择与Prometheus的集成也是无缝的，并且与Micrometer捆绑在一起。

    io.micrometer
    micrometer-registry-prometheus

另一方面， 客户服务使用Dropwizard指标，并且需要一些定制以根据Prometheus协议收集和公开所需的指标。

@ApplicationScoped
public class PrometheusServletProvider implements ServletContextAttributeProvider{
    @Inject private MetricsConfig metricsConfig;
    
    @PostConstruct
    public void init() {
        CollectorRegistry.defaultRegistry.register(new DropwizardExports(metricsConfig.getMetricRegistry()));
        DefaultExports.initialize();
    }
    
    @Produces
    public ServletDescriptor prometheusServlet() {
        String[] uris = new String[]{"/prometheus"};
        WebInitParam[] params = null;
        return new ServletDescriptor("Prometheus", uris, uris, 1, params, false, MetricsServlet.class);
    }

    @Override
    public Map getAttributes() {
        return Collections.emptyMap();
    }
}

统计

除了纯粹的特定于JVM的选项之外， statsd是值得一提的。 本质上，它是用于不同指标后端的前端代理。

一个网络守护程序，在 Node.js 平台 上运行， 并侦听通过 UDP 或 TCP 发送的 统计信息（如计数器和计时器）， 并将聚合发送到一个或多个可插拔的后端服务（例如Graphite ）。 – https://github.com/statsd/statsd

有大量的客户端实现可用，此后将statsd定位为多语言微服务体系结构非常吸引人的选择。

开放遥测

到目前为止，我们已经看到了很多关于如何进行指标检测和收集的意见。 最近，在OpenTelemetry框架下宣布了一项新的全行业计划。

OpenTelemetry 由API和库的集成集以及通过代理和收集器的收集机制组成。 这些组件用于生成，收集和描述有关分布式系统的遥测。 此数据包括基本的上下文传播，分布式跟踪，度量标准以及将来的其他信号。 OpenTelemetry 旨在使您可以轻松地从服务中获取关键遥测数据，并将其导入您选择的后端。 对于每种受支持的语言，它提供了一套API，库和数据规范，并且开发人员可以利用他们认为合适的任何组件。 – https://opentelemetry.io/

OpenTelemetry的目标远远超出了度量标准，我们将在本教程的后续部分中进一步讨论其中一些目标。 到目前为止， OpenTelemetry仅可用作规范草案 。 但是，如果您想尝试一下，它基于著名的OpenSensus项目，该项目还包括指标工具 。

JMX

对于JVM应用程序，还有另一种使用Java管理扩展 （ JMX ）公开实时指标的方法。 公平地说， JMX是一种非常古老的技术，您可能会觉得使用它很尴尬，但是它可能是了解基于JVM的应用程序和服务的最简单，最快的方法。

通过JMX连接到JVM应用程序的标准方法是使用JConsole ， JVisualVM或最新的方法，即JDK Mission Control （ JMC ）。 例如，下面的屏幕快照说明了运行中的JVisualVM ，该可视化显示了保留服务通过JMX公开的Apache Cassandra的请求度量。

客户服务通过JMX公开的Cassandra指标

通过JMX公开的指标只是暂时的，仅在应用程序和服务启动并运行时才可用（确切地说，持久性是可选的，不可移植且很少使用）。 另外，请记住， JMX的范围不仅限于指标，而是一般的管理。

8.可视化

正如我们已经了解的那样，典型的JVM应用程序或服务公开了很多指标。 其中一些很少有用，而另一些则是应用程序或服务运行状况的关键指标。 我们必须采取什么手段使这种区分变得明显，更重要的是，有意义和有用？ 答案之一是实时操作或/和业务仪表板的可视化和构建。

诸如Graphite ， Prometheus和InfluxDB之类的监视和指标管理平台确实支持相当复杂的查询语言和图形，因此您甚至可能无需进一步挖掘。 但是，如果您要寻找最先进的仪表板或整合多个指标源，则需要四处搜寻。

格拉法纳

毫无疑问， 到目前为止，Grafana是一站式的商店，可进行指标可视化并创建真正漂亮的仪表板（ 已经有大量的预建仪表板）。

Grafana 是用于可视化指标的领先开源项目。 支持对每个流行的数据库（如Graphite ， Prometheus和InfluxDB）进行丰富的集成。 – https://grafana.com/对于JCG

对于JCG租车平台， Grafana非常适合，因为它与Prometheus具有出色的集成性。 在使用Micrometer库的Reservation Service的情况下，有一些社区构建的仪表板可以帮助您快速入门，下面显示了其中一个。

预订服务的Grafana仪表板

值得强调的是， Grafana具有高度的可定制性和可扩展性，因此，如果您选择将其用作指标可视化平台，那么将来该决定就不太可能会后悔。

9.云

对于部署在云中的应用程序和服务，指标的重要性（以及警报，更多信息将在本教程的后续部分中介绍）至关重要。 您将很快发现的模式是度量管理与我们在本教程的上一部分中已经讨论过的相同产品一起提供，因此让我们快速浏览一下它们。

如果您在AWS上运行应用程序，服务，API网关或功能，则Amazon CloudWatch会自动代表您收集并跟踪大量指标（以及其他运营数据），而无需任何其他配置（包括基础架构）。 此外，如果您只是在寻找存储部分，那么一定值得探索Amazon Timestream ，这是一种快速，可扩展，完全托管的时间序列数据库产品。

Microsoft Azure的用于指标收集和监视的产品是Azure Monitor数据平台的一部分。

与其他服务类似， Google Cloud也没有仅用于指标管理的独立产品，而是将其与Stackdriver Monitoring （ Stackdriver产品的一部分）捆绑在一起。

10.无服务器

对于无服务器工作负载，最重要的观念转变是与主机系统相关的指标不再是您关注的问题。 另一方面，您需要了解无服务器环境中哪些类型的指标相关并进行收集。 那是什么

1. 调用持续时间 。 函数执行时间的分布（因为这主要是您要支付的）。
2. 调用计数 。 该函数被调用了多少次。
3. 错误调用计数 。 该功能没有成功完成多少次。

这些是一个很好的起点，但是最重要的指标将是业务或应用程序的指标，这是每个功能应该执行的操作所固有的。

大多数云提供商都收集和可视化其无服务器产品的指标，而好消息是流行的开源无服务器平台（例如jazz ， Apache OpenWhisk ， OpenFaas ， Serverless Framework）至少具有基本的工具，并且从盒子也一样。

11.费用是多少？

到目前为止，我们一直专注于度量标准的重要性，以收集见解，监督趋势和模式。 但是，从存储和计算的角度来看，我们都没有谈到这样做的成本。

很难得出通用成本模型，但是要考虑许多因素和权衡取舍。 最重要的是：

• 指标总数。
• 每个特定指标存在的不同时间序列的数量。
• 后端存储（例如，将所有数据保留在内存中非常昂贵，而磁盘则便宜得多）。
• 收集原始指标与预先汇总的指标。

您可能面临的另一个风险与在大量时间序列上运行查询和聚合有关。 在大多数情况下，这是非常昂贵的操作，如果确实需要支持，最好提前计划容量。

您可能会猜到，当漂流时，事情可能会变得很昂贵。

12.结论

在本教程的这一部分中，我们讨论了可观测性的另一Struts指标。 指标和日志构成了在微服务体系结构之后构建的每个分布式系统的绝对必需的基础。 我们已经了解了如何对应用程序和服务进行检测，如何收集和存储指标，最后但并非最不重要的一点是，如何使用仪表板以一种人性化的方式来表示它们（警报部分将随之出现）。

最后，可以公平地说，我们的重点主要是针对指标管理平台，而不是Apache Druid或ClickHouse等分析平台，或Nagios或Hawkular等监控平台 （尽管这里有些交叉点）。 尽管如此，请继续关注，我们将在本教程的最后部分回到更广泛的监视和警报主题。

13.接下来是什么

在本教程的下一部分中，我们将讨论分布式跟踪。

翻译自: https://www.javacodegeeks.com/microservices-metrics.html

java 开发微服务