Sync with Inventory
by Austin Kuo
Hi all,
I’m currently investigating how to sync with inventory server.
Here’s the example scenario:
Consider the following problem. A user creates version 1 of the app with
two http servers, one listening on port 8080, the other on port 8181. In
version 2, the http server listening on port 8181 is no longer needed.
When the old version is stopped and the new version started, there will be
just one http server listening. The application is not aware of the
previous state. What should we do so that the second http server is removed
from Inventory?
Thanks in advance.
9 years, 9 months
Hawkular Metrics 0.17.0 - Release
by Stefan Negrea
Hello Everybody,
I am happy to announce release 0.17.0 of Hawkular Metrics. This release is
anchored by performance enhancements and new Grafana Datasource Plugin.
Here is a list of major changes:
1.
*Grafana Datasource Plugin - Experimental*
- A new Grafana 3 datasource plugin is now available for Hawkular
Metrics. This plugin integrates natively via the REST API.
- For downloads and installation instructions please visit Hawkular
Datasource for Grafana
<https://github.com/hawkular/hawkular-grafana-datasource>
- The plugin is developed as an independent project and contributions
are welcomed.
2.
*InfluxDB API - DEPRECATED*
- The InfluxDB API has been deprecated and will be removed in the
upcoming release.
- This was an addition to make project integrations easier. As the
REST interface matured, the role of the InfluxDB compatibility interface
was reduced only serve as the Grafana interface. With the release of the
native Grafana plugin, this is no longer needed.
- For more details: HWKMETRICS-411
<https://issues.jboss.org/browse/HWKMETRICS-411>
3.
*Fetching Raw Data - Multiple Metrics - Experimental*
- Prior to this release, it was possible to only fetch raw data points
for a single metric. This release added POST */query endpoint that
allows querying for raw data points for multiple metrics.
- The endpoints are:
- POST /hawkular/metrics/gauges/raw/query
- POST /hawkular/metrics/counters/raw/query
- POST /hawkular/metrics/counters/rates/query
- POST /hawkular/metrics/strings/raw/query
- POST /hawkular/metrics/availability/raw/query
- POST /hawkular/metrics/metrics/raw/query
- The endpoint accepts a list of metrics ids and allows filtering by
providing start time, end time, sort order and limit.
- For more details: HWKMETRICS-393
<https://issues.jboss.org/browse/HWKMETRICS-393>
4.
*Performance Enhancements*
- Two Cassandra driver settings (maxConnectionsPerHost and
maxRequestsPerConnection) are now user configurable. Part of the update,
the default values have been increased from the driver defaults. The new
defaults had a significant performance boost for a simple test
deployment.
The settings are configurable to allow users to optimize driver behavior
for larger Hawkular Metrics deployments. (HWKMETRICS-430
<https://issues.jboss.org/browse/HWKMETRICS-430>)
- On Linux deployments, the Cassandra driver uses Netty native epoll (
HWKMETRICS-418 <https://issues.jboss.org/browse/HWKMETRICS-418>)
5.
*Cassandra*
- Fixed an issue with schema upgrades present in Hawkular Metrics 0.15.0
and 0.16.0. We recommend upgrading from previous versions directly to
0.17.0. For more details: HWKMETRICS-425
<https://issues.jboss.org/browse/HWKMETRICS-425>
- Cassandra 3.7 is now the supported version of Cassandra. Support
has been deprecated for Cassandra 3.5.
*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.17.0
JBoss Nexus Maven artifacts:
http://origin-repository.jboss.org/nexus/content/repositories/public/org/...
Jira release tracker:
https://issues.jboss.org/browse/HWKMETRICS/fixforversion/12330692
A big "Thank you!" goes to John Sanda, Thomas Segismont, Mike Thompson,
Matt Wringe, Michael Burman, and Heiko Rupp for their project
contributions.
Thank you,
Stefan Negrea
9 years, 9 months
Metrics and use of metrics_idx
by Michael Burman
Hi,
This sparked my interest after the discussions in PR #523 (adding cache to avoid metrics_idx writes). Stefan commented that he still wants to write to this table to keep metrics available instantly, jsanda wants to write them asynchronously. Maybe we should instead just stop writing there?
Why? We do the same thing in tenants also at this time, we don't write there if someone writes a metric to a new tenant. We fetch the partition keys from metrics_idx table. Now, the same ideology could be applied to the metrics_idx writing, read the partition keys from data. There's a small performance penalty, but the main thing is that we don't really need that information often - in most use cases never.
If we want to search something with for example tags, we search it with tags - that metricId has been manually added to the metrics_idx table. No need to know if there's metrics which were not initialized. This should be the preferred way of doing things in any case - use tags instead of pushing metadata to the metricId.
If we need to find out if id exists, fetching that from the PK (PartitionKey) index is fast. The only place where we could slow down is if there's lots of tenants with lots of metricIds each and we want to fetch all the metricIds of a single tenant. In that case the fetching of definitions could slow down. How often do users fetch all the tenant metricIds without any filtering? And how performance critical is this sort of behavior? And what use case does list of ids serve (without any information associated to them) ?
If you need to fetch datapoints from a known metricId, there's no need for metrics_idx table writing or reading. So this index writing only applies to listing metrics.
- Micke
9 years, 9 months
errors when embedding c*
by John Mazzitelli
> We have embedded C* today using the maven 'embeddedc' profile.
> HOWEVER, I can tell you that that still doesn't work quite right
> ...
> some components throw errors at startup and you usually have to
> shutdown the h-server, restart it, and usually (not always) things
> start working again.
Whether we embed C* in -services or in another distro, either way, we have a problem.
I'm sure all of us have seen this at one time or another :)
It seems if I restart the server, most times (not all) I no longer see these errors. I have no idea if this is just going to cause problems in alerts, or if there are other problems we'll see. But I see lots of these kinds of errors:
===========
2016-07-05 11:06:21,747 ERROR [org.jboss.as.ejb3.invocation] (Thread-127 (ActiveMQ-client-global-threads-913106351)) WFLYEJB0034: EJB Invocation failed on component CacheManager for method public java.util.Set org.hawkular.alerts.bus.init.CacheManager.getActiveDataIds(): javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0241: EJB 3.1 PFD2 4.8.5.5.1 concurrent access timeout on CacheManager - could not obtain lock within 5000MILLISECONDS
...
at org.hawkular.alerts.bus.init.CacheManager$$$view16.getActiveDataIds(Unknown Source)
at org.hawkular.alerts.bus.listener.MetricDataListener.onBasicMessage(MetricDataListener.java:82)
at org.hawkular.alerts.bus.listener.MetricDataListener.onBasicMessage(MetricDataListener.java:50)
at org.hawkular.bus.common.consumer.BasicMessageListener.onBasicMessage(BasicMessageListener.java:77)
at org.hawkular.bus.common.consumer.BasicMessageListener.onMessage(BasicMessageListener.java:63)
...
9 years, 9 months
inventory startup exceptions - but not causing problems
by John Mazzitelli
Lukas:
https://paste.fedoraproject.org/387177/14673904/
I see several of these inventory warnings in my agent itests - all my tests pass, so its not causing any problems that I can see. But just wanted to point it out. Seems to happen at startup?
-------
12:25:28,470 WARN [org.hawkular.inventory.rest] (default task-9) RestEasy exception, : java.lang.IllegalStateException: Transaction already open.
at org.hawkular.inventory.impl.tinkerpop.spi.GraphProvider.startTransaction(GraphProvider.java:93)
at org.hawkular.inventory.impl.tinkerpop.InventoryContext.startTransaction(InventoryContext.java:55)
at org.hawkular.inventory.impl.tinkerpop.TinkerpopBackend.startTransaction(TinkerpopBackend.java:125)
at org.hawkular.inventory.base.TransactionConstructor.lambda$startInBackend$88(TransactionConstructor.java:40)
at org.hawkular.inventory.base.TraversalContext.startTransaction(TraversalContext.java:339)
at org.hawkular.inventory.base.TraversalContext.startTransaction(TraversalContext.java:335)
at org.hawkular.inventory.base.Util.inCommittableTx(Util.java:76)
at org.hawkular.inventory.base.Traversal.inCommittableTx(Traversal.java:105)
at org.hawkular.inventory.base.Traversal.inTx(Traversal.java:96)
at org.hawkular.inventory.base.Traversal.inTx(Traversal.java:79)
at org.hawkular.inventory.base.Fetcher.loadEntity(Fetcher.java:72)
at org.hawkular.inventory.base.Fetcher.entity(Fetcher.java:55)
at org.hawkular.inventory.base.Fetcher.entity(Fetcher.java:39)
at org.hawkular.inventory.api.ResolvableToSingle.exists(ResolvableToSingle.java:52)
at org.hawkular.inventory.rest.cdi.AutoTenantInventoryProducer$AutotenantInventory$2.get(AutoTenantInventoryProducer.java:150)
at org.hawkular.inventory.rest.cdi.AutoTenantInventoryProducer$AutotenantInventory$2.get(AutoTenantInventoryProducer.java:141)
at org.hawkular.inventory.rest.RestTenant.get(RestTenant.java:54)
at org.hawkular.inventory.rest.RestTenant$Proxy$_$$_WeldClientProxy.get(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:129)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
at java.security.AccessController.doPrivileged(Native Method)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.hawkular.inventory.impl.tinkerpop.spi.NoRecordedStacktrace
9 years, 9 months
List of endpoints in components
by Lukas Krejci
Due to a bug in the listing of endpoints in inventory (something I never
really paid attention to, because it seemed like this was autogenerated from
Resteasy metadata) I started thinking about what is actually returned from
that endpoint.
The format is somewhat spartan:
[{"uri": "...", "methods": ["GET", "POST", ...]}, ...]
Now during the build, all the Hawkular components use something much more
complete and elaborate - the swagger.json - which we use to generate the API
documentation for hawkular.org.
I think it would be much better if the endpoint listing actually returned the
swagger.json instead of the above format lacking much of the information
available in swagger.
What do you think?
This would obviously break the current users but would be much more helpful
for API consumers given the richness of the swagger format and the amount of
information we include.
--
Lukas Krejci
9 years, 9 months
