February 2016 - hawkular-dev - Jboss List Archives

Cancelled: Discussion, Planning, and status on Testing Openshift & Hawk-Metrics Integration for Openshift 3.1

by Michael Foley

A single instance of the following meeting has been cancelled: Subject: Discussion, Planning, and status on Testing Openshift & Hawk-Metrics Integration for Openshift 3.1 Organizer: "Michael Foley" <mfoley(a)redhat.com> Location: Bluejeans http://www.bluejeans.com/mfoley51 Time: Wednesday, February 17, 2016, 3:00:00 PM - 3:30:00 PM GMT -05:00 US/Canada Eastern Required: pruan(a)redhat.com; mmahoney(a)redhat.com; vnguyen(a)redhat.com; snegrea(a)redhat.com; jsanda(a)redhat.com; mwringe(a)redhat.com Optional: jon-qa-list(a)redhat.com; jboss-on-team(a)redhat.com; hawkular-dev(a)lists.jboss.org *~*~*~*~*~*~*~*~*~* Hi, Let's have a discussion and planning session on testing Openshift & Hawkular Integration! Let's use this etherpad to coordinate the discussion -->> http://pad.engineering.redhat.com/Management-nextAndOpenshiftTestPlanning 5 Point Plan for Openshift 3.1 GA * Unit tests .... owned by Hawk-Metrics developers * Integration tests ... owned by Hawk-Metrics developers and Hawk-Metrics QE * Performance CI on Hawk-Metrics (this one is actually new and was not discussed on Wednesday , but I now see it makes sense) * Functional Integration tests on Hawk-Metrics latest + Openshift Origin latest * Funtional/UI .... Cucumber/Ruby tests ...owned by Openshift QE * Functional/Rest ... Cucumber/Ruby tests ... owned by Openshift QE * Performance & Scalability .... owned by Openshift QE Regards, Michael Foley QE Supervisor, Middleware BU

8 years, 2 months

1
0
0 / 0

Increasing heap size

by Gary Brown

Does anyone have any issue with the heap size being increased to: -Xms256m -Xmx2048m When Elasticsearch has a reasonable amount of data it needs more memory. Next question is how best to modify this in standalone.conf from a feature pack - any suggestions appreciated. My only thought was extract from wildfly, modify and then store the modified version in btm feature pack - so assumes alignment of wildfly version with hawkular. Regards Gary

8 years, 2 months

2
2
0 / 0

Move ptrans into its own repo

by Heiko W.Rupp

Hey, I think it could make sense to move ptrans from under the metrics repo into its own repo for further improvements. Wdyt?

8 years, 2 months

2
2
0 / 0

Alpha 10 released

by Juraci Paixão Kröhling

Alpha 10 is released: http://repository.jboss.org/org/hawkular/hawkular-dist/1.0.0.Alpha10/hawk... - Juca.

8 years, 2 months

1
0
0 / 0

Hawkular Alerts 1.0.0.Final Released!

by Jay Shaughnessy

We're proud to announce version 1.0.0.Final of Hawkular Alerts! Our first major release marks over a year of development and has a bunch of great enhancements. Hawkular Alerts is an open source, scalable alerting tool for monitoring your Data Center or anything else. Out of the box you get: * A robust REST API * Complex Alerting * Powerful Event Handling * Pluggable Action Handlers with many built-in (e-mail, SMS, etc) * Alert Lifecycle (Ack, Resolved, etc) * Flexible Deployment, either standalone or as part of Hawkular * And Much More What's new: * [HWKALERTS-123] - Introduce time constraints on actions o Want e-mail during the day and SMS on nights and weekends? You got it! * [HWKALERTS-126] - Add full tagging support to Alerts o Need to group your alerts for customized fetch or presentation? You got it! * [HWKALERTS-8] - Add Import/Export of Triggers o Want to dump your defined triggers to a file and import them in another server? You got it! * [HWKALERTS-79] - Define actions per life-cycle state o Want to send e-mail when an alert is ack'd or resolved? You got it! * [HWKALERTS-124] - Unify full trigger creation on a single step o Want to define or fetch your *whole* trigger in one call? You got it! * [HWKALERTS-127] - Data driven group triggers o Want to automatically generate member triggers just based on incoming data? You got it! * And more... o [HWKALERTS-131] - Persist member trigger dataId mappings for re-use on condition updates o [HWKALERTS-129] - Improve context and tag handling when adding member triggers o [HWKALERTS-130] - Automate clustering tests o [HWKALERTS-128] - Add external configuration for multiple email servers on email plugin o [HWKALERTS-132] - Move hawkular-examples to hawkular-alerts repo o [HWKALERTS-121] - Add integration tests covering bus scenarios o [HWKALERTS-106] - Review REST API doc o [HWKALERTS-125] - Close JMS connection on action plugins o [HWKALERTS-133] - Migrate CommandEventListener to Hawkular Links: * Jira release-notes o https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12315924&versi... * Hawkular o http://www.hawkular.org/ * Hawkular Alerts o http://www.hawkular.org/docs/dev/alerts.html * Hawkular Alerts Rest API o http://www.hawkular.org/docs/rest/rest-alerts.html * GitHub o https://github.com/hawkular/hawkular-alerts * Examples o https://github.com/hawkular/hawkular-alerts/tree/master/examples Hawkular Alerts Team Jay Shaughnessy (jshaughn(a)redhat.com) Lucas Ponce (lponce(a)redhat.com)

