Hey @patrickxb looks pretty cool. Since it says custom stats, that means you can create your own right? The webpage shows all devops type stats, is there a limitation in what can be created?
@patrickxb Thanks for the quick response! We really want to evaluate this option as we currently use statsd and graphite.
1) What would you say this offers over statsd+graphite?
2) What alerting/anomaly detection do you have? Are you using seyren? Something else?
Report
I'm the founder of StatHat. Let me know if you have any questions about the product.
We have a big new feature launching this week. I'll add a comment here when it is deployed.
Report
@jpatil You can create any kind of stat you want: user created, number of paid users, number of messages sent from females to males, api calls, load averages, page views, number of seconds iPhone app was active, etc. Any number or event in your application/system.
It is all custom stats, there are no default stats.
@patrickxb I am passing some information on from one of our developers.
"It looks like they are just a wrapper around statsD with some nice charting. Their Python lib has some issues, IMO, and their instructions are incorrect.
They say to do:
from stathat import StatHat
stathat.ez_post_count('test@test.com', 'My awesome stat', 1)
but you actually need to instantiate the StatHat class or you'll get a NameError.
You need to do:
from stathat import StatHat
stathat = StatHat() #this line
stathat.ez_post_count('test@test.com', 'My awesome stat', 1)
Alternatively they could change their library and not have the methods be attached to the StatHat class and just declare them at the module level. There really is no reason for them to have it under a class since the class isn't storing any data. If they made their code like this http://pastebin.com/224gNWAr then they could just do:
import stathat
stathat.ez_post_value('test@test.com', 'awesome stat', 100)
Their class should also be extending object in their implementation. The class is basically useless right now since it isn't storing any state or anything like that.
So, now if they do http://pastebin.com/U3256949 the class is more useful. You initialize it with your key. In general I think a single app would probably be sending stats to the same account 99% of the time so this approach saves you from needing to pass that key in every time you call the method.
stathat = StatHat('test@test.com')
stathat.ez_poast_value('my awesome stat', 1)
ALSO, it just sends HTTP request to their web api. The major issue is its synchronous so if you are sending stats your app won't continue until the request finishes so if their site gets bogged down or something its going to slow your app down.
One last piece of feedback: i'm trying to change my interval to show 1 day of history in 5 minutes instead of 15, but it keeps changing back to 15.
Oh, and one last note:
"ha yeah this dude did basically exactly what i was thinking https://github.com/kennethreitz/...
He is a Python baller though, we use his Requests library in every single Python project here I think."
Report
@ffumarola StatHat is not a wrapper around statsd.
And yes, Kenneth's python library is better.
We make our libraries asynchronous when the language supports it. We would never suggest you make a synchronous call from an online application. One good option that some of our python users use is Celery.
As far as the timeframe interval, that's because you have a free account. Paid accounts can look at timeframes down to 1 hour at 1 minute intervals. Free accounts are limited to 1 day at 15 minute intervals.
fintech spy
fintech spy
fintech spy