adessose / eureka-prometheus-bridge Goto Github PK

On startup, log all configuration parameters and their values and check if all mandatory parameters are valid (config template file must exist, for example). Throw an exception if not valid so that the application doesn't start at all.

#8

Instead of handling the YML as a string, it should be handled with a YML library that allows handling it via Java (or Kotlin). This way, we have a refactoring-safe (and easier-to-test) way of dealing with YML.

... for full featured example with one command to start.

Instead of passing all configuration parameters as @value into the Generator and ScheduledJob classes, it would be better to use @ConfigurationProperties to bind them to a new class EurekaPrometheusBridgeProperties
and inject this class into classes that need those properties.

Create a github repo that contains examples so that an interested user can easily run it to test the bridge. The repo should contain:

• a Spring Boot App that acts as Eureka Server

• two Spring Boot Apps that act as Eureka Clients

• a guide on how to run the bridge to work with the eureka server

• Reminder: "/prometheus" endpoint needs to be defined by the eureka-clients.

Then:

• Link this repo from the README

Provide unit tests for all classes.

add a Travis CI pipeline that build the app, runs the tests and automatically deploys the JAR and the docker file to the adesso organization on Bintray.

Hi Silas,
very interesting project!

I have a little enhancement for your Dockerfile:

• Switch from java base image to openjdk, because java ist deprecated
• add the -XX:MaxRAM flag to avoid java taking more RAM than docker allows, which would lead to automatic shutdown of the container

You'll find more information in my Template for a Dockerfile to run a spring boot application.
You could also check out Halil's talk about DBs and Java in Docker

Best regards
Kevin

Provide a readme that explains

• what this application does and why it was built
• all configuration parameters
• how to start the application (with and without docker)
• where to download the application or docker file
• how to configure Prometheus

Currently, the interval to query Eureka is fix every 10 seconds, since it's defined in @Scheduled(fixedRate = 10000)

It would be nice to make this interval configurable. We could leave the @Scheduled annotation as is but add a check to the start that checks if the last job was longer than <configurable_interval> ago by storing the last execution time in an instance property (a little dirty, since the class has state then, but I wouldn't mind for this use case).

and copy the file to this certain location, so generation is better separated from the file which falls out

The logic for querying Eureka should be extracted into a separate class. The class ScheduledJobs should simply provide the @Scheduled entry point and orchestrate any classes that do stuff.

• protect branches

• create pull-rq template

when basic app is finished

Currently, there are 2 @ScheduledJobs, one that pulls the data from Eureka and one that writes it into the Prometheus file. Why are those separated? This may lead to all kinds of synchronization issues.

Better to make a single @ScheduledJob that pulls the data and directly writes it into the prometheus configuration file. This way, the service does not need to manage state.