Reasons not to use org.jboss.logging.annotations.Cause at all?
by Peter Palaga
Hi *,
I am just improving the log output in Pinger and Availability Creator
[1] and I found out that one can define a LogMessage containing all the
details of a thrown exception (incl error message and stack trace) like
this:
@LogMessage(level = Logger.Level.ERROR)
@Message(id = 5007, value = "Could not send a message to the bus")
void eCouldNotSendMessage(@Cause Throwable e);
Indeed, messages like this can be seen in Bus, Agent and Inventory, but
nowhere else.
Are there some reasons for *not* using this @Cause message style at all?
It is clear that not every thrown exception needs to clutter the log
with its stack trace. But generally, things that are supposed to work in
all cases and situations (like sending messages to bus) should be logged
incl. stack traces, should they not?
Thanks,
Peter
[1] https://issues.jboss.org/browse/HAWKULAR-309
9 years, 6 months
Alpha1 is out, en route for Alpha2, Alpha3...
by Thomas Heute
Thank you for the hard work on Alpha 1 release.
The next prioritized topics would be:
- More Wildfly monitoring. The WF agent expose quite some metrics now,
only a few of those are currently displayed in the UI
In particular:
- HAWKULAR-217 [1] App Server Detail - JVM Metrics Tab
- HAWKULAR-218 [2] App Server Detail - Web Metrics Tab
- HAWKULAR-220 [3] App Server Detail - Deployments Metrics Tab
- Some Wildfly operations (part of HAWKULAR-220)
- "HAWKULAR-130 [4] Multiple alerts for a single issue" is close to my
heart as I find it annoying --> It doesn't have to be solved by the UI
team AFAIK, the UI shouldn't change (much).
- More integration tests (move them ?)
- ...
Beside the UI, there are quite a few things to add or start to think
about if you look at the mockups [5]
- inventory filtering/searching if that's not yet done, this was not
implemented as part of Alpha1 UI AFAIK
- actions on deployments (Enable/disable/redeploy/(add/remove)) ->
this is a new area, we should start now, it may not make it (all) for
Alpha 2
- some metrics aggregation (Active sessions for all webapps of a
single WF server for instance)
- ...
PS: Mockups attached to JIRAs are not correct
Thomas
[1] https://issues.jboss.org/browse/HAWKULAR-217
[2] https://issues.jboss.org/browse/HAWKULAR-218
[3] https://issues.jboss.org/browse/HAWKULAR-220
[4] https://issues.jboss.org/browse/HAWKULAR-130
[5]
https://docs.google.com/document/d/1kLOGUyajyMsZuJoUxrLJkOzIyQb1V_r4JHj99...
(Unfortunately this doc which adds more details is not accessible
outside Red Hat employees)
9 years, 6 months
Hawkular-pluggable data processors for metrics: Weekly Report
by Aakarsh Agarwal
Hi all,
I am currently working on the Hawkular Metrics repository as part of the Google Summer of Code 2015 program and this is to update the progress of my project.
I spent the last week familiarizing myself with the existing Hawkular Metrics repo on github and some of its code. As of now, I have created a new git repo on my github profile which intends to implement a simple plugin interface using 5 basic statistical algorithms. These are -
Minimum of the entered data set.
Maximum of the entered data set.
Average of the entered data set.
Mode of the entered data set.
Standard Deviation of the entered data set.
The link to this git repo is - https://github.com/Akki5/hawkular_plugin
This is just initial draft for the interface to be implemented. Here, StatisticalAlgo.java is the interface and other named java classes are the classes implementing the interface. PluginDemo.java is the test class. At the moment, everything in the code is hardcoded and static in nature which will later be converted for dynamic usage.
The next step requires following listed work to be done -
Use maven to build the project.
Use Classloader for all classes implementing StatisticalAlgo.
Require input from user as to which plugin is to be used.
Regards,
Aakarsh Agarwal
9 years, 6 months
On the way to the M1 release ...
by Heiko W.Rupp
Hey,
I see those things that need (at least) to be done/fixed for the next
Wed release:
- pinger does not respond to deletions (HAWKULAR-235/-263)
- inventory does not delete metrics on resource deletion HWKINVENT-45
(if INV can not make it, can UI send the delete metrics requests ?)
- duplicate URL addition HAWKULAR-255
- alerts is not multi-tenant yet (PR is sent, but may be too disruptive
?) HWKALERTS-40
-- Add url fails across tenants for same url (HAWKULAR-277 contains a
possible solution)
-- marking alerts as resolved (needs above PR for the backend)
- working pagination
- working availability charts
- move everything on non-snapshot releases
- update / write documentation on hawkular.org
As we will most probably not have full app servers functionality,
we should disable that tab so that users are not confused by it
and re-enable and work on it after the release.
Similar for the embedded agent.
Can we please concentrate on the above (and what else is needed that is
not yet on the list) to get
the release out?
9 years, 6 months
[GSoC] Hawkular Android Client: Weekly Report
by Artur Dryomov
Hi everyone,
This year I am working on the Hawkular Android application as part of the
Google Summer of Code 2015 program.
The last week I spent of familiarization with the project and its key
terms. With the help of public Hawkular servers, the Docker image and
snapshots I looked at the API and experimented a bit to understand how
things actually work. As a result I’ve created a wiki page [1] with the
brief overview of key Hawkular terms. In the process I’ve opened a very
first Hawkular issue regarding Docker image [2]. As a result of better
understanding what is what I’ve created a very rough mockup of the UI [3]
which I’ve also sent to the design team. Hopefully after a review of
functions and design I can proceed with the development itself. There is
some source code already [4] but mostly it is just a basic project
structure, it is almost useless to the end user at this point.
I would like to start the development process this week. Of course it will
require a better understanding of what actually should be done — I’ve tried
to clarify this with creating the mockup. I think a basic authentication
plus resources fetching is a good bet to work on even without clear
requirements, so it can be started right away. Probably I should prepare a
script to fill a Hawkular instance with some sample information — in Python
or just plain cURL. If anyone has something like that — that will be a
great help. I was advised to look at the test scenario [5] as a departure
point but maybe someone of you have a similar thing locally.
Regards,
Artur.
[1]: https://github.com/hawkular/android-client/wiki/Overview
[2]: https://issues.jboss.org/browse/HAWKULAR-268
[3]: https://github.com/hawkular/android-client/wiki/Design
[4]: https://github.com/hawkular/android-client
[5]:
https://github.com/hawkular/hawkular/blob/65f2573987890b1ffd4460e3449fb02...
9 years, 6 months
OAuth Documentation
by Artur Dryomov
Hi everyone,
Is there any documentation regarding the OAuth authentication method to the
Hawkular server? At moment I am using the basic authentication method and
it works well, but probably OAuth is a better thing to do.
Thanks,
Artur.
9 years, 7 months
Release instructions
by Heiko W.Rupp
Hey,
Triggered by https://github.com/hawkular/hawkular-accounts/pull/30/files
Can we please agree on one maven profile for all Hawkular components that
is used to create a release?
I think that otherwise people less versed in a certain component that need to
craft a release will just miss the right profiles.
-Pdistribution certainly sounds like a good candidate.
Heiko
9 years, 7 months
