この記事は公開されてから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に集約
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は初めての参加でしたが、これからも注目していきたい思います。
5
