So to make our life even more interesting, we decided to take over the world – IT world. Not the whole world, but rather specific destination. To be more accurate, city of Hanover in Germany.

This city is famous for hosting digital industry’s largest and most international exhibition –CeBIT.  Last year more than 4,200 companies like Zabbix, maybe some of bigger size, from more than 70 countries tried to conquer the Earth. And some of them really did so.

So this year Zabbix decided to rule. If you are among those who plan to join the event, you will be able to find us at Hall No. 6, Stand D08 of CeBIT pro section. We plan to surprise you with a demonstration of the very latest version of Zabbix by showing around the newest features and talking about upcoming developments. We plan to devote a special presentation to a long awaited release of Zabbix 2.0 version, revealing to general public all those benefits and advantages that makes it so different from previous versions.

Our special force during this event will be represented by Alexei – Mega-Mind, Jelena – Open-Mind, and Rich – Master-Mind.

It all started out when Pavel Timofeev pointed out a problem with vm.memory.size checks on FreeBSD: some of the memory checks on FreeBSD as supported by Zabbix 1.8 agent are not very meaningful (see ZBXNEXT-1024 for more details). So we started looking into the issue and discovered that some memory checks on other operating systems are not very meaningful either. One of these operating systems was Mac OS X. Since it is not a common guest in our office, developers decided to take the opportunity and take a look at Zabbix code for Mac OS X. Among other things, support for Mac OS X lacked network checks. So we started looking at network checks for other platforms and so it went…

Mac OS X

Since we do not see Mac OS X very often, the documentation page for 1.8 has a bunch of question marks to indicate that we did not know which checks are supported. During this development we have added some and documented all checks supported for Mac OS X on the documentation page for 2.0.

Here is a summary of new items supported on Mac OS X:

• system.boottime
• system.cpu.num[max]
• net.if.collisions
• net.if.in
• net.if.out
• net.if.total
• vfs.fs.discovery

In 1.8, item system.cpu.num[online] actually returns the number of available CPUs. This has been fixed and support for system.cpu.num[max] was added. There is now also a possibilty to monitor network traffic and discover file systems!

net.tcp.listen and net.udp.listen

As the development when along, item net.tcp.listen has been added on Mac OS X and item net.udp.listen has been added on FreeBSD, Mac OS X, and Solaris.

vm.memory.size

The main part of development was related to a single memory check: vm.memory.size. The problem pointed out by Pavel was that, for instance, vm.memory.size[used] on FreeBSD did not return very useful information and there was no way to monitor FreeBSD-specific types of memory: active, inactive, wired. Other platforms turned out to have the same problem and it was clear that vm.memory.size had to be redesigned a bit.

Clearly, it is necessary to monitor platform-specific types of memory, so item vm.memory.size now provides access to most of them. For instance, Zabbix can now monitor pinned and free memories on AIX, as well as active, inactive, wired, anon, exec, file, free memories on NetBSD. The complete list for all platforms is available at the documentation page for 2.0.

It is also apparent that monitoring platform-specific types of memory is not always necessary. What is required is a user-level estimate on how much memory is used and how much memory is available. Items vm.memory.size[used], vm.memory.size[pused] and vm.memory.size[available], vm.memory.size[pavailable] are intended to provide these estimates – in bytes and in percentages from total.

Note that vm.memory.size[used] plus vm.memory.size[available] do not necessarily equal total amount of memory. For instance, on FreeBSD active, inactive, wired, cached memories are considered used, because they store some useful information. At the same time inactive, cached, free memories are considered available, because these kinds of memories can be given instantly to processes that request more memory. So, for example, inactive memory is both used and available simultaneously. Because of this, item vm.memory.size[used] is designed for informational purposes only, while item vm.memory.size[available] is designed to be used in triggers. These user-level estimate items are available for all platforms. More information is available on the page describing vm.memory.size parameters.

