Zabbix Upgrade & Consulting

Zabbix Upgrade and Consulting Services for Enterprises

Last reviewed by Tyler Eastridge

AceMQ gives monitoring teams Zabbix engineers for LTS upgrade planning, database and housekeeper performance reviews, proxy and high-availability design, and a written answer to whether to stay on Zabbix or move to Prometheus and Grafana. AceMQ engineers lead each engagement and partner Zabbix specialists do the Zabbix-specific work, under one AceMQ contract. It starts with a quote within 1 hour and a written plan before anything changes. AceMQ is independent of Zabbix and ships no Zabbix builds.

A senior engineer, not an SDR. No sales sequence attached.

Fastest response target, by plan
15 min
Support cover
24/7
AceMQ customers
160+
Years in business
10+

Without a rip-and-replace of the monitoring you already trustFor production incident cover, see AceMQ Zabbix 24/7 support.

Customers

  • Microsoft
  • Henry Schein
  • Enbridge
  • Gojek

Partners

  • Broadcom
  • Redis
  • VMware Tanzu
  • OSSeva

The Problem

Why teams call us about Zabbix

Eight Zabbix problems that teams bring to AceMQ, from a 6.0 LTS server running on critical fixes only to a proxy that loses its history at the first start after an upgrade. If one describes your week, that is where the review starts.

  1. 01

    Production runs Zabbix 6.0 LTS, which Zabbix moved to limited support (critical fixes only) in February 2025, and nobody has written down how to reach 7.0 or the next LTS

  2. 02

    The database upgrade has never been timed: Zabbix warns that it may take a long time depending on database size, and the maintenance window is a guess

  3. 03

    History and trends tables keep growing, the housekeeper runs every hour by default, and the database spends its day deleting rows the server also wants to write

  4. 04

    TimescaleDB is installed, but the hypertable script was not rerun after the last upgrade, or housekeeping was left on and partitions are not being dropped

  5. 05

    Proxies lag the server by a version or two, so the server runs them with limited functionality and configuration updates to them are off

  6. 06

    Poller or history syncer utilization sits above the 75 percent default alert line for hours, and the queue of delayed items only ever grows

  7. 07

    A proxy on SQLite loses its stored history at the first start after an upgrade, because Zabbix deletes the old database file

  8. 08

    The team is asking whether Prometheus and Grafana would be easier, and nobody has costed the answer

A good fit if you run Zabbix in production for hosts, network devices or services that page real people, and want senior engineers who know the database, the housekeeper and proxy behavior, whether you stay on Zabbix or plan a move.

Not a fit for small teams with non-critical workloads. AceMQ is not a budget consultancy: we work with enterprises running business-critical and compliance-heavy Zabbix.

Running Zabbix in production? Get a quote from a senior engineer, answered within one hour.

Contact Us

How it breaks, and the fix

What happens to Zabbix when the database cannot keep up with writes?

Every value Zabbix collects passes through the history cache and is written to the database by history syncers. When the database is slow, the cache fills, values arrive late, and triggers evaluate old data. The monitoring system itself becomes the thing that needs monitoring.

History cache filling, values arriving late

Three collection sources, one history cache, one database, and the triggers that read it

Illustrative

  1. Pollers and proxies deliver values, the history syncers write them as fast as they arrive and the history cache stays low. Triggers see current data.

  2. The history and trends tables have grown and the housekeeper's deletes compete with inserts. The history cache climbs towards its 75 percent alert line, values land late and triggers and dashboards show old data.

  3. Retention is set to what is actually read, housekeeping or partitioning keeps deletes cheap, and cache and syncer settings match the load. The cache drains and triggers see current data again.

A slow database is the most common reason a Zabbix server falls behind, and the fix is rarely one setting. AceMQ reads the server's internal metrics first: process utilization, history and value cache usage and the queue. Then it compares table growth with the retention that is really needed, checks whether the housekeeper keeps pace or whether TimescaleDB partitions are being dropped, and only then changes cache sizes or syncer counts. The same data decides how long a version upgrade will take, because the schema upgrade has to rewrite what those tables hold.

Our Services

Zabbix Consulting & Services

