-
15. Re: Api functionality
Mike Thompson wrote:
What about adding simple counters (these are very common in websites)?
Example: Api.incrementCounter('home.page.counter');
Cassandra even has a special counter type.
Definitely need to figure out sooner rather than later how we are going to use counters. Counter columns cannot be mixed with other data types other than those used for the primary key.
-
16. Re: Api functionality
option 3 - Do not overwhelm the server and only retry failed data
The server can report back to the agent the raw data that it failed to store. The agent can spool that data to disk, and resend it at some point in the future. There could be some different approaches. The agent could retry on some fixed interval, or maybe it uses some initial delay with an increasing back off, e.g., 2 minutes, 4 minutes, 8 minutes, etc. This option requires the most work, but I think that it is the most robust.
At any point during the processing the server side process may crash, time out or the network be partitioned. This can happen when the data is received, but before being persisted or even after it's persisted, but before the response is being written. No matter what, to the client both errors look the same: the ack for a particular data point is missing. If you really want to provide delivery guarantees as described before, then you would need to ACK every single data point once it's persisted and eliminate duplicate entries that may occur when a client resends the data.
Taking everything into account, I think it's not worth trying to achieve strong delivery guarantees for a metric system.
-
17. Re: Api functionality
John Sanda schrieb:
I am -1 on the idExists method if the only use case is to determine if an id exists. We can wind up with ids stored in Cassandra that have no corresponding data because it has all aged out. What purpose does having an id with no data serve? We could easily build a method on top of the core API to check whether or not there is any metric data for a given id.
What are the use cases for manual delete operations?
Imagine a room full of boxes. You are allowed to put stuff into the boxes (blindly). You are allowed to get something from a box if you happen to know box where it is in.
You are not allowed to get a list of all the boxes in there.
You are not allowed to clean up a box when you know that you don't need it anymore.
If we only allow things that Cassandra excels in and move all other responsibilities to the client, why would a client then want to use our stuff and not something else?
Wrt manual delete. OpenTSD says they keep raw data "forever". So if you have collected 2 years of raw data for a host and decommission the host, you probably want to get rid of that stored data so re-use that space for other purposes.
IdExists and listIds are services for people that want to write dashboards.
-
18. Re: Api functionality
// The idExists call [...]. We
// need to decided whether or not this check is really necessary. There isn't really
I don't see this one as a must have. [If we did have it I assume this would be a rest HEAD call on a resource]. Instead, i would like to see an API to search just the Ids so we can provide dynamic type-as-you-go selection of valid ids in a UI.
Just my opinions.
The RestApi has this as org.rhq.metrics.restServlet.MetricHandler#listMetrics the comment on the backend is
// TODO Do we really need this method?
// The C* based impl for this may very well require additional schema so I want us to
// be careful about about introducin new query operations.
This listIds can of course be uses to implement the idExists call - it is probably a shortcut or convenience method.