moving okhttp library from 2.x to 3.x
by John Mazzitelli
We have been using version 2.x of the okhttp library and its associated WebSocket library.
Moving to the latest 3.x stream would keep us up-to-date and would be useful because we recently saw some odd behavior where the websocket library was spitting out warnings about resources leaking and that problem I think is fixed in the 3.x versions.
So I wrote this JIRA: https://issues.jboss.org/browse/HAWKULAR-1138
There are four PRs associated with that JIRA for parent-pom, commons, inventory, and agent that I need peer reviewed. We then need to publish these in an organized fashion (parent-pom first, then we move commons pulling in the new parent pom, then inventory and agent pulling in the new commons and parent pom).
Also: Metrics: I noticed hawkular-metrics defines a property for a VERY old okhttp version (2.0.0) but it doesn't seem to even be using it. See https://github.com/hawkular/hawkular-metrics/search?q=squareup - I think metrics should get rid of that obsolete version property definition.
Does anyone know of anywhere else we are using okhttp?
7 years, 11 months
Hawkular APM 0.13.0.Final released
by Gary Brown
Hi
We are pleased to announce the availability of Hawkular APM version 0.13.0.Final. The release can be found here: https://github.com/hawkular/hawkular-apm/releases
This release includes:
* OpenTracing (Java and JavaScript) providers:
- sampling API
- use deployment metadata information from OpenShift environment to automatically name services/versions
* OpenTracing based JVM agent
- ability to define custom ByteMan rules
* OpenShift
- template improvements to separate out management of Elasticsearch cluster
- vertx-opentracing example updated to separate services into individual deployments, with Ansible script for single command install
* UI
- trace instance diagram colour coded to show areas with performance issues
- filter sidebar applied to transaction pages
Regards
Hawkular APM Team
7 years, 11 months
Docker build on a VM
by Jay Shaughnessy
I was stumped for quite a while about why I couldn't get a docker build
to run on my VM. The symptom is that the docker build can not reach the
outside world, and therefore can't pull in what it needs. This happens
even though the VM itself has no connectivity issues. Note, I assume
this is a VM thing because it happened to both mazz and myself, using
Virtual Box fedora vms, but it may not be limited to VMs. I finally
stumbled on a stack overflow entry that solved the issue [1].
Basically, you need to tell docker about your DNS servers, and also
Google's DNS server 8.8.8.8. Your mileage may vary, perhaps you'll only
need a subset of of servers, but hopefully this helps you out, because
it was a pita.
[1]
http://stackoverflow.com/questions/25130536/dockerfile-docker-build-cant-...
7 years, 11 months
Re: [Hawkular-dev] Invitation: Hawkular Metrics - Tag Filtering - JsonPath @ Mon 2016-12-12 10:30 - 11:30 (mwringe@redhat.com)
by Matt Wringe
I have a meeting conflict and I cannot make it.
Without having something in place to do data migrations from the old format to the new one, its not going to be that use useful for the OpenShift case as the moment.
Aside from this issue, data migration between formats is something that we do need to figure out. Sooner or later we are going to want to store things differently (especially with Heapster being deprecated)
----- Original Message -----
> From: "Stefan Negrea" <snegrea(a)redhat.com>
> To: mwringe(a)redhat.com, jshaughn(a)redhat.com, hawkular-dev(a)lists.jboss.org, lponce(a)redhat.com, miburman(a)redhat.com,
> lkrejci(a)redhat.com, jsanda(a)redhat.com
> Sent: Friday, 9 December, 2016 5:15:44 PM
> Subject: Invitation: Hawkular Metrics - Tag Filtering - JsonPath @ Mon 2016-12-12 10:30 - 11:30 (mwringe(a)redhat.com)
>
> more details »
> Hawkular Metrics - Tag Filtering - JsonPath
> Hello,
>
> This session will be a design & implementation review for tag filtering of
> metric definitions based on Json Path. The feature is at proposal stage (not
> yet merged), so all feedback is greatly appreciated.
>
> The filtering mechanism could be extended to Alerting and Inventory
> components; feedback from those projects would also be great.
>
> Design Document:
> http://jbosson.etherpad.corp.redhat.com/286
>
> PR:
> https://github.com/hawkular/hawkular-metrics/pull/706
>
> Jira
> https://issues.jboss.org/browse/HWKMETRICS-523
>
>
>
>
>
>
>
>
> When
> Mon 2016-12-12 10:30 – 11:30 Eastern Time
> Where
> http://bluejeans.com/3980552127 ( map )
> Calendar
> mwringe(a)redhat.com
> Who
> •
> snegrea(a)redhat.com - organizer
>
> •
> jshaughn(a)redhat.com
>
> •
> hawkular-dev(a)lists.jboss.org
>
> •
> lponce(a)redhat.com
>
> •
> miburman(a)redhat.com
>
> •
> mwringe(a)redhat.com
>
> •
> lkrejci(a)redhat.com
>
> •
> jsanda(a)redhat.com
>
>
> Going? Yes - Maybe - No more options »
>
>
> Invitation from Google Calendar
>
> You are receiving this email at the account mwringe(a)redhat.com because you
> are subscribed for invitations on calendar mwringe(a)redhat.com.
>
> To stop receiving these emails, please log in to
> https://www.google.com/calendar/ and change your notification settings for
> this calendar.
>
> Forwarding this invitation could allow any recipient to modify your RSVP
> response. Learn More .
>
7 years, 11 months
Hawkular Metrics 0.22.0 - Release
by Stefan Negrea
Hello,
I am happy to announce release 0.22.0 of Hawkular Metrics. This release is
anchored by performance and compression enhancements.
Here is a list of major changes:
- *Compression*
- Prevent OutOfMemoryError on Cassandra when compression job runs (
HWKMETRICS-520 <https://issues.jboss.org/browse/HWKMETRICS-520>)
- Avoid compression job executing in a loop when execution falls
behind (HWKMETRICS-536
<https://issues.jboss.org/browse/HWKMETRICS-536>)
- Avoid future executions of compression job from not running if
Cassandra is shutdown abruptly (HWKMETRICS-518
<https://issues.jboss.org/browse/HWKMETRICS-518>)
- Added a flag to disable the compression job; the data will be
persisted and retrieved without compression (HWKMETRICS-524
<https://issues.jboss.org/browse/HWKMETRICS-524>)
- The block size for compression is now configurable (HWKMETRICS-545
<https://issues.jboss.org/browse/HWKMETRICS-545>)
- The compression job can now be triggered manually (HWKMETRICS-502
<https://issues.jboss.org/browse/HWKMETRICS-502>)
- *Server Clustering*
- The external alerter is now cluster-aware and will not process the
same request on multiple nodes (HWKMETRICS-515
<https://issues.jboss.org/browse/HWKMETRICS-515>)
- Schema updates are correctly applied when multiple servers are
started at the same time (HWKMETRICS-514
<https://issues.jboss.org/browse/HWKMETRICS-514>)
- Added Cassandra connection information to the status page and
created an admin version with detailed Cassandra cluster information (
HWKMETRICS-526 <https://issues.jboss.org/browse/HWKMETRICS-526>)
- Internal system metrics are now persisted under admin tenant; this
gives a good overview of the current system load (HWKMETRICS-550
<https://issues.jboss.org/browse/HWKMETRICS-550>)
- *REST API*
- Added endpoint to allow fetching of available tag names (
HWKMETRICS-532 <https://issues.jboss.org/browse/HWKMETRICS-532>)
- Fixed an issue where the API would report an internal server error
on invalid query (HWKMETRICS-543
<https://issues.jboss.org/browse/HWKMETRICS-543>)
- *Hawkular Alerting - Updates*
- End to end performance enhancements
- Major improvements to REST API documentation
<http://www.hawkular.org/docs/rest/rest-alerts.html>
- New cross-tenant endpoints for for fetching alerts
- Email and webhook action plugins are now packaged in the main
distribution (HWKMETRICS-552
<https://issues.jboss.org/browse/HWKMETRICS-552>)
*Hawkular Alerting - included*
- Version 1.4.0
<https://issues.jboss.org/projects/HWKALERTS/versions/12331986>
- Project details and repository: Github
<https://github.com/hawkular/hawkular-alerts>
- Documentation: REST API Documentation
<http://www.hawkular.org/docs/rest/rest-alerts.html>, Examples
<https://github.com/hawkular/hawkular-alerts/tree/master/examples>,
Developer
Guide
<http://www.hawkular.org/community/docs/developer-guide/alerts.html>
*Hawkular Metrics Clients*
- Python: https://github.com/hawkular/hawkular-client-python
- Go: https://github.com/hawkular/hawkular-client-go
- Ruby: https://github.com/hawkular/hawkular-client-ruby
- Java: https://github.com/hawkular/hawkular-client-java
*Release Links*
Github Release:
https://github.com/hawkular/hawkular-metrics/releases/tag/0.22.0
JBoss Nexus Maven artifacts:
http://origin-repository.jboss.org/nexus/content/repositorie
s/public/org/hawkular/metrics/
Jira release tracker:
https://issues.jboss.org/projects/HWKMETRICS/versions/12332012
A big "Thank you" goes to John Sanda, Matt Wringe, Michael Burman, Joel
Takvorian, Jay Shaughnessy, Lucas Ponce, and Heiko Rupp for their project
contributions.
Thank you,
Stefan Negrea
7 years, 11 months
*/raw/query doesn't return CORS allow headers
by Gareth Healy
I am using the grafana plugin with Hawkular on OCP. If we *dont* set the
CORS allowed value to all, then the grafana plugin gets AJAX errors due to
CORS. As shown by some simple cURL commands below.
Hawkular CORS set to: http://test.com
**/counters/stats examples:*
Fails due to Origin mismatch but still returns data - didn't expect to get
data back if a 400 is returned... not sure if thats a bug or not.
localhost:hawkular-client-java garethah$ curl -u admin:admin --header
"Hawkular-Tenant: unit-testing" --request GET "
http://192.168.99.100:8080/hawkular/metrics/counters/stats?bucketDuration..."
--header "Origin: http://bob.com" -vvv
* Trying 192.168.99.100...
* Connected to 192.168.99.100 (127.0.0.1) port 8080 (#0)
* Server auth using Basic with user 'admin'
> GET
/hawkular/metrics/counters/stats?bucketDuration=1d&percentiles=90.0&metrics=noofzsny&stacked=true
HTTP/1.1
> Host: 192.168.99.100:8080
> Authorization: Basic YWRtaW46YWRtaW4=
> User-Agent: curl/7.49.1
> Accept: */*
> Hawkular-Tenant: unit-testing
> Origin: http://bob.com
>
< HTTP/1.1 400 Bad Request
< Expires: 0
< Cache-Control: no-cache, no-store, must-revalidate
< X-Powered-By: Undertow/1
< Server: WildFly/10
< Pragma: no-cache
< Date: Mon, 05 Dec 2016 17:25:22 GMT
< Connection: keep-alive
< Content-Type: application/json
< Content-Length: 217
<
* Connection #0 to host 192.168.99.100 left intact
[{"start":1480929922811,"end":1481016322811,"min":-5.3461447394508227E18,"avg":1.13394506239459277E18,"median":1.41820444399757005E18,"max":6.5335287915888394E18,"sum":1.1339450623945933E19,"samples":1,"empty":false}]
Working example with correctly returned Access-Control-Allow-Origin:
localhost:hawkular-client-java garethah$ curl -u admin:admin --header
"Hawkular-Tenant: unit-testing" --request GET "
http://192.168.99.100:8080/hawkular/metrics/counters/stats?bucketDuration..."
--header "Origin: http://test.com" -vvv
* Trying 192.168.99.100...
* Connected to 192.168.99.100 (127.0.0.1) port 8080 (#0)
* Server auth using Basic with user 'admin'
> GET
/hawkular/metrics/counters/stats?bucketDuration=1d&percentiles=90.0&metrics=noofzsny&stacked=true
HTTP/1.1
> Host: 192.168.99.100:8080
> Authorization: Basic YWRtaW46YWRtaW4=
> User-Agent: curl/7.49.1
> Accept: */*
> Hawkular-Tenant: unit-testing
> Origin: http://test.com
>
< HTTP/1.1 200 OK
< Expires: 0
< Cache-Control: no-cache, no-store, must-revalidate
< X-Powered-By: Undertow/1
< Access-Control-Allow-Headers: origin,accept,content-type,hawkular-tenant
< Server: WildFly/10
< Pragma: no-cache
< Date: Mon, 05 Dec 2016 17:26:13 GMT
< Connection: keep-alive
< Access-Control-Allow-Origin: http://test.com
< Access-Control-Allow-Credentials: true
< Content-Type: application/json
< Content-Length: 217
< Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, HEAD
< Access-Control-Max-Age: 259200
<
* Connection #0 to host 192.168.99.100 left intact
[{"start":1480929973847,"end":1481016373847,"min":-5.3461447394508227E18,"avg":1.13394506239459277E18,"median":1.41820444399757005E18,"max":6.5335287915888394E18,"sum":1.1339450623945933E19,"samples":1,"empty":false}]
**/counters/raw/query examples:*
Gets data but doesn't return any Access-Control-Allow-Origin headers thus
will fail in grafana.
localhost:hawkular-client-java garethah$ curl -u admin:admin --header
"Hawkular-Tenant: unit-testing" --request POST "
http://192.168.99.100:8080/hawkular/metrics/counters/raw/query" --data
"{order:\"ASC\",ids:[\"noofzsny\"]}" --header "Content-Type:
application/json" --header "Origin: http://test.com" -vvv
* Trying 192.168.99.100...
* Connected to 192.168.99.100 (127.0.0.1) port 8080 (#0)
* Server auth using Basic with user 'admin'
> POST /hawkular/metrics/counters/raw/query HTTP/1.1
> Host: 192.168.99.100:8080
> Authorization: Basic YWRtaW46YWRtaW4=
> User-Agent: curl/7.49.1
> Accept: */*
> Hawkular-Tenant: unit-testing
> Content-Type: application/json
> Origin: http://test.com
> Content-Length: 30
>
* upload completely sent off: 30 out of 30 bytes
< HTTP/1.1 200 OK
< Expires: 0
< Cache-Control: no-cache, no-store, must-revalidate
< X-Powered-By: Undertow/1
< Server: WildFly/10
< Pragma: no-cache
< Date: Mon, 05 Dec 2016 17:30:38 GMT
< Connection: keep-alive
< Content-Type: application/json
< Content-Length: 590
<
* Connection #0 to host 192.168.99.100 left intact
[{"id":"noofzsny","data":[{"timestamp":1480943333446,"value":-5346144739450823145},{"timestamp":1480943363446,"value":5257714416350875295},{"timestamp":1480943393446,"value":4269323419475977241},{"timestamp":1480943423446,"value":4996234959867023108},{"timestamp":1480943453446,"value":-4477830536950343320},{"timestamp":1480943483446,"value":3744561193794180662},{"timestamp":1480943513446,"value":-3619119654582223963},{"timestamp":1480943543446,"value":6533528791588839899},{"timestamp":1480943573446,"value":225819548751014015},{"timestamp":1480943603446,"value":-244636774898588607}]}]
Have i missed something in the grafana / hawkular setup? or is this a bug?
Cheers.
7 years, 11 months
