I'm new to metrics in general and especially Micrometer, so this might be a dumb question:
Micrometer describes itself on the home page as a "facade" "without vendor lock-in", "think SLF4J, but for metrics". With "built-in support for [...] Netflix Atlas". The docs say it's included in Spring Boot 2.
So what I'd expect is the ability to configure the monitoring system on start-up - just as I would with SLF4J. So this doc describes a setting management.metrics.export.atlas.enabled (among others) for Spring Boot. But even with this setting auto-wiring a MeterRegistry registry fails as follows:
Parameter 4 of constructor in [snip] required a bean of type 'io.micrometer.core.instrument.MeterRegistry' that could not be found.
Action:
Consider defining a bean of type 'io.micrometer.core.instrument.MeterRegistry' in your configuration.
Google led me to Baeldung where I read about some micrometer-registry-atlas dependency plus providing a MeterRegistrybean of type AtlasMeterRegistry. This works, but it's not what I call a "facade without vendor lock-in", but I guess I'm just doing it wrong?
How can I provide the monitoring system during runtime, switching between Atlas and any other without re-compiling?
#crusy you are actually right, but the feature is part of the Actuator module. This is not well documented and I was lucky to find the answer in the Spring Boot Gitter channnel https://gitter.im/spring-projects/spring-boot/archives/2019/01/24?at=5c4980b00721b912a5cdc02f.
You will notice that the Metrics section in the Spring Boot documentation is under Actuator: https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#production-ready-metrics.
This means that in order for Micrometer to work out of the box, you need to include Actuator in your build. E.g for Gradle:
implementation ('org.springframework.boot:spring-boot-starter-actuator')
The MeterRegistry bean will be there now.
One of the definitions I found on Wikipedia says that vendor lock-in:
makes a customer dependent on a vendor for products and services,
unable to use another vendor without substantial switching costs.
Micrometer helps to unify interfaces to collect metrics (timers, gauges, counters, etc.), but there is no standard on how these metrics are shipped to backends (Atlas, Prometheus, etc.). That is the main reason why you need to define a specific library (micrometer-registry-atlas), properties, and sometimes also additional configuration.
Micrometer doesn't bring costs needed to switch to another backend to zero, but at least they are kept to minimum.
Related
When creating a new Spring Boot project using Spring Initializr and adding Azure Support, it adds a dependency to com.microsoft.azure:azure-spring-boot-starter.
implementation 'com.microsoft.azure:azure-spring-boot-starter'
The spring cloud documentation says:
The Azure Support entry contains auto-configuration support for Azure
managed services [...]
Now I'd like to send and receive messages from Azure Service Bus and the documentation wants me to add a dependency to azure-servicebus.
implementation 'com.microsoft.azure:azure-spring-boot-starter'
implementation 'com.microsoft.azure:azure-servicebus'
Okay fine. When I now switch over to Microsoft and read the documentation about Service Bus there, it mentions two libraries, where Microsoft states the second one is dated and legacy.
azure-messaging-servicebus (latest) implementation 'com.azure:azure-messaging-servicebus:7.0.0'
azure-servicebus (legacy) 'com.microsoft.azure:azure-servicebus'
Question
Is the Spring Boot documentation just outdated?
I have read somewhere that libraries in com.microsoft.com are for managing the resource itself, while libraries in com.azure are for managing the data. Is this true?
What is meant by auto-configuration support?
As you can see I am very confused which dependencies I need to add. Also I don't get the difference between packages from com.azure and com.microsoft.azure.
Can someone please shed some light on this?
I mean the Eclipse preference under Window|Preferences|Spring|Beans Support
"Disable Auto Config Detection".
When this option is not checked, I notice a delay when saving Java files:
Building Workspace...
Loading ...ServerApplication
or
Loading ...DaoConfig
These messages are for Spring Boot main application classes (ServerApplication) or Spring configuration classes with #ComponentScan (DaoConfig) which are located in the workspace.
This can take a few seconds, which is a bit annoying.
When I check the above preference option, I don't notice the delay for loading these classes (at least for the Spring Boot main classes).
What are the consequences of disabling Auto Config Detection, e.g. what does this option really do, what functionality do I loose? Any pointers to documentation?
Can I speed up the save process without having to disable Auto Config Detection?
In STS3, the IDE creates an internal model of your Spring application, so that it can display a nice overview of your Spring elements in the Spring Explorer view, provide content-assist in Spring XML config files and more. In order to build up this internal Spring beans model, it needs to know where to start from when building that model. You can define those entry points manually in the properties for each project: Spring -> Beans Support. That preference allows you to define Spring XML config files and/or Spring-annotated configuration classes to be used by the IDE internally to build up that model.
In addition to that there is a mechanism to detect those files (Spring XML config files and Spring Boot application configuration annotations) automatically, so that you don't need to configure them manually. But the result is the same. Those files/classes end up being configured to be used by the IDE to built this internal model.
I guess that the delay that you see comes from building this internal beans model - this is at least what the messages indicate that you mentioned.
So far for the background. You can disable that auto-config mechanism and you don't need to configure those files/classes manually. This will result in the Spring Explorer, for example, not showing anything meaningful for those projects.
As an alternative and in case you are working mostly with Spring Boot projects, I would strongly recommend to switch to the all-new Spring Tools 4 (also available as a ready-to-use Eclipse distribution). It provides a slightly different set of features and is implemented in a different way, so that it doesn't need the expensive internal bean model creation. You should give it a try. And if you are missing something that you love in STS3 that is not yet part of Spring Tools 4, let us know.
After some researching, I have discovered that there is a spring actuator project which is used to monitor and log information about the application. Here is the link that suggests how to put log in to my own custom repository for post processing. [http://www.sedooe.com/2017/08/tracing-requests-and-responses-with-spring-boot-actuator/ ]
However, the total in/out byte counts are not included. I know that I can try to wrap HttpServeletRequest and HttpServeletResponse (in the filter, pass them to the filter chain so that it can count in/out throughput whenever they are consumed or written out) which will return custom SerlvetInputStream and ServletOutputStream that can count the number of bytes.
This seems to be a common problem in business application and there should already be a solution so I wonder if there is any easier way to achieve this.
From my understanding the Spring-Boot 1.5 actuator implementation doesn't provide such a functionality. (Assuming you are talking about Spring-Boot 1.5.)
What you could do is having a look at the Micrometer project. It's the new actuator metrics "backend" for Spring-Boot 2.0. In case you are still using Spring-Boot 1.5 you can use the micrometer-spring-legacy library in your app.
Key thing to understand here is that for Spring-Boot 1.5 this is a metric backend which is living next to the "old" actuator.
What the project provides is instrumentation for embedded Jetty and Tomcat server. Allthough only the latter does provide in and out traffic metrics.
Assuming Tomcat, you'll get tomcat_global_received_bytes_total and tomcat_global_sent_bytes_total metrics over which you can reason about in your favorite monitoring system.
I use Apache commons config very often, and its a great library .
I wander what's springs solution to handling property files.
I have seen a few DataSource JDBC config examples, and I want to know more.
hope it has set of great features the commons offers, such as variable substitution etc..
For a quick introduction, check Spring 3.1 M1: Unified Property Management. From the summary:
Summary
Spring's Environment abstraction provides a single location to configure both profiles and properties. Profiles, as described in earlier posts, determine which bean definitions should be registered for a given deployment context; the property support described in this post provides a consistent abstraction over any source of properties, resulting in more flexible property access and placeholder resolution throughout your application configuration.
When we run a sample main program which reads a applicationContext.xml with a single bean..
how does Spring do the logging..and how can one overwrite the default logging.
I didnt see any log4j.xml in the spring dependencies as well..
Regards
This is described in the documentation:
Logging is a very important dependency for Spring because a) it is the only mandatory external dependency, b) everyone likes to see some output from the tools they are using, and c) Spring integrates with lots of other tools all of which have also made a choice of logging dependency. One of the goals of an application developer is often to have unified logging configured in a central place for the whole application, including all external components. This is more difficult than it might have been since there are so many choices of logging framework.
The mandatory logging dependency in Spring is the Jakarta Commons Logging API (JCL). We compile against JCL and we also make JCL Log objects visible for classes that extend the Spring Framework. It's important to users that all versions of Spring use the same logging library: migration is easy because backwards compatibility is preserved even with applications that extend Spring. The way we do this is to make one of the modules in Spring depend explicitly on commons-logging (the canonical implementation of JCL), and then make all the other modules depend on that at compile time. If you are using Maven for example, and wondering where you picked up the dependency on commons-logging, then it is from Spring and specifically from the central module called spring-core.
The nice thing about commons-logging is that you don't need anything else to make your application work. It has a runtime discovery algorithm that looks for other logging frameworks in well known places on the classpath and uses one that it thinks is appropriate (or you can tell it which one if you need to). If nothing else is available you get pretty nice looking logs just from the JDK (java.util.logging or JUL for short). You should find that your Spring application works and logs happily to the console out of the box in most situations, and that's important.
(emphasis mine)
Follow several sections describing how to use various logging frameworks.