These examples certainly seem like good use cases for counters.

Being able to "alert" when a counter reaches a particular value could involve doing a read before write (or immediately after the write) or maintaining counter values in memory. Cassandra is not a good fit for the former. For the latter Infinispan might be a good fit.

I was not sure whether or not we would need to tagging for counters, but I think we will want it based on these use cases. I am not sure how RHQ Metrics could distinguish between b) and c) without applying additional, domain/application specific semantics to the metrics. Right now the schema for the counters table looks like,

CREATE TABLE counters (
   group text,
   c_name text,
   c_value counter,
   PRIMARY KEY (group, c_name)
);

If I want to track API calls per method, I could do

UPDATE counters SET c_value = c_value + 1 WHERE group = 'api calls' AND c_name = 'Method1';
UPDATE counters SET c_value = c_value + 1 WHERE group = 'api calls' AND c_name = 'Method2';

And then to track calls per user

UPDATE counters SET c_value = c_value + 1 WHERE group = 'jsanda api calls' AND c_name = 'Method1';
UPDATE counters SET c_value = c_value + 1 WHERE group = 'jsanda api calls' AND c_name = 'Method2';

This is pretty straightforward. If the application writer has some understanding of the schema, then he might realize that all counters in the same group can be fetched in a single query. And if he wants to fetch all user counts, then he might consider doing something like,

UPDATE counters SET c_value = c_value + 1 WHERE group = 'user api calls' AND c_name = 'jsanda:Method1';
UPDATE counters SET c_value = c_value + 1 WHERE group = 'user api calls' AND c_name = 'theuete:Method2';

I think counters sound about right, but not entirely. Very often such api usage calls involve a (sliding) window and apparently our current counters don't do that. See also the other thread about metric types.