IoT implementation in telecom: how Target integrated MQTT and Zabbix into infrastructure monitoring

A power failure at a remote piece of equipment can look to operations like a communication outage. A discharging battery can keep a site running while its autonomy shrinks. In a shared infrastructure, identifying these signals also helps separate problems of the operator responsible for the infrastructure from those related to the equipment of the companies it serves.

This case study describes a project carried out for a nationwide telecommunications operator. To protect the client’s information, its identity will not be disclosed. Throughout the article, we will refer to the organization as the “operator.”

The operator needed greater visibility into the components that support its distributed infrastructure. TARGET took full responsibility for the project’s services: architecture definition, selection and configuration of technologies, development of integrations, deployment, team training, and platform operation. The work connected device telemetry to monitoring, diagnosis, and incident routing.

In the solution designed and implemented by Target, MQTT is the communication protocol, EMQX is the broker software, and Zabbix is the monitoring software. Target developed the layer that integrates these technologies and structured the history in PostgreSQL and TimescaleDB. The first integrated model brings together 39 monitoring items and 32 configured rules, and the platform has templates and mappings prepared for six device families. These numbers describe the technical scope delivered, not the number of devices deployed in the field.[1]

The project gives a practical perspective to the discussion presented in IoT in Brazil in 2026: what the data reveal about the market: the expansion of connected infrastructure must be accompanied by the ability to operate the equipment and use its data.

The challenge of monitoring a distributed infrastructure

The environment includes equipment installed at outdoor sites, dependent on electrical power, rectifiers, batteries, a direct-current bus, and communication. The failure of any one of these components can compromise the service and require action from teams with different responsibilities.

Without a centralized view of the conditions at these sites, service can begin with an unavailability complaint and little evidence about its origin. The team must investigate whether there was a loss of power, battery degradation, a communication problem, or a failure in another component before deciding on the appropriate routing.

The client’s goal was to gather measurements, events, and history on a platform that would allow assets to be tracked and that investigation to be qualified. The deployment also had to meet corporate access requirements and accommodate equipment from different manufacturers, without requiring an independent monitoring platform for each model.

For Target, this meant connecting three dimensions of the project: the telemetry produced by the equipment, the technical interpretation of the messages, and the context needed for service.

How the IoT architecture was defined and implemented

TARGET organized the platform in layers, with distinct responsibilities for communication, integration, and monitoring. This separation makes it possible to adapt the handling of a new device model without concentrating all of the manufacturer’s particularities in the operational rules.

The equipment publishes measurements and events over MQTT, using communication protected by TLS. The protocol works with message publishing and subscription, mediated by a broker. The MQTT specification treats the content of these messages as application data; therefore, using the same protocol does not guarantee that different devices adopt the same fields, units, or codes.[2]

To connect messaging to monitoring, Target developed the Target Plugin in Go. This in-house layer interprets the topics and the data received, identifies the equipment, and forwards the values to the corresponding items in Zabbix.[1]

The team also deployed PostgreSQL with TimescaleDB to store history and events, making it possible to query how the monitored conditions evolve. The data flow was structured by Target to turn the received message into information associated with the asset and available to operations.

This choice takes advantage of Zabbix as a monitoring platform and adds an integration specific to the project’s needs. The product offers mechanisms for receiving external data and host management APIs; the translation and registration logic used in this case was developed by Target.[4]

This combination of field telemetry and central infrastructure deepens the topic of the article IoT monitoring and IT monitoring: what changes in practice?. In this case, Target applied that vision by integrating device messages, monitoring rules, and history into a common architecture.

EMQX as the communication layer for IoT devices

EMQX is an MQTT messaging platform that mediates communication between the clients that publish data and the consumers interested in those messages. Its role in the architecture is to receive connections and distribute publications according to topics and subscriptions, separating device communication from the processing performed by applications.[3]

In the operator’s project, Target deployed and configured EMQX to receive measurements, events, and status from the devices and make them available to the integration developed by the team. The configuration includes connection authentication, protected communication, and tracking of connected clients. These capabilities give operations evidence to investigate communication, while the Target Plugin handles the interpretation of messages and their association with the monitored assets.[1][3]

This separation organizes responsibilities: messaging receives and forwards publications; Target’s own integration turns the content into data usable by monitoring. The architecture, configuration, and integration work for these layers was carried out entirely by Target.

Zabbix as the monitoring platform and operations support

Zabbix is the software used to gather monitored data, evaluate conditions, and make information available to the operations team. Its templates make it possible to organize reusable monitoring configurations and associate them with assets, establishing a common monitoring baseline for equipment with similar characteristics.[4]

In this case, Target developed and configured the device family templates, collection items, rules, severity classification, dashboards, and notifications. The in-house integration delivers to Zabbix the values interpreted from the MQTT messages, and the team queries measurements and events in a centralized environment.[1]

Using Zabbix’s APIs and data-receiving mechanisms allowed Target to automate technical registration and bring telemetry into the monitoring flow. The delivery results from Target’s work of adapting, integrating, and configuring these capabilities for the operator’s requirements, as well as preparing the team to use them.[1][4]

Integration across manufacturers and automatic registration

One of the requirements was to allow the incorporation of equipment with different message formats. Target implemented mappings per device family, relating the topic pattern, the asset identification, and the items of the monitoring model.

With this organization, adding a compatible family involves preparing its mapping and its template, in addition to validating the equipment’s behavior. The core of the platform remains shared. The approach reduces coupling to a single manufacturer’s formats while preserving the differences needed to interpret each model.

