Third-Party & Custom Integrations
Monitoring is only as good as its blind spots are small. Integration work is what removes them.
Most estates are monitored unevenly. The network is well covered because network gear speaks SNMP; the applications the business actually depends on are not covered at all, because nobody wrote the integration. The result is a monitoring platform that is confident about switches and silent about the order-entry system.
GİTA Teknoloji builds the integrations that close that gap. For common platforms we use established collectors and templates. For everything else — the in-house application, the legacy system with no API, the vendor appliance with an undocumented interface — we write a purpose-built exporter or agent in Python or Go, and it becomes part of the same alarm model as everything else.
Integration work is quoted per system, so it can be added incrementally rather than as one large project. Source code for anything written specifically for a customer belongs to that customer.
Platforms we integrate as standard
These are established integrations, not bespoke work.
VMware vCenter
Cluster and host health, resource pressure, datastore capacity, guest state, HA and DRS events.
Proxmox VE and XenServer
Node and guest metrics, storage state, cluster quorum and replication status.
FortiGate and network security
VPN tunnel state, session counts, throughput, HA failover, certificate expiry and hardware alarms.
Network hardware
Cisco, Juniper, HPE, Dell and others over SNMP — interfaces, errors, capacity, optics and environmental sensors.
Backup platforms
Veeam and Acronis job outcomes, so a failed backup is an alarm rather than something discovered during a restore.
Microsoft and cloud services
Microsoft 365 and Azure service health and tenant-level signals, plus Cloudflare zone and origin health.
How we reach a system
What a device exposes determines the approach. Establishing that is the first step of any integration.
SNMP
The richest option for network and hardware. Interface counters, environmental sensors, vendor-specific MIBs and traps.
ICMP and TCP probes
Availability and latency where nothing else is exposed. Sub-minute thresholds for WAN links that drop intermittently.
HTTP and API checks
REST and SOAP endpoints, response codes and payload assertions, transaction checks, TLS certificate expiry.
SSH and command output
For appliances that offer a CLI and nothing else — parsed into metrics rather than read by a human.
Syslog and log patterns
Event-driven alarms from devices that report state by log line rather than by counter.
IPMI, Redfish and WMI
Out-of-band hardware health and Windows-side metrics, independent of the operating system being up.
When nothing standard exists
The systems most worth monitoring are often the ones with no off-the-shelf integration.
Custom exporters
Purpose-written collectors in Python or Go that expose an existing system’s state in a form the monitoring platform understands.
Agents for in-house applications
Lightweight agents that report application-level health — queue depth, job state, business-level counters — not just whether the process is running.
Database-derived metrics
Where an application records its own state in a database, that table becomes a metric source and, where it matters, an alarm.
Legacy and undocumented systems
Where there is no API, we work from what exists: a log file, a port, a file drop, a screen-scrapable interface.
Synthetic transactions
Scripted end-to-end checks that exercise the path a user takes, catching failures that component-level checks miss.
Source ownership
Integration code written for a customer is delivered to that customer, documented, and version-controlled — not locked to us.
Outbound integrations
An alarm that does not reach the right person on the right channel has not worked.
Telegram
Widely used by operations teams in Türkiye, and usually kept when we take over an environment that already uses it.
Email and reporting
Alarm delivery plus scheduled weekly and monthly reports, sent through a managed delivery service for reliability.
SMS for critical alarms
A separate path for the small set of alarms that must reach someone even when data connectivity is the thing that failed.
Slack and Microsoft Teams
Channel delivery with severity routing, for teams whose operational conversation already lives there.
Webhooks
Generic outbound webhooks into ticketing, on-call rotation or your own automation.
Ticket creation
Alarms that should become tracked work items can open tickets directly, rather than relying on someone to transcribe them.
Frequently asked questions
Can you monitor an application that has no API?
Usually yes. If it writes a log, listens on a port, records state in a database, or produces a file, that is enough to build a check against. The first step is a short investigation of what the system actually exposes.
How long does a custom integration take?
A straightforward exporter against a documented interface is a matter of days. An undocumented legacy system takes longer, and most of that time is investigation rather than coding. We scope each integration separately so you can decide system by system.
Who owns the integration code?
You do. Anything written specifically for a customer is delivered with source and documentation. We do not build dependencies that make it expensive to change supplier.
Can integrations be added later?
Yes, and that is the normal pattern. Estates are brought into monitoring in stages, starting with the systems whose failure costs the most, with further integrations added under the ongoing service.
Do you support our ticketing system?
Where it accepts an inbound webhook or API call, yes. Where it does not, an email-based path is normally available and we build against that instead.
Related services
Which system is currently invisible?
Tell us what you cannot see today and we will tell you what it would take to see it.
Get in touch