AceMQ runs five Zabbix service lines: upgrade and LTS planning, database and performance review, proxy and HA architecture, trigger and alert noise, and a stay-or-move assessment. Any of them can roll into 24/7 support with response targets from 15 minutes, by plan.

  • 01

    Zabbix Upgrade and LTS Planning

    A route from 6.0 or 7.0 to the LTS you should be on, with the database floor, the proxy order and the outage window written down and rehearsed on a copy.

    • Upgrade notes read against your estate, version by version, although Zabbix lists a direct upgrade to 7.4 from every release back to 2.0
    • Database engine and version floors, including the notes that dropped Oracle Database support and raised the minimum PHP version
    • Upgrading Zabbix server first and each Zabbix proxy after it: the order Zabbix recommends, with the proxy compatibility rule applied
    • HA cluster steps, including the standalone-node step for a major version
  • 02

    Database, Housekeeper and Performance Review

    A slow server traced to its cause: table growth, housekeeping, cache sizes or poller counts, using the server's own internal metrics instead of guesses.

    • History and trends sizing against retention, and the per-item overrides that bypass the global setting
    • Housekeeper behavior, including what changes when TimescaleDB partitions are used
    • Process utilization, history cache and value cache read against the Zabbix server health template
    • Queue analysis: which items are delayed, on which pollers and behind which devices
  • 03

    Proxy, HA and Architecture

    Proxy placement, server high availability and database layout designed for the number of items you actually collect, not the first proof of concept.

    • Proxy placement and sizing per site, and the SQLite versus database-backed proxy decision
    • Server HA with standby nodes: HANodeName, NodeAddress and failover delay
    • Database layout for growth: partitioning, TimescaleDB where it applies, replication health
    • Backup and restore tested against your recovery target
  • 04

    Templates, Triggers and Alert Noise

    Alerts that fire on every maintenance window or duplicate each other are fixed in the trigger and action design, not by muting channels.

    • Trigger dependencies so a failed switch does not page for every host behind it
    • Action conditions, escalations and media types reviewed against who is on call
    • Maintenance periods and tag-based routing
    • Template ownership and a cleanup of items nobody reads
  • 05

    Stay-or-Move Assessment

    A move to Prometheus and Grafana planned from an inventory of what your Zabbix estate does today, with a parallel run before cutover. We also say when the right answer is to stay.

    • Inventory of hosts, items, templates, SNMP devices, discovery rules and actions in use
    • Mapping of each to an exporter, a scrape job, a PromQL alert or an Alertmanager route, with the gaps listed
    • Zabbix as a Grafana data source during the transition
    • A stay-or-move recommendation with the effort of each path costed
  • Response targets from 15 minutes, by plan

    24/7 Zabbix Support

    Senior engineers briefed on your environment, response targets from 15 minutes, by plan, and no ticket routing.

    • Response targets from 15 minutes, by plan
    • Senior engineers, no first-line triage layer
    • Proactive CVE & health monitoring
    • Quarterly deployment reviews
    Compare the four Zabbix support tiers

Want AceMQ to take this off your team's plate? Tell us about your Zabbix estate.

Contact Us

24/7 Support

Zabbix Support When It Matters Most

AceMQ Zabbix support gives you an AceMQ engineer and response targets from 15 minutes, by plan, when the server is down or failing, 24/7. Lower severities get 1-hour, 4-hour and next-day responses. AceMQ is independent of Zabbix: fixes still come from Zabbix releases, and AceMQ ships no builds of its own.

  1. From 15 min (by plan)first responseEmergencyProduction down, messages not flowing, queue manager failure
  2. 1 hourfirst responseCriticalSevere degradation, high error rates, approaching capacity
  3. 4 hoursfirst responseHighPerformance issues, configuration problems, non-critical failures
  4. Next Dayfirst responseStandardQuestions, guidance, best practices, non-urgent improvements

Response targets by plan; your contract sets the tier.

P1 escalation path

A replay of one P1, from the first page to the written root-cause analysis

SLA 15:00
T+Elapsed15:00
Engineer on your bridge

Response targets from 15 minutes, by plan; 24/7.
A response time, not a resolution time.

  1. T+00:00

    P1 opened, on-call engineer paged

    Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.

    Paged
  2. T+15:00

    Senior engineer on your bridge

    A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.

    Live
  3. T+30:00

    Specialists across the stack join

    When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.

    If needed
  4. After

    Written root-cause analysis

    Root cause, the fix applied and the prevention steps, delivered after every P1.

    Every P1

How Our Support Actually Works

Beyond SLAs — the model behind senior-only, zero-cold-start expert access.

  • Engineers Who Know Your Environment

    Tickets go to senior engineers briefed on your environment, not an anonymous queue. The proposal states who does the work.

  • Live Escalation on Any Ticket

    Any ticket can be escalated to a live session with an engineer through calendar booking. No gatekeeping and no approval step.

  • Proactive Risk Mitigation

    Scheduled health checks on your deployment and alerts on risks in the versions you run, so problems surface before they reach production.

  • Critical Bug & CVE Intelligence

    Proactive alerts on critical bugs and CVEs affecting your exact version, with version compliance monitoring so you're never caught off guard.