Technical registration was also automated. Upon receiving the first message from a still-unknown device, the integration creates the host in Zabbix and associates the corresponding model. Operations then complete the identification and location information needed for service.[1]

The benefit delivered is removing manual host creation from this entry path. The automation also standardizes the initial association of monitoring rules. The operational context remains the team’s responsibility, which must keep the registry consistent as assets are installed or changed.

What the platform makes it possible to track

In the first integrated model, the 39 items comprise 12 measurements, 26 alarm indications sent by the device, and one connection status item. The template brings together 32 configured rules, combining conditions reported by the equipment and comparisons of measurements against thresholds.[1]

Coverage includes electrical power, bus voltage, battery conditions, rectifier, load, and environmental or physical security events. It also includes indications related to communication and the controller. The goal is to present the available signals in an organized way, respecting the telemetry offered by each device.

History adds an important dimension to diagnosis. In a power-outage scenario reproduced during training, the team was able to follow the loss of power, the start of battery discharge, and the later drop in bus voltage. The sequence helps in understanding how the problem evolves and in forming a hypothesis for the service call.[1]

This use combines reading events with human analysis. The presence of a connection item also does not remove the need to check data freshness: the age of the last measurement received is relevant evidence for investigating equipment that stops publishing.

It is an application of the problem discussed in IoT device monitoring: why is connecting not enough?: operations must assess whether information keeps arriving and whether it offers useful evidence for diagnosis, in addition to checking communication.

Cloud, security, and platform continuity

TARGET deployed the solution on Oracle Cloud Infrastructure, with components in containers orchestrated by Kubernetes. The architecture defined by the team includes recovery mechanisms specific to the services and to the database, according to the function of each component.[1]

The deployment incorporated infrastructure-as-code and GitOps practices, using Terraform, GitLab CI, Helm, and ArgoCD. Infrastructure, application packages, and per-environment configuration are versioned, making it possible to review changes and keep the platform’s desired state under control.

For access, the project separates device communication from the interfaces used by operations. Corporate authentication was integrated with Microsoft Entra ID. History, events, and configurations have backup routines, while the environment itself tracks the execution of those routines and the availability of the solution’s components.[1]

These decisions broaden the scope of the implementation: besides receiving field messages, the platform must be administered, updated, and supervised throughout operation.

Deliverables and benefits for operations

TARGET put into production a platform with telemetry ingestion, in-house Zabbix integration, automatic technical registration, centralized history, and notifications. It also delivered templates and mappings prepared for six device families, with sets of items and rules suited to the characteristics of each family.[1]

The technical benefits can be tied directly to these deliverables. Centralization brings together information that was previously scattered along the investigation path. Automatic registration reduces a manual asset-entry activity. The mappings and templates establish a common way to incorporate different equipment. History makes it possible to examine how a condition evolves, while notifications take the configured events to the responsible team.

Training was part of the delivery. Target used simulated devices to demonstrate incidents, follow their evolution, and exercise diagnostic procedures in the solution’s environment. As a result, the team had contact with the data and the situations it would need to interpret during operation.

The available indicators do not yet make it possible to quantify reductions in costs, field visits, or repair time. These gains are goals to track as the fleet advances in the field. Detection time, time to complete registration, and referrals made with a diagnosis are measures that can support this assessment.[1]

The implementation shows how to combine IoT messaging, integration development, monitoring, and cloud infrastructure around a concrete operational problem. Target’s experience lies in that articulation: defining how data arrives, how it is interpreted, and how it becomes useful to the people responsible for keeping the infrastructure running.

From implementation to operation with Target Solutions

IoT projects require choices about protocols, equipment, data models, monitoring tools, and integration with existing processes. TARGET works on defining the architecture, developing integrations, deploying, and training teams to operate this whole.

If your organization needs to implement IoT monitoring for distributed assets or integrate telemetry into the tools it already uses, talk to Target about the context and requirements of your operation.

About Target Solutions

Target Solutions has spent more than 15 years helping organizations evolve their infrastructure, monitoring, observability, automation, and operational intelligence operations. Across that journey, it has participated in projects in complex environments such as telecom, technology, government, energy, and large enterprises, helping increase operational efficiency and service reliability. That experience also includes Internet of Things (IoT) projects, where connectivity, technical integration, and operational follow-up matter to turn connected devices into useful solutions for organizations.

About the author

Paulo Florêncio de Menezes is a partner and cofounder of Target Solutions and has spent more than 15 years on projects involving infrastructure, monitoring, observability, automation, and IT and telecom operations.

He holds a degree in data processing from the Federal University of Amazonas (UFAM), an MBA in business management from Fundação Dom Cabral (FDC), and a professional master’s in economics from Fundação Getulio Vargas (FGV).

In his master’s research, he developed the IBEOP-IA (Brazilian Index of Occupational Exposure Potential to Artificial Intelligence), studying the potential exposure of Brazilian occupations to AI capabilities by combining occupational data, artificial intelligence patents, and natural language processing techniques.

References

[1] Technical documentation of the telecommunications IoT implementation project (anonymized client). Version of October 29, 2026. Reference material used in preparing this case study; it does not identify the client or expose internal files.

[2] OASIS. MQTT Version 5.0. OASIS Standard, March 7, 2019. Conceptual reference on publishing, subscription, and messages; it does not identify the version used in the project.

[3] EMQX. Official documentation of the messaging platform (overview) and of MQTT client authentication, consulted on October 29, 2026. General product reference; the documented options do not imply adoption of all mechanisms in the project.

[4] Zabbix. Official documentation consulted on October 29, 2026: Zabbix trapper, API, IoT monitoring overview, and templates/template groups (version 7.0).