8 years, 2 months

5
4
0 / 0

HAWKULAR-549 Metrics protected by Accounts: next steps

by Thomas Segismont

Hi everyone, I have been working on integrating the next version of the Metrics component into Hawkular. It's not a trivial version change. First, a bit of context. Metrics produces different artifacts, each one having its own tenant selection, authentication and authorization logic. # Standalone Metrics -> Hawkular-Tenant header sets the tenant -> No authentication, no authorization # Openshift integration -> Hawkular-Tenant header sets the tenant -> Basic Auth (based on htpassword file) or Openshift OAuth -> Basic auth: no authorization (if you're authenticated, you can query any tenant) -> Openshift OAuth: tenant is verified # Hawkular integration -> Authentication and authorization based on Accounts -> Credentials + optional Hawkular-Persona header set the tenant It might look confusing but it is necessary to implement the requirements of the consumer projects. That said, here's the list of impacts I could think of (may not be exhaustive). # Grafana over InfluxDB endpoint Grafana now works with both standalone Metrics and Hawkular https://issues.jboss.org/browse/HWKMETRICS-343 # Clients which must work with different Metrics artifacts ## Wildfly Agent Mazz already implemented a switch in the agent https://issues.jboss.org/browse/HWKAGENT-56 ## Ruby, Java and Python clients ## vertx-hawkular-metrics and ptrans ## Hawkular Charts A switch must be implemented: - Standalone Metrics: set Hawkular-Tenant header - Hawkular: Basic Auth + Hawkular Persona (optional) I'm not sure how we should proceed with Hawkular Charts. Having the switch as a directive parameter would not be convenient. Language clients, vertx SPI and ptrans updates should not be blocking with respect to the next Hawkular alpha. # Clients which must work with Hawkular only ## hawkular-ui-services We need to remove the Hawkular-Tenant header from the HTTP calls, otherwise Metrics will reject the requests as invalid (status 400) I will send a PR when I'm back (I'm out of office next week). ## Pinger and AvailCreator Since Pinger and AvailCreator need to work with any tenant, it seems impractical to require users to configure all credentials for HTTP Client. I've created HWKMETRICS-347 Hawkular Component should accept metric input from the bus. The PR is sent and ready for review. https://github.com/hawkular/hawkular-metrics/pull/445 If we agree on the principle of queues for metrics data input coming from Hawkular components, then we'll only have to update Pinger and AvailCreator so that they use the bus instead of an HTTP client. I believe it is doable to upgrade Metrics for the next Hawkular alpha, but it requires good coordination and a little bit of help :) In particular, I'm not sure I can come up with a good solution in time for Hawkular Charts. Best regards, Thomas

8 years, 2 months

1
2
0 / 0

license checker error again

by John Mazzitelli

(01:11:43 PM) mazz: we are getting that annoying license checker error again! (01:11:52 PM) mazz: ppalaga_bbl: here's a travis log for you: https://travis-ci.org/hawkular/hawkular-agent/builds/108584979 (01:12:14 PM) mazz: all that changed was jpkroehling|afk's pom change to bump up to the new accounts. NO other files changed (01:12:22 PM) mazz: this was NOT happening yesterday

8 years, 2 months

2
2
0 / 0

UI issues when integration BTM into Hawkular console - help required from UI devs

by Gary Brown

