自己紹介
- 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世界観による情報整理