Open-source alternative to Splunk ITSI for teams that need service monitoring without the ITSI license
Zabbix, Prometheus and Grafana cover service monitoring and dashboards, but ITSI's event analytics and KPI-based service model have no direct one-to-one equivalent. If your ITSI renewal is coming up, or your service model has outgrown its tooling, plan on rebuilding the service layer rather than exporting it. Splunk lists IT Service Intelligence on its platform pricing page as a separate offering for AI-driven incident prediction, detection and resolution that reduces alert noise, so confirm with Splunk exactly which ITSI capabilities your current contract includes before you decide what must be replaced. DeployOpen does not publish prices, and a quote follows from a written scope.
The open-source stack maps well to host and infrastructure health. Zabbix handles discovery, triggers, templates and host-level problems, and its proxy groups and native server high availability cover the availability of the monitoring itself. Prometheus collects metrics by pull and evaluates PromQL rules, and Alertmanager groups, inhibits and silences alerts. Grafana builds service dashboards on top of these sources. What you must design yourself is the service model: which hosts, databases and endpoints make up each business service, how their KPIs roll up into a health score, and which dependency failures should suppress downstream alerts. Document these mappings as code, for example Zabbix templates and Prometheus recording rules, so they survive upgrades.
The main gap is ITSI's event analytics: its correlation of notable events, adaptive thresholds and ML-driven noise reduction have no packaged open-source counterpart. Expect to replace them with explicit grouping rules, inhibition and tuned thresholds, and to accept more manual tuning. Also plan for Prometheus's local storage, which is not clustered or replicated and keeps 15 days of data by default, so long-term retention needs a remote write target. Ask any implementation partner to show how the service model, alert grouping and retention will be tested against your historical incidents before ITSI is switched off, and confirm the support tier you need, since Zabbix support subscriptions are optional.
Which ITSI capabilities map to Zabbix, Prometheus, Grafana and Alertmanager
This table maps each major ITSI capability to the open-source component that covers it, with notes on depth of coverage. Read the rows marked as having no direct equivalent as the work your team must design, build or buy before cutover. The main takeaway is that the open-source stack covers metrics, dashboards and alert routing well, while service-level event analytics must be assembled from several parts.
| ITSI capability | Open-source option | Coverage notes |
|---|---|---|
| Service modeling and dependencies | Zabbix host groups, templates and triggers; Grafana dashboards grouped by service | Zabbix models hosts and their triggers, not business services with weighted dependencies. Build the service tree as code or in a CMDB and confirm how far your team needs it to roll up. |
| KPIs and health scores | Prometheus recording rules with PromQL; Zabbix calculated items and dependent items | Both can compute ratios and weighted sums. ITSI's built-in health score and threshold tuning per KPI have no direct equivalent and must be designed and reviewed by your team. |
| Entity discovery | Zabbix low-level discovery; Prometheus service discovery | Strong for hosts, containers and endpoints. Discovery of business entities across non-monitored systems usually needs a CMDB or custom inventory feed. |
| Episode or alert grouping | Alertmanager grouping, inhibition and silences; Zabbix event correlation and problem suppression | Alertmanager groups alerts by label, which covers many cases. Cross-source episode creation similar to ITSI's correlation is not a native feature and must be built or bought. |
| Event analytics and anomaly detection | Grafana alerting, PromQL functions and Zabbix trigger expressions; third-party ML add-ons | Threshold and statistical rules are native. Machine-learning anomaly detection and predictive incident scoring, which Splunk positions as part of ITSI, have no direct open-source equivalent in this stack. |
| Service dashboards | Grafana dashboards, provisioned as code | Grafana covers service views well. Confirm that per-service access and drill-down match the views your operations teams use in ITSI. |
| Notifications and on-call routing | Alertmanager receivers and routes; Grafana contact points and notification policies | Routing by label and severity is native. Escalation schedules and on-call rotations usually come from an external tool such as an incident response platform, which you must select and run. |
| Multi-tenant access and SSO | Grafana LDAP, generic OAuth and Entra ID support; Zabbix user authentication options | Grafana SAML, team sync and SCIM require Grafana Enterprise. Confirm which identity features your SSO design needs before choosing the edition. |
Choosing Zabbix, Prometheus or both for service health
Zabbix, Prometheus and Grafana cover different parts of what ITSI does, and most teams end up combining them. The cards below describe what each tool is good at, where it needs extra components, and what to check before you commit to a layout for service health.
Zabbix for host and service checks
Zabbix fits teams that want one server to watch hosts, network devices, services and their triggers, with a built-in web interface and alerting. Since Zabbix 7.0 it is released under AGPLv3, so check that AGPLv3 works for your internal use and any modifications you distribute. Confirm your HA design: the native server cluster uses one shared database, and failover happens after a configurable delay between 10 seconds and 15 minutes.
Zabbix proxies for distributed sites
Proxy groups in Zabbix 7.0 and later redistribute monitored hosts between proxies when one goes offline, which helps when services span branches, data centers or cloud accounts. The trade-off is that proxy design becomes part of your service model, so document which proxy owns which dependency chain. Ask your team to test a proxy outage before go-live rather than assuming redistribution covers every check type.
Prometheus for metrics and alerting
Prometheus pulls metrics over HTTP from targets found by service discovery or static configuration, and is queried with PromQL. It is Apache-2.0 licensed with no paid edition of the project, so the costs sit in infrastructure, storage and the people who run it. Its docs say it values reliability over precision, so it suits service health signals, not per-request billing or other workloads that need exact counts.
Local storage limits in Prometheus
Prometheus local storage is not clustered or replicated and is managed like a single-node database. Its default retention is 15 days, so decide early whether longer history must go to remote write storage. Plan backups, disk sizing and a second Prometheus instance for availability, and confirm how your long-term store will serve queries during an outage.
Alertmanager for alert grouping
Alertmanager groups, inhibits and silences alerts from Prometheus, which is the closest open-source counterpart to ITSI's alert noise reduction, though it works on rules you write yourself. It can run as a cluster for high availability, and Prometheus should be pointed at every Alertmanager instance rather than a load balancer. Confirm your grouping and inhibition rules with the on-call team before relying on them for paging.
Grafana as the shared dashboard layer
Grafana can read from both Zabbix and Prometheus, so service health views can sit in one place. Its core is AGPLv3, and high availability needs two or more active-active servers sharing MySQL or PostgreSQL, because SQLite does not scale for production. Confirm that alerting is configured to avoid duplicate notifications, and that SAML and SCIM are available only in Grafana Enterprise.
How service models and health scores are rebuilt without ITSI
ITSI organizes KPIs under services, links those services in dependency trees and computes a health score that rolls child results up to the parent. Without ITSI, the same model is rebuilt from parts you already own. In Zabbix, the service unit is usually a host group or a set of host groups that represents one business function, with hosts and items inside it. Dependencies are expressed through trigger design: a trigger on a database host can be made to suppress or downgrade triggers on the application servers that depend on it, using trigger dependencies in the Zabbix frontend. In Prometheus, the equivalent is a set of recording rules that aggregate per-instance series into one series per service, written in PromQL, and then alert rules built on those series. In Grafana, a dashboard panel per service, with a status stat or state timeline, gives the operator the view that an ITSI service analyzer provides.
The health score is the part you must design yourself, and it must be reviewed before anyone relies on it. ITSI's scoring is configured through its own service and KPI settings, and open-source tools do not ship an equivalent weighted model. In Zabbix, the closest result is a calculated item or a trigger severity rollup that your team defines. In Prometheus, a score is a PromQL expression, for example a weighted average of normalized KPI values, so its thresholds and weights are code that goes through change control. Confirm with your service owners which KPIs are critical, what weight each carries and what a degraded state means for a customer. Test the score against past incidents that you can reconstruct from your own history before it drives paging.
Write the score logic as version-controlled configuration, not as a set of unreviewed dashboard edits. Store Zabbix templates and Prometheus rule files in Git, and provision Grafana dashboards from files so the model can be audited and rolled back, which Grafana's provisioning documentation supports. Record who approved each weight and threshold, and schedule a periodic review tied to changes in the services they describe. Expect this review work to recur after go-live, because service maps drift as applications change. A useful check before cutover is to run the old ITSI health view and the new score side by side for a fixed period and document every case where they disagree and why.
Running open-source service monitoring next to Splunk
This is the most common starting point. Splunk stays the system of record for logs, security events and SIEM content, while service health moves to Zabbix for host and service checks and to Grafana for dashboards that combine Zabbix and Prometheus data. Nothing in the security pipeline changes, so the review burden stays limited to the monitoring layer. Service models, dependency maps and health scores have to be rebuilt in Zabbix host groups, triggers and dashboards, because ITSI's service trees do not transfer.
- Source of truth: Decide per alert type whether Zabbix or Splunk owns it, and write that down before cutover.
- Service models: Rebuild service groups and dependencies in Zabbix or Grafana rather than expecting ITSI definitions to import.
- Log-derived signals: Keep log-based alerts in Splunk and forward only the resulting notification path where needed.
- Grafana reads: Grafana can query Zabbix as a data source, but Splunk search results are not a standard Grafana data source, so confirm the connector you plan to use.
Confirm with your Splunk administrator which saved searches feed service alerts today, since those are the ones that would otherwise stay silently in Splunk after cutover.
During a parallel run, ITSI and the open-source stack watch the same services and both produce notifications. The goal is to compare alert timing and service state for a agreed period before ITSI is switched off. The main operational risk is duplicate paging, so one path must be designated as the paging path for each service while the other records only. Route each source to a separate, clearly labeled channel during the run so responders can tell which system raised an alert.
- Single paging path: Let only one system page on-call for a given service, and send the other's notifications to a non-paging channel.
- Alertmanager grouping: Prometheus alerts sent to Alertmanager are grouped and can be inhibited, which reduces repeats within the open-source side.
- Zabbix notifications: Use Zabbix action conditions and escalation steps as the paging path once the run ends, and check the notification media and recipients during the run.
- Comparison log: Record each incident in both systems with timestamps so differences in detection can be reviewed.
Confirm how ITSI's notable events are delivered to your incident tool today, because duplicates often come from an integration that was never documented.
Retiring ITSI means that service health, health scores and event analytics are provided by the open-source stack alone. Zabbix, Prometheus with Alertmanager and Grafana take over monitoring and alert routing, and Splunk is used only for logs and SIEM. ITSI's AI-driven event analytics have no direct open-source equivalent, so teams usually replace them with explicit grouping rules, dependency-aware suppression and recorded runbooks. Plan the retirement only after the parallel run has shown the open-source alerts cover the services that mattered most.
- Grouping rules: Recreate noise reduction with Alertmanager grouping, inhibition and silences, and Zabbix problem suppression.
- Health scores: Derive simple health states from trigger severity and dependency status in Grafana, rather than expecting a score that matches ITSI.
- Historical ITSI data: Export the ITSI KPI and notable event history you need for review before the license ends, since ITSI data is not moved automatically.
- Grafana storage: Grafana needs MySQL or PostgreSQL for production and high availability, so set that up before retirement.
Confirm with Splunk which exports and retention you need for audits, and check your Zabbix support tier before depending on it for paging.
Teams often assume Grafana can simply dashboard Splunk. The practical options are narrower. Splunk search results can be exported in several formats through Splunk Web, the CLI, the REST API and SDKs, and the CLI is described by Splunk as the most stable retrieval method. Exported data can then be loaded into a store Grafana can query, which keeps Splunk as the source while Grafana provides the view. Live, high-volume reads from Splunk into Grafana need a connector and capacity planning that should be tested first.
- Exports: Use search results exported as CSV or JSON for periodic reports, and the CLI for scheduled pulls.
- Live reads: Confirm with your Splunk team which REST endpoints and rate limits apply before building panels on them.
- Metrics from Zabbix and Prometheus: These are native Grafana sources and need no Splunk exports.
- Retention: Splunk search export is not a backup, so keep archived copies according to your retention policy.
Confirm the Grafana plugin or pipeline you will use for Splunk data, and test it on a representative time range before committing.
Migrating ITSI services, KPIs and alerts step by step
This sequence moves service definitions, KPI logic and alert routing out of ITSI and into Zabbix, Prometheus and Grafana, with both paths running side by side until the new alerts match what your operators expect. The result is a documented cutover and a retired ITSI deployment.
Inventory services, KPIs and episode rules in ITSI
The Splunk platform administrator and the service owners list every business service in ITSI, its dependent services, its KPIs with their thresholds and search definitions, and the notable event and episode rules that group alerts. Export these definitions from ITSI's configuration through the REST API or the CLI so they can be reviewed as files. Done means every service, KPI and grouping rule has a row in a shared inventory with an owner and a named target in the new stack, and the exported definitions are stored in version control. Confirm the export format for your ITSI version with Splunk's documentation before relying on it.
Map services to host groups and triggers
The monitoring engineer translates each ITSI service into a Zabbix host group or tag set, and each KPI into one or more Zabbix items, triggers or Prometheus recording and alerting rules. Dependencies become host relationships in Zabbix or label-based grouping in Prometheus, and the team decides which dependency failures should suppress child alerts. Done means every KPI has a mapped metric source, a trigger or alert expression, and a documented reason for any KPI that does not map directly. Items that have no direct equivalent, such as ITSI's adaptive thresholds or service health scores, are flagged for a design decision rather than silently dropped.
Rebuild service dashboards in Grafana
The platform engineer recreates the ITSI service overviews as Grafana dashboards, using the Zabbix or Prometheus data sources and provisioning files so that dashboards are stored as code. Each dashboard is checked against the ITSI view it replaces, including the KPI panels, the service hierarchy and the drill-down paths operators use during an incident. Done means each in-scope service has a provisioned dashboard, a reviewer from the operations team has signed off on the panels, and the dashboard files live in the same repository as the rest of the configuration. Grafana's provisioning documentation describes the options for loading these files at startup.
Export historical data and set expectations for trends
The Splunk administrator exports any history that auditors or capacity planners will need from ITSI and the underlying indexes, using the CLI or REST API for larger result sets and saved searches for smaller ones. Zabbix and Prometheus start with fresh history, so the team records which trend and baseline questions will be answered from the archive instead of the new platform. Done means an archive location and retention owner are agreed, the export has been tested on a sample window, and the operations team knows that KPI baselines in Zabbix and Prometheus will rebuild over time. Confirm the retention rules that apply to your own compliance obligations before deciding what to archive.
Run both alerting paths in parallel
The operations lead keeps ITSI alerting active while Zabbix triggers, Prometheus rules and Alertmanager grouping send notifications to a test channel. The team compares the two paths over a period agreed in advance, logging every alert that fires in one path but not the other, and tunes grouping, inhibition and thresholds until the differences are explained. Done means every difference has a recorded cause and fix, and the on-call group has reviewed the test notifications. Alertmanager should be configured to receive from every instance it runs, as its documentation describes for high availability.
Cut over notifications to the new stack
The incident manager switches live notifications from ITSI to Alertmanager and Zabbix actions for each service, one service group at a time, starting with the lowest-impact services. Escalation paths, on-call schedules and acknowledgement steps are verified against the runbooks before each switch. Done means every in-scope service sends production notifications from the new stack, a rollback procedure has been tested, and the change record names who approved each switch. Ask your incident response provider or paging vendor to confirm that their integrations accept the new alert sources.
Retire ITSI and document the new service model
Once the parallel period has ended with no unexplained gaps, the Splunk administrator disables the ITSI services and KPIs, removes the ITSI app from the search heads only when no other app depends on it, and archives the final configuration export. The platform team writes the operating documentation covering service definitions, dashboard provisioning, alert rules and upgrade procedures for Zabbix, Grafana and Prometheus. Done means ITSI is disabled, its configuration export is stored with the migration record, and the new documentation has been reviewed by the people who run the service. Check your Splunk license terms with your account team before changing the deployment, as ITSI is listed as a separate offering on Splunk's platform pricing.
Questions buyers ask before replacing ITSI
What drives the cost of replacing Splunk ITSI with Zabbix, Prometheus and Grafana?
The software is free to use, so the cost sits in people, infrastructure, storage and optional support. Zabbix states that its open source software has no license fee, no device limits and no feature gates. Staff time is the largest recurring item: someone must model services and dependencies, tune thresholds and alert grouping, and maintain dashboards. Infrastructure and storage scale with the number of monitored hosts and the retention you choose. Paid Zabbix support comes in Silver, Gold, Platinum, Enterprise and Global tiers, with response times ranging from 1 day to 1 hour, so ask whether you need that coverage at all. Ask any consultant to split a fixed-scope quote into one-time build work and recurring operations, and to name the infrastructure they assume.
How long does an ITSI replacement take, and what makes it longer?
The duration depends mostly on how many services you need to model and how well documented your dependencies are. Work usually follows four stages: inventory of services and their hosts, building Zabbix and Prometheus data collection, building Grafana dashboards and health views, and running the old and new alerting in parallel until results agree. Teams with a clear service catalog move faster than teams that must discover dependencies first. Integrations with ticketing or on-call tools add time, and so do compliance evidence requirements. No duration is fixed here, so ask a provider to tie each stage to a written scope and to name the assumptions behind the estimate.
Can our own team replace ITSI without an outside partner?
Yes, if you have people who already run Zabbix or Prometheus and can own service models and alert rules after go-live. The tools are documented and widely used, and Grafana provisioning lets dashboards and data sources live as YAML or JSON files that you can version in Git. The risk is capacity: ITSI's health scores and event analytics take time to reproduce, and a small team may struggle to maintain both the build and daily operations. A common middle path is an outside team for design and hardening, then internal ownership. Be honest about your on-call load before deciding.
Which ITSI features have no direct open-source equivalent?
The main gap is ITSI's event analytics, which Splunk positions as AI-driven incident prediction, detection and resolution that reduces alert noise. Zabbix, Prometheus and Grafana cover metrics, thresholds, alert grouping and dashboards, but they do not provide an out-of-the-box machine learning engine that predicts incidents from correlated events. Prometheus Alertmanager handles grouping, inhibition and silences, which covers much of the noise reduction, yet adaptive episode scoring has no direct match. Confirm with each vendor which anomaly detection, correlation or service-level features you need, and plan a manual or rule-based replacement for each one.
How is high availability designed for Zabbix and Grafana?
Zabbix and Grafana use different HA models. Zabbix server has a native high availability cluster: several server nodes share one database, one node is active and the others stand by, and failover happens when the active node exceeds a configurable failover delay between 10 seconds and 15 minutes. Zabbix 7.0 and later also support proxy groups that redistribute hosts when a proxy goes offline. Grafana HA uses two or more active-active servers behind a load balancer sharing a MySQL or PostgreSQL database. Grafana's documentation notes that alerting needs extra configuration to avoid duplicate notifications, and Grafana Live has limitations in HA. Your database tier, backups and load balancer remain your responsibility, so confirm the design with the vendors and test failover before production.
What should we ask a consultant in a fixed-scope quote for this work?
Ask for a written scope that lists the services to model, the data sources to integrate, the dashboards and alert routes to build, and the acceptance tests that show the new stack matches ITSI's outputs. Request the deliverables for each stage, the assumptions about hosts, retention and infrastructure, and the list of systems the consultant will touch. Ask how they handle HA testing, documentation, handover and training, and what happens if the scope changes. DeployOpen plans and implements these engagements in your own infrastructure and provides a quote from a written scope, so ask for the same level of detail from any provider you compare.
Do Zabbix and Grafana releases force upgrades on a fixed schedule?
They follow published cycles, so plan upgrades as recurring work. Zabbix standard releases come out every 6 months and receive 12 months of support, while LTS releases come every 1.5 years with 3 years of full support and 2 years of limited support. Zabbix 7.0 LTS has full support until 30 June 2027. Grafana ships major releases once a year and minor releases every other month, with each minor release supported for 9 months. Prometheus minor releases start a new cycle every 6 weeks, so an LTS line is usually the safer choice for production. Budget staff time for these upgrades in your operations estimate, and confirm the current support dates on each vendor's life cycle page.
Where ITSI's event analytics have no direct equivalent
The main gap is event analytics. Splunk describes IT Service Intelligence on its platform pricing page as a separate offering for AI-driven incident prediction, detection and resolution that reduces alert noise. Zabbix, Prometheus and Grafana do not reproduce that out of the box. Prometheus Alertmanager does provide grouping, inhibition and silences, but those are rules you write, not learned correlation. Zabbix problem correlation and event tagging, and Grafana alert rules, likewise need explicit configuration. Your team must decide which events belong together, which symptoms should suppress downstream alerts, and how duplicates collapse into one incident.
Plan that work as a design task before cutover. Map the top alert sources for each service in your model, then write grouping labels, inhibition rules and Zabbix trigger dependencies for the patterns you see repeatedly. Expect the first rule set to be incomplete, and track which alerts still reach on-call unsorted. If you need statistical anomaly detection or ML-driven prediction, that is additional tooling, and it has its own data science, tuning and licensing questions. Confirm with the vendors which of these features exist, and in which editions, for the exact versions you plan to run, since the feature set changes between releases.
Before committing, run a two-week comparison in parallel with ITSI if you have it. Replay real incident histories through your rules and count how many pages each design would have produced, and which incidents the rules would have missed. Ask the vendors for written confirmation of any feature you assume is included, and record the gaps as accepted risks or as scope for a fixed-scope implementation plan. That record is also useful evidence for the operations owner who will maintain the rules after handover.
Operational risks to plan for after cutover
Once Zabbix, Prometheus and Grafana replace ITSI service monitoring, the risks move from licensing to operations. The cards below cover storage, database, alerting and release decisions that determine whether the new stack stays reliable after the migration team leaves.
Prometheus storage is single-node
Prometheus keeps its local time series database on one node, and that storage is not clustered or replicated. Losing the host means losing the local history that service health trends depend on. Plan for backups of the data directory, decide the retention window (the default is 15 days), and set up remote write to long-term storage if health scores need longer history. Confirm the recovery procedure with your own platform team before cutover.
Grafana needs a production database
Grafana stores its configuration in SQLite by default, and the installation docs state that SQLite does not scale for production. Dashboards, data sources and alerting rules that your service views depend on should live in MySQL or PostgreSQL from the first day. Choosing SQLite for a pilot and migrating later is extra work, so make the database choice part of the build, not a later decision.
Alertmanager must see every instance
Alertmanager handles grouping, inhibition and silences for Prometheus alerts. For high availability, Prometheus should point at every Alertmanager instance rather than at a load balancer in front of them. Test this path explicitly: a silenced or grouped service alert that appears on one node but not another would undermine the alert grouping you adopted from ITSI. Document the cluster flags and verify failover during the parallel run.
Zabbix failover timing
Zabbix server high availability uses one active node and standby nodes that share a database. Failover happens when the active node exceeds a configurable failover delay, which can be set from 10 seconds to 15 minutes. A short delay speeds recovery but can trigger switchovers on brief network hiccups, while a long delay leaves services unmonitored. Choose the value with your network team and test it with a simulated outage.
Grafana HA can duplicate alerts
Grafana high availability runs two or more active-active servers behind a load balancer, sharing a MySQL or PostgreSQL database. The documentation notes that alerting needs additional configuration to avoid duplicate notifications, and that Grafana Live has limitations in HA. Confirm the alerting settings on your version before relying on paging from Grafana, and keep Alertmanager as the single notification path for service alerts where possible.
Track release and support windows
Zabbix standard releases are supported for 12 months, while LTS releases get five years, three of full support and two of limited support. Prometheus minor releases stop receiving bug fixes after about six weeks, and its LTS line receives fixes for one year. Put these dates in your upgrade calendar, pin the version you run, and schedule upgrades before a line leaves support rather than after.
What a fixed-scope ITSI replacement covers
A fixed-scope engagement to replace Splunk IT Service Intelligence starts with the service model inventory, not with software installs. DeployOpen works with your team to list the business services in scope, the hosts, containers, cloud resources and network devices behind each one, and the dependencies between them, such as a payment API that relies on a database cluster and a load balancer. That inventory becomes the basis for the written scope, deliverables and timeline, and it determines how much of the ITSI work maps to Zabbix host groups and triggers, to Prometheus targets and recording rules, and to Grafana dashboards. Ask for the inventory to be reviewed and signed off before any build starts, because the most expensive rework in these projects comes from services that were modeled incorrectly.
Inside your own cloud accounts, data centers or air-gapped network, DeployOpen implements the stack: Zabbix server in a high availability configuration with a shared database, Zabbix proxies or proxy groups where sites need them, Prometheus with its storage and retention sized to your metric volume, Alertmanager clustered so that every Prometheus instance points at each Alertmanager node, and Grafana backed by MySQL or PostgreSQL rather than SQLite. Hardening follows the Grafana security hardening guidance, Zabbix authentication settings and your own access model, and the result is documented as runbooks, configuration records and a restore procedure that your staff can follow. DeployOpen prepares these systems and evidence for compliance assessments, but independent auditors and certification bodies issue any audit reports or certifications. After handover, ongoing support, upgrades and continuous testing are available as retainers, and the retainer scope should be agreed separately from the build quote.
How DeployOpen delivers ITSI replacement
DeployOpen plans, builds and hands over a self-hosted service monitoring stack inside your own infrastructure, using Zabbix, Prometheus and Grafana for service models, health views and alert grouping. Engagements start with a written, fixed scope so you know what is modeled, built and documented before work begins.
How we scope
- Inventory the services, owners and dependencies that ITSI service trees would currently model
- Agree in writing which health indicators, thresholds and alert groups are in and out of scope
- Define the systems, data sources and environments the stack will run in before any build starts
- Confirm ongoing support or a retainer for upgrades and changes after handover is a separate written item
How we build
- Configure Zabbix hosts, templates and proxies, with server high availability where your design needs it
- Build Grafana dashboards and provisioning files so data sources and dashboards are defined as code
- Set up Prometheus and Alertmanager routing, grouping and silences that match the agreed alert model
- Run security hardening and access configuration for each component, including identity provider integration
How we hand over
- Document the service model, dependency mapping, thresholds and alert routing as a maintained reference
- Walk your operations team through dashboards, alert triage, upgrades and backup procedures
- Deliver configuration in version control so changes can be reviewed and reproduced
- Record which ITSI event analytics functions are not replicated, so gaps are accepted in writing
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope build
- Plan component upgrades against the vendor release and support calendars you confirm with us
- Review alert noise and dependency changes with your team as services change
- Coordinate any paid Zabbix support tier you choose directly with Zabbix, separate from DeployOpen's work
