Re: [Hawkular-dev] Pushing 'hawkular-1275' branches to master (Done)
by Jay Shaughnessy
Note that the master branches now contain the Prometheus-based
components for:
hawkular-commons
hawkular-agent
hawkular-services
The hawkular-1275 branches are no longer in use. The proper Services
docker container label is now 'latest'.
On 12/15/2017 10:55 AM, Jay Shaughnessy wrote:
>
> At this point please refrain from generating PRs against the
> hawkular-1275 branches. We are in the process of migrating to
> master. The Hawkular Commons PR is generated, after it is merged we
> can merge Hawkular Agent, and then Hawkular Services. It should be
> completed no later than Monday.
>
> On 12/14/2017 9:18 AM, Jay Shaughnessy wrote:
>>
>> Note that this is for the server-side repos:
>> hawkular-commons
>> hawkular-agent
>> hawkular-services
>>
>> The provider side repos (ruby/miq) will remain in the hawkular-1328
>> branches hosted by Edgar's github account.
>>
>> On 12/13/2017 2:06 PM, Matthew Wringe wrote:
>>> Unless there is any objection, we would like to merge the
>>> hawkular-1275 branches to master and continue to work in the master
>>> branch.
>>>
>>> Once we are in the master branch we will also be moving towards a
>>> one PR per jira issue. The workflow in jira will require this and
>>> will automatically close the jira when a PR is merged.
>>>
>>> Thanks,
>>>
>>> Matt Wringe
>>>
>>>
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>
4 years, 7 months
Re: [Hawkular-dev] Pushing 'hawkular-1275' branches to master
by Jay Shaughnessy
At this point please refrain from generating PRs against the
hawkular-1275 branches. We are in the process of migrating to master.
The Hawkular Commons PR is generated, after it is merged we can merge
Hawkular Agent, and then Hawkular Services. It should be completed no
later than Monday.
On 12/14/2017 9:18 AM, Jay Shaughnessy wrote:
>
> Note that this is for the server-side repos:
> hawkular-commons
> hawkular-agent
> hawkular-services
>
> The provider side repos (ruby/miq) will remain in the hawkular-1328
> branches hosted by Edgar's github account.
>
> On 12/13/2017 2:06 PM, Matthew Wringe wrote:
>> Unless there is any objection, we would like to merge the
>> hawkular-1275 branches to master and continue to work in the master
>> branch.
>>
>> Once we are in the master branch we will also be moving towards a one
>> PR per jira issue. The workflow in jira will require this and will
>> automatically close the jira when a PR is merged.
>>
>> Thanks,
>>
>> Matt Wringe
>>
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
4 years, 7 months
problem with jmx exporter reading an attribute we need for availability
by John Mazzitelli
Ok, well, i hate to leave it like this but - this is so friggin' odd that I can only say "it is not my fault" :)
First - note someone changed jmx exporter code because they saw the same thing as we are - that's what this comment is about:
https://github.com/prometheus/jmx_exporter/blob/master/collector/src/main...
See: https://github.com/prometheus/jmx_exporter/issues/89
But the fix is not 100%.
If you grab these three files - you can see it yourself: https://github.com/jmazzitelli/test/tree/master/javaagent
(get Makefile and the two .java files and then run "make download-wildfly unzip-wildfly compile run")
You see i use the same API as the jmx exporter here: https://github.com/jmazzitelli/test/blob/master/javaagent/TestJavaAgent.j...
and that is what you will see:
16:31:05,290 INFO [stdout] (Test Java Agent Thread) =============================================================
16:31:05,291 INFO [stdout] (Test Java Agent Thread) FIND INFORMATION ABOUT MBEAN: jboss.as:management-root=server
16:31:05,291 INFO [stdout] (Test Java Agent Thread) =============================================================
16:31:05,291 INFO [stdout] (Test Java Agent Thread) isRegistered:
16:31:05,291 INFO [stdout] (Test Java Agent Thread) true
16:31:05,291 INFO [stdout] (Test Java Agent Thread) getMBeanInfo:
16:31:05,291 INFO [stdout] (Test Java Agent Thread) description: The root node of the server-level management model.
16:31:05,291 INFO [stdout] (Test Java Agent Thread) #attributes: 19
16:31:05,291 INFO [stdout] (Test Java Agent Thread) getAttribute:
16:31:05,291 INFO [stdout] (Test Java Agent Thread) serverState=reload-required
16:31:05,291 INFO [stdout] (Test Java Agent Thread) queryNames:
16:31:05,291 INFO [stdout] (Test Java Agent Thread) []
16:31:05,291 INFO [stdout] (Test Java Agent Thread) queryMBeans:
16:31:05,291 INFO [stdout] (Test Java Agent Thread) []
16:31:05,291 INFO [stdout] (Test Java Agent Thread) queryNames(null, null):
16:31:05,291 INFO [stdout] (Test Java Agent Thread) FOUND IT: jboss.as:management-root=server
16:31:05,291 INFO [stdout] (Test Java Agent Thread) =============================================================
You will see SOME JMX APIs can see the MBean, queryMBeans and queryNames canNOT (note the empty arrays []).
But notice getMBeanInfo CAN see it - I can even get the attribute value from that! (you can see it is in reload-required state)
But again, queryMBeans returns nothing.
Oddly, queryNames(null, null) DOES return it in the list (see the "FOUND IT" line). It is only if I specifically ask for it does it fail in the query API.
The end result - JMX Exporter (at least sometimes) is not able to get "Server Availability" because it can't get this MBean.
For some odd reason it can get it sometimes - but it seems when it can't, it will never get it.
4 years, 7 months
Tip: Hawkular running in Openshift on OS/X
by Mike Thompson
This pertains only to Hawkular services running on Mac OS/X via Openshift.
There is a small but critical detail that *must* be adjusted before running
Hawkular in Openshift on OS/X. *Not doing so will result in an
endless(almost) looping and crashing of pods *with very little information
because of the pod logs/events crash very close to startup.
The trick here is to make sure that the OS/X docker has enough memory
because the default is only 2 Gb, which is not enough to run
Hawkular/Cassandra. To adjust this setting go into docker preferences and
find the *Advanced* tab. There you can adjust the Memory and CPU. The
memory is set initially at 2Gb which is not sufficient for
Hawkular/Cassandra -- *adjust this to 8 Gb or more*.
[image: Inline image 1]
The feel free to run Hawuklar/Cassandra:
`oc new-project mm-app;oc process -f hawkular-services-ephemeral.yaml | oc
create -f -`
Hawkular Services Ephemeral Template
<https://raw.githubusercontent.com/hawkular/hawkular-services/master/opens...>
Special thanks to Matt Wringe and Matt Mahoney for their time and expertise
in diagnosing this issue.
[Jstickler, you may want to add this to documentation]
4 years, 7 months
Pushing 'hawkular-1275' branches to master
by Matthew Wringe
Unless there is any objection, we would like to merge the hawkular-1275
branches to master and continue to work in the master branch.
Once we are in the master branch we will also be moving towards a one PR
per jira issue. The workflow in jira will require this and will
automatically close the jira when a PR is merged.
Thanks,
Matt Wringe
4 years, 7 months
OpenShift Deployment
by Matthew Wringe
With the changes that are now going to include Prometheus, how do we want
to deploy this in OpenShift?
We can have a few options:
ALL-IN-ONE CONTAINER
We put both Hawkular Services and Prometheus in the same container.
Pros:
- easy to deploy in plain docker (but this doesn't appear to be a usecase
we are targetting anyways)
- shares the same network connection (even localhost) and ip address (eg
but both services are on the different ports).
- Does't require any special wiring of components.
- Can share the same volume mount
- version of components can't get out of sync.
Cons:
- workflow doesn't work nicely. Docker containers are meant to only run a
single application and running two can cause problems. Eg lifecycle events
would become tricky and require some hacks to get around things.
- can't independently deploy things
- can't reuse or share any existing Prometheus docker containers.
ALL-IN-ONE POD
Hawkular Services and Prometheus are in their own containers, but they are
both deployed within the same pod.
Pros:
- shares the same network connection.
- bound to the same machine (useful if sharing the same hostpath pv) and
don' need to worry about external network configurations (eg firewalls
between OpenShift nodes)
- pvs can be shared or separate.
- lifecycle events will work properly.
Cons:
- lifecycle hooks will mean that both containers will have to pass before
either one will enter the ready state. So if Prometheus is failing for some
reason, Hawkular Services will not be available under the service.
- cannot independently update one container. If we need to deploy a new
container we will need to bring down the whole pod.
- are stuck with a 1:1 ratio between Hawkular Services and Prometheus
SEPARATE PODS
Hawkular Services and Prometheus have their own separate pods.
Pros:
- can independently run components and each component has its own separate
lifecycle
- if in the future we want to cluster Hawkular Services. this will make it
a lot easier and will also allow for running an n:m ratio between Hawkular
Services and Prometheus
- probably the more 'correct' way to deploy things as we don't have a
strong requirement for Hawkular Services and Prometheus to run together.
Cons:
- more complex wiring. We will need to have extra services and routes
created to handle this. This mean more things running and more chances for
things to go wrong. Also more things to configure
- reusing a PV between Hawkular Services and Prometheus could be more
challenging (especially if we are using hostpath pvs). Updating the
Prometheus scrape endpoint may require a new component and container.
4 years, 7 months
starting wildfly+agent using new script
by John Mazzitelli
Once my PR [1] is merged, we'll have a script to run the wildfly+agent distro easier.
Get the wildfly+agent (build from here [2]) and run the start-with-hawkular.sh script passing in a few arguments.
Usage is:
Usage: ./start-with-hawkular.sh
-d|--domain - to run in domain mode as opposed to standalone mode
-s|--server <server-name> - the host where the Hawkular Server is running
-u|--username <username> - the username to use when logging into the Hawkular Server
-p|--password <password> - the username credentials
[-h|--metrics-host <host/IP>] - the hostname to bind the metrics exporter
* -u and -p override environment variables HAWKULAR_USER and HAWKULAR_PASSWORD.
You can set those environment variables as an alternative to using -u and -p.
* -h will default to '<your machine here>' if not specified.
--John Mazz
[1] https://github.com/hawkular/hawkular-agent/pull/423
[2] https://github.com/hawkular/hawkular-agent/tree/master/hawkular-javaagent...
4 years, 8 months
need discussion around how we are going to do domain support
by John Mazzitelli
Spent time trying to figure out how to support WildFly domain mode with the new stuff. It's not going well. Next week I will need to have some discussions on how we want to do this.
The issues with domain mode (I'll try to be short):
1) host controllers do not emit JMX metrics for slave servers - just not implemented in WildFly. Need to go to slave servers for their own JMX metrics.
2) slave servers do not have managed interfaces available remotely (can't connect to slaves over remote management interface - so agent can't get any inventory from slaves - have to get all inventory from host controller)
This means our agent in the host controller needs to collect all inventory for both master host controller and slave servers.
But we need the slave servers to have a metrics endpoint because its only in the slaves where we can get JMX metrics (remember, host controller can't give us that, we must scrape the slave servers for the JMX metrics).
If we do not have our agent in slave server (why bother if we can't connect to it over DMR API to get inventory?), we still need to somehow get the P8s JMX Exporter installed in the slaves. But if we just use the raw jmx exporter agent, how do we tell our h-services server/P8s server about the new endpoint that needs to be scraped? And how do we get the jmx exporter yml config to install there?
So I suppose we should put our agent in a kind of "metrics only" mode in all slave servers so it can expose the JMX exporter and pull down the correct jmx exporter yml from h-services server and have it tell the server to add the scrape endpoint to p8s.
But because we aren't getting inventory from slave servers, how can our agent tell the server to add the scrape endpoint? Our current implementation only adds scrape endpoints to our P8s server when new agents go into inventory. Workaround: either have agent store a small inventory (just the agent resource itself) which triggers the new scrape endpoint addition, or add a inventory REST endpoint for the agent to call to add the new scrape endpoint manually.
OK, assume we have all this. How do we link the JMX metrics getting collected from one feed (the agent in the slave server) to the inventory from another feed (the agent in the host controller). Right now, it is assumed the inventory metadata from feed "A" is matched with metrics from the same feed. Now that we have to break that link (feed A's inventory refers to feed B's metrics) we need to figure out how to fix this.
There are other ancillary issues - like how do I get the correct metadata defined for host controller so it can match resources/metrics from the slaves. I assume that will be "implementation details."
I'm sure this sounds like gibberish, but that's how convoluted supporting domain mode is going to be.
(note: none of this attempts to solve how we are going to get MiQ UI to use this new inventory/metrics data - I have no idea if it will be trivial or be convoluted, too)
4 years, 8 months
