Services and Roles

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.

f:id:mackerelio:20200923113905p:plain

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".

f:id:mackerelio:20200923113947p:plain

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.

f:id:mackerelio:20200923114109p:plain
Monitors and notification groups can be configured for "services".

f:id:mackerelio:20200923114203p:plain
Likewise, monitors and notification groups can be configured for "roles"
.

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).

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.

f:id:mackerelio:20200923114309p:plain
When a "role" is displayed in a single graph, each host is color-coded.

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 staging or production
  • 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-90 or filesystem-95 (Monitors that correspond to roles are configured and operated separately)

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.

f:id:mackerelio:20200930172003p:plain

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".