In Mackerel, instead of managing hosts one by one, they are aggregated into appropriate groups and managed/configured by their unit.
A "service" is the unit used to group multiple hosts that make up the system or service to be monitored. A host can belong to multiple "services" as well.
Within a "service", hosts are alloted certain roles/responsibilities. To express this concept, Mackerel uses "roles".
A "role" is the unit used to further catorgorize hosts that belong to a "service". "Roles" can be created for each "service" and a host can belong to multiple "roles". Hosts that belong to a "service" must have a "role".
You can create as many "services" and "roles" as you like for free. Refer to the following page for more on how to so.
Creating services and roles - Mackerel Help
The advantages of creating "services" and "roles"
Creating "services" and "roles" and grouping multiple hosts together lets you do more. Below are some of the benefits.
- Groups of hosts are easier to manage when linked to "services" and "roles" that are based on specific policies.
- Metadata can be added and managed for "services" and "roles".
- Monitoring targets can be filtered by "service"/"role" using a monitor's
filter conditions. - Hosts/alerts can be filtered by "service"/"role" from the Hosts list screen and Alerts list screen.
The following are features available for "services".
- Recipients of alert notifications via notification groups can be switched on a service-by-service basis.
- Numerical indicators of a service (metrics that are not / should not be linked to a specific host) can be posted for the "service" (service metrics).
- Response time obtained using an external URL monitor can be registered as a service metric.
The following are features available for "roles".
- Graphs of multiple hosts that belong to the same role can be displayed together in one graph.
- Load statuses of past hosts that no longer exist can also be checked in this graph.
- There are a few things to consider when using this feature. See the 'Notes regarding "roles"' section below.
Example units for creating "services" / "roles"
When it comes to creating a "service" / "role" unit, there is no wrong answer. An optimal unit can depend on scale, provision method, and organizational structure of the target system or service. Consider the following examples.
Example units of "services"
- A unit based on the provided system or service
- A unit based on the environment of the provided system or service
- such as
stagingorproduction
- such as
- A micro-service based unit, such as a system consisting of micro-service architecture
Example units of "roles"
- A unit based on each function of hosts belonging to the "service"
- such as "application server", "batch server", "database server", etc.
- A unit based on applications/middleware running on the server
- Servers are grouped with those that should have similar load trends
- A unit based on host server specs
- A unit based on monitoring level
- such as
filesystem-90orfilesystem-95(Monitors that correspond to roles are configured and operated separately)
- such as
Taking into consideration that "services" and "roles" can be used to narrow down and filter multiple host groups, creating an optimal unit is important.
Notes regarding "services"
The following should be taken into consideration when using "services".
- "Services" cannot be configured to span multiple organizations.
- Once created, the name of a "service" cannot be changed. You must recreate a new "service" and delete the old one. "Services" can be deleted via the settings link displayed to the right of the "service" name.
Notes regarding "roles"
The following should be taken into consideration when using "roles".
― "Roles" cannot be configured to span multiple organizations. - Using "roles", you can display graphs of multiple hosts that belong to the same "role" together in one graph, but the graph will only contain host information from after the configuration to that "role".