One notable consequence of these changes is that we have removed item vm.memory.size[pfree]. Since free is a platform-specific memory type, getting its percentage from total is not very useful. Item vm.memory.size[pavailable] now provides the necessary functionality.

A final small note is that vm.memory.size[shared] has been dropped for Linux 2.6, because it always returned 0. It is still supported for Linux 2.4 and corresponds to “shrd” memory in top(1) output.

That’s what happens when management isn’t looking. Beware.

Picture by Ed Schipul

Zabbix is used to monitor many of the world’s biggest environments. But it also monitors its own (albeit small) environment. And this environment recently saw a shark attack.

One early Friday morning arriving in the Zabbix office revealed suspicious sounds from the server room. It sounded a bit as if a plane was locked up in there and tried to break free. Opening the door resulted in… no, not this sound as the title might have made you guess, and not even in Wiresharks. Instead it resulted in a significant heat wave, which also immediately explained the reason for that plane-like sound – with such temperature all fans were trying real hard to prevent hardware from frying.
Turned out, electricity supply for the conditioning unit had died off, and the devices, busily serving various Zabbix resources, were fighting for fresh air.

Here we can see a 3 day ambient temperature (temperatures for CPU and disks were higher) for one server. Temperature starts rising before midnight until a sharp decrease several hours later.

We can see how before the incident temperature was very stable at 21 degree, barely deviating from this value. During the non-global warming it jumped up to 36 degrees, followed by a very rapid drop for about one hour. Temperature drop stops around 6 in the morning and here it doesn’t go back to the previous level of 21, instead sticking to ~23 degrees. While not significant, there’s a small rise around 9 o’clock to about 24 degrees.

If we also look at a graph for one of the virtualisation servers for one week, we can see the same rise of temperature, here to 37 degrees (with a very steady 21 before that, same as for the previous server).

This graph does show one weird thing, though – a decent guess would be that during the temperature rise fan RPM goes up as well. Here it’s not like that – fan RPM drops instead from about 3485 RPM to 3465 RPM. If anybody has insight into this unexpected response, please share that with us.

Let’s look at another graph. This one shows UPS data for one day, including output voltage and UPS load. While other values don’t change in response to the temperature increase, UPS load does, and does notably. It goes from 76% to 85% during the temperature increase period, with the same sharp drop afterwards.

While some of that can be attributed to increased fan RPM (except for that virtualisation system), there might be something else – again, if you have some experience with power draw monitoring at different temperatures, please, share it.

While graphs are interesting visually, they also do show some useful data, like times when temperature started to increase and when it dropped. The puzzle of one system fan RPM going down during temperature increase is very interesting as well. Additionally, this incident gave some ideas on what additional values could be monitored in the Zabbix environment – maybe that also gave some new ideas to you?

Talking about Zabbix

We had two days of Zabbix talks about various topics, including Zabbix in safety critical environments, scaling in huge enterprises, performance and API usage – and lots of others. In between the talks heated discussions took place about various practical topics. What we learned – breaks were not long enough, at least the first ones. Everybody seemed to be so very excited to meet others whom they could discuss secrets of monitoring with, that it was hard to get in the mood for another talk. Given the extreme variety of industries and environments that participants represented, it was indeed a unique chance to catch that person who implemented something you just started looking into.

It was amusing to see some speaker show how concerned they were with a specific problem with triggers going into UNKNOWN state – which in their environment was represented by blue icons  – by saying “red and blue lights” (while intending to say “red and green”, of course). Or, after some discussion with our USA friends on how “nobody says from USA” the previous night, hear the European slant of the event with “I’d like to introduce our next speaker from the USA”…

Who was there

More than 100 people participated in the conference from many countries from as far as Brazil and Japan. The biggest amount of visitors was from Russia, while Estonia grabbed the second place. Third place was tied between Japan, Lithuania and The Netherlands.

…not just Zabbix

