Alive and kickin’

We’ve been little sluggish on updating you with news from SZARP world for a last few months. It’s not because nothing of interest was happening with our system. Quite the contrary – we’ve been doing some serious groundwork on core SZARP components. It’s just that updating occupies low position on our priority list, there are always things to do that are more important or fun ;).
But now that moment has finally come – on a gentle nudge from the guy who is paying our salaries, we had no choice but to give you some update on what is going on with SZARP 😉

In my opinion the most important, but not yet complete, is change of a database format. The goal is to let SZARP store data with (nearly) arbitrary time resolution, effectively. In addition to the extra flexibility, this also brings other advantages over existing format:

  • database occupies less disk space
  • (as a consequence of previous point) database sync takes less time
  • there is no longer distinction between high-resolution probes that sit on a server and can only be accessed trough TCP connection and archival data of 10 minute resolution that can be synchronized to local machine, with new db format all data can be synchronized to local machine and viewed with no connection to a server.

While working on new database format, we make our new db engine to support multiple data types (our old db supports just one data type). This is also a change that will make our life easier, but for SZARP to be able to take advantage of that improvement, other components of the system will need to be adapted. Even more goodies will be coming with new db format/engine but we’ll talk about them more once we have the code ready.

Of course this is not the only thing that we have been busy with. Here follows the list of changes that are not as major as the db switch, but still are worth highlighting:

  • draw3 has a data extraction feature, this feature somewhat duplicates ekstraktor3 features, but with draw3 you can extract data from user defined/network parameters, which cannot be done with ekstraktor3
  • szarp logging library “liblog” has been reworked to support multiple, configurable at runtime, backends, for now there exits 3 backends:
    • classic – old-style (i.e. used by SZARP so far) backend directly writing to files
    • syslog – backend using syslog library
    • async_syslog – our home-brew, libevent based implementation of syslog protool, aimed for apps using libevent
  • New feature for draw3. Some background info – on main draw3 graph widget each point (for periods decade, year, month, week and season) representes average value of parameter from corresponding time span (e.g. for period year, each point represented average param value for a month). For some types of params (especially counters) it isn’t necessarily the most interesting piece of information user would like to have. Because of this draw3 has been extended to allow user to choose among 3 different kind of values to be displayed for decade, year, month, week and season period:
    • average, default and only option available so far, each point represents param average value
    • last, last 10-minute probe for a point time span is drawn
    • diff, difference between value of last 10-minute probe and first 10-minute of time span covered by point is drawn

    New option is accessible from context menu of graphs’ list

  • and as usual, tons of minor changes and improvements