build 001f4800 | content blog-content@c8490fa · 338 posts | profiles 20 · corpus 232 | 0 skipped |
Service · support

Monitoring

Every system can raise an alert. The skill is relating them to each other rather than receiving fifty messages for one outage.

Topics capabilities · idf weight Monitoring monitoring 3.10 Managed Services managed-services 3.40
03Solutions
02Capabilities
232Corpus

The actual problem

Every product, hardware and software alike, can send alerts. That is precisely the difficulty: in a single outage the host, the storage, the database and the application all speak up at once, and in that volume the one message naming the cause gets lost.

What a monitoring estate has to do

It is made of senders and receivers, and its job is correlation: relating messages to each other so that fifty events become one incident. Only then is analysis possible at all.

Two kinds, and both are needed

Availability monitoring answers whether something is running. It reports the outage.

Performance monitoring answers how well it is running. It reports the trend leading to the outage, and is therefore the half that prevents one.

Run only the first and you reliably learn that something is broken. Run both and you learn it beforehand.

What to watch

An alert nobody acts on is worse than no alert: it trains the team to ignore messages. Before rollout, settle which message reaches whom and what happens next.

Experts for this

Focus areas are not yet confirmed, so nobody is suggested here automatically. · 0 experts in corpus (n=232)

You might also like

service 1.00

Managed Service

caps 1 (neither declares a vendor) = 1
service 0.52

Service Desk

caps 0.52 (neither declares a vendor) = 0.52
post 0.48

Infrastructure assessment with HPE CloudPhysics

0.7 × caps 0.48 + 0.3 × vendor 0.5 (unknown) = 0.48