Of course, it wasn’t just strictly Zabbix that was being discussed. There was quite a lot of other activities, like several nights of various Riga specialties, including the welcoming Riga Old Town, beer and Riga Black Balsam (which seemed to earn a special place in hearts and clothes of some participants). You can see both official and less official events in the picture gallery. If you have your own stories about the Zabbix conference, feel free to share them in the comments here.

Oh, and if you have your own pictures of the event, send them over to the Zabbix conference e-mail (if you have more than a few, just let us know – we’re all technical people here, we surely can figure out better means to transmit images).

Have any other feedback? Post that in the conference forum thread.

Couldn’t attend?

For those who couldn’t attend or would like to refresh their memories most of the slides are available for download on the conference agenda page. While that won’t have most of the content that was given during the talk itself, it might at least give some indication of the topics covered during the conference.

See you next year

We also heard that many people could not come because they found out about the event too late – to prevent that from happening next year (we just have to have this event again…), we would like to start planning a bit sooner. To keep up with the news you can follow the usual community channels (forum, IRC channel), and you can also subscribe to the Zabbix newsletter – see left hand side on the Zabbix homepage.

Suggested dates for the next year event will be announced shortly – stay tuned. In the meanwhile we could promise to tell you next year in-person how one of the conference memes started.

…no Wi-Fi

Preparing for the conference

Last things are checked and prepared in the conference venue:

Preparing in a different way

In the meanwhile, some of the participants are preparing in a different way, making sure they have the required strength:

Zabbix provides a network map feature, where images may represent triggers, hosts, host groups etc. They may show current status, problem count and lots of other data. There are some default images that may be used in the maps, and users may also upload their own. This uploading has been a problem in the past.

These images are stored in the database. The problem is, Zabbix supports 5 different databases, and they store binary data in different formats. And that resulted in users having different problems when database encoding was incorrect. Of course, maintaining data in multiple different formats is also not that easy, and updating icon set is harder than it should be.

Re-base the images

Thus the idea is to unify image storing and keep them in base64 for all databases. While that would increase the amount of space images take, it would solve lots of problems and make life easier for Zabbix users. The problem is upgrading.

