https://boiteaoutilsinformatique.fr/en/it-supervisory-centre/
IT Toolbox
IT Toolbox

IT Monitoring Center

Monitoring & exploitation

IT Monitoring Center

Build a consistent monitoring plan for servers, network devices, backups, web services, cloud and telephony.

Add rapidement

Choisissez un modèle de supervision préconfiguré.

Éléments supervisés

Inventaire des actifs et services à surveiller.

TypeNameIP / URLCriticitéDisponibilité cibleResponsableNotes

Contrôles & seuils

Définissez ce qui doit déclencher une alerte.

Équipement / serviceMétriqueWarningCritiqueFréquenceFenêtreAction attendue

Alertes & escalade

Qui reçoit quoi, et dans quel délai.

LevelCanalDestinataireDélai d’escaladePlage horaireConsigne

Synthèse de couverture

Analyse simple des écarts dans le plan de supervision.

Couverture par type

Seuils recommandés

CPUWarning ≥ 80 % / Critique ≥ 95 %
RAMWarning ≥ 85 % / Critique ≥ 95 %
DisqueWarning ≤ 20 % libre / Critique ≤ 10 %
Latence WANWarning ≥ 100 ms / Critique ≥ 200 ms
Perte paquetsWarning ≥ 2 % / Critique ≥ 5 %
Certificat TLSWarning ≤ 30 j / Critique ≤ 7 j
BackupAlerte dès 1 job critique en erreur
DisponibilitéContrôle toutes les 1 à 5 min selon criticité

Exporter le plan de supervision

Pour documentation interne, audit, passation ou mise en production.

Plans locaux

Jusqu’à 10 plans enregistrés dans ce navigateur.

None plan enregistré.

Key point: les seuils proposés sont des valeurs de départ. Adaptez-les à la charge habituelle, à la criticité métier et au comportement normal de chaque équipement.
Field troubleshooting

Center mission

8 playbooks

Turn an alert into a decision: verify it is real, measure impact, correlate dependencies, avoid false positives and confirm recovery with evidence.

Quick triage

  • Verify from at least one second source before intrusive action.
  • Determine impacted business service and dependencies.
  • Compare current value, baseline and duration of threshold breach.
  • Correlate simultaneous alerts to find root cause.
  • Record acknowledgement, actions and recovery time.

Decision tree

Host down→

Test network, gateway, power/hypervisor then OS.

Service down but host up→

Check process, port and service dependency.

High resource threshold→

Validate duration/trend before changing threshold.

Many alerts at once→

Find common dependency before treating each alert separately.

Intervention playbooks

Start read-only, collect evidence, then change one variable at a time.

01Host reported downRead-only
Symptom

Monitoring loses ping/agent/SNMP on a server or device.

Checks

  • Test from another network point.
  • Check DNS, route and gateway availability.
  • Check hypervisor/power if server.

Commands / evidence

ping <host>tracert <host>Test-NetConnection <host> -Port <agent-port>

Expected result

Failure is localized between monitoring, network, host or agent.

Corrective actions

  • Fix failing layer then force a check only after recovery.
  • Avoid permanently acknowledging an unexplained alert.

Escalate when

Multiple hosts at same site are down or infrastructure management is lost.

02Application service downControlled change
Symptom

Host responds but monitored service, URL or port fails.

Checks

  • Test port and service locally then remotely.
  • Read logs and dependencies.
  • Check certificate/DNS/backend for web service.

Commands / evidence

Get-Service <service>Test-NetConnection <host> -Port <port>curl -I https://<host>/

Expected result

Process listens and functional test returns expected code.

Corrective actions

  • Fix dependency or service then retest from probe.
  • Do not auto-restart a looping service without cause.

Escalate when

Critical service, repeated restarts or shared backend affected.

03Recurring false positiveControlled change
Symptom

Alert regularly triggers without real impact.

Checks

  • Compare threshold, window and actual value.
  • Check probe jitter, timeout and dependencies.
  • Measure frequency and duration of occurrences.

Commands / evidence

ping -n 100 <host>Test-NetConnection <host> -Port <port>Get-Date

Expected result

False-positive condition is reproducible and quantified.

Corrective actions

  • Adjust duration/hysteresis/threshold based on measurements.
  • Preserve ability to detect real outage.

Escalate when

Tuning would hide real incidents or metric itself is unreliable.

04Disk space below thresholdControlled change
Symptom

