27 Nov
2014
27 Nov
'14
5:36 p.m.
Hello,
given that the module is providing the connector from kamailio.cfg to
statsd, it indeed is fine from this point of view -- no new
stats/counters being defined inside the module.
Overall the module is ok, before pushing it to official repository, few
things have to be taken care of.
Important:
- the README in the module directory must be the one generated from the
xml doc, right now is the markdown version of an install guide for the
module being hosted out of kamailio repo, which will become irrelevant
once included there
- the stats.txt from doc subfolder should not be added
- README file can be generated with: make modules-readme
modules=modules/statsd (you can add nocatalog=yes if stucks when trying
to generate on mac os x)
Can be dealt after the import:
- variables must be declared at the beginning of functions (or blocks)
-- it ensures the compatibility with old or strict C standard
- add IDs to the xml docbook sections for functions and parameters to
have proper alphabetic indexing - guidelines here:
http://kamailio.org/wiki/devel/module-docbook-readme#section_ids
- a long integer is printed in a 20 byte buffer, being signed and zero
terminated, can end up with 21 bytes - not the case of such value (time
being printed at least as I could see), but it is better to be safe
- use snprintf() instead of sprintf() when printing the statsd commands
to ensure that it doesn't exceed the declared buffer size -- as I could
spot, key can be given as parameter, with no restriction on lenght
Since we are here, a wish list for the future:
- add option to push an internal stats/counter value to statsd on demand
from config by giving the stats name as parameter and eventually on a
timer task based on a module parameter listing the names of the stats to
be pushed
- make the functions to take parameters with variables -- should be easy
by looking at other modules that export functions accepting variables
Cheers,
Daniel
On 24/11/14 11:54, Eloy Coto Pereiro wrote:
Hi,
Thanks for your replies.
- About the doc, it's in xml, but I copied plaintext file. [0]
- Yes, but in this case the counter is not stored by kamailio. Counter
is a datatype into statsd [1]. BTW: I didn't use snmpagent in the
last year, I will have a look to check if exist any best way.
[0]
https://raw.githubusercontent.com/eloycoto/statsd/master/doc/statsd.xml
[1] https://github.com/etsy/statsd/blob/master/docs/metric_types.md
Regards
2014-11-23 10:07 GMT+00:00 Olle E. Johansson <oej(a)edvina.net
<mailto:oej@edvina.net>>:
Great stuff! Very useful functions.
Some notes:
- The documentation needs to be in xml format, not a text file
- we already have to modules handling one set of counters/stats
objects in the core. Maybe you should look into
using those counters instead of adding a new set. These counters
are also exposed in kamcmd and some in
snmpagent automatically, so you gain a lot by using them.
- I wonder if this module should be focused on the connection to
statsd and the timing functions
should be somewhere else. I can't point to where now...
/O
On 21 Nov 2014, at 21:26, Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Hello,
thanks for the contribution, we will grant you git access to push
the module in the official repository. I will send you another
email asking the afferent details.
Meanwhile I will do a bit of a review just in case some exiting
parts worth to be re-used.
Cheers,
Daniel
On 19/11/14 21:08, Eloy Coto Pereiro wrote:
Hi all Kamailio developers,
I would like to propose a new module that I've written recently, that provide
native integration with statsd[0]/graphite[1].
The module provides the ability to send information to statsd (You can use InfluxDB
too) with different kind of information. I wrote small post in my blog[2] and doc are in
the repo [3].
The typical scenario for this module is for monitoring features into kamailio. For
example:
- Monitor how long we need to reply a new request.
- Store how many errors send our providers.
- Check how long take one sqlquery.
- Check how many times are using the new feature
Nowadays we[4]are using kamailio-statsd and we track in simple dashboard[5][6] all
information that we get from kamailio, and other software (Asterisk, Django Backend,
Diamond[7]) and we have in simple click all the information that we want.
The module doesn't have any special deps, it's a simple socket that connect
to Graphite. For timing function I'm using avp to set init_time.
I hope that this contribution could be useful for the community and I look forward to
hearing your feedback, thoughts, suggestions.
Best regards,
Eloy Coto.
[0] https://github.com/etsy/statsd/
[1] http://graphite.wikidot.com/
[2]
http://acalustra.com/kamailio-statsd-better-statistics-in-your-voip-platfor…
[3] https://github.com/eloycoto/statsd
[4] http://www.foehn.co.uk <http://www.foehn.co.uk/>
[5] http://grafana.org <http://grafana.org/>
[6] http://play.grafana.org/#/dashboard/db/new-features-in-v19
[7] https://github.com/BrightcoveOS/Diamond
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org <mailto:sr-dev@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -
http://www.linkedin.com/in/miconda
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org <mailto:sr-dev@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev