A developer may think that its job scope is bound to the functional part of the application. Valid and validated, the application runs and works fine. It meets the specifications and never hangs, dies or misfunctions, it is documented and tested. For god's sake, it is the best application I have ever seen.
But this developer cannot answer some very easy questions: Is it running right now? How can I know it is running? Can I automatize this knowledge in any way?
If your application is a CRUD database manager for documents, you can enter in the application, notice it is up, login yourself and use the wet finger method for more health and performance measures. However, if your application controls thermonuclear weapons, please make us a favor and resign.
I was asked to develop a plugin for every company application, in order to get current status, some statistics and maybe perform some executions to self-testing methods. After several weeks and thousands of euros invested on this project, I managed to create a /checkUp servlet that performed a database test and, if /checkUp responded "ok", then we assumed that the application was up.
Fortunately, JavaMelody did this for us, much better, much easier, much appealing... I couldn't have done it better, for sure.
Follow the installation, just include 2 jars and 10 lines in your web.xml file, and you will have lots of statistics, a /monitoring servlet giving all pretty-printed data and some performance measures.
From its web:
"The goal of JavaMelody is to monitor Java or Java EE applications servers in QA and production environments. It is not a tool to simulate requests from users, it is a tool to measure and calculate statistics on real operation of an application depending on the usage of the application by users.
JavaMelody is opensource (LGPL) and production ready: in production in an application of 25 person years. JavaMelody is easy to integrate in most applications and is lightweight (no profiling and no database).
JavaMelody is mainly based on statistics of requests and on evolution charts.
It allows to improve applications in QA and production and help to:
give facts about the average response times and number of executions
make decisions when trends are bad, before problems become too serious
optimize based on the more limiting response times
find the root causes of response times
verify the real improvement after optimizations
It includes summary charts showing the evolution over time of the following indicators:
Number of executions, mean execution times and percentage of errors of http requests, sql requests, jsp pages or methods of business façades (if EJB3, Spring or Guice)
Java memory
Java CPU
Number of user sessions
Number of jdbc connections
These charts can be viewed on the current day, week, month, year or custom period."
Certainly, installing it took me no more than 10 minutes, using Maven dependencies, on an already existent application, and result was impressive, something like this (took from JavaMelody):
Something similar can be got using JMX, but it takes longer, and it is less human readable.
Try it in any of your applications, you will repeat!
Albert Navarro :)
This blog is written for teaching about Java technologies and best-practices. I will talk about patterns, Maven, J2EE, Artifactory, Hudson, Sonar, and so on.
Suscribirse a:
Enviar comentarios (Atom)
Etiquetas
maven
logstash
vrr
logback
json
matrix
artifactory
cis
configuration
CheckStyle
developers
devops
filebeat
ops
elasticsearch
importance
installation
java
priority
severity
tomcat
SpringSource
book of the month
critical
debug
important
log
low
plugin
What if
code repository
curator
dependencies
essential readings
essentials
structured arguments
Eclipse
Formatter
Tunning
apache
basic
best practices
codegen
continuous deployment
continuous integration
contract-first
deploy
gradle
jenkins
kibana
lombok
manager
nexus
opinion
performance
persistence
pom.xml
slf4j
storage
svn
testing
401
409
ChekStyle
Error
Homogeneous
JavaMelody
Managing
Monitoring
Scrum
Solution
Style
Trenches
XP
advantages
algorithm
ansible
architecture
aws
bitbucket
cabotrafalgar
cd
chargers
cheap
chef
ci
comparison
cons
cow
cvs
dependences
disk
distribution
docker
docker-compose
documentation
eb
ecs
elastic
elk
ender's game
enforcing
essential tools
estimation
external
fail
findbugs
folders
git
github
grok
html
hudson
ide
inheritance
javadoc
jcl
jmr
jmx
kv
libvirt
lifecycle
load
log4j
logbacl
logger
low cost
mdc
memory
multiple files
mysql
nature
nifty-gui nifty-flow
organization
permissions
pmd
pragmatic programmer
profiles
pros
puppet
q outside the office
release
remote
reporting
save
security
several files
simulated annealing
site
snapshot
sonar
standard
strategies
stress
suppressions
surveillance
tale
throughput
unit
upload
usvn
vagrant
versioning
war
wires
No hay comentarios:
Publicar un comentario
Nota: solo los miembros de este blog pueden publicar comentarios.