Monitoring

apiVersion: soultec.ch/v1kind: Servicemetadata: name: monitoring locale: en labels: group: support capability/monitoring: 2.71 capability/managed-services: 3.23 annotations: source: src/content/services/en/monitoring.md route: /en/services/monitoring/ schema: /nerd/schema/services.json markdown: /en/services/monitoring.mdspec: title: Monitoring group: support order: 3 tags: [monitoring, managed-services] summary: >- Every system can raise an alert. The skill is relating them to each other rather than receiving fifty messages for one outage. photo: monitoring-wall photoNeed: "A monitoring dashboard at 2am tone: dark room, one screen, one person" stub: false draft: false sections: - heading:

The actual problem

body: | 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. - heading:

What a monitoring estate has to do

body: | 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. - heading:

Two kinds, and both are needed

body: | **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. - heading:

What to watch

body: | 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.status: corpus: 267 solutions: - {ref: solutions/vmware/vmware-cloud-service-provider, score: 0.44} - {ref: solutions/vmware/vmware-cloud-foundation/addon/business-operations, score: 0.40} - {ref: solutions/vmware/vmware-cloud-foundation/addon/network-observability, score: 0.38} - {ref: solutions/hpe/hpe-greenlake, score: 0.37} alsoLike: - {ref: services/managed-service, score: 1.00} - {ref: services/service-desk, score: 0.54} - {ref: experts/valentina-cicmak, score: 0.51} experts: - {ref: experts/valentina-cicmak, score: 0.51} - {ref: experts/matthias-frech, score: 0.41} - {ref: experts/mike-schmid, score: 0.34}

