Overview

Role in the system

Operational visibility designed with the system, not after it: what is measured, how signals are collected and correlated, who is alerted, and what each audience needs to see.

Monitoring should provide visibility across:

  • Servers
  • Storage
  • Networks
  • Security systems
  • Cloud resources
  • Applications
  • Databases
  • Interfaces
  • Edge devices
  • Field equipment
From monitored source to closed alertTen kinds of source feed a pipeline: collect with synchronised time, normalise, store and search, correlate, alert, assign and escalate, and close with evidence. Dashboards are built separately for operations staff, infrastructure teams, application teams, security teams, management and service owners.SourcesServersStorageNetworksSecurityCloudApplicationsDatabasesInterfacesEdge devicesField equipmentCollecttime-syncedNormaliseone formatStoresearch, retainCorrelateacross sourcesAlertprioritisedAssignowner, escalateClosewith evidenceSignals become engineered alertsDashboards built for each audienceOperations staffInfrastructure teamsApplication teamsSecurity teamsManagementService ownersTest the monitoring itself before commissioningInduce a fault, then confirm detection, alert routing, ticket creation and escalation; confirm an alert is raised when a source stops reporting
From signal to closed alert. Signals from every layer are collected, correlated and turned into assigned, escalated alerts that close with evidence. Dashboards are built per audience.

What is monitored

Infrastructure monitoring

Condition and capacity are tracked over time, so that trends such as storage growth surface well before they become incidents.

Infrastructure monitoring may include:

  • Availability
  • Processor utilisation
  • Memory utilisation
  • Storage capacity
  • Disk performance
  • Network utilisation
  • Hardware alerts
  • Power
  • Temperature
  • Virtualisation status

Application monitoring

A server can be healthy while the application on it is not. Application signals show what users and dependent systems actually experience.

Application monitoring may include:

  • Service availability
  • Response time
  • Error rates
  • Transaction volume
  • Queue depth
  • Database performance
  • Interface health
  • User-session health
  • Background-job status

Logs, alerts and dashboards

Log management

Time synchronisation comes before correlation: events from different systems can only be ordered if their clocks agree.

Log management should include:

  • Collection
  • Time synchronisation
  • Normalisation
  • Storage
  • Search
  • Correlation
  • Retention
  • Access control
  • Alerting

Alert engineering

Alerts should be:

  • Relevant
  • Prioritised
  • Actionable
  • Assigned
  • Escalated
  • Closed with evidence

Poorly configured monitoring creates excessive alerts without improving operations.

Dashboards

Each audience gets the view that supports its decisions; one crowded screen for everyone serves none of them.

Dashboards should be designed for different users:

  • Operations staff
  • Infrastructure teams
  • Application teams
  • Security teams
  • Management
  • Service owners

Discuss an ICT Requirement

Describe the requirement, the locations involved and where the project stands. We will respond with the technical questions that need answering first.

Discuss an ICT Requirement