Volume drops below capacity threshold or trend predicts saturation.

Checks

  • Measure free space and growth trend.
  • Identify main consumption source.
  • Check snapshots/logs/backups by role.

Commands / evidence

Get-Volume | Sort-Object SizeRemainingGet-ChildItem <path> -Directory | Sort-Object LastWriteTimevssadmin list shadowstorage

Expected result

A cause and time-to-full are estimated.

Corrective actions

  • Clean/reduce retention or extend according to cause.
  • Adjust threshold only if normal capacity justifies it.

Escalate when

Critical system volume or rapid abnormal growth.

05CPU / memory over thresholdRead-only
Symptom

High resource alert lasts several minutes.

Checks

  • Compare transient spike and sustained saturation.
  • Identify dominant process.
  • Correlate with batch, backup or user load.

Commands / evidence

Get-Process | Sort-Object CPU -Descending | Select -First 15Get-Counter \Processor(_Total)\% Processor Time,\Memory\Available MBytesGet-Date

Expected result

Threshold reflects real impact or explainable scheduled behavior.

Corrective actions

  • Address cause before raising threshold.
  • Create maintenance window for scheduled load if appropriate.

Escalate when

Persistent saturation, OOM or structural capacity shortfall.

06Certificate nearing expiryControlled change
Symptom

Alert reports certificate expiring in days/weeks.

Checks

  • Check actually served certificate and remaining days.
  • Identify owner and renewal method.
  • Check whether multiple nodes/certificates are involved.

Commands / evidence

openssl s_client -connect <host>:443 -servername <host> </dev/null 2>/dev/null | openssl x509 -noout -datescurl -vkI https://<host>/

Expected result

Expiry and renewal process are known before critical window.

Corrective actions

  • Schedule renewal with margin and validate external deployment.
  • Keep alert until new certificate is actually served.

Escalate when

Critical certificate without owner or failed automation near expiry.

07Backup alertIntrusive / escalation
Symptom

Monitoring reports missing/failed job or breached RPO.

Checks

  • Check latest actually valid restore point.
  • Read backup engine error.
  • Confirm repository and VSS/snapshot.

Commands / evidence

vssadmin list writersGet-VolumeGet-Date

Expected result

Actual RPO is known and a new restore point can be secured.

Corrective actions

  • Open backup incident if expected point is missing.
  • Do not clear alert without confirming new backup.

Escalate when

Critical RPO breached or no secondary copy.

08Alert stormIntrusive / escalation
Symptom

Dozens of alerts arrive almost simultaneously across services.

Checks

  • Group by timestamp, site and common dependency.
  • Identify upstream root alert.
  • Check monitoring platform itself and management network.

Commands / evidence

ping <gateway>Test-NetConnection <core-service> -Port <port>tracert <core-service>

Expected result

A common cause explains most secondary symptoms.

Corrective actions

  • Address root cause before dependent alerts.
  • Put only truly dependent objects in maintenance if needed.

Escalate when

Site/core outage, monitoring unavailable or inability to separate cause and effects.

End-of-intervention checklist

  • Confirm metric returned to normal range.
  • Verify service from a second source.
  • Close/annotate alert with cause and action.
  • Adjust threshold only if measurements justify it.
  • Create prevention/capacity action if incident may recur.

Continue in BAOI

Related cheat sheetNetwork ports — monitoring references IT toolsCalculate, inspect or generate without leaving the workflow. ProceduresFollow a controlled implementation procedure. Known failuresCross-check the symptom with known failure patterns.
Practical guidance

Use the result with confidence

Recommended workflow

  1. Use a non-sensitive representative input for preparing IT monitoring.
  2. Run the operation and review the result before copying or exporting it.
  3. Validate the output in the target application or environment before relying on it.

What to verify

  • Confirm the scope, units and input values before interpreting the output.
  • Separate the observed result from the operational decision that follows from it.
  • Validate the conclusion against the real target system, logs or configuration before changing production.
FAQ

Questions about this tool

What should be documented when using preparing IT monitoring?

Record names, identifiers, owners, addressing or flow direction and the technical dependency that makes each entry necessary.

How do I keep the result useful over time?

Use a clear source of truth, date changes and reconcile the document with real configuration during reviews.

What should I validate before production changes?

Compare the plan with routing, switching, firewall, DNS/DHCP and monitoring configuration that already exists.

♡ 0