MackerelのAlert設計思想
株式会社はてなが提供するSaaS型監視サービス「Mackerel」は、2014年のリリース以来、多くの国内企業に利用されてきました。Mackerelの最大の特徴は、単なるメトリクス収集ツールではなく、「どのようにアラートを設計すべきか」という思想を製品に込めている点にあります。
"Mackerel," the SaaS-type monitoring service offered by Hatena, has been used by many domestic companies since its release in 2014. Mackerel's greatest feature is that it is not a mere metrics collection tool — it imbues into the product a philosophy of "how alerts should be designed."
症状駆動アラート
Mackerelが推奨するのは、「原因」ではなく「症状」に基づくアラート設計です。たとえば「CPUが高い」というアラートは原因側の指標で、ユーザーが実際に影響を受けているかは分かりません。一方、「APIの応答時間が500ミリ秒を超えた」は症状側の指標で、ユーザー体験に直接結び付きます。
What Mackerel recommends is alert design based not on "cause" but on "symptom." For example, "CPU is high" is a cause-side metric, and you cannot tell whether users are actually being impacted. On the other hand, "API response time exceeded 500 milliseconds" is a symptom-side metric, directly tied to the user experience.
ホスト単位とサービス単位のグルーピング
Mackerelは全メトリクスを「ホスト」と「役割（ロール）」、そして「サービス」の三層で管理します。個別ホストの障害は許容されるが、同じ役割を持つホスト群の半数が落ちると重大という、組織の視点に沿ったアラート条件が設定できます。これによりオートスケールで頻繁にホストが入れ替わる環境でも安定した監視が可能になります。
Mackerel manages all metrics across three layers: "host," "role," and "service." It allows alert conditions aligned with the organizational viewpoint — for example, "individual host failures are tolerated, but if half of the host group sharing the same role goes down, it is serious." This enables stable monitoring even in environments where hosts frequently swap in and out via autoscaling.
オンコールローテーションとの統合
Mackerelは単独でアラート配信を完結させるのではなく、PagerDutyやOpsgenieといった専門のオンコール管理サービスと連携する設計を採用しています。当番の輪番、エスカレーション、通知抑止（業務時間外の扱いなど）はそれら専用サービスに任せるという役割分担です。
Rather than completing alert delivery alone, Mackerel adopts a design that integrates with specialized on-call management services such as PagerDuty and Opsgenie. The role division is to entrust on-call rotation, escalation, and notification suppression (such as handling outside business hours) to those dedicated services.
Monitor as CodeとTerraformプロバイダー
監視設定をUIから手作業で行うと、誰がいつ何を変更したかが分からなくなりがちです。Mackerelは公式のTerraformプロバイダーを提供しており、全監視設定をコードとしてGitで管理できます。プルリクエストレビューを経て本番に反映される仕組みは、一般的なインフラ構成管理と変わらない体験です。
When monitoring configurations are done manually from the UI, it tends to become unclear who changed what and when. Mackerel provides an official Terraform provider, allowing all monitoring configurations to be managed as code in Git. The mechanism by which changes go through pull request review before being reflected in production provides an experience no different from general infrastructure configuration management.
プッシュ型とプル型の使い分け
従来の監視ツールはプル型（監視サーバーが対象にメトリクスを取りに行く）が主流でしたが、Mackerelは基本プッシュ型（各ホストのエージェントがメトリクスを送り付ける）を採用しています。プッシュ型はファイアウォール越しでも動作しやすく、オートスケール環境との相性が良いです。一方、特定のユースケースではPrometheus互換のプル型収集もサポートされており、適材適所で選択できます。
Conventional monitoring tools were mainstream pull-type (the monitoring server fetches metrics from targets), but Mackerel fundamentally adopts push-type (an agent on each host sends metrics up). Push-type works easily across firewalls and has good compatibility with autoscaling environments. On the other hand, for specific use cases, Prometheus-compatible pull-type collection is also supported, allowing users to select the right tool for the right place.
おわりに
Mackerelの設計思想は、「人が反応できないアラートは作らない」という一点に集約されます。症状駆動、役割単位のグルーピング、オンコールサービスとの連携、Monitor as Code — これらは全て当番担当者の負担を減らし、本当に重要な障害に集中できる環境を作るための手段です。
Mackerel's design philosophy converges on a single point: "do not create alerts to which humans cannot respond." Symptom-driven, role-based grouping, integration with on-call services, Monitor as Code — these are all means to reduce the burden on on-call engineers and create an environment in which they can focus on truly important incidents.