Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Temporal Counter #62

Open
BillBarnhill opened this issue Jul 8, 2013 · 3 comments
Open

Temporal Counter #62

BillBarnhill opened this issue Jul 8, 2013 · 3 comments

Comments

@BillBarnhill
Copy link

I am doing Zotonic web page statistics and rather than outsource them I'd like to track them in Folsom, with periodic dumps to external store. One of the things I am doing is a metric such as page requests. I have this as a set of counters with these names:
{nodal, page_req, Path}
{nodal, page_req, Path, Year, all, all, all}
{nodal, page_req, Path, Year, Month, all, all}
{nodal, page_req, Path, Year, Month, Day, all}
{nodal, page_req, Path, Year, Month, Day, Hour}

All but the first are created as needed, using notify/3.

What happens is that a page request comes in, the time components are gotten from the current date and time, and an {inc, 1} event is sent to each of the above counters.

The behavior I'd like is in three parts.

I) There is a type temporal_counter (or some other name) that I can declare {nodal, page_req, Path} as, and have Folsom automatically create the following counters (I changed format from above as it makes more sense I think and matches erlang:localtime()):
{{nodal, page_req, Path}, {{Year,all,all},{all,all,all}}}
{{nodal, page_req, Path}, {{Year,Month,all},{all,all,all}}}
{{nodal, page_req, Path}, {{Year,Month,Day},{all,all,all}}}
{{nodal, page_req, Path}, {{Year,Month,Day},{Hour,all,all}}}

Generically this is {Name, erlang:localtime like pseudo match spec}. I used all rather than '' because I thought storing '' in ETS might be problematic.

II) When an {inc, N} or {dec, N} event is sent for a temporal counter Folsom gets the current date and time and parses it into parts. This is ok since we're tracking at the hour level. If we were tracking the stats at the second level then we should have the time sent from the client, but that's a different use case. The event is then also applied to the corresponding temporal counters, creating them if they did not already exist.

III) Getting the individual counters would not be changed, so to get the above you would use the full name. The following additional function gets the data associated with this type of counter:
-spec get_temporal_metrics(name()) -> [{name(), date_spec()}] | []
get_temporal_metrics(Name) -> ...

If this issue is approved I'd be happy to work it, and contribute the result back to Folsom.

@joewilliams
Copy link
Contributor

Sorry it's taken me so long to review this issue. I'll get back you in the morning on if this is something that would get merged. Thanks!

@joewilliams
Copy link
Contributor

I think rather than include something like this in Folsom I think it's likely something that should be built on top of Folsom specific to your needs. I would be willing to entertain patches to make sure Folsom would allow you to built this but probably not a specific metric that has this behavior.

@joewilliams
Copy link
Contributor

Folsom has moved, please resubmit your issue at https://github.com/folsom-project Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants