Documentation writing
by Heiko W.Rupp
Hey,
as we made some progress with hawkular.github.io, the question came up what should go there and if we can't just use something else instead.
I am very much in favor of using AsciiDoc + git for the documentation -- user and developer
Clear advantages that I see for this solution:
- versioning is easy as it is built into git. We can easily create branches for various versions of the Hawkular
without the complicated clone process that we had in the past
- offline possibility an author does not need to be online to write docs
- AsciiDoc is plain text. The pages may have a handful of specific header lines, but if you don't want to format any markup, then just don't
- Contributing is easy. People just git clone the repo, make their changes and submit a pull-request
- docs are directly rendered on GitHub
- AsciiDoc is already used in our README.adoc files
- With AsciiDoctor there is a good tool chain for creating good print, html, pdf, docbook output
- it is possible to write docs in vi/emacs/Notepad
Tooling may not yet be that perfect; the mvn jbake:inline mode is already quite well able to re-create
the website locally though; with a browser extension like "live-reload", editing a text is as wysiwyg as on a wiki
There are other JBoss projects that follow the AsciiDoc+git approach with great success
like http://arquillian.org, http://hibernate.org, http://liveoak.io, http://torquebox.org(*)
Anyway I've started a doodle to get feedback and then proceed further - so please visit
http://doodle.com/a8ctk6wgwi3nh9f8
so that we can come to a documentation solution that we all use.
Heiko
*) Actually uses Markdown as markup language
11 years
Response time ?
by Thomas Heute
What is a useful representation of a response time over a period of time ?
- Average of all the samples ? *2.22s*
- 90/95/99 percentile ? 99% of your requests took less than *2.45s*
- Percentage of valid samples ? *94%* of your requests took less
than your 3s acceptable time.
- Apdex ? http://en.wikipedia.org/wiki/Apdex
Anything else ? (This is for a quick overview of the health of a system).
Thomas
11 years
Availability (Service and UI)
by Thomas Heute
Getting back to availability discussion...
To me availability is a set of periods, not so much "time series" and we
should just record change of status (closing the previous event and
opening a new one).
- Server is up from 8:00am to 11:30am
- Server is down from 11:30am to 11:32am
- Server is unknown from 11:32am to 12:00pm (an agent running on a
machine can tell if a server is up or down, if the agent dies then we
don't know if the server is up or down)
- Server is in erratic state from 12:00pm to 12:30pm (agent reports
down every few requests)
We were discussing the best way to represent availability over time in a
graph, representation in RHQ [1] is very decent IMO, can be extended
with more colors to reflect how often/long the website was down for each
"brick" (if the line represent a year with 52 blocks, 1 block can be
more or less red depending on how long it was done during the week).
But thinking of it more, availability graph is not that interesting by
itself IMO and more interesting in the context of other values.
I attached a mockup of what I meant, a red area is displayed on response
time graph, that means that the system is down, obviously there is no
response time reported anymore in that period. Earlier there is an
erratic area, seems related to higher response time ;) Rest of the time
the system is just up and running...
Additionally I would want to see reports of availability:
- overall availability over a period of time (a day, a month, a
year...). "99.99% available in the past month"
- lists of the down periods with start dates and duration for a
particular resource or set of resources (filtering options)
Thoughts ?
[1]
http://3.bp.blogspot.com/-0MsmG5h5i5E/TfjTMZlvx3I/AAAAAAAAABU/6PKDs0RlzuI...
Thomas
11 years
Low-impact clients and never dropping any events
by Randall Hauch
Forgive my ignorance, but I’m new to the list and I didn’t see anything in the archives about $subject, detailed below. Lately I’ve been very interested in several topics ancillary to monitoring, so I’m quite intrigued by the planned direction and approach.
How do clients/systems/services that are to be monitored actually send their monitorable information? What is the granularity of this information: is it already summarized or somewhat aggregated in the client, or is it very low-level and fine-grained events? What is the impact on the client of adding this extra overhead?
Do you have an estimate or goal for how much volume of incoming data can be handled without impacting on clients? What, if anything, does a client submission wait for on the back-end?
Also, how do you plan to ensure that, no matter what happens to the Hawkular system or anything it depends upon, no client information is every lost or dropped?
Finally, is the plan to make Hawkular embeddable (excluding the stuff that has to be embedded in monitored clients/systems/services), or only a separate turn-key (i.e., install-and-run-and-use) system?
Thanks!
Randall Hauch
11 years
[metrics] Small agent to push metrics
by Michael Burman
Hi,
There was discussion on #hawkular at some point about providing real
world metrics to get some understanding on how the system works in
reality. Following the python-client, here's a small agent that will
supply metric-information of cpu & memory to the Hawkular-metrics instance:
https://github.com/burmanm/gather_agent
The only external requirement is installing rhq-metrics-python-client
(with the setup.py) and it should work fine (version 0.2.2 required,
which is the current one). If you want to see those metrics in the
hawkular-metrics-ui, remember to use correct tenant (test).
- Micke
11 years
Water cooler tomorrow - Hawkular Accounts
by Juraci Paixão Kröhling
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Team,
As mentioned in another thread, I've started a draft for another
Hawkular component that would take care of the permission checking,
based on the idea that we would not have tenants, but users and
organizations.
This is still an early draft (as most components, I assume), but I'd
like to get some feedback about it.
The backend code is here:
https://github.com/hawkular/hawkular-accounts
I started a draft for the UI as well, but it's not very interesting at
this point (I used it mostly to test the authentication):
https://github.com/jpkrohling/hawkular-ui-components/tree/JPK-AccountsUI
On the backend, there's a "sample" module, which shows how an external
component (ie: yours) can make use of the permission checker and of
the organization/user services.
I would like to have a water cooler discussion about it sometime this
week, hopefully tomorrow or Friday.
- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJU5JD/AAoJECKM1e+fkPrXCoAH/jYpyvR4ELGQeauR8zhdQ6PE
K3mdIYlOOn0LRVA288+XM5zETqTkc47KXf9MmRPkwXI4g/7GuDm/GY9+mu3HrpK2
DkyQo0urVKlpCAii4tYrTwMcsSyfMDSE0vFhtIRxC7mTpgd7gKOA59BRR64KSGfp
HZHpUxMpwHOBXneHoOmG5h8SY5Y0KUHFW4h13mrGaTk8Sf92M8Ng+LmLd1EB5hwy
GEegstGLtpPMQ6aLcHChiOzVB5unxKpPRB2IkZ7xOvHFxxc5zdUiUu+6809Ln9le
ntisWvlLgswjhWW16gxZktmU0hwxgrrvlT39qLpvIk6ONQyhrWeAVgVtQ/RaDJk=
=8UO+
-----END PGP SIGNATURE-----
11 years
integration assembly distro is ready
by John Mazzitelli
OK, all the components for our test distro are on the nexus snapshot repo and we can build a test distribution by simply cloning the "mazz/integration-assembly" branch in the hawkular repo - found here:
https://github.com/hawkular/hawkular/tree/mazz/integration-assembly
"mvn clean install" will build the distro zip (if you build with -Pdev, it will unzip for you in the target/ dir).
Simply run wildfly*/bin/standalone.sh and you'll run the server with everything in it.
Does it do anything? I'll leave that up to the folks that wrote the individual components (alerts, metrics, inventory, etc) to tell us :)
But it does run and everything deploys.
Note: because they are snapshots, you don't have to build any of the components yourself. If anyone commits fixes to those components, github/travis will deploy those new snapshot builds to nexus and you can just rebuild your distro locally to pick up the change. So you really only need https://github.com/hawkular/hawkular/tree/mazz/integration-assembly git cloned locally.
Note that the assembly distro itself is NOT uploaded to nexus - so there is no download of the zip yet. If we want to consider doing this, it should be easy.
11 years