Compare Zabbix support plans

How It Works

What actually happens next

A Zabbix engagement from AceMQ runs in four stages: a scoping call with a quote within 1 hour, a written assessment, a plan rehearsed on a copy of your database, then delivery with your engineers and a handover. Each stage ends in writing.

Quote within 1 hour

Scoping call and quote

A senior AceMQ engineer asks what you run: Zabbix server and proxy versions, database engine and size, TimescaleDB or partitioning, high-availability setup, item and host counts and who owns the templates. A quote request is answered within 1 hour.

Scoped per estate

Assessment

A written review of version position against the Zabbix life cycle, database growth and housekeeping settings, process utilization, cache usage, queue behavior, proxy versions and the alert and template estate. Findings are ranked by production risk before anything changes.

Scoped per estate

Plan and rehearsal

An upgrade path that names the database version floors, the proxy order and the outage window, rehearsed on a copy of your database so the schema upgrade is timed before it is run for real.

Scoped per estate

Delivery and handover

Server, proxies and database changed with your engineers in the documented order, with a rollback point at each step. You keep the runbooks, the test checklist and the written results.

  • Written findings before any change
  • Schema upgrade timed on a copy of your database
  • Your engineers in the room
  • You keep the runbooks
  • Ad hoc engagements or an annual partnership

A senior engineer, not an SDR. No sales sequence attached.

Typical engagements

How Zabbix engagements run

Typical Zabbix engagements from AceMQ: what the environment looks like, what AceMQ assesses or changes, and what the engagement delivers. Each card links to the full write-up.

All use cases

Solutions

Every way AceMQ works with Zabbix.

AceMQ covers Zabbix end to end. Projects: consulting and implementation, health checks and migrations. Ongoing cover in four tiers, from 24/7 support and incident management to proactive monitoring, managed Zabbix on your infrastructure and fully managed Zabbix on AceMQ infrastructure, plus end-of-life versions.

Projects

Build, fix or move Zabbix

Fixed-scope work led by a senior engineer: architecture and new builds, a health check of what you run today, or a migration with a reversible cutover.

Support and managed services

Keep Zabbix running

Four tiers of ongoing cover once you are live. Each tier hands more of the day-to-day work to AceMQ, from on-call cover with response targets from 15 minutes, by plan, to AceMQ hosting and running Zabbix for you.

Compare the four Zabbix support tiers

Side by side

Stay on Zabbix, add Grafana, or move to Prometheus and Grafana: what changes?

All three can monitor the same estate, but they collect, store and alert differently. Staying means an upgrade. Moving means rebuilding every template, discovery rule and action in another model. Each row below answers one question about the choice.

Staying on Zabbix, adding Grafana dashboards and moving to Prometheus and Grafana compared on trigger, collection, storage, alerting, team impact, when each is wrong and what AceMQ adds
QuestionStay on Zabbix and upgradeZabbix with Grafana dashboardsMove to Prometheus and Grafana
What usually triggers it?Zabbix 6.0 LTS is on critical fixes only until 28 February 2027, the server is slow, or a new LTS is due.The team likes Zabbix collection but wants dashboards shared with other tools. Grafana Labs lists a Zabbix plugin for Grafana that reads Zabbix data.The estate is mostly Kubernetes and application metrics, or the platform team already runs Prometheus.
How is data collected?Agents, SNMP, HTTP and other checks, with proxies per site, all configured through templates and discovery rules.The same. Grafana only reads what Zabbix has collected.Prometheus scrapes exporters and instrumented services. SNMP devices need an exporter between them and Prometheus.
Where is the data stored?In a PostgreSQL or MySQL database, in history and trends tables cleaned up by the housekeeper, or partitioned with TimescaleDB.The same database. Dashboard queries add read load to it.In Prometheus's local time-series database, with Thanos or Mimir when retention must reach months or years.
How are alerts defined?Triggers, actions and escalations in Zabbix, with dependencies and maintenance periods.Still Zabbix triggers. Grafana can alert on panels too, which creates a second place to look.PromQL alert rules and Alertmanager routing, grouping and inhibition.
What changes for the team?Little. The database version floor, the PHP minimum and the proxy order change with each upgrade.Dashboards are rebuilt in Grafana, and users work in two interfaces.Every template, discovery rule and action is rebuilt as exporters, scrape jobs and rules, with both systems running in parallel until parity is proven.
When is it the wrong choice?When nobody on the team wants to own a server and a database, or the estate is mostly short-lived containers.When the goal is to retire Zabbix. It adds a second system instead.When the only reason is that Zabbix is old. An upgrade is smaller than a re-platform, and SNMP-heavy network estates are where Zabbix is strongest.
What does AceMQ add?A written upgrade path rehearsed on a copy, then 24/7 cover with response targets from 15 minutes, by plan.A review of the extra database load, then support for both Zabbix and Grafana under one contract.An inventory, a gap list and a parallel-run plan, then support through the Prometheus and Grafana pages.

