You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: