How can I get Zabbix and TimescaleDB to keep up with 20,000 hosts?

November 13, 2026 4 answers
Asked by ~excellent!indoor+posture

I'm polling close to 20,000 hosts with Zabbix. The TimescaleDB server has 96 GB of RAM, 12 vCPUs and 1.5 TB of storage, but the disk fills in less than a week and queries are slow. Compression is set to start after two days, and Grafana connects directly to the database.

What should I investigate before moving to something like VictoriaMetrics or ClickHouse?

Answers

radish relay team

Start with the collection side. Check the templates and identify which items are actually useful. Default templates can collect a lot of data that nobody looks at, especially when applied across thousands of hosts.

For anything you do need, check whether the polling interval makes sense. Moving an item from five seconds to ten seconds roughly halves the number of samples it produces, assuming regular polling. That can add up quickly across the fleet.

bracket_907+closed:

For SNMP in particular, check which MIB data is being collected and whether it is needed for monitoring or alerts.

Reply to this answer
__mostly_untangled

Look at retention as well as compression. Compression may reduce the space older data uses, but it does not remove it. If you don't need long histories for every item, shorter retention could reduce the storage pressure.

I'd also check whether compression jobs are finishing and keeping up with the incoming data. A two-day delay still leaves two days of uncompressed data to fit on disk.

Reply to this answer
seldom-used-megaphone

Measure the write rate and storage growth before picking a new backend. Host count alone doesn't tell you much without the number of items per host, their polling intervals and retention. Those numbers will help you estimate how much capacity you actually need, including room for uncompressed data.

Also check which queries are slow and what time ranges they're scanning. Grafana connecting directly doesn't by itself make a large query cheap.

Reply to this answer
volleyball_without_volley

Changing databases might be worth exploring, but I'd treat it as a separate architecture decision rather than the first fix. Reducing unnecessary collection and planning for faster or larger storage could still matter with another backend. Test the workload before committing to a migration.

Reply to this answer

Add your answer

Answers are reviewed before publication.

Related Discussions