Skip to content
This repository was archived by the owner on Jul 9, 2022. It is now read-only.

Add SCSt 2.0 and Micrometer compatibility #51

Closed
sabbyanandan opened this issue Mar 1, 2018 · 3 comments
Closed

Add SCSt 2.0 and Micrometer compatibility #51

sabbyanandan opened this issue Mar 1, 2018 · 3 comments
Assignees
Milestone

Comments

@sabbyanandan
Copy link

sabbyanandan commented Mar 1, 2018

As a developer, I'd like to upgrade to SCSt 2.0, so I can bring Micrometer compatibility.

Background:
Boot 1.x based Metric infrastructure is replaced with Micrometer in the 2.0 release. SCSt 2.0 builds on the new foundation already. The goal is to convert metrics-collector into another SCSt 2.0 consumer/sink.

Acceptance:

  • Refactor and adapt to new infrastructure
  • The collector functionally provides (via REST) the same data structure currently available in 1.x
  • The newer Meter components and extra stats are "added" on top of it
  • REST endpoints continue to operate against the same user credentials
  • Unit/IT tests are refactored to adapt to the new infrastructure
  • Migration guide provided (if necessary)
@sabbyanandan sabbyanandan added this to the 2.0.0.M1 milestone Mar 1, 2018
@tzolov
Copy link
Contributor

tzolov commented Mar 26, 2018

This story depends on spring-projects/spring-boot#12594
Later enables the Spring Integration micrometer integration required to compute the stream rates.

@sabbyanandan sabbyanandan assigned jvalkeal and markpollack and unassigned jvalkeal and tzolov Mar 27, 2018
@sabbyanandan
Copy link
Author

We would also have to review the operational specifics of router-sink as part of this effort. Based on the findings and the complexity, we can split it into a different story.

@sabbyanandan
Copy link
Author

Also, note, we do not have any specifical handling in Flo for router-sink, so that's something we need to take into account as well.

@sabbyanandan sabbyanandan assigned tzolov and unassigned jvalkeal Apr 4, 2018
tzolov added a commit to tzolov/spring-cloud-dataflow-metrics-collector that referenced this issue Apr 9, 2018
Resolve spring-attic#51

- New metrics have already the rates and latencies precomputed. Therefore the rate compute logic is removed from the ApplicationMetricsService. For the same reason the Cache keeps only the last metrics for an app instance (use to keep last 2 metrics).
- New ApplicationMetrics and Metrics model classes to represent the JSON format
- New AggregateMetrics model class to represent the metrics aggregated across multiple app instances
- New compute logic for the Application#getAggregateMetrics
- The MetricJsonSerializer is altered to adapt the new Metrics format into the REST format expected by the SCDF Metrics Controller the UI
tzolov added a commit to tzolov/spring-cloud-dataflow-metrics-collector that referenced this issue Apr 11, 2018
Resolve spring-attic#51

- Extend MetricAggregator to accept and dispatch Metrics coming from SpringBoot 1.x apps as well as MicrometerMetrics from SpringBoot2/SCSt2 apps.
  - Uses the spring.integration.send string as metrics type discriminator.
- MetricAggregator converts on the fly the received MicrometerMetrics classes into Metrics such.
  - The MicrometerMetrics multidimensional (e.g. multi-tag) identity is converted into hierarchical Metrics name convention.
  - Only the spring.integration.x MicrometerMetrics metrics are filtered in.
- The MicrometerMetrics have the rates precomputed. Therefore the ApplicationMetricsService rate computation logic is applied only to the Metrics (1.x) metrics.
- New compute logic for the Application#getAggregateMetrics
- Support for mixed SCSt1.x and SCSt2.x app metrics
- Fix the Metrics 1.x tests and add MicrometerMetric tests
tzolov added a commit to tzolov/spring-cloud-dataflow-metrics-collector that referenced this issue Apr 11, 2018
Resolve spring-attic#51
Resolve spring-attic#55

- Extend MetricAggregator to accept and dispatch Metrics coming from SpringBoot 1.x apps as well as MicrometerMetrics from SpringBoot2/SCSt2 apps.
  - Uses the spring.integration.send string as metrics type discriminator.
- MetricAggregator converts on the fly the received MicrometerMetrics classes into Metrics such.
  - The MicrometerMetrics multidimensional (e.g. multi-tag) identity is converted into hierarchical Metrics name convention.
  - Only the spring.integration.x MicrometerMetrics metrics are filtered in.
- The MicrometerMetrics have the rates precomputed. Therefore the ApplicationMetricsService rate computation logic is applied only to the Metrics (1.x) metrics.
- New compute logic for the Application#getAggregateMetrics
- Support for mixed SCSt1.x and SCSt2.x app metrics
- Fix the Metrics 1.x tests and add MicrometerMetric tests
@markpollack markpollack removed the in pr label Apr 16, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

4 participants