Ad Widget

**Tractor** · 31-10-2006, 20:15

Huh, and also one other thing (I had seen mentioned in the forum somewhere, but as understood, this issue currently is not solved?):

hosts identification: currently hosts are identified by the name (if it is written somewhere in dns or /etc/hosts) or, in the other case - by the IP address. Actually, there are lots of situations when host can be accessed only by IP address (maintaining DNS or /etc/hosts can be painful) but the same IP can mean different hosts. For example: having several servers with active agents under one NAT. Or other example: virtual hosts or jails on UNIX servers. Or third example: network virtualisation, when the same actual hosts are used for different logical monitoring layers (e.g. different services, etc.).

So, it would be nice to have host identification by name even if there IP address is used when host is monitored. Or this is already possible?

**Alexei** · 31-10-2006, 20:39

Originally posted by Tractor

So, it would be nice to have host identification by name even if there IP address is used when host is monitored. Or this is already possible?

Yes, it is already possible. If one uses active checks only, ZABBIX Server does not connect to the agent at all. ZABBIX Agent initiates all connections and hostname defined in agent's configuration file uniquely identifies host name.

**Tractor** · 31-10-2006, 23:18

But this will not help in case of simple checks?

**Alexei** · 01-11-2006, 10:08

Simple checks already use either hostname or IP address depending on host configuration.

**Alexei** · 01-11-2006, 10:45

I'm not sure if the buffering will ever be implemented. Some buffering may be implemented quite easily (history, configuration), however the whole logic of ZABBIX highly depends on whole data stored in the database, so it would be very difficult to duplicate the information in memory/disk files for no-database operations. Also how long ZABBIX could operate in this mode? Until memory is out, disk space? There are many problems to be solved and I do not see good justification of all these changes.

I like the second idea about storage of original values. This is something to be considered in the future releases.

Thanks for the pointer to the old discussion regarding SLA stats. We already implemented support of downtimes, more improvements will come soon as well.

**Tractor** · 01-11-2006, 16:49

Hi again :-)

Data buffering and config caching are really needed. Those are needed so hardly that it is hard to explain. Simply when monitoring is used in wide environments and there are tens, hundreds or thousands of agents, data collecting nodes and corresponding count of network connections and local networks, it is impossible to ensure that all the supporting environment will work correctly. So without additional buffering and configuration caching Zabbix will become the Single Point of Monitoring Failures.

I think reprogramming problems aren't so impossibly big as it can be seem at first time. Actually those can be solved in structural way. The big problem is not on the technical side, like available disk space (we can ask the same question: what will be when mysql have no space on disk? huh...). The problem is how is it easy to change Zabbix in this way?

The imlpemented processes can be as follows:

1. Data collecting:
- Zabbix probes give values to agent
- agent collects values and sends them to buffer
- buffer temporary saves values and sends them to server with transactions
- server collects values from buffers and sends them to other server with transactions or to DB buffer
- DB buffer temporary saves values and sends them to SQL server

So, in the most cases (even on long outages) we will need few additional megs on the agent machines and up to several hundreds of megs on the server. Of course this will not work on the embeded agents, but this will not be big trouble - normal collecting servers can be used there.

2. Configuration buffering:
- server receives configuration data from DB
- server puts data into config cache
- agent receives configuration data from config cache
- agent puts data into its own config cache

All the caches will not be big. I think even in the largest monitoring systems server will have not more than several megs of cache and agents will use few kilobytes each.

3. Buffering or config caching for UI is not needed at all.

------

Of course there can be other possibility which can be more easily implemented in some cases - some lightweight SQL servers can be used. Several of them are available by GPL license. Maybe this way can be more easy?

------

The big feature you will receive with strong buffering will be "offline" monitoring. For example, you put such monitoring agent into server located in the ship. Server connects to main server several times per month (or several times per year) and you have all the data about how effectively that ship infrastructure work. I think such possibilities are hardly needed by some companies.

------

Again, about SLA: some time ago I had prepared some technical specifications according to ITIL (our company prepared requirements to some monitoring software supplier), so I can share with you.

**Alexei** · 02-11-2006, 21:18

The buffering seems to be quite complex issue which requires lots of thinking. I cannot comment on you ideas which are really very interesting and possibly the buffering may be implemented this way at some point.

By the way, it is likely that support of a light weight database will be implemented prior to release of 1.4.

The offline monitoring is an interesting feature (I already heard about this idea). I believe it fits nicely into ZABBIX distributed monitoring (DM) approach. More information and beta release of DM will come soon.

I would be very interested in the ITIL docs regarding calculation of SLA! Please send it to a l e x @ z a b b i x . c o m. Thanks.

**Tractor** · 03-11-2006, 12:52

Hi, I sent doc to you ;-)

Do not hesitate to ask for more info and explanations :-)

**israel dominguez** · 20-06-2008, 02:26

How monitored space in DB SQL(windows)???

Hi Alexei

I monitored free space of disk in my servers, but i don't How monitored free space in Data Base SQL????

For example my DataBase size 80Gb and

80 GB Total space
40 GB space used

I want to know, how monitored and send alert when the space to be the limit 15% free

i'm sorry for my Inglish

**swaterhouse** · 23-06-2008, 14:15

I assume you mean MS SQL Server since this is on winodws?

If so, the database size can be monitored by a performance counter and is included with the MS SQL template available in new installations of 1.4 and also on the wiki.

**israel dominguez** · 23-06-2008, 18:33

My server is Windows, i can used one perfcounter or UserParameter whit an query ????

For example this is Postgres and my servers is SQL server

UserParameter=psql.db_size[*],psql -U postgres --tuples-only -c "select pg_database_size('$1')"

i think put query whit an .bat and execute whit zabbix

**swaterhouse** · 24-06-2008, 14:19

If you use the template available on the wiki you will get the database size. You do not need to write a script or add any user parameters.

**israel dominguez** · 24-06-2008, 18:01

Originally posted by swaterhouse

If you use the template available on the wiki you will get the database size. You do not need to write a script or add any user parameters.

send me the link please!!!!

Thank you

**swaterhouse** · 25-06-2008, 14:18

you should really try searching the forums as this has been discussed multiple times.

http://www.zabbix.com/wiki/doku.php?...trib:templates

Ad Widget

The batch of feature requests

The batch of feature requests

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment