Managed Monitoring & Observability
We build the monitoring platform, then run it for you — so the alarms that reach your team are the ones worth acting on.
GİTA Teknoloji designs, deploys and operates monitoring platforms for organisations in Türkiye. We work with Zabbix, Grafana and Prometheus, and we run the result as a managed service rather than handing over a dashboard and walking away.
A typical engagement covers multi-site WAN connectivity, virtualisation platforms, firewalls, Linux and Windows estates, storage, and the customer’s own applications reached through purpose-built integrations. Deployment is a one-off engagement; operation is a monthly managed service with a defined support window, ticket allowance and escalation path.
Most organisations that come to us already have a monitoring tool. What they do not have is a working alarm model. Reducing thousands of daily notifications to a handful of actionable alarms is the part of the work that changes how the operations team spends its day.
A nationwide branch-connectivity deployment
One engagement covers a nationwide retail-scale estate connected over MPLS VPN back to a central data centre. The previous platform generated so many notifications that operators had stopped reading them. We rebuilt the alarm model around what an operator can actually act on, added scheduled reporting, and took over day-to-day operation.
What the service includes
Every engagement covers the same core, scoped to the size of the estate.
Metric and event collection
Agent-based and agentless collection over SNMP, ICMP, TCP and HTTP probes, SSH, REST APIs, syslog, WMI and IPMI/Redfish, depending on what each device actually exposes.
Alarm design and noise reduction
Thresholds, dependencies, maintenance windows and flap suppression, so a single upstream failure produces one alarm instead of two hundred.
Dashboards
Grafana dashboards built for the people who use them — one view for the NOC, another for management, rather than one dashboard nobody opens.
Scheduled reporting
Weekly and monthly availability and incident reports delivered by email, so service quality is a number rather than an impression.
Notification and escalation
Email, SMS for critical alarms, Telegram, webhook and chat-platform delivery, with an escalation path agreed up front.
Ongoing operation
A defined support window with a ticket allowance, platform upgrades, and changes as the estate grows — the managed part of managed monitoring.
The stack we work with
We are not tied to one tool. We choose per estate, and often combine them.
Zabbix
Strong at agent-based collection, network discovery and templating across a large fleet of similar devices. Frequently kept as the collector even when the alerting and visualisation layer is replaced.
Grafana
Visualisation and, increasingly, the alerting engine. Grafana Alerting gives one alarm model across several data sources, which is what makes noise reduction tractable.
Prometheus
The right choice for dynamic targets — containers, microservices, cloud workloads — where service discovery matters more than a static host list.
Exporters and agents
Standard exporters where they exist, and purpose-written ones in Python or Go where they do not.
Time-series storage
Retention sized to the reporting you actually need, so history is available for capacity planning without unbounded storage growth.
Infrastructure as code
Configuration managed with Ansible, so the platform can be rebuilt and changes are reviewable rather than remembered.
What we monitor
WAN and branch connectivity
MPLS and internet links, ICMP keepalives with sub-minute thresholds, latency and packet loss, per-site availability reporting.
Network devices
Switches, routers, wireless controllers and load balancers over SNMP, including interface errors, capacity and hardware health.
Firewalls and security
FortiGate and similar platforms: session counts, VPN tunnel state, throughput, HA status and hardware alarms.
Virtualisation
VMware vCenter, Proxmox VE and XenServer — host and guest health, resource pressure, datastore capacity and cluster state.
Servers and operating systems
Linux and Windows: CPU, memory, disk, filesystem, service state, log patterns and hardware health via IPMI or Redfish.
Applications and APIs
HTTP and TCP probes, certificate expiry, transaction checks, and metrics from in-house applications through custom integrations.
How the engagement is structured
A one-off deployment, then a monthly service. Both are quoted before work starts.
Discovery
We inventory what exists, what is already monitored, what actually pages someone at night, and which of those alarms anyone acts on.
Deployment
A control node running Ansible plus the monitoring stack itself, sized to the estate and deployed either on your infrastructure or on infrastructure we operate.
Parallel run
The new platform runs alongside the existing one until the alarm model is proven, so nothing is lost at cutover.
Managed operation
A support window — business hours or extended — with an agreed annual ticket allowance and a named escalation path.
Reporting cadence
Weekly operational reports and a monthly service review covering availability, incidents and recurring causes.
Change and growth
New sites, new devices and new integrations are added under the same service rather than as separate projects.
Frequently asked questions
Do we have to replace our existing Zabbix?
No. In many engagements Zabbix stays in place as the collection layer and we rebuild the alerting and visualisation on top of it. Replacing the collector is a decision we make after discovery, not before.
Can you monitor an application we wrote ourselves?
Yes. Where an application exposes an API, a log, a database table or a port, we can build a check against it. Where it exposes nothing useful, we write an exporter or agent for it in Python or Go as a scoped piece of work.
Which notification channels do you support?
Email, SMS for critical alarms, Telegram, webhooks, and chat platforms such as Slack and Microsoft Teams. Teams already using Telegram for alarms usually keep it — there is no reason to retrain operators on a new channel during a migration.
Is the service 24/7?
We offer a business-hours support window as standard and extended coverage where the estate justifies it. Monitoring and alarm delivery run continuously regardless; the support window defines when our engineers respond.
Where does the monitoring platform run?
Usually on virtual machines inside your own environment, which keeps monitoring data on your infrastructure. We can also operate it on infrastructure we manage where you would rather not host it.
What happens to our historical data?
Existing history can be retained by keeping the current collector in place during and after migration. Where history must be carried across, we scope that as part of the deployment rather than assuming it.
Related services
Tell us what is paging your team at night
A short discovery conversation is usually enough to say whether the problem is the tool or the alarm model.
Get in touch