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

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、坂巻です。

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

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

目次

  • 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に集約

1

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は初めての参加でしたが、これからも注目していきたい思います。