Hawkular Metrics Openshift Containers
by Matt Wringe
I have a new subproject in Hawkular Metrics which sets up creating
components for Openshift/Fabric8
(https://github.com/hawkular/hawkular-metrics/pull/200).
There are 3 main parts
Cassandra: creates a custom seed provider to support
ReplicationControllers in Kubernetes, creates a folder/zip archive which
can be used to generate a Docker image. It may make sense to move the
Cassandra parts out to a separate project.
Hawkular Metrics: creates a folder/zip archive which can be used to
generate a Docker image
Kubernetes: pulls everything together into a single kubernetes
application. Can be used to deploy an application zip into fabric8 (via
drag and drop in the web console or via the maven plugin) or deploy all
the components into Openshift via the kubernetes.json configuration file.
The docker images are not created and deployed to a docker registry as
part of the build, it will just create a folder where you can run the
docker build from. None of the maven docker plugins I looked at seemed
to really work properly, so its still a manual process to do the build
(and push to a registry). Its something which needs to be improved.
The Cassandra service currently only supports adding new nodes to a
cluster and not removing them via the ReplicationController. This is due
to the replication factor being set to be 1 by default (which means when
a node is removed, so is the data it contained).
I believe the docker subproject of hawkular metrics is obsolete and can
be removed
(https://github.com/hawkular/hawkular-metrics/tree/master/docker), but
someone please correct me if I am wrong. It's scripts are referring to
the console which no longer exists as part of the project.
- Matt
1 year, 3 months
Tenant Id - Not Part of URL
by Stefan Negrea
Hello Everybody,
I've been working on a PR for the upcoming Hawkular Metrics release that will remove the tenant id from the end-point URLs. The tenant id will be moved to either a header parameter or a query parameter. The query parameter is in place for cases (such as curl) where setting a header is not possible, difficult, or inconvenient.
Here is an example of the change:
Existing URL:
/{tenantId}/gauge/{metricId}/data
New URL:
/gauge/{metricId}/data
Tenant id set via:
1) header - tenantId
2) query parameter - tenantId
There are two exceptions to this rule, /tenants and /db/{tenantid}/series. The /tenants end-point will be changed into something different in the upcoming releases since it is mostly a management type API that does not belong in the same place with the regular metrics endpoint. And /db/{tenantid}/series end-point is needed in this exact format for compatibility with Influxdb compatible services.
Now, to the merits of this change. The tenant id is volatile, can change any time, and changes to it should be expected; but the rest of the URL is fixed. The second issue is that the tenant id is a security concern. So we were limited in design choices since a security concern was leaking as part of the URL.
So removing the tenant id from the URL will give us permanent & consistent addresses for resources (metrics and metric data points). And we will gain a lot of flexibility on the security side. In the future, users could authenticate with a user/pass combo and the backend would transform that into a tenant id to be used on the request. If the same user later decides to use a tenant id to pass along the request, the URL of the resources would not change. Another expectation is that tenant id is not sufficient, it is typically a combo of id + secret; so we would have resorted to a header or query param for the second piece of information (the secret).
This change will give us the flexibility to adjust the security model (the meaning of tenant ids and ways to validate them) without compromising the URL structure. This will help Hawkular Metrics as it gets integrated into more and more projects and products.
Here are the links to the JIRA and the PR for this change:
https://github.com/hawkular/hawkular-metrics/pull/202
https://issues.jboss.org/browse/HWKMETRICS-68
Thank you,
Stefan Negrea
Software Engineer
1 year, 3 months
New and noteworthy in hawkular-parent 25
by Peter Palaga
Hi *,
hawkular-parent 25 brings the following:
* srcdeps-maven-plugin 0.0.5
* meets the promisses falsely done for 0.0.4:
* less console output
* built without tests
* wildfly-maven-plugin 1.1.0.Alpha4
I have sent PRs to all components repos.
Thanks,
Peter
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
1 year, 3 months
Hawkular Inventory Storage and Queries In a Nutshell
by Lukas Krejci
Hi all,
given the recent discussion about the backend we should be using for
inventory, I've quickly put together a brief explanation of what inventory
actually stores and how it queries things.
This is expected to raise more questions than to provide answers though and is
meant as a starter for the discussion that I hope will happen in the comments
section of the google doc [1].
Thanks,
[1] https://docs.google.com/document/d/
1Z1pIQS4EML7_0tuSyHUPX6jzNvaeEqGm4XAiYcRGbvQ/edit?usp=sharing
--
Lukas Krejci
9 years, 4 months
Cassandra Cluster with docker.
by Ruben Vargas Palma
I was testing a little bit with Hawkular-Services + Cassandra cluster
using docker containers, I created a GitHub repository with my setup:
https://github.com/rubenvp8510/hwk-cassandra-docker
It seems to work fine, at least on my environment, I did some different
tests but I couldn't test more than 3 nodes on my machine, but hopefully
it will work for N nodes.
Some issues I found:
- Sometimes hawkular throws a timeout exception "Cassandra timeout
during read query at consistency LOCAL_ONE", I only managed to reproduce
it 2 times.
- This setup is not enough robust because the Keyspace has replica
factor of 1, so if one node dies hawkular-services started complain
about it.
Regards
9 years, 5 months
wildfly agent: jmx/jolokia and prometheus support
by John Mazzitelli
There is a concern that the Hawkular WildFly Agent is bloated with stuff people aren't really using or are going to use and is going to make maintaining it more complicated than it needs to be.
So I want to get feedback on the following plan. This is being tracked in JIRA here: https://issues.jboss.org/browse/HWKAGENT-142
We are going to take out support for JMX/Joloxia and Prometheus managed endpoints. The agent will only support collecting metrics from "DMR endpoints" (that means WildFly Servers - either in standalone or domain mode).
Rather than lose the code for the JMX/Jolokia and Prometheus support, we are going to fork master into a separate branch. If we ever do need to resurrect that code, or someone wants to build an agent with those features to play around with, we'd have that branch available.
Thoughts?
9 years, 5 months
Metrics tag queries ( and inventory)
by Heiko W.Rupp
Hey,
I was looking at how to find all tags in the metrics system
and found endpoints like
http://www.hawkular.org/docs/rest/rest-metrics.html#GET__gauges_tags__tags_
(similar exist for Counters, avail, ...)
Those expect a "tag-query". With some looking at the source and trying
I found out that app:* works, but not *:cpu or even *:* to find all tags.
Do metrics-only users completely rely on external orchestration to find
possible tags?
Now with pets vs cattle and containers coming and going, we need those
labels to identify what belongs together.
For Hawkular-services, how will we store those tags in a way that
clients (e.g. ManageIQ) can find them and thus also query metrics for
those labels?
9 years, 5 months
Hawkular Alerting 1.2.0.Final has been released!
by Jay Shaughnessy
The Hawkular Alerting team is happy to announce the release of Hawkular
Alerting 1.2.0.Final.
This is a feature and fix release.
* [HWKALERTS-160] - CompareCondition can not require both DataIds to
be supplied for the same engine firing
o This makes CompareCondition more useful and predictable by
removing the restriction that both metrics [used in the
comparison] be reported at the same time.
* [HWKALERTS-161] - Extend alerts criteria to support resolved and ack
timestamps
o More powerful querying around life-cycle changes.
* [HWKALERTS-162] - Allow to not store external events
o EventConditions can now be evaluated using transient
(unpersisted) events. This prevents unnecessary storage of
events meant only for trigger condition evaluation.
* [HWKALERTS-163] - Unify actions architecture under a single
implementation
o A refactor to simplify action plugins by unifying on one type of
plugin registration.
* [HWKALERTS-164] - Simplify Alert.resolvedTime and Alert.ackTime with
Alert.lifecycle
o More powerful life-cycle handling, allowing more status
transitions for a single alert, and an easily accessible list of
status changes.
* [HWKALERTS-165] - Refactor hawkular-alerts-rest to support several
artifacts
o A refactor to provide artifacts for both standalone and Hawkular
Services. Starting with this release the different artifact
flavors are all published.
* [HWKALERTS-166] - CassCluster needs to detect schema is fully
created on multi nodes environments
o A stability enhancement for clustered deployments, to ensure the
Cassandra schema is ready for all nodes.
* Hawkular Metrics embeds Alerting!
o V1.2.0.Final is the base version for embedded alerting in
Hawkular Metrics! Coming Soon!
For more details for this release:
http://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12315924&versio...
Hawkular Alerting Team
Jay Shaughnessy (jshaughn(a)redhat.com)
Lucas Ponce (lponce(a)redhat.com)
9 years, 5 months
Best Practices: MiQ Dependencies around other branches
by mike thompson
Hey Hawkular Folk,
So I just wanted to know what is the ‘the way’ to incorporate branches or PRs that one’s branch is dependent on? Since merging into MiQ master takes so long, what is our strategy around dependent merges? We are unfortunately in the realm of long lived branches now. Much more rebasing and conflicts given the extended timeframes for merging.
I have asked around, and no one is confident in “the way”.
I have a couple methods in mind but not sure what the best practices are…. Please speak up if one works for you and we can adopt it.
— Mike
9 years, 5 months