{ "apiVersion": "soultec.ch/v1", "kind": "Service", "metadata": { "name": "monitoring", "locale": "en", "labels": { "group": "support", "capability/monitoring": "2.71", "capability/managed-services": "3.23" }, "annotations": { "source": "src/content/services/en/monitoring.md", "route": "/en/services/monitoring/", "schema": "/nerd/schema/services.json", "markdown": "/en/services/monitoring.md" } }, "spec": { "title": "Monitoring", "group": "support", "order": 3, "tags": [ "monitoring", "managed-services" ], "summary": "Every system can raise an alert. The skill is relating them to each other rather than receiving fifty messages for one outage.", "photo": "monitoring-wall", "photoNeed": "A monitoring dashboard at 2am tone: dark room, one screen, one person", "stub": false, "draft": false }, "sections": [ { "heading": "

The actual problem

", "body": "Every product, hardware and software alike, can send alerts. That is precisely the\ndifficulty: in a single outage the host, the storage, the database and the application all\nspeak up at once, and in that volume the one message naming the cause gets lost." }, { "heading": "

What a monitoring estate has to do

", "body": "It is made of senders and receivers, and its job is correlation: relating messages to each\nother so that fifty events become one incident. Only then is analysis possible at all." }, { "heading": "

Two kinds, and both are needed

", "body": "**Availability monitoring** answers whether something is running. It reports the outage.\n\n**Performance monitoring** answers how well it is running. It reports the trend leading to\nthe outage, and is therefore the half that prevents one.\n\nRun only the first and you reliably learn that something is broken. Run both and you learn\nit beforehand." }, { "heading": "

What to watch

", "body": "An alert nobody acts on is worse than no alert: it trains the team to ignore messages.\nBefore rollout, settle which message reaches whom and what happens next." } ], "status": { "corpus": 267, "solutions": [ { "ref": "solutions/vmware/vmware-cloud-service-provider", "score": "0.44" }, { "ref": "solutions/vmware/vmware-cloud-foundation/addon/business-operations", "score": "0.40" }, { "ref": "solutions/vmware/vmware-cloud-foundation/addon/network-observability", "score": "0.38" }, { "ref": "solutions/hpe/hpe-greenlake", "score": "0.37" } ], "alsoLike": [ { "ref": "services/managed-service", "score": "1.00" }, { "ref": "services/service-desk", "score": "0.54" }, { "ref": "experts/valentina-cicmak", "score": "0.51" } ], "experts": [ { "ref": "experts/valentina-cicmak", "score": "0.51" }, { "ref": "experts/matthias-frech", "score": "0.41" }, { "ref": "experts/mike-schmid", "score": "0.34" } ] }}

apiVersion = "soultec.ch/v1"kind = "Service"[metadata]name = "monitoring"locale = "en"[metadata.labels]group = "support""capability/monitoring" = "2.71""capability/managed-services" = "3.23"[metadata.annotations]source = "src/content/services/en/monitoring.md"route = "/en/services/monitoring/"schema = "/nerd/schema/services.json"markdown = "/en/services/monitoring.md"[spec]title = "Monitoring"group = "support"order = 3tags = ["monitoring", "managed-services"]summary = "Every system can raise an alert. The skill is relating them to each other rather than receiving fifty messages for one outage."photo = "monitoring-wall"photoNeed = "A monitoring dashboard at 2am tone: dark room, one screen, one person"stub = falsedraft = false[[sections]]heading = "

The actual problem

"body = '''Every product, hardware and software alike, can send alerts. That is precisely thedifficulty: in a single outage the host, the storage, the database and the application allspeak up at once, and in that volume the one message naming the cause gets lost.'''[[sections]]heading = "

What a monitoring estate has to do

"body = '''It is made of senders and receivers, and its job is correlation: relating messages to eachother so that fifty events become one incident. Only then is analysis possible at all.'''[[sections]]heading = "

Two kinds, and both are needed

"body = '''**Availability monitoring** answers whether something is running. It reports the outage.**Performance monitoring** answers how well it is running. It reports the trend leading tothe 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 learnit beforehand.'''[[sections]]heading = "

What to watch

"body = '''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.'''[status]corpus = 267[[status.solutions]]ref = "solutions/vmware/vmware-cloud-service-provider"score = "0.44"[[status.solutions]]ref = "solutions/vmware/vmware-cloud-foundation/addon/business-operations"score = "0.40"[[status.solutions]]ref = "solutions/vmware/vmware-cloud-foundation/addon/network-observability"score = "0.38"[[status.solutions]]ref = "solutions/hpe/hpe-greenlake"score = "0.37"[[status.alsoLike]]ref = "services/managed-service"score = "1.00"[[status.alsoLike]]ref = "services/service-desk"score = "0.54"[[status.alsoLike]]ref = "experts/valentina-cicmak"score = "0.51"[[status.experts]]ref = "experts/valentina-cicmak"score = "0.51"[[status.experts]]ref = "experts/matthias-frech"score = "0.41"[[status.experts]]ref = "experts/mike-schmid"score = "0.34"

<?xml version="1.0" encoding="UTF-8"?><manifest kind="Service"> <apiVersion>soultec.ch/v1</apiVersion> <metadata> <name>monitoring</name> <locale>en</locale> <labels> <group>support</group> <entry key="capability/monitoring">2.71</entry> <entry key="capability/managed-services">3.23</entry> </labels> <annotations> <source>src/content/services/en/monitoring.md</source> <route>/en/services/monitoring/</route> <schema>/nerd/schema/services.json</schema> <markdown>/en/services/monitoring.md</markdown> </annotations> </metadata> <spec> <title>Monitoring</title> <group>support</group> <order>3</order> <tags> <item>monitoring</item> <item>managed-services</item> </tags> <summary>Every system can raise an alert. The skill is relating them to each other rather than receiving fifty messages for one outage.</summary> <photo>monitoring-wall</photo> <photoNeed>A monitoring dashboard at 2am tone: dark room, one screen, one person</photoNeed> <stub>false</stub> <draft>false</draft> </spec> <sections> <section> <heading>

The actual problem

</heading> <body>Every product, hardware and software alike, can send alerts. That is precisely thedifficulty: in a single outage the host, the storage, the database and the application allspeak up at once, and in that volume the one message naming the cause gets lost. </body> </section> <section> <heading>

What a monitoring estate has to do

</heading> <body>It is made of senders and receivers, and its job is correlation: relating messages to eachother so that fifty events become one incident. Only then is analysis possible at all. </body> </section> <section> <heading>

Two kinds, and both are needed

</heading> <body>**Availability monitoring** answers whether something is running. It reports the outage.**Performance monitoring** answers how well it is running. It reports the trend leading tothe 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 learnit beforehand. </body> </section> <section> <heading>

What to watch

</heading> <body>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. </body> </section> </sections> <status> <corpus>267</corpus> <solutions> <item> <ref>solutions/vmware/vmware-cloud-service-provider</ref> <score>0.44</score> </item> <item> <ref>solutions/vmware/vmware-cloud-foundation/addon/business-operations</ref> <score>0.40</score> </item> <item> <ref>solutions/vmware/vmware-cloud-foundation/addon/network-observability</ref> <score>0.38</score> </item> <item> <ref>solutions/hpe/hpe-greenlake</ref> <score>0.37</score> </item> </solutions> <alsoLike> <item> <ref>services/managed-service</ref> <score>1.00</score> </item> <item> <ref>services/service-desk</ref> <score>0.54</score> </item> <item> <ref>experts/valentina-cicmak</ref> <score>0.51</score> </item> </alsoLike> <experts> <item> <ref>experts/valentina-cicmak</ref> <score>0.51</score> </item> <item> <ref>experts/matthias-frech</ref> <score>0.41</score> </item> <item> <ref>experts/mike-schmid</ref> <score>0.34</score> </item> </experts> </status></manifest>

The actual problem

What a monitoring estate has to do

Two kinds, and both are needed

What to watch

The actual problem

What a monitoring estate has to do

Two kinds, and both are needed

What to watch

The actual problem

What a monitoring estate has to do

Two kinds, and both are needed

What to watch

The actual problem

What a monitoring estate has to do

Two kinds, and both are needed

What to watch

The actual problem

What a monitoring estate has to do

Two kinds, and both are needed

What to watch

Experts for this

Valentina Cicmak

Matthias Frech

Mike Schmid

You might also like

Managed Service

Service Desk

Valentina Cicmak