by shigemk2

当面は技術的なことしか書かない

memo はてなサービスプラットフォームチームにおけるMackerel #mackerel_ug

自己紹介

  • motemen
  • はてなCTO
  • Mackerelディレクター
  • アプリケーションエンジニア Go/Git

モニタリング自体を本業としてはやっていないのでご了承

Mackerelとは

「直感的サーバー監視サービス」

サーバーのメトリクスとかも見れる

Mackerelの歴史

200x はてな社内サーバー管理ツール を社外に販売できないか 2013 クラウドサーバー監視サービス 2014 Mackerelチーム結成 2014 ベータ 2014 正式リリース 2017 3周年

特徴的なもの

  • サービス ホストを運用する単位
  • ロール ホストの役割(アプリケーションとかデータベースとか)

(書いた)

  • サービス(webサービス はてぶとか増田とか)

    • webサーバー アプリケーションサーバー バッチサーバー DB
  • ホストの識別はエージェント(エージェントレスではない)

mackerel-agent

  • インストールすることでメトリックを投稿
  • Golangで開発されているOSS

    • 結構活発に開発されている
  • wgetからインストール(shとwgetがあればいい)

  • mackerel-agent.conf メトリック カスタマイズ監視 ホストに基づくサービス ロール

API

  • サービス/ロール一覧
  • ホスト情報の取得更新
  • メトリック投稿取得

webUIだけじゃない

mkr

  • mackerelio/mkr
  • Mackerel APIのコマンドラインインターフェイス
  • mackerel-agentの動くホストならAPIキー指定が不要
  • はてなではすべてのホストにagentとmkrがはいっている

メトリック

  • ホストメトリック
    • 稼働状況
    • ソフトウェアの状態
  • サービスメトリック

    • サービス全体の稼働状況
      • KPIの監視
      • ビジネス上のメトリック
  • ロールのメトリック

    • ロール内のホストを比較 積み上げ
    • LAの比較 CPU使用率を積み上げで確認

プラグイン

  • mackerel-agent-plugins

監視

  • ホストメトリック監視
  • サービスメトリック監視
  • チェック監視(小さいプログラムを定期的に走らせてアラートをはっぽうする)
  • 外形監視
  • 式監視

通知チャンネル

  • アラートの通知
    • Slack
    • webhook
    • メール
    • LINE
  • webから手動でグラフ画像を共有できる

通知グループ

  • 通知チャンネルとサービスの紐付け
  • チームのSlackチャンネルに興味あるサービスのアラートをだす

以上、Mackerelの紹介

サービスプラットフォームチームでのMackerelの使い方

組織構造

  • OpTeam ServiceA/ServiceB

運用チームは1つだけで、他の開発チームの運用を横断的に面倒をみている

サービスプラットフォームチーム

  • 基盤ぶぶんを担当している
    • いろんなサービスの基盤の面倒をみている
    • ユーザー向けサービスの基盤
    • と、古いサービス
    • ほぼオンプレ
    • 既存システムの解体と再生が今後の課題
    • インフラ的な事情

SPF: システム特性

  • 巨大なモノリス
  • 全貌を理解は難しい
  • Devs / Ops でともに理解しながら

Devs と Opsのあいだにあるmackerel

1ウェブサービスがMackerelの1サービスに対応

アプリケーション / 外からの観察

  • 外形監視
    • サービスはインターネットに公開されているので、どこかからアクセスして200監視
    • SSL証明書の有効期限監視
    • レスポンスボディ内容チェック
    • サービスに紐付けてレスポンスタイムの監視も
  • サービスメトリック
    • より詳しいステータス状況を監視
    • fluentd-plugin-mackerel
    • レイテンシ(平均90%)
    • ステータスコード
      • percentage count
      • 平均90%が200で、グラフでみれる

Platform-API サービス

  • 複数のサービスにわたるAPIエンドポイントを1箇所に集約
    • HTTPの健康度を確認
    • 健康でいなければならないステータスを一覧する
  • チームのAPIカタログ

ホスト死活

  • 最低限監視
  • mackerel-agentが起動すると自動的に監視
  • agentが落ちたらアラート

ホストメトリック

  • ビルトイン LA CPU Memory FS
  • カスタムメトリックを入れる
    • モニタリング用でアラートを飛ばす用ではない
    • あとから確認できるようにする

静的なシステム理解

  • IaaS
  • アプリケーションエンジニアはいくつかのサービスについてDevs
  • Opsは複数のサービスをみている
    • サーバー設定、ミドルウェア設定の保守運用を担当

Service/Role世界観

  • リポジトリがService/Role対応
    • hatena/hatena-identity
  • リポジトリのなかのディレクトリがservice/role対応

  • サーバーとミドルウェアとの距離が近い

監視: 一般的なホストメトリック

  • Connectivity(死活監視)
  • Filesystem%
    • すべてのホストについてFS使用量について確認
    • logrotate忘れとかに対応できる
    • 特殊例として一部のサーバーの設定を無効にできる

監視: ロール固有のメトリック

  • db(MySQL) worker(TheSchwartz)
  • chefでロールに合わせてカスタムメトリックも設定
  • 監視の閾値は手でチューニング
    • 一括で設定はまだ出来ていない

監視: チェック監視

  • アプリケーション ミドルが正しく動いているか
    • ポート監視など
  • グラフにイベントをつけられる

その他

  • イベントグラフ投稿
    • Dev: デプロイ
    • Op: chef適用
  • mkrでサービス事情の監視
    • cronでDB不整合の件数をメール通知
    • mkr throwでサービスメトリック監視や監視閾値を設定

Example: Go App

  • 新しいアプリケーションを作ったときにどんな監視をするかケーススタディ
  • 新規開発の例: APIサーバー
    • APIサーバーとの結合監視
    • 外形監視 レスポンスボディチェック
    • nginx - app間通信(専用エンドポイント)
    • app - db間通信(専用エンドポイント)
    • nginx カスタムメトリック
    • app カスタムメトリック
    • app-versionチェック

置き換え後

  • 旧システムでロール全体のCPU減少
  • ホスト数も削減
  • 非エンジニアとの会話にもグラフ

  • オペレーションエンジニアと開発エンジニアとの架け橋

  • Slackチャンネルでやりとりできて面白い

Mackerelをつかってみて

  • DevsとOpsでシステムを理解していくための場
  • Service/Role世界観による情報整理