Suggest that Clock by default use UTC times, e.g. in JSON serialized report
williamwsmith opened this issue · comments
The JSON serialized metric registry reports a datetime Now which includes timezone offset etc. These times can be ambiguous. Suggest that the Clock class use UTC as the default. Also could add a getter to Clock that is UTCDateTime() or something like that as the counter to LocalDateTime property. BTW I do really appreciate the practice of passing in a Clock interface/abstract class everywhere when a date/time is needed. Makes testing easier.
Can you guys work together? https://github.com/danielcrenna/metrics-net
I like you design in terms of yours is much more extensibile/pluggable with the wide use of interfaces.
However now that Ayende (http://ayende.com/blog/167553/metrics-hunt-in-ravendb) is involved and contributed to metrics-net, and RavenDB is using it, Daniel's version will get more production level testing. So why not combing forces (again)?
@williamwsmith initially when I needed a metrics library I started using Daniel's port - which is really great - but Daniel moved on with his career and does not actively maintain the library. This was the main reason for creating another port.
Another reason, was trying to clean up the API as much as I can, keep the core library free from any 3rd party dependencies (like servicestack.json or json.net) and provide extension points so that adapters can be built independently of the core library.
I've tried suggesting my port to Ayende (you can see the comments to the Metrics Hunt post), and i'm currently working on introducing a "context" (see https://github.com/etishor/Metrics.NET/blob/metricsets/Samples/Metrics.Samples/MultiRegistryMetrics.cs) to the metrics that would easily allow the use case needed in RavenDb, but I guess Ayende & HR already invested in using Daniel's port. Maybe in the next RavenDb version :)
Anyhow, i'm keeping an eye on the changes to Daniel's port and to the original Java library, and try to port any applicable changes.
Switching to UTC time makes perfect sense. I'll do that soon.
Great thanks for the reply. I am sticking with your "port" as it is easier to extend. I have been working on a Redis backend and a Redis Reporter extending your work. I don't know if it will lead to anything you might find interesting yet.
That sounds awesome. I'm glad to hear others find the library useful.
My next item on the todo list is to polish and finish introducing the Metric Context concept. This is something I ended up needing after adding 100+ metrics to a project. I need a way to categorize them when viewing.
After this I plan to find a solution to persistent metrics. I would really really like to use Graphite or Influxdb but getting them to run on winodws is a dreadful experience and most of my prod environment is windows.
I'm even considering using something like Ayende's Raven.Voron or even LMDB directly as a time series storage. Or even porting Graphite from python to C# (i hope it will not come to that).
Redis is a good candidate also as there are some articles about using it as a timeseries db. My main concern with Redis is that ALL the data is ALWAYS in the RAM - which in this case might not be optimal.
I ended up removing the LocalTime and only using UTC time. Changes are merged in the dev branch.