[レポート]Mackerel Meetup #12 Tokyo #mackerelio

こんにちは、坂巻です。

先日開催されたMackerel Meetupに関するレポートをお伝えします。

なお、既に公式のレポート記事が掲載されていますので、こちらもご紹介します。

• Mackerel Meetup #12 Tokyo を開催しました ＆ 開催レポート！

目次

• 200週連続新機能リリースとこれから
• 機械学習を用いたMackerelの異常検知機能について
• トレタのインフラ運用を支えるMackerel
• フルマネージドホスティングの運用監視にMackerelを導入した話

200週連続新機能リリースとこれから

登壇者 : Mackerel 株式会社はてな プロダクトマネージャー 松木 雅幸 様

概要

今年のMackerelのロードマップ状況と今後の展望についてお話します。特にリリースしたばかりのアラートグループ機能の解説や、現在開発中のコンテナ対応状況についてお知らせします。

今後の継続リリース

• 毎週リリースは継続します
• 毎週必ず新機能をお届けすることにはこだわりません
• 新機能を計画的に継続的にお届けしていきます

Mackerelが提供しているOSS(抜粋)

• mackerel-agent (39)
• mackerel-agent-plugins (69)
• go-check-plugins (41)
• mkr (41)
• fluent-plugin-mackerel (13)
• cookbook-mackerel-agent (11)
• ansible-mackerel-agent (12)
• itamae-plugin-recipe-mackerel-agent (7)

2018年Contribution抜粋

• Add --upgrade option to plugin install. #150
  • mkrでプラグインを冪等に更新できる機能
  • 他にもmackerel-agentのconfigtestもfujiwaraさん
• goroutine leaking? #18
  • Songmu/timeoutのgoroutineリーク
  • 焦って修正
  • 他にもmackerel-plugin-mysqlの追加メトリック取得機能もnetmarkjpさん
• Auto retire with shutdown on Windows #505
  • mackerel-agentのWindows自動退役対応
  • そもそもWindwos対応自体がmattnさん

Contributeについて

• GitHub上は基本は英語でお願いします
• Mackerel User Group Slackで日本語相談OKです
• 日本人同士なので英語の練習ってことで
• Blogで取り上げていただくこともありがたいです

2018年公開ロードマップ

• アラートグループ（リリース済）
• コンテナ正式サポート（開発中）
• カスタムダッシュボードv2（開発中）
• 異常検知（開発中）

アラートグループ

• アラートの洪水を防ぐ
• ルールベースでグルーピング
  • サービス・ロール
  • 監視ルール
• 「サービス」で設定するのがおすすめ
• アラートとアラートグループは別イベント
• アラートは個別の異常状態のイベント
• 自動化などのために勝手にまとまるのはよろしくない

コンテナ正式サポート

• mackrel-container-agent(仮)
  • 社内でドッグフード中
  • 今はprivateだけどもちろんOSSにします
  • 11月頃を予定
• 設計方針
  • ECSやKubernetesでオーケストレーションしている環境が対象
  • TaskやPodに対するsidecar agent
  • オーケストレーションツールが提供しているAPIと連携
  • PodやTaskをMackerelのロールに所属
  • クローズドベータ検討中

カスタムダッシュボードv2

• 仕様やリリース予定
  • 各種ウイジェットを画面上に自由に配置
  • 早ければ9月に1stリリース
    • グラフウィジェット
    • 数値ウィジェット
    • テキストウィジェット
  • リリース後機能追加していきます

異常検知

• 詳しくは次のセッション
• 早ければ10月リリース予定

Mackerelのこれから

• ミッション
  • クラウド監視サービスを提供し、世のエンジニアの開発・運用プロセスを革新する
• ビジョン
  • DevOps中枢サービスのデファクトとして進化しつづける
  • サービス監視・運用の価値を高め、面白くする
  • 顧客のサービス成長を加速させる
• バリュー
  • Infrastructure as Codeを体現する
  • devops文化を根付かせる
  • ドッグフーディング
  • エンジニアをワクワクさせる
  • OSSエコシステムと共生する
• 次期開発検討項目
  • インテグレーション対応
  • GCPインテグレーション
  • SAML認証
  • 新機械学習活用機能
  • 時系列データベースの機能拡充

機械学習を用いたMackerelの異常検知機能について

登壇者 : Mackerel 株式会社はてな アプリケーションエンジニア 吉田 康久 様

概要

現在開発中の異常検知機能はこれまでの監視ルールと何が異なるのか、何ができて何はできないのか、はてな社内の実例を元にお話します。

はじめに

現在開発中の機能につき、リリース時には詳細が変更されている可能性がある

サーバ監視の困り事

• サーバ監視初心者の場合(例：アプリケーションエンジニア)
  • クラウドを使うようになって、サーバも自分で立てるようになった
  • 本質的にはアプリケーションの開発に集中したい
• サーバ監視玄人の場合
  • インフラ周りの知識が豊富、何を監視すればいいか経験的に知っている
  • 見なければいけないサービスも多く、多忙なことも
  • 監視ルールを一度設定すれば終わり、ではなく定期的にメンテナンスする必要がある
