I'm trying to setup prometheus metrics with CircuitBreaker, our application uses CircuitBreakerConfigCustomizer with an entry in application.properties as outlined in https://resilience4j.readme.io/docs/getting-started-3
Since its a customizer, we need an entry in application.properties to set resilience4j.circuitbreaker.backends.backendA.register-health-indicator=true where backendA is the circuit breaker name.
Probably, this is associating the CB backendA with some registry. However, I want to retrieve this registry so that I can use TaggedCircuitBreakerMetrics.ofCircuitBreakerRegistry and bind it to a PrometheusMeterRegistry - but how can I fetch the associated registry?
I created a new registry using ofDefaults() but that is a different instance and doesn't have references to the backends already defined in properties.
How do I setup metrics to work with this setup?
Since you are using micrometer, resilience4j provides a micrometer module so that the metrics would be exported out of the box.
Check the documentation for details here
Related
I would like to generate a list of my application configuration values, with their description and default values. Just like quarkus has for the framework itself on https://quarkus.io/guides/all-config, but for my application properties.
Would it be possible to achieve this using the SmallRye Config or Quarkus APIs?
Quarkus does not have an official support for this. This has been discussed, and there is even an issue to add it properly at some point: https://github.com/quarkusio/quarkus/issues/19020
At your own risk, you can add the quarkus-extension-processor to your project and annotate the mappings with #ConfigRoot(phase = ConfigPhase.RUN_TIME)(it still requires the #ConfigMapping), which will generate the adoc files used by Quarkus for its own configuration.
I want to configure the CosmosQueryRequestOptions.maxDegreeOfParallelism while using the CosmosRepository. I didn't find any documentation around it.
This blog shows how to configure and use this setting through a custom client, but I want to use the repository instead. https://medium.com/#middha.nishant173/improve-query-performance-with-azure-cosmosdb-java-sdk-v4-db1fc54cb484
CosmosQueryRequestOptions is implementation detail for Spring Data Cosmos SDK, so customers cannot set it through spring application.
This can be implemented as a new feature, and can be exposed through application.properties via query.maxDegreeOfParallelism - which customers can opt in if they want.
Default value for maxDegreeOfParallelism is 0, which is the right value for single partition queries. For cross partition queries in the current SDK version, you can get the cosmosClient through spring boot applicationContext and run the query directly against the client. This example shows how to do it - https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/cosmos/azure-spring-data-cosmos-test/src/test/java/com/azure/spring/data/cosmos/repository/integration/PageableAddressRepositoryIT.java#L144
I am implementing a Spring Boot application which will be providing a multitenant environment. That is achieved in my case by using a database schema for each customer. Example see this project.
Now I am wondering how to implement tenant-specific configurations. I am using #ConfigurationProperties to bundle my property values, but these are getting instantiated once and not for each tenant.
What if I would like to use Spring Cloud Config with multiple tenant specific git repository as an configuration backend. Would it be possible when using a jdbc backend for Spring Cloud Config?
Is there any way with default Spring mechanisms or do I have to implement a database based configuration framework myself?
Edit: For example I have two tenants called Tenant1 and Tenant2. Both are running over the same application in the same context and are writing in the database schemes tenant_1 and tenant_2.
Identification of tenants is happening over keycloak (see Spring Keycloak multi tenant example). So I identify the tenantId from the jwt token and select the database connection like described here.
But now I would need the same mechanism for #Configuration beans. Since #Configuration beans are as far as I know Singletons, so there is always ONE configuration per application scope, and not ONE configuration per tenant.
So using Spring Cloud Config Tenant1 is using https://git-url/tenant1, Tenant2 is using Hashicorp Vault as backend and perhaps Tenant3 will be using a jdbc based configuration backend. And all of that in ONE (of course scalable) application.
In case your application uses tenant specific files (html templates etc), the following can be applied. As I have used the below approach for handling many tenants and works fine and easy to maintain.
I would suggest that you maintain a consistent configuration source (JDBC) for all of your tenant configurations. This helps you have a single source that is cacheable and scalable for your application. Also, you could have your tenants navigate to a configuration page to manage their settings and alter them to suit their needs at any point of time on the fly. (Example Settings: Records Per Page, Theme, Logo, Filters etc...)
Having the tenant configuration in files in git will be a difficult task when you wanted to auto-provision tenant's when they sign-up as it will involve couple of distributed services. Having them in a TenantSettings table with the tenantId as a column could help you get the data in no time and will be easy.
You can use Spring Cloud Config for your scenario and it is adoptable. It is easily configurable and provides out of the box features. For your specific scenario, you can have any number of microservices running yet all controlled by one Spring Cloud Config Server which is connected to one Git Repository. Your all microservices are asking configuration properties from Spring Cloud Config Server and it is directly fetching properties from Git Repository. That repository can have multiple property files. It can hold common properties for all the microservices or specific service based configuration properties. If you want to keep confidential properties more securely, that is also made possible via HashiCorp vault. I will leave an image below for you to get a better idea about this concept.
In the below image, you can see the Git Repository with common configuration property files and specific configuration property files for different services yet in same repository.
I will add another image for you to get a better idea how does this can be arranged with application profiles as well.
Finally I will add something additional to show the power of Spring Cloud Config and out of the box features it allows us to play with. You can automatically refresh configuration properties in running application as well. You can configure Spring Cloud Config to do that. I will add an architectural diagram to achieve that.
References for this answer is taken from Spring in Action, Fifth Edition
Craig Walls
I have a springboot 2 application, and I want to display metrics in AWS Cloudwatch.
I have included micrometer cloudwatch dependency in pom.
Here setting is documented for various metric systems but not cloudwatch.
Whar else configurations I need to do for cloudwatch?
First of all you may have to add some additional dependecies. I needed the following:
org.springframework.boot - spring-boot-starter-actuator
org.springframework.cloud - spring-cloud-starter-aws
io.micrometer - micrometer-core
io.micrometer - micrometer-registry-cloudwatch
Boot was not able to manage the versions for these dependencies except for actuator in my case, so you might have to figure out the right versions for you.
Firthermore some application properties have to be set:
# disable unwanted features to prevent autoconfigure which will produce errors and abort of application startup eventually
# alternatively you can try to configure those features correctly if you intend to use them
cloud.aws.stack.auto=false
# enable micrometer for cloudwatch (only where there is actually access to it)
management.metrics.export.cloudwatch.enabled=true
# set the namespace that will contain the metrics for this application
management.metrics.export.cloudwatch.namespace=test
# set max batch size to the actual maximum (if not a bug in certain versions of micrometer for cloudwatch will send
# batches that are too big)
management.metrics.export.cloudwatch.batchSize=20
The next step will be in AWS. The role associated with your EC2-instance (or whatever you are using) needs to have the permission CloudWatch:PutMetricData.
Using this configuration should enable CloudWatch-Monitoring for your Spring-Boot-Application.
One of the sources I encountered stated that you should use:
cloud.aws.credentials.instanceProfile=false
This will prevent Spring Boot from automatically obtaining credentials that are necessary to push metrics to CloudWatch. You could also provide own credentials another way, but I didn't try that.
I'm using Spring 2.5.6. I have a bean whose properties are being assign from a property file via a PropertyPlaceholderConfigurer. I'm wondering whether its possible to have the property of the bean updated when the property file is modified. There would be for example some periodic process which checks the last modified date of the property file, and if it has changed, reload the bean.
I'm wondering if there is already something that satisfies my requirements. If not, what would be the best approach to solving this problem?
Thanks for your help.
Might also look into useing Spring's PropertyOverrideConfigurer. Could re-read the properties and re-apply it in some polling/schedular bean.
It does depend on how the actual configured beans use these properties. They might, for example, indirectly cache them somewhere themself.
If you want dynamic properties at runtime, perhaps another way to do it is JMX.
One way to do this is to embed a groovy console in your application. Here's some instructions. They were very simple to do, btw - took me very little time even though I'm not that familiar with groovy.
Once you do that you can simply go into the console and change values inside the live application on the fly.
You might try to use a custom scope for the bean that recreates beans on changes of the properties file. See my more extensive answer here.
Spring Cloud Config has facilities to change configuration properties at runtime via the Spring Cloud Bus and using a Cloud Config Server. The configuration or .properties or .yml files are "externalized" from the Spring app and instead retrieved from a Spring Cloud Config Server that the app connects to on startup. That Cloud Config Server retrieves the appropriate configuration .properties or .yml files from a GIT repo (there are other storage solutions, but GIT is the most common). You can then change configuration at runtime by changing the contents of the GIT repo's configuration files--The Cloud Config Server broadcasts the changes to any Client Spring applications via the Spring Cloud Bus, and those applications' configuration is updated without needing a restart of the app. You can find a working simple example here: https://github.com/ldojo/spring-cloud-config-examples