-
Notifications
You must be signed in to change notification settings - Fork 3
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
14 changed files
with
597 additions
and
52 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -11,36 +11,36 @@ Learn how do create a Business Process composed from existing Icinga2 Checks. | |
|
|
||
| <!--more--> | ||
|
|
||
| ## Adding our first Business Process | ||
| ## Adding our first Business Process Definition | ||
|
|
||
| Now that BPMON is set up, lets define a *business process*. Again, we do that | ||
| via YAML, a file per *business process*: | ||
| via YAML, a file per *business process*. Put the following content into `$BPMON_HOME/bp.d/web_service_x.yaml` | ||
|
|
||
| ```yaml | ||
| --- | ||
| # Give it a name. Names can be changed anytime... | ||
| name: Application X | ||
| name: Web Service X | ||
| # Also give it an ID. This is used to store results in the database and | ||
| # therefore should not be changed. | ||
| id: app_x | ||
| id: ws_x | ||
| # Tell BPMON during what time the process needs to be avalable. Remember | ||
| # the availabilities section from the global configuration...? This links | ||
| # there. | ||
| availability: 9to5 | ||
| availability: medium | ||
| # You can also specify a 'responsible' string. This string can then be used in | ||
| # the trigger template. This could be for example trigger a specific http | ||
| # end point, pass some uri parameters, send an email to a specific address etc. | ||
| # The 'responsible' string is inherited by its KPIs if not overwritten... | ||
| responsible: [email protected] | ||
| # By providing a list of 'recipients' subcommands such as 'beta dashboard' can | ||
| # By providing a list of 'recipients' subcommands such as 'dashboard' can | ||
| # use that information in order do provide some sort of authorization. | ||
| recipients: [ UsersAppX ] | ||
| # Now the KPIs... | ||
| kpis: | ||
| - | ||
| # We already know the name and ID part... | ||
| name: Load Balancer Availability | ||
| id: lb_availability | ||
| name: Database Availability | ||
| id: db_availability | ||
| # The 'operatinon' defines how the services must be evaluated. Possible | ||
| # options are: | ||
| # * AND: All services need to be 'OK' for the KPI to be 'OK'. | ||
|
|
@@ -55,14 +55,28 @@ kpis: | |
| # And now the processes. Host and service relate to how you named those | ||
| # things in your Icinga2 setup. | ||
| services: | ||
| - { host: haproxy1.example.com, service: ping } | ||
| - { host: haproxy2.example.com, service: ping } | ||
| - name: App Nodes Availability | ||
| id: app_availability | ||
| operation: MINPERCENT 50 | ||
| - { host: database1.example.com, service: ping } | ||
| - { host: database2.example.com, service: ping } | ||
| - name: Frontend Nodes Availability | ||
| id: frontend_availability | ||
| operation: MINPERCENT 60 | ||
| services: | ||
| - { host: app1.example.com, service: api_health, responsible: [email protected] } | ||
| - { host: app2.example.com, service: api_health } | ||
| - { host: app3.example.com, service: api_health } | ||
| - { host: app4.example.com, service: api_health } | ||
| - host: frontend1.example.com | ||
| service: api_health | ||
| responsible: [email protected] | ||
| - { host: frontend2.example.com, service: api_health } | ||
| - { host: frontend3.example.com, service: api_health } | ||
| - { host: frontend4.example.com, service: api_health } | ||
| - { host: frontend5.example.com, service: api_health } | ||
| - { host: frontend6.example.com, service: api_health } | ||
| ``` | ||
| Certainly you have to adopt the configuration to match systems monitored via your icinga instance or use | ||
| [icingamock](//github.com/unprofession-al/bpmon/blob/master/cmd/icingamock/README.md) to use our Business Process | ||
| Definition: | ||
| ``` | ||
| icingamock -bp $BPMON_HOME/bp.d | ||
| ``` | ||
|
|
||
| Configuration done, lets check...! | ||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,14 @@ | ||
| --- | ||
| title: "Run BPMON" | ||
| date: 2018-10-29T11:07:36+01:00 | ||
| optional: false | ||
| duration: "2 min" | ||
| menu: "doc" | ||
| weight: 30 | ||
| --- | ||
|
|
||
| All set and configured... Let's see the results! | ||
|
|
||
| <!--more--> | ||
|
|
||
| ### Basic Configuration |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -69,35 +69,35 @@ <h1>Create Business Processes</h1> | |
|
|
||
| <p></p> | ||
|
|
||
| <h2 id="adding-our-first-business-process">Adding our first Business Process</h2> | ||
| <h2 id="adding-our-first-business-process-definition">Adding our first Business Process Definition</h2> | ||
|
|
||
| <p>Now that BPMON is set up, lets define a <em>business process</em>. Again, we do that | ||
| via YAML, a file per <em>business process</em>:</p> | ||
| via YAML, a file per <em>business process</em>. Put the following content into <code>$BPMON_HOME/bp.d/web_service_x.yaml</code></p> | ||
|
|
||
| <pre><code class="language-yaml">--- | ||
| # Give it a name. Names can be changed anytime... | ||
| name: Application X | ||
| name: Web Service X | ||
| # Also give it an ID. This is used to store results in the database and | ||
| # therefore should not be changed. | ||
| id: app_x | ||
| id: ws_x | ||
| # Tell BPMON during what time the process needs to be avalable. Remember | ||
| # the availabilities section from the global configuration...? This links | ||
| # there. | ||
| availability: 9to5 | ||
| availability: medium | ||
| # You can also specify a 'responsible' string. This string can then be used in | ||
| # the trigger template. This could be for example trigger a specific http | ||
| # end point, pass some uri parameters, send an email to a specific address etc. | ||
| # The 'responsible' string is inherited by its KPIs if not overwritten... | ||
| responsible: [email protected] | ||
| # By providing a list of 'recipients' subcommands such as 'beta dashboard' can | ||
| # By providing a list of 'recipients' subcommands such as 'dashboard' can | ||
| # use that information in order do provide some sort of authorization. | ||
| recipients: [ UsersAppX ] | ||
| # Now the KPIs... | ||
| kpis: | ||
| - | ||
| # We already know the name and ID part... | ||
| name: Load Balancer Availability | ||
| id: lb_availability | ||
| name: Database Availability | ||
| id: db_availability | ||
| # The 'operatinon' defines how the services must be evaluated. Possible | ||
| # options are: | ||
| # * AND: All services need to be 'OK' for the KPI to be 'OK'. | ||
|
|
@@ -112,17 +112,30 @@ <h2 id="adding-our-first-business-process">Adding our first Business Process</h2 | |
| # And now the processes. Host and service relate to how you named those | ||
| # things in your Icinga2 setup. | ||
| services: | ||
| - { host: haproxy1.example.com, service: ping } | ||
| - { host: haproxy2.example.com, service: ping } | ||
| - name: App Nodes Availability | ||
| id: app_availability | ||
| operation: MINPERCENT 50 | ||
| - { host: database1.example.com, service: ping } | ||
| - { host: database2.example.com, service: ping } | ||
| - name: Frontend Nodes Availability | ||
| id: frontend_availability | ||
| operation: MINPERCENT 60 | ||
| services: | ||
| - { host: app1.example.com, service: api_health, responsible: [email protected] } | ||
| - { host: app2.example.com, service: api_health } | ||
| - { host: app3.example.com, service: api_health } | ||
| - { host: app4.example.com, service: api_health } | ||
| </code></pre></div> | ||
| - host: frontend1.example.com | ||
| service: api_health | ||
| responsible: [email protected] | ||
| - { host: frontend2.example.com, service: api_health } | ||
| - { host: frontend3.example.com, service: api_health } | ||
| - { host: frontend4.example.com, service: api_health } | ||
| - { host: frontend5.example.com, service: api_health } | ||
| - { host: frontend6.example.com, service: api_health } | ||
| </code></pre> | ||
|
|
||
| <p>Certainly you have to adopt the configuration to match systems monitored via your icinga instance or use | ||
| <a href="//github.com/unprofession-al/bpmon/blob/master/cmd/icingamock/README.md">icingamock</a> to use our Business Process | ||
| Definition:</p> | ||
|
|
||
| <pre><code>icingamock -bp $BPMON_HOME/bp.d | ||
| </code></pre> | ||
|
|
||
| <p>Configuration done, lets check…!</p></div> | ||
| </div> | ||
|
|
||
| </div> | ||
|
|
||
Oops, something went wrong.