Hi UI devs I've been working on integrating BTM into Hawkular, which is achieved through a feature pack - installing the server war/scripts/agent jar for the backend, and the js/css (and plugin html - one of the issues discussed below) for the frontend. To make this work, some changes were made in the Hawkular console to reference these js/css files, add a couple of additional dependencies in bower.json and add the extra tabs. The feature pack is available in BTM master, to build the snapshot simply use: "mvn clean install -DskipTests" - there is also a standalone build of the BTM distribution in dist/target. Once the snapshot is available, then build this branch for the hawkular project: https://github.com/objectiser/hawkular/tree/HWKBTM-312 - rebased recently so should be more or less up to date. However there are a number of issues that I initially thought were just in the integrated hawkular console, but since have also found in the BTM UI within the standalone server. In an attempt to try to narrow down the problem, I've aligned dependency versions and changed the gulpfile to be equivalent to the approach used by the hawkular console. I'd appreciate some help in fixing some of these issues, although the important one that has the biggest impact (and therefore would prevent a release with this integration) is the first one: https://issues.jboss.org/browse/HWKBTM-315 Appears to be a problem with the accordian and dropdown menus. Instructions for reproducing and four example images showing the issue have been added to the jira. https://issues.jboss.org/browse/HWKBTM-319 Even though the html templates are cached, the UI complains if it cannot retrieve the html from the server. This wasn't an issue when using gulp on port 2772 to do live updates of the UI during development, but now prevents live updates using the approach used by hawkular console where the js/css files are updated in the console war in the server. https://issues.jboss.org/browse/HWKBTM-318 The interval and time span dropdowns on the APM and BTM info pages are no longer showing the default values. (not investigated yet) https://issues.jboss.org/browse/HWKBTM-316 The hawkular-ui/btm page, when business txns have been configured, shows summary boxes for each business txn. In the BTM UI they are stable during the refresh cycle (i.e. just the numbers are refreshed), but in the hawkular UI, there appears some transition that occurs when a new instance of the btxn is added as a separate box, and then the old one (I assume) is removed - so probably to do with the way I have applied the updates (not investigated yet). As mentioned the first issue is the main problem, and the second issue would be good to solve to help future debug/development. Haven't had a chance to investigate the last two yet, so may be simple, but any pointers would also be appreciated. Thanks in advance. Regards Gary

8 years, 2 months

2
1
0 / 0

Behavioral Change in Alerting

by Jay Shaughnessy

With the merge of Hawkular-922 we've moved trigger definition out of the UI code and into the server. This simplifies the UI coding but more importantly it means users don't need to log in and perform UI navigation in order to initiate alerting. Now, as soon as the agent discovers resources, and inventory notifies the bus, triggers are defined. These out-of-box (OOB) triggers will now monitor data prior to any user login. Moreover, our OOB triggers are now defined as Group triggers (the H-Alerts equivalent to Alert Definition Templates in RHQ). So, for new Resource-Types we define Group triggers, and then for each new Resource of those types we add a member trigger to the group. In alpha-10 we maintain nearly the same UI wrt alerts, but one big difference is that editing a trigger definition now affects all members of that group. So, for example, if you change a CPU trigger from > 20% to > 30% it will actually change all of the CPU triggers in the same way. If you want to disable NonHeap triggers you can disable then all at one time. Etc.. This gets us closer to a "policy" approach to alerting where everything is monitored in the same fashion. There is another change to mention that makes sense but may seem a little surprising. Because the OOB triggers are now defined server-side, outside of a UI session, there is no obvious user associated with their creation. In the UI we had the user that was logged in at the time but on the server, but now we don't. Because we don't have an email address it's not possible to define an email action at trigger creation time . For now, to activate an email action it will require a UI session and an edit of the trigger. The email will be applied to all of the triggers in that group (not all triggers in the system). There is a new on/off switch on the email action and it will initially be set to off. It's unclear where we go from here, but if there is further work in this area there are several things to discuss, like: - a more robust [email] action approach - ad-hoc group triggers - detaching members from groups - ad-hoc [standard] triggers Jay

8 years, 2 months

1
0
0 / 0

Sending data to metrics via Pinger - bus? REST?

by Juraci Paixão Kröhling

With the latest update of metrics, it seems that the Pinger is now broken: Metrics is now protected via Accounts, meaning that REST calls would need to include auth data, which are not available to pinger. Pinger is a process that runs on Hawkular server, so, either we would need to get a token from users when they first request an URL to be monitored, or we would need to somehow send data to Metrics "directly". Of course, the bus comes to my mind. I'm sure this was discussed at length before, but I just want to catch up on the current state of things. My understanding is that Pinger would send a "PingerResult" to a topic, where interested parties would be listening. Inventory and Metrics would be such parties: a Topic Listener on each of those components would be responsible for doing inventory-specific and metrics-specific logic. The question, though, is: where would this code reside? Heiko's idea is that this would be part of a "glue", ie, a code "somewhere inside Hawkular". In my view, the glue is the bus, so, this should reside within the component itself. In metrics case, the listener would probably be inside the "hawkular-component" module. The code on "hawkular-component" would just listen to this topic and call MetricsService. What would be the most appropriate way to have the pinger's results stored in metrics? - Juca.

8 years, 3 months

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

hawkular-dev February 2016