Generic Hawkular-UI in MiQ
by Heiko W.Rupp
Hey,
the current way we implement the Hawkular-part of the MiQ ui is static,
where we write .haml files that show what properties and relations to
show.
Basically for each resource type one such page exists.
Adding a new kind of server like e.g. Apache Tomcat would need to add
a ton new .haml files.
In RHQ we had a pretty generic UI that was driven off of the metadata
inside the plugin descriptor. If a resource type had <operation>
elements,
then the UI showed the operations tab. Similar for the list of metrics
or the Events tab etc. Also for the resource configuration, the tab and
the
list of configuration properties was driven off of the plugin
descriptor.
See also [1].
The idea is now to apply the same mechanics to the ManageIQ UI so that
the resource type definitions coming from the agent can drive the UI.
We most probably need to extend the current config [2] to show
- what is shown by default
- how relations are to be shown
- which properties should be grouped together
The agent would store those in the resource type, which MiQ
can pull and build the UI from those definitions.
There is currently a rough spot: how to deal with one / more "competing"
WildFly RTs?
In RHQ we had the one canonical definition of a
resource type. Now each agent could send a different one. While
technically we can
work with that, it may be confusing if 2 WF-standalone look different.
It will not happen
often though - especially in container-land, where the config is "backed
into the image".
I wonder if we should change this way of inventory a bit to be similar
to RHQ (but more
simple):
- RT definition is done on the server
- agent asks for the RT definition on 1st start
- MiQ also gets the RT definition from the server.
With Inventory.v3 this may mean that some startup code needs to populate
RTs
and probably periodically refresh them.
Thoughts?
[1]
https://github.com/pilhuhn/misc_writing/blob/master/HowToWriteAnRhqPlugin...
[2]
https://github.com/hawkular/hawkular-agent/blob/master/hawkular-javaagent...
8 years, 9 months
Openshift/k8s templates, tagged images vs IfNotPresent
by Pavol Loffay
Hi,
we are providing OpenShift and k8s templates for Jaeger project
https://github.com/jaegertracing.
What is the "standard" in the industry when providing *public* templates?
Should we use tagged versions of images or depend on IfNotPresent strategy
(pull image when not present)?
I would say that public templates should use tagged versions because it's
always tested against a specific version and therefore guaranteed that it
works as expected. This also seems to be the case templates provided by
fabric8 team. Another thing is that templates not using tagged versions
might get quickly outdated.
IfNotPresent may lead to weird states when a template is not compatible
with pulled image. Plus it does not allow to simply update deployment when
using tagged templates.
I'm just interested in what people think and use.
Regards,
--
PAVOL LOFFAY
Red Hat Česká republika <https://www.redhat.com/>
Purkyňova 111 TPB-B 612 45 Brno
M: +421948286055
<https://red.ht/sig>
8 years, 10 months
https://hub.docker.com/r/hawkular/*
by Jiri Kremser
Hi,
the Dockerhub is the image registry that is enabled by default for
dockerd. IMO, we can't support only our internal RH registries and ignore
the dockerhub. This is what we deliver to the community. Less and less
people are downloading zip files and installing stuff these days (or even
using package managers). If I want to try tool/product/project X (where X
can be prometheus, ) First thing that comes to my mind is to google for the
docker image and some short code (like `docker run -e foo=bar org/image`)
that I can copy&paste to the terminal and have everything set up correctly.
We have nothing like that today and that was 1 of the reasons, why I
started the hawkinit cli/tui tool.
Currently we have dozens of images there that are obsolete or that were
used for 1 particular use-case/demo. For instance the hawkular-metrics
https://hub.docker.com/r/hawkular/hawkular-metrics/tags/ has the latest
change before 2 years and contains bunch of images that have snapshot in
the tag. If I am a newcomer trying to play with hawkular-metrics, I would
run away quickly.
The very first image is the https://hub.docker.com/r/hawkular/hawkular/
which should be the "Hawkular", right? Last change is 1 year old and again,
for the newcomers it's hard to explain the fact that it's the old version
containing the old components, but it has the rich UI, while the new ones
have no UI, but new components.
Could you guys look and reply to this email if you want to preserve certain
image?
Currently these are 'maintained' and quite ok (I didn't go through all of
them):
* hawkular-services
* hawkular-openshift-agent
* wildfly-hawkular-javaagent
* wildfly-hawkular-agent-domain
* wildfly-hawkular-agent
* hawkular-website
* hawkular-grafana-datasource
* hawkular-openshift-agent-example-jolokia-wildfly (despite the name, (name
!= description))
... the rest seems to be abbandoned or was created for some demo and it's a
question if those images should be under the hawkular org, or if we
shouldn't move them to something like hawkular-labs or hawkular-examples,
or similar. I don't know.
One note to the naming: we have quite a lot of different agents without any
description or metadata in the image itself, what should I use and when? I
know that, mazz knows that and probably couple of other guys know that, but
people out there would have no idea.
Perhaps it would be good to have also some thoughts from people that are
relatively new in the team or work a lot with the d. images. Like Caina,
Paul, Josejulio.
wdyt, guys?
jk
8 years, 10 months
Application Performance Metrics within minishift
by Abdel Hegazi
Hi,
I am trying to find a way to visualize APM within each container running
which is something I am not able to do with Prometheus (I am running
Openshift Origin/ minishift)
With some help from google, I found this blog post from openshift guys
https://blog.openshift.com/performance-metrics-apm-spring-boot-microservi...
which (theoretically) is exactly what I am looking for but it looks like
nothing it really working as the documentation says as I am always hit by
this error message which I already posted at the comment section but no one
replied
ERROR: Neither $JAVA_MAIN_CLASS nor $JAVA_APP_JAR is set and 0 found in
/deployments (1 expected)
As I see the ENTRYPOINT is missing, so regardless the the value of the
$JAVA_OPTIONS env variable it doesn't look like it feels it.
So, with some more search I found this blog post by you which seemed great,
http://www.hawkular.org/blog/2017/03/25/collecting-application-metrics-op...
but the thing even starting $minishift --metrics but I am still not able to
receive any metrics as it always says metrics isn't enabled within the
cluster.
I tried to run some of the example mentioned wildfly, java, python ..etc
something is still missing, I am not able to find-out what should I do as
to get some metrics I am assuming all of these base images in all your
examples will have hawkular agent .jar injected within them so that they
should be able to export metrics to wherever endpoint, what I would like to
have either to visualize these metrics at grafana (which I assume via
prometheus) or at hawkular server interface.
Is there any working documentation which is actually updated and tested?
Thanks,
--
Abdel
8 years, 10 months
Application metrics from Jaeger clients
by Gary Brown
Hi Metrics Experts!
Re: https://github.com/uber/jaeger-client-java/issues/172#issuecomment-299723621
This issue is concerned with supporting Prometheus endpoints within the Jaeger instrumented client applications, to capture Jaeger related metrics (e.g. number of spans reported/sampled/dropped, etc) but also application metrics - i.e. number of requests, errors and latency(duration) for different services/operations (endpoints).
As we will be interested in capturing and analysing these metrics within Hawkular Metrics, would be good if someone with relevant experience could get involved in the discussion to ensure the metrics are reported in the most appropriate way.
For example - is it a good idea to have generic metrics names (jaeger-rpc.requests - which I assume is a counter, and jaeger-rpc.latency), or a metric name per endpoint - e.g. I was thinking service.operation.direction?
Based on the referenced comment, I'm not sure how the tags would relate to the metric names - I thought the tags needed to be constant for a particular metric name, but it might be my misunderstanding of what they are proposing.
Would be good to discuss - possibly here first and then when better understood make a proposal on the github issue.
Regards
Gary
8 years, 11 months