• 複数条件を考慮した障害の早期発見
  • 人間が複数のAND条件を網羅するのは困難
  • 例：「CPU使用率はそれほど高くない」かつ「MEMORY使用量は多い」

異常検知によるアラートの実例

• 成功事例1
  • 始業直後にアラートが発報され、full GCを検知
  • 一時的に負荷が上昇していたことがわかり、full GCが終わったタイミングで異常検知のアラートも閉じられていた
• 成功事例2
  • diskのreadが上昇し、loadavgが上がったタイミングで異常検知アラートが発報
  • 問題のプロセスをkillし、障害を未然に防げた

異常検知とは？

• ガウス分布に基づく方法(教師なし学習)
  • 起きる確立の高い現象は正常と見なし、低い事象は異常と見なす
  • システムメトリックの約20個を総合的に見て判定
• 負荷の波がある場合
  • 昼／夜で負荷傾向が異なる場合、一つのガウス分布ではサーバ負荷の状態を表現しきれず、誤報が多くなる
  • 高負荷の場合、低負荷の場合といくつかガウス分布を用意するとよさそう
• 混合ガウス分布に基づく異常検知
  • 複数のガウス分布の足し合わせで対応
  • 負荷の波があってもご検知しない

トレタのインフラ運用を支えるMackerel

登壇者 : 株式会社トレタ インフラエンジニア 山田 隆司 様

概要

飲食店向け顧客管理台帳システムを提供するトレタにおけるMackerel活用事例について、インフラ運用の話を交えながらお話します。

トレタのインフラ運用

• laC(Packer, Ansible, Terraform, Serverspec等)
• Blue-Green Deployment
• Immutable
• オートスケール
• アラート、モニタリングはmackerelに集約

mackrel-agent.conf

• 基本的には公式のプラグインを利用
• インフラに問題があった時には、[plugin.checks.syslog]とかを都度仕込む
• Packerビルドの中では、host_statusのon_startはstandbyにしている
• サーバが問題なく通信できるようになったら、workingに変える運用

Systemd

• オートスケールした時にmackrelから自動的に退役させるスクリプトを作成していた
  • スクリプトは不要でAUTO_RETIREMENTいけることが判明

使い初めてよかったこと

• ダッシュボード
  • エンジニア以外も理解することができ、お客さんとのコミュニケーションにつながった
• グラフアノテーション
  • ETLのボトルネックを検出できた（感謝）
• AWSインテグレーション
  • これまではRDB監視のため、モニターサーバを立てていた

期待していること

• vuls
  • サーバ立てて、スキャンしてCVE-IDを通知する等のスクリプトを、フルスクラッチで実装している

フルマネージドホスティングの運用監視にMackerelを導入した話

登壇者 : アイテック阪急阪神株式会社 主事 森本 健一 様

概要

既存の監視システムで抱えていた問題をMackerelで解決したこと、導入時に工夫した内容などをお話します。

抱えていた問題

• ユーザへの障害通知のタイムラグ
• 混在している監視システム
• たびたび起こる監視設定の間違い
• 監視サーバの設計上の問題

Mackerel 導入理由

• 個々の課題の解決方法は色々あった
• Mackerel を使えば総合的に解決できそう
• SaaS / マネージドサービス
• コスト比較
  • クラウドに Zabbix インスタンス 冗長構成
  • VPN、監視運用、管理

監視サーバの保守が不要

• クラスタ構成(PaceMaker等)、複数台構成
  • Pandora FMS, Zabbix, Zabbix Proxy
• 台数、容量増加時にスケールできる設計が必要

プライベート NW 環境に導入しやすい

• セキュリティ要件の厳しい顧客のプライベートネットワーク環境
• api.mackerelio.com 443 port への outbound の許可があればOK
  • HTTP Proxy or NAT
  • 監視のために 443 通します、という説明は必要
• 監視サーバからのルーティング、FW許可などが不要

Mackerel 導入後の構成

• エージェントインストールで死活監視は自動的に開始
• これだけで監視漏れがなくなる安心感が得られる

Mackerel 導入前 URL 監視設定フロー

• サーバ構築者が監視内容をexcelに記入
• サーバ構築者がチケットにexcelを添付
• 監視担当者がチケット内容を元に監視設定

Mackerel 導入後 (予定)

• 担当者が監視内容を設定
  • mkr monitors pull して編集
  • branch 切って commit, push (社内 Gitlab )
  • Merge Request 投げる
• チェック者が Merge
  • Gitlab CI で自動的に設定

まとめ

• エージェントインストールだけで監視が始まる安心感
• API が豊富に提供されていて大抵のことはできる
• 運用監視を Mackerel に任せることでサービス提供に集中できる

さいごに

機械学習を用いた異常検知機能は、ロールを選択するだけのお手軽な設定で、
障害を未然に防ぐことにつながる素晴らしい機能でした。
今回ご紹介いただいた機能のリリース時期は、だいたい「クリスマス」と覚えておけばよさそうですw

Mackerel Meetupは初めての参加でしたが、これからも注目していきたい思います。