Users would want to keep their existing images, probably. So upgrade should convert them to base64 (keeping support for old format would be duplicate work, and there would be no way to phase this support out later anyway. Doing this for all supported databases does not seem to be possible at this time with the upgrade process Zabbix currently uses – Zabbix database patches for going to the next major version are in SQL. Involving a separate process outside the database at this time is not considered, and storing images in the filesystem wouldn’t work because of the distributed monitoring.

So the question to the Zabbix community would be – how would you handle this problem?

And, by the way, we are looking for great PHP programmers…

This article has already been translated into Brasilian Portuguese – Representante do ZABBIX-JP está indo para a Letónia.

“Community activities changed everything” – The only Japanese engineer working in Latvian company

2011/04/27

Latvia is a country by the Baltic Sea. The country is one sixth of Japan, official language is Latvian, and there are many people who speak Russian. The capital is Riga, which is a beautiful port city, called “Pearl of the Baltic”. Zabbix SIA, which is developing Zabbix, an open source monitoring software, is located here.

“I had never dreamed that I might work abroad, moreover in Latvia,”

Republic of Latvia, Riga

says Kodai Terashima, who is a representative of ZABBIX-JP (Zabbix community in Japan) and the only Japanese engineer working in Latvia. He had been working for MIRACLE LINUX CORPORATION, but quit the company in April 2011. Soon after that, he went to Latvia and now he works for Zabbix SIA.

Going to Latvia – it was a very big decision for his career. Why does he work in a foreign country in which there are only 20 Japanese people? His answer is very simple. “It’s the community activities of Zabbix.”

The encounter with Zabbix has changed everything

He first encountered Zabbix in 2005. At that time, he worked for a System Integrator company as an infrastructure engineer who manages and constructs networks and servers for IT systems.

Mr. Kodai Terashima, Zabbix SIA

“Our system is down often, so we would like you to construct a monitoring system, but we don’t have enough budget.” It was one of those projects that would change his career.

“My work was “looking for a good and free monitoring software.” I searched and compared some open source monitoring software. So, I had my eye on Zabbix.”

At that time, Nagios was the most famous software as an open source monitoring tool. There were many installations of Nagios in Japanese companies, and translated Japanese documents. On the other hand, Zabbix was a totally unknown software. In his words, there was not one Japanese document related to Zabbix as a result of Google search in 2005.

However, features of Zabbix were an equal match for Nagios. As a result of comparing some open source monitoring software, Zabbix was adopted in the project. “The project might be a very early installation of Zabbix in Japan,” says Kodai.

Only one in community

In August 2005, a few months after the project completion. Mr. Terashima launched ZABBIX-JP site, as a community of Zabbix in Japan.

Forum on ZABBIX-JP

“I posted a patch which was Japanese translation of Zabbix web interface at the same time. That was the start of exchanging some e-mails.”

The main activities of ZABBIX-JP are translation of web interface and documents, sharing of information on the forum, creating and sending patches. Currently ZABBIX-JP has hundreds of users in the mailing list and 8 person staff, but it was only himself in the community in 2005.

There were many tasks for him alone. The translations were especially troublesome. He hadn’t used English in his life and work before launching ZABBIX-JP. He had only read some English technical documents. He continued to gather and translate Zabbix information after work for several years.

Launching and managing the site of the software which he encountered in the project alone — not only doing some tasks but also keeping his motivation going seems hard. However, Mr. Terashima says, “I became an infrastructure engineer because I was interested in Linux, so I had a dream of launching a open source community.” Moreover, “If a forum is opened, I have to answer the posts,” he smiles quite openly.

Zabbix at work not only in community

Mr. Terashima thought “I would like to get into the open source world”, so he changed his job to MIRACLE LINUX CORPORATION. At first, his work was related to Linux, and then he launched a Zabbix business in the company because of a request for “good monitoring software” by his customer in 2008.

He planned and did consultations, support for third-party software of Zabbix, and has grown the business. The business has grown to 4 full-time engineers in Zabbix team. As a result, the team has achieved the completion of about 20-30 Zabbix projects in about 3 years.

Zabbix began to spread in Japan with the expansion of the business. There were not many posts on the forum of ZABBIX-JP at the beginning, but the number of posts increased after a while. As Zabbix-related information was placed in some media in 2008, the posts in the forum increased to 10 posts per day.

“I must get wide knowledge as an engineer”

Mr. Terashima got into Zabbix not only with the community but also work. He is thankful to his company which accepted his community work and gave him the opportunity to launch the Zabbix business, but he started thinking about a job change.

“I wanted to know more things. I have been using Zabbix for 6 years, and I have worked for MIRACLE LINUX for 5 years. If someone works for one company, their knowledge and work style tends to fix. I want to know other technologies and companies, and to get more knowledge.”

Infrastructure engineers should have wide knowledge including servers, networks, applications, etc. He says “I am an infrastructure engineer,” again and again. His words, “An engineer should want to acquire varied knowledge, not stick to one technology,” reveal his goal as an infrastructure engineer.

Why don’t you work in Latvia?

November 2010. The turning point came suddenly from across the sea.

“If you are going to change your job, why don’t you work in Latvia?”

Mr. Terashima and Mr. Alexei Vladishev, in Tokyo.

He told Mr. Alexei Vladishev who is the president of Zabbix SIA and his friend from 2005 about the job change and he was offered this, “First of all, why don’t you work for Zabbix SIA as an engineer for one year.” The offer surprised him, but he accepted it readily.

“For a man who had been in the community, it would be a pleasure to read and touch software codes in the original company. And I’m looking forward to seeing the engineers in Zabbix SIA who I have communicated with only by e-mail,” he says with a smile.

Zabbix is not like general OSS, developed by a company. So, all of the contributors could work for Zabbix SIA. In Latvia, a new land and environment, a possibility to join the development team of the software can be suitable for anyone who wants to do “challenging a new things.”

He asked his company about it, and got “Please come a big in Latvia” as response, with encouragement. Six months later, he would set foot in Latvia.

Relationships with people are bred by community activity

Mr. Terashima’s role in Latvia is to be a “Bridge between Japan and Latvia”, supporting Zabbix users and Zabbix partner companies, and marketing for Zabbix in Japan. He says “I want to join the development of Zabbix in the future.”

On the other hand, he still worries about language communication. He has only used English with ZABBIX-JP community work, not on business. In addition, engineers of Zabbix SIA speak English in Zabbix SIA, but the official language is Latvian in Latvia. The distance of Japan and Latvia is revealed by his words “There is only one Latvian language book in Japan”. “But”, he added.

“If I was alone, I wouldn’t have enough courage to go to Latvia. But I have a relationship which was cultivated through ZABBIX-JP. I think that engineers in Zabbix SIA, Alexei and many people will help me, so I could decide to go there.”

And, the relationships with people in Japan also give him confidence.

“I have joined the Open Source Conference and study meetings of infrastructure engineers from 2010. I’m glad that I could get a chance to have relationships with many people and I am called “Terashima-san, specialist of Zabbix” in this community.”

Translation of OSS into Japanese will extend your activity

“Why don’t you try to do a community activity?” he emphasizes.

Community activities create a good chance to build relationships, especially for an engineer who wants to work abroad. He especially recommends trying an OSS which has not been translated into Japanese yet. There are many things to do like translations and creating patches, then engineers from abroad will get to know your name while talking about these tasks in the mailing list.

He also mentions English communication which most of engineers might worry about “Even if you have not used English before, you can translate or write e-mails in English because most Japanese can read and write in English well. You don’t have to speak English. You can write an e-mail in English, it’s a good starting point,” he encourages.

“I think that it is hard to keep your motivation going if you are doing the translation tasks alone. You will get greater confidence if you can communicate with foreign engineers in English by e-mail if you are not good at English.”

The activity started alone goes over the sea

We asked him what he would like to experience in Latvia, and how he would like to grow as engineer. He answered, “I want to become an engineer who knows the entire IT technology widely and generally and then knows specific points deeply.”

Most of “Great engineers” who he has met at the Open Source Conference or study meetings for infrastructure engineers are that type, he thinks.

“Well, it’s difficult if you are not so. If you have specific technical knowledge deeply, everyone remembers you as a specialist of something in community or study meeting. It’s important.”

Zabbix is an integrated monitoring software, it can monitor many type of devices, so it is necessary to have a wide knowledge of applications and infrastructure. Exactly, Mr. Terashima is an engineer who “knows the entire IT technology widely and knows more than just anyone about Zabbix.”

The community activities started alone became a business, made relationships and have gone over the sea. “Now, I am glad that I have one more pleasure in seeing the map of the world.”

Baltic sea

What is Zabbix configuration cache

Zabbix server generates configuration cache, mostly containing information on hosts and items to be monitored. It re-creates this cache by default every 60 seconds. This period can be customised by configuration parameter CacheUpdateFrequency.
The cache size itself may be set with configuration parameter CacheSize and by default is 8MB.

This means that at any given time Zabbix server sees a snapshot of the configuration. If you make changes in the frontend, they are written to the database – but not immediately seen by the server.

Be in control of it

Now, if you are not making constant changes to the Zabbix configuration, reloading this cache every minute is not really necessary, and can be a bit resource intensive on large installations. In those cases it would be useful to increase this interval. But then any changes to the configuration would be noticed much later, which is not that nice either. How could this be solved?

Potential solution – some way to initiate reloading of configuration cache without restarting server daemon. Which is what got implemented for Zabbix 1.8.6.

Previously, no solution existed for modifying any Zabbix daemon characteristics while they are running, so there was a new generic decision to make – how to do that, because there might be further, similar functionality in the future. Eventually, this was implemented as a generic “runtime control” flag that gets an option passed to it. To quote “man zabbix_server”:

 -R, --runtime-control <option>
Perform administrative functions according to option.

So it would accept additional option. Currently only one is supported – config_cache_reload. When using this option, server process looks at the configuration file and tries to find the PID file, as defined there. If found, signal is sent to the process, specified in the PID file.

# zabbix_server -R config_cache_reload
command sent successfully

Upon receiving this signal, server reads configuration from the database and rebuilds the cache. It logs receiving of the signal in the logfile as well:

forced reloading of the configuration cache

If configuration is being read already at that time (either previously initiated by real time control or just a scheduled run), on the commandline success is still reported and entry is added to the logfile, but signal itself is ignored.

Configuration cache and proxies

Now, that was mostly about Zabbix server. The wonderful remote data collector, Zabbix proxy also keeps the configuration cache – what about it? Of course, it was not forgotten.
There are two types of Zabbix proxies – passive one is contacted by the server, active one connects to the server.

Active proxy loads all its configuration data from the server upon startup and then repeats this process every hour by default. This period can be customised by configuration parameter ConfigFrequency. Configuration data is then stored in the local database on the proxy.
Thus, if one would make any configuration changes on the server, it might take up to one hour for these changes to propagate to the proxy (and then potentially a bit more time to reach active Zabbix agents).

It is desirable to have some way to signal proxy that it should re-read this configuration data, especially when doing the initial configuration or testing – but re-reading it from the local database, like server does it, would be no good – it’s synchronisation from the server that matters. The great news is that active Zabbix proxy, upon receiving configuration cache reload request, is smart engouh to actually ask for this configuration from the server first.

Sending the configuration cache reload signal to an active proxy would result in log entries like these:

forced reloading of the configuration cache
Received configuration data from server. Datalen 6629

Passive Zabbix proxy is different – there the server connects to the proxy and sends the configuration data. When configuration cache reload signal is sent to a passive proxy, success is reported, logged – but ignored. It is not possible yet to signal server to re-send configuration information to passive proxies.

Happy reloading.

The dark past

Up to now, Zabbix daemons would do something nasty when they encountered an unknown parameter in configuration files – for example, if one made a typo and instead of DBName option wrote DBNaame, Zabbix server would read configuration file up to that entry, fail… and still try to start up. What would this mean? That not only the misspelt configuration parameter would be ignored, but also everything after it, possibly without any warning at all.

Does that sound painful enough? Rightfully so, it has been a bane for both novice and experienced users. For example, writing TrendSizeCache instead of the correct version, TrendCacheSize, would not only use default trend cache value (4 MB), but also skip all the parameters that would follow it.

Now, this might get worse. Configuration parameters are case sensitive. Did you write Startpollers? There we go, you’re not getting the value specified, your server will run with the default amount of pollers, which is 5. And remember that it will also ignore all other parameters after this misspelt one.

The bright future

Zabbix 1.8.6 gets tough. It gets rough. It checks your parameter spelling and teaches you a hard lesson. Right, right, not really – it actually keeps a gentleman calm as if receiving an insult in a pub and refusing to fight. Zabbix daemons will refuse to start up if incorrect parameters will be detected in the corresponding configuration file.

While for most people that will be a wonderful thing that will allow to catch spelling mistakes early, it also means that your Zabbix daemons might not start up after upgrading to 1.8.6. It should be easy to solve – just be careful with the upgrade and test your configuration files before doing a full roll-out in production.

This is especially relevant for people with long-living Zabbix installations that have been upgraded and upgraded, possibly since Zabbix 1.0, thus accumulating all kind of cruft in the configuration files. Whether it’s the amusingly named poller parameter in older versions or anything else, Zabbix might not start up after the upgrade, if you were careless with the configuration files.

It should be noted that specifying a parameter more than once will still result in later values overriding all the previous definitions – that is not changed from previous versions.

There have been a few unorthodox things being monitored that we have looked at already – monitoring Zabbix documentation and monitoring weather forecast. But what could we monitor to determine the size of Zabbix community?

The archaeological dig

One of the standard communication methods for open source projects is IRC. For Zabbix users, place to communicate is channel #zabbix on IRC network Freenode. While precise records of the beginning of this channel are not available, some preserved logfiles show 13 users at June 1st, 2006. The same set of logfiles holds information about user count till today, mostly from channel join messages and manually invoked user list command. While more precise user count fluctuations could be deduced coupling user join/part records with this information, that’s probably not that crucial to have.

Analysing the records

Of course, to get some nice result we will try to use Zabbix itself. This is a quite non-common monitoring need, thus Zabbix does not have a built-in item to gather such information – yet. After a few kludgy scripts, concatenated files and format conversions (while all the logs luckily were from the same IRC client – Irssi – naming scheme and formatting had changed several times over this 5-year span) a list of timestamps and corresponding amount of users was obtained. Original logfiles had entry times in local time. To keep things simple, they were converted to Unix timestamps ignoring summer time offset. At the scale we will be looking at this data that shouldn’t cause any issues (and messing with the clock is silly anyway).

Once we have a list like that, we should somehow get that in Zabbix – and proficient Zabbix users probably have guessed by now that we will use a very nice commandline utility called zabbix_sender to do that. This utility allows to send any values to a specific Zabbix item type – Zabbix trapper items. Before sending the values, care was taken to set trend retention period (Keep trends option in item properties) to 10 years, because we would like to gather and keep this information for a long period of time. If that was not done, the internal Zabbix process that is responsible for old information cleanup, housekeeper, would come over and delete old values soon after we had imported them.

Getting the result

With the values imported it was time to look at a nice long term graph. But… by default Zabbix graphs are limited to 2 years. Our timespan was almost 5 years (to be more specific, 5 years minus one day). What to do? Luckily, this limit can easily be changed. As documented in the Zabbix manual, we had to change ZBX_MAX_PERIOD in the include/defines.inc.php file. After setting this to some larger value, a long term graph was available.

The great thing is that user count has increased over all this time. Other interesting things include pretty slow uptake during the first few years, with steady increase kicking in around… yeah, what year is that? Apparently, Zabbix graphs could be slightly improved when looking at longer period of data, otherwise no year information is shown. Digging a bit deeper and looking at data we can see the increase starting around first half of 2009. While x axis labels could be improved, at least the graph was generated pretty much instantly.

We can also see some periods of missing data (indicated by unlikely straight lines), but they don’t seem to hide significant trending information. Examining the legend we can see that maximum amount of users in the channel (at least as caught by the logfiles) has been 126 – not too shabby. Minimum has been only 7, though… and that seems to be caused by one of the significant drops much later in the channel history. That can probably be attributed to a netsplit, or maybe to some real life event (like celebrations in December).

Another interesting bit about the generated graph itself is it’s title – it shows “4y 12m”. While that might seem somewhat weird, we may try to recall the data range we have – and that’s 5 years one day short.

But preparing this long term report was motivating to keep such data gathered in the future as well, and maybe even with better granularity. Thus amount of users in the channel has been recorded for the last week hourly. Looking at the graph for approximately one week, we can see expected daily fluctuations (“working time” highlighting is based on GMT+3).

User count increases around 09:00 in the morning for that timezone and drops more or less steadily afterwards, indicating slight preference of European working time. There’s a significant but short drop on Friday – without further investigation we could again blame netsplit or another technical issue on the IRC server side. Of course, when comparing this drop with previous chart we have to take y axis scaling into account – note that the first graph started at 0 while this one has been autoscaled by Zabbix to start at 70. The drop would be barely noticeable if we would set the y axis scale to start at 0.

With the channel seeing a healthy increase we welcome you all to discuss (mostly) Zabbix related things in there right now.