Alternative to using RDBMS

[lupacexi]

Hi All,

I'm new to Zabbix and I have a concern of using relational database to store transactional/historical data in it which will eventually grow over the time. Does anyone have any good strategy to address this?

Another concern, if the database server crash, will the main monitoring function still works (i.e monitoring availability of other hosts and services and then sending alerts) or do I need a separate tool just to monitor Zabbix's database?

Thanks in advance.

[LenR]

Zabbix has a housekeeping function to keep the database pruned. If you are very large, the history and trends tables should be partitioned and just delete partitions when their retention is reached. Our database still grows, but so does our host count, so it's hard to blame Zabbix. Remember, your dbms may not return free space to the file system, that is an advantage to the partitioning method.

Zabbix has an alert for database down, but anything can break and not be able to notify. Each installation has it's weakest links, you fix what you can afford to fix :-)

[Linwood]

just as a different thought: many of us were drawn to zabbix because it DOES use a real database, allowing for referential integrity and transactional control, and also easier direct access when people need to go around the code (or verify the code). People coming from a database background wonder how something like Nagios actual works with all those text files.

[AdrianG001]

I would rather go for zabbix . I`m user of Nagios since it is used by most of the companies but after using it for a while in my company. We are looking for a alternate solution something like Zabbix. Here is the main reasonwe are thinking to do so Hidden costs of Nagios open source monitoring and Minimal Support.

Regards,
Adrian Gates
Windows Admin

[DmitryL]

No need to worry about SQL database in terms of size. As already mentioned Zabbix has built-in process called Housekeeper, and the task of this process is to delete historical data from database that is older then retention period specified for particular item.
Housekeeper may struggle and cause some performance issues on 500G+ databases (depends on hardware and configuration) by simply not keeping up with all incoming data. Table scan takes too much time, locks, other process suffer etc.
Therefore personally I always recommend to start with partitioning in history and trends tables. It is very easy and quick process in the beginning, but will take extra hours when your database will be big.

And always remember, that in growing environment database also will grow.
If you use retention period 3 month for history than your database will grow quickly for first 3 months.