AceMQ is independent of Zabbix, Prometheus and Grafana, so the recommendation follows your estate and not a product. To see how the Prometheus route is supported, read the Prometheus support options guide.

Not sure which option fits? A senior Zabbix engineer will scope it with you.

Contact Us

One partner, not five

We Support Your Entire Tech Stack

Zabbix rarely fails in isolation. AceMQ covers the full surrounding infrastructure — so one team owns the whole path instead of pointing at each other.

Messaging & Streaming

Databases & Caching

Search & Analytics

Lakehouse & Compute

Observability & Monitoring

Data Integration

Cloud & Containers

API Management

VMware Tanzu

See all the technologies we supportShow fewer

Guides, articles and comparisons

Go deeper on Zabbix.

Guides from AceMQ engineers on how open-source monitoring is supported, plus the AceMQ services around it: Prometheus, Grafana, New Relic and the databases underneath.

Guides

1

Comparisons

9
Show 3 moreShow fewer

Related services

Ready to talk Zabbix? Get a quote or send us a message.

Contact Us

FAQs

Zabbix Questions Answered

Five answers on Zabbix from AceMQ: which versions are supported, how to upgrade, why a server is slow, whether to stay or move, and what an independent provider is.

Still have questions about Zabbix? Email an Expert

Which Zabbix versions are supported, and is 6.0 end of life?

Not yet. Zabbix's life cycle page (read 4 November 2026) shows 6.0 LTS full support ended on 28 February 2025 and limited support, critical fixes only, runs to 28 February 2027. Zabbix 7.0 LTS has full support to 30 June 2027 and limited support to 30 June 2029. Zabbix 8.0 LTS is planned for Q4 2026 and is not released. AceMQ supports Zabbix 6.0, 7.0 and 7.4 and plans the move.

How do we upgrade Zabbix without losing monitoring data?

Back up the database, rehearse the schema upgrade on a copy to time it, then stop, upgrade and start the server and upgrade the proxies one after another. Running proxies keep collecting while the server is down. The exception is a SQLite proxy, whose database file Zabbix deletes if it is older than the new version requires. AceMQ writes this path down and rehearses it first.

Why is our Zabbix server slow?

Usually one of four things: history and trends tables too large for the retention set, a housekeeper that cannot keep up, caches sized for an older item count, or pollers held busy by slow devices. Zabbix's own server health template alerts at 75 percent process utilization and 95 percent value cache use. AceMQ reads those internal metrics first and changes settings after.

Should we stay on Zabbix or move to Prometheus and Grafana?

Stay when your estate is SNMP devices, hosts and agents with templates that work, and the problem is an old version or a slow database. Consider a move when the estate is mostly Kubernetes and application metrics. AceMQ inventories what you use, costs both paths and puts the recommendation in writing. Grafana can also read Zabbix data, so the two can run side by side.

Does AceMQ sell Zabbix support or patched builds?

AceMQ is an independent provider and not a Zabbix partner. Zabbix sells its own support tiers; AceMQ's engineers complement or replace them for the operational work but have no access to Zabbix development. AceMQ ships no patched Zabbix builds: fixes come from Zabbix releases.

Can we work with AceMQ on Zabbix without a long contract?

Yes. AceMQ works on Zabbix in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual contract that covers 24/7 support and proactive reviews. Many teams start ad hoc and move to an annual contract once the first engagement is done.

How much does AceMQ Zabbix support or consulting cost?

Every AceMQ proposal is tailored to your requirements: your Zabbix environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how Zabbix is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.

Let's talk

Tell Us What You Run. We Quote Within 1 Hour.

A senior AceMQ engineer reviews your Zabbix estate, tells you whether to upgrade, tune or move, and quotes it. Quote requests are answered within 1 hour.

A senior AceMQ engineer, not a sales queueAbout your Zabbix estate, not a pitch deckQuote requests answered within 1 hour

Production incident right now?Email a Zabbix Architect

Get in Touch

Talk to a Zabbix Expert

Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.

305-204-2607
info@acemq.com
66 W. Flagler St. 9th Floor
Miami, FL 33130

Prefer to talk now? Call us directly or use the consultation tab to find a time that works.

We respond within 1 hour.

Pick a time that works — no pressure, no pitch. Just 30 minutes with an expert.

We respond within 1 hour.