Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
en:documentation:01_understanding:01_introduction [2021/05/19 13:15]
127.0.0.1 editor externo
en:documentation:01_understanding:01_introduction [2021/11/08 19:41] (current)
jimmy.olano Enlaces internos.
Line 162: Line 162:
 In order to be able to draw up action procedures, it will be necessary to take into account several factors: In order to be able to draw up action procedures, it will be necessary to take into account several factors:
  
-***Urgency of the event**: being able to distinguish something normal from something rare or critical. ***Form of notification**: email, sms, Telegram, sound alert… ***Scaling**: different forms of warning in face of a recurrent problem. A common case is notification to a manager after a certain amount of time without solving a problem. +***Urgency of the event**: being able to distinguish something normal from something rare or critical. ***Form of notification**: email, sms, Telegram, sound alert… ***Scaling**: different forms of warning in face of a recurrent problem. A common case is notification to a manager after a certain amount of time without solving a problem. Before entering any configuration, it is advisable to have these concepts clear, draw up schemes with the critical elements, how to monitor them, what to do with all the information gathered and how to report problems that arise. {{  :wiki:scalation_example.png?500  }}By focusing on the most critical issues first, you reach a logical starting point that defines **what**  the most important issues for your organization are. Once you know what the most critical elements are, you can define **how**  to monitor the target(s), while considering **who**  will be responsible for the resolution of the reported problems in those systems as well as how to notify the appropriate people of the existence of a problem.
-Before entering any configuration, it is advisable to have these concepts clear, draw up schemes with the critical elements, how to monitor them, what to do with all the information gathered and how to report problems that arise. +
- +
-{{  :wiki:scalation_example.png?500  }} +
- +
-By focusing on the most critical issues first, you reach a logical starting point that defines **what**  the most important issues for your organization are. Once you know what the most critical elements are, you can define **how**  to monitor the target(s), while considering **who**  will be responsible for the resolution of the reported problems in those systems as well as how to notify the appropriate people of the existence of a problem. +
 ==== Supervision Models ==== ==== Supervision Models ====
  
Line 190: Line 184:
  
 Maybe, but from our experience, each client works in a certain way and regardless of how much we know about monitoring, we may not know more about how your infrastructure was configured than you do. Monitoring easy tasks presents no problems, the hard job is to adapt monitoring to your business without having to adapt your business to monitoring. Not an easy task. More than 800 pages await, if you wish to discover the best way to monitor your organization with Pandora FMS. It is a challenge, but one we believe is well worth the effort. Maybe, but from our experience, each client works in a certain way and regardless of how much we know about monitoring, we may not know more about how your infrastructure was configured than you do. Monitoring easy tasks presents no problems, the hard job is to adapt monitoring to your business without having to adapt your business to monitoring. Not an easy task. More than 800 pages await, if you wish to discover the best way to monitor your organization with Pandora FMS. It is a challenge, but one we believe is well worth the effort.
 +
 +[[:en:documentation:start|Go back to Pandora FMS documentation index]]
  
  
ºº