IT Infrastructure Monitoring: From Metrics to Business Services
Information technology — often simply called IT — exists to put technological capabilities to work for different purposes, for the benefit of people. For services to come into being, both off-the-shelf components and components built specifically for an organization or individual can be used. Of these components — application, platform, security, network, storage and infrastructure — the most diverse and the one made up of the most layers is infrastructure. Infrastructure is a word used for virtually everything that fits together, from physical connection points (ports) to processing capacity at every scale (CPU, memory, disk). When infrastructure becomes complex, it naturally becomes harder to address the problems that arise and to guarantee the service quality the end user experiences.
The management software used for this purpose is broadly known as infrastructure monitoring software. As in many other fields, there are open-source point solutions as well as more holistic solutions that can monitor many components end to end.
Looking more closely at infrastructure monitoring, we come across many terms: network, storage, hardware, operating system, database, URL, application server, ping, SNMP, agent-based, agentless, log file, process/service monitoring and more. Strip away the terminology, and the goal is clear: to check every potential risk factor at regular intervals, so that a likely problem is detected before it occurs — or the moment it does. By regular monitoring we mean observing at short intervals such as 1–5 minutes, collecting large volumes of metrics and informing operations teams through threshold checks. A metric-based approach also makes it possible to stay objective, to forecast capacity in an orderly way and to guide investment decisions. As an organization’s business volume and headcount grow, or when services are provided by external parties, supporting disciplines such as IT Service Management (ITSM) may also be needed. While infrastructure monitoring focuses on systems, ITSM focuses on people, and structures the activities that improve service levels by drawing on best practices.
To run infrastructure monitoring effectively with a small team, IT automation — runbook automation as well as server, database and middleware automation — is essential.
Monitoring Techniques
The SNMP protocol, long used in network infrastructures, makes configuration and change management of widely used devices easy, and helps us quickly deploy the monitoring system and deliver regular tracking and reporting. What really matters is keeping the system alive and sustaining it in a setup that remains manageable throughout its natural life cycle. SNMP-based infrastructures — through both generic tools and vendors’ own management systems — also cover hardware monitoring and problem detection. SNMP is also used for alarm management in the storage layer.
The operating systems that run physical and virtual servers (Linux, Windows, Unix, VMS, OS/400, OS/390 and others) can be monitored to a limited extent via SNMP, or with agent-based and agentless management tools. The main goal is to observe and record the state of standard and organization-specific components. By tracking the errors, configuration changes, availability, performance and security of the operating system and applications, a centralized console structure is supported.
To monitor databases (RDBMS – Relational Database Management Systems) and application servers, elements such as logs, processes, services, JMX, SQL queries and performance metrics are tracked and analyzed — both through Application Performance Management (APM) and through the operating system, monitored with or without agents.
URL and port monitoring methods, in turn, help us understand the impact of different layers on the system and raise alerts when needed.
The spread of cloud computing has made it necessary for traditional monitoring to cover cloud resources as well. The hybrid cloud concept requires existing infrastructures to be blended with modern techniques. Cloud resources can be monitored independently by the respective providers (AWS, Microsoft Azure, Google Cloud, Oracle, Salesforce.com, SAP, Office 365 and others), or integrated monitoring systems can be designed alongside the existing metrics of the traditional environment.
New technologies such as Kubernetes, OpenShift and Docker require monitoring systems to use different techniques (API-based) to see how dynamically orchestrated components interact with existing ones. You can find more detail on combining these different perspectives under APM.
Business Services Management (BSM)
To give some meaning to popular buzzwords, I would like to take a closer look at the concept of service-based management. Although the dynamics of an organization’s industry may call for minor adjustments, our goal is to build a meaningful service tree. A service tree can be used for root-cause analysis when a problem occurs, or for impact analysis when planning a change.
Before designing our service tree, I would like to briefly touch on the Configuration Management Database (CMDB). As the components organizations use have become commodities, it has also become possible for organizations to learn from one another. Whether a Linux or Windows server is physical, or virtualized on OpenStack or VMware, does not change the problems that can occur in the network, storage, operating system, database or application layer. That is why discovering technical relationships and adding a few organization-specific logical definitions enables an approach that works for organization A as well as organization B.
Looking at the successful projects we have delivered across the industry, we see that financial institutions share similar concepts — core banking, physical branches, internet and mobile banking — just as retail shares similar approaches to ERP, supply chain, logistics and stores. For this reason, our service tree should follow a hierarchical model that is easy to define and understand: one that uses the business service–application relationship as a filter and essentially leads down to the end user (internal or external customer), platform and infrastructure components. The contribution this makes to analyzing technical problems — through relationship types that define each component’s color codes and propagation rules — is undeniable.
Another function of the service tree is to combine technical metrics with business metrics in the design of an overall business/IT dashboard (BVD – Business Value Dashboard), enabling IT and business performance to be monitored in real time. After an analysis that defines the metrics and the visual expectations, followed by a short development effort, a shared dashboard can be created for different levels of management to use together.