Upgrade to Pro — share decks privately, control downloads, hide ads and more …

「ソフトウェアの梃子(てこ)」と Mackerel #cmdevio / mackerel with software insulator

Daisuke Inoue
November 02, 2019

「ソフトウェアの梃子(てこ)」と Mackerel #cmdevio / mackerel with software insulator

Developers.IO 2019 Okayama https://dev.classmethod.jp/news/191102-dev-io-okayama/ での登壇資料です。

Daisuke Inoue

November 02, 2019
Tweet

More Decks by Daisuke Inoue

Other Decks in Technology

Transcript

  1. 1
    “ソフトウェアの梃⼦” と

    柔軟でワクワクするサーバー監視を⼿に⼊れる
    株式会社はてな
    井上 ⼤輔(id:a-know )

    View Slide

  2. 2
    ⾃⼰紹介
    ⽒名:井上 ⼤輔(a-know / @a_know)
    所属:株式会社はてな Mackerelチーム
    職種:CRE(Customer Reliability Engineer)
    主な業務
    l テクニカルサポート
    l テクニカルコミュニケート
    l カスタマーサクセス推進
    l プロダクト改善への貢献
    • VoC(Voice of Customer)の吟味・検討・提案
    l セールス

    View Slide

  3. 3
    ⾃⼰紹介
    略歴
    l 2006年 〜 2016年
    l システムエンジニア・Webアプリケーションエンジニア
    等の肩書きで、システム・アプリケーション開発に従事
    l 2016年 〜
    l 株式会社はてな にセールスエンジニアとして⼊社
    l 2017年より CRE に改称
    l 岡⼭県出⾝です
    l 2012年〜2019年6⽉まで東京に
    l 今年7⽉から岡⼭県倉敷市へ・リモート勤務
    l 趣味
    l Webサービスの個⼈開発

    View Slide

  4. 4

    View Slide

  5. 5
    https://classmethod.jp/news/hatena_mackerel_dealer/

    View Slide

  6. 6
    サーバー監視の重要性
    l 1⼈あたり1台以上のスマートフォン端末が普及している時代
    Ø 様々な機能、サービスがサーバーから提供されることも当たり前に。
    Ø サーバーの安定稼働を維持することの重要性が増している
    l 提供サービスの改善についても、早さや確実性がより求められるように。
    Ø プログラムが壊れないように・壊れてもすぐに気がつけるようにテストを
    常に実⾏するのと同じく……
    Ø サーバーに対して怖がることなくデプロイ、設定変更をしていくために、
    という意味でも、サーバー監視は重要なものに。

    View Slide

  7. 7
    ここでいう “サーバー監視”
    l 監視対象リソースの死活・負荷・リソース状況を⼀定間隔でチェックし
    つづけ、問題が観測されたら適切に通知をおこなうこと
    l 監視の結果を継続的に記録し続け、その内容をいつでも参照・閲覧可能
    な状態にしておくこと

    View Slide

  8. 8
    “ソフトウェアの梃⼦(テコ)”

    View Slide

  9. 9
    ソフトウェアの梃⼦
    l『UNIXという考え⽅』という本の中での表現
    (Mike Gancarz 著・芳尾 桂 監訳(オーム社、2001年))
    Ø “よいプログラマはよいコードを書く。偉⼤なプログラマはよいコードを借りてくる”
    Ø “⼩さなプログラムをいくつもつなぎ合わせるコツを⼼得る”
    Ø “コードを他者が梃⼦として使うのを認める”
    Ø “すべてを⾃動化する”
    l 私の好きな考え⽅のひとつです

    View Slide

  10. 10
    ソフトウェアの梃⼦
    ü
    ü 独⾃技術や規格などではない、標準的なI/Fにより、他の仕組みとの連携を⾮常
    にしやすくすること
    Ø 標準出⼒、終了ステータス、ASCIIフラットファイル(プレーンテキスト)、HTTP
    リクエスト、シェルスクリプト、 ……
    Ø API や Webhook なども “梃⼦” であるよなぁ、と思っています
    ü それらを組み合わせて使うことで、⼤きな仕事を達成できる……という考え⽅

    View Slide

  11. 11
    ソフトウェアの梃⼦
    l コードを書く、ということは極めて創造的な活動。
    • 思い通りのプログラムができたらとても楽しい
    l いくつかのコード(モジュールやライブラリなども含む)を組み合わせて⼤きな
    結果を出す・その組み合わせ⽅を考えるということも、創意⼯夫やアイデアを凝
    らすことのできる、とてもクリエイティブな作業(=楽しい!)

    View Slide

  12. 12
    .BDLFSFM͸ɺ lιϑτ΢ΣΞͷᑏࢠzΛ
    ඇৗʹ͏·͘׆༻͍ͯ͠Δͳʙʙɺͱ
    ೔ʑ࣮ײ͍ͯ͠·͢

    View Slide

  13. 13
    『Mackerel とソフトウェアの梃⼦』という観点を意識しつつ、
    Mackerel で実現できる様々な “監視” をご紹介します
    :テコ・ポイント

    View Slide

  14. 14
    Mackerel の監視アーキテクチャ
    ΤʔδΣϯτ͔Β
    ϝτϦοΫΛ౤ߘ
    (API 経由(HTTPS))
    44-ূ໌ॻͷ
    ༗ޮظݶ؂ࢹ
    ΋0,ʂ

    View Slide

  15. 15
    エージェントがやっていること
    $ cat /proc/meminfo
    MemTotal: 1015472 kB
    MemFree: 81576 kB
    MemAvailable: 82920 kB
    Buffers: 0 kB
    Cached: 94076 kB
    SwapCached: 27000 kB
    Active: 419108 kB
    Inactive: 391240 kB
    Active(anon): 359752 kB
    Inactive(anon): 366444 kB
    Active(file): 59356 kB
    Inactive(file): 24796 kB
    Unevictable: 0 kB
    Mlocked: 0 kB
    SwapTotal: 2097148 kB
    SwapFree: 1857868 kB
    Dirty: 32 kB
    Writeback: 0 kB
    AnonPages: 708588 kB
    Mapped: 23396 kB
    Shmem: 9924 kB
    Slab: 79900 kB
    SReclaimable: 31160 kB
    SUnreclaim: 48740 kB
    KernelStack: 5920 kB
    PageTables: 10372 kB
    NFS_Unstable: 0 kB
    Bounce: 0 kB
    WritebackTmp: 0 kB
    CommitLimit: 2604884 kB
    Committed_AS: 1375884 kB

    公式エージェントソフトウェア
    (mackerel-agent)

    View Slide

  16. 16
    ⾃動のスケールイン / スケールアウトにも対応
    Ø initd / systemd によるシャットダウンをトリガーにホスト退役処理を実⾏
    スケールアウト
    スケールイン

    View Slide

  17. 17
    Q. エージェントのインストールができない対象の場合は?
    • 例えば AWS の各種マネージドサービス、サーバーレス環境の場合。
    • Amazon RDS
    • AWS Lambda
    • など

    View Slide

  18. 18
    l Assume Role などで Mackerel に対して Cloud Watch API へのリクエストを
    許可(移譲)。
    l Mackerel が⾃動的に⼀定間隔で Cloud Watch API をリクエストし、
    得た情報(メトリック)を Mackerel に対して投稿
    A. 『AWSインテグレーション』を使う

    View Slide

  19. 19
    mackerel-agent で監視ができる項⽬について
    l エージェント単体で監視ができる項⽬は以下の6項⽬。
    • ロードアベレージ
    • CPU使⽤率
    • メモリ使⽤量
    • ディスクIOPS
    • ネットワークインターフェース I/O
    • ディスク使⽤量
    l Q. それ以外にも監視したい項⽬がある場合はどうする?
    • 例1)アプリケーションログに出⼒されるエラーログの監視がしたい!
    • 例2)Webサーバーに対するリクエスト数などの状況の監視がしたい!

    View Slide

  20. 20
    A. プラグインを使って監視できる項⽬を増やせます
    Ø エージェント単体では取得しないメトリック項⽬を追加で取得させられるよう
    にできたり、監視のための処理を追加でおこなわせることができるようになる
    仕組みがあります
    Plugin Target
    ② get values
    ③ return values by stdout
    Host
    ④ POST by API
    Mackerel
    ① exec
    mackerel-agent

    View Slide

  21. 21
    プラグイン利⽤例1)アプリケーションログに出⼒されるエラーログの監視
    Ø プラグインを利⽤するには、mackerel-agent に対する設定を追加すればOK!
    Ø “check-log” は、そのサーバー内にインストールされた、単体で実⾏可能なコマンド!
    # mackerel-agent.conf
    [plugin.checks.applog]
    command = ["check-log", "--file", "/var/www/app/log/production.log", "--pattern", "failed", "--return"]

    View Slide

  22. 22
    プラグイン利⽤例1)アプリケーションログに出⼒されるエラーログの監視
    l 監視の結果をコマンドの終了ステータスで返却している
    Ø 0 : OK
    Ø 1 : WARNING
    Ø 2 : CRITICAL
    Ø それ以外: UNKNOWN
    l つまり、「なんらかの監視処理をして、その結果を終了ステータスとして返す」
    プログラムでありさえすれば、チェックプラグインとして利⽤可能!
    l シェルスクリプト、Ruby、Java、……お好きな⾔語でどうぞ
    l 今回の check-log は公式提供しているもので、簡単に利⽤可能です

    View Slide

  23. 23
    プラグイン利⽤例2) Webサーバーに対するリクエスト数などの状況の監視
    Ø 同じくプラグインを利⽤することで対応可能。
    Ø “mackerel-plugin-nginx” も、単体で実⾏可能なコマンド!
    # mackerel-agent.conf
    [plugin.metrics.nginx]
    command = "mackerel-plugin-nginx"

    View Slide

  24. 24
    プラグイン利⽤例1)アプリケーションログに出⼒されるエラーログの監視
    l 監視の結果を特定フォーマットでの標準出⼒として返却している
    Ø メトリック名・メトリック値・タイムスタンプ(unixtime)をタブ区切りで
    l 「監視対象のメトリックを取得するための処理をして、その結果を所定の
    フォーマットで標準出⼒する」プログラムでありさえすれば、メトリックを
    追加で取得・送信するためのプラグインとして利⽤可能!
    l mackerel-plugin-nginx も公式提供しているもので、簡単に利⽤可能です

    View Slide

  25. 25
    (少し脱線)今回の nginx 監視はどのように実現されているのか?
    l “ngx_http_stub_status_module” というモジュールを nginx に対して
    設定することで、nginx からのメトリックの取得を可能にしています
    nginx.conf

    View Slide

  26. 26
    (少し脱線)今回の nginx 監視はどのように実現されているのか?
    Ø モジュールを nginx に対して設定することで、nginx の内部状態が観測できるよう
    になったわけです
    ü HTTPを話す⼝を開ける
    ü パース可能なフォーマットでの HTTP レスポンス
    Ø Observability(可観測性)
    ü 「システムの内部状態が取得できる状態」
    ü 観測するためには、観測可能にする必要がある(可観測性は監視の前提となる)
    ü ⾃社サービス、アプリケーションを開発する際に、Observability を考慮した開発が
    できること、というのは重要なスキルのひとつだと思います

    View Slide

  27. 27
    ͍ΖΜͳ؂ࢹ͕Ͱ͖Δ͜ͱ͸Θ͔ͬͨ

    View Slide

  28. 28
    ؂ࢹͷ݁Ռͱͯ͠ͷΞϥʔτͷ௨஌ɺ
    ͦͷରॲʹ͍ͭͯ͸Ͳ͏ͳͷʁ

    View Slide

  29. 29
    アラートの通知
    Ø メール通知をはじめとして、
    様々な通知インテグレーション
    に対応しています

    View Slide

  30. 30
    アラートの通知
    Ø インテグレーションとして対応していない通知先であっても、汎⽤的なWebhook リクエス
    トを任意の送信先に送信することができるので、これで対応が可能
    https://blog.a-know.me/entry/2018/06/03/211757

    View Slide

  31. 31
    障害対応の⾃動化 ①
    l これも Webhook リクエスト送信機能が利⽤可能。例えば......
    1. Mackerel で検知した障害を Webhook 連携で API Gateway にリクエスト
    2. API Gateway から任意の Lambda を起動
    3. コード化された、おこないたいオペレーションを Lambda で実⾏
    • インスタンスの強制再起動をするとか
    • 発⽣した障害種類を判定して、種類に応じた担当者呼び出しを実⾏するとか

    View Slide

  32. 32
    障害対応の⾃動化 ②
    l 実は、チェックプラグインを利⽤する場合には `action` オプションが利⽤可能
    https://mackerel.io/ja/blog/entry/weekly/20171027

    View Slide

  33. 33
    障害対応の⾃動化 ②
    l `action` オプションを⽤いることで、例えば「プロセスの死活監視をおこない、プロセスの
    ダウンが検知されたらすかさずプロセス再起動コマンドをエージェントに実⾏させる」……
    といったことも可能に。
    l チェック監視処理⾃体の実⾏結果は各種環境変数にセットされており、actionコマンドでも
    参照可能

    View Slide

  34. 34
    【応⽤】action を使ってログ出⼒を Mackerel に連携する

    View Slide

  35. 35
    【応⽤】action を使ってログ出⼒を Mackerel に連携する
    l アプリケーションログに対するチェック監視の `action` として、検出ログ出⼒⾏をグラフに
    プロットさせてみる例です。
    Ø グラフへのプロットは、元々存在する “グラフアノテーション” 機能を利⽤。
    Ø アノテーションの投稿は、公式コマンドラインツール・mkr を利⽤しての API 経由。
    # mackerel-agent.conf
    [plugin.checks.applog]
    command = ["check-log", "--file", "/var/www/app/log/production.log", "--pattern", "failed", "--return"]
    action = { command = "bash -c '[ ¥"$MACKEREL_STATUS¥" != ¥"OK¥" ]' && mkr annotations create --service
    hoge-service --role fuga-role --from `date +%s` --to `date +%s` --title plugin.checks.applog --
    description ¥"$MACKEREL_CHECK_MESSAGE¥"" }
    https://blog.a-know.me/entry/2019/10/25/181245
    ˞Ұ෦όοΫεϥογϡ͕ l=zʹͳ͍ͬͯΔͷͰ͝஫ҙ͍ͩ͘͞

    View Slide

  36. 36
    “mkr” もまた、ソフトウェアの梃⼦
    l GUI や API からおこなえる操作を、簡単なコマンドを発⾏することでもおこなえるように
    しているツールです
    l 内部的には Web API をリクエストしています
    l `mkr hosts` でホストの⼀覧取得、`mkr monitors` で監視ルールの⼀覧取得、`mkr status`
    でホストステータスの変更......などなど、様々なことがおこなえる
    l 中には、mkr でしかおこなえない便利なものも。

    View Slide

  37. 37
    “mkr wrap” でバッチ処理の成否を監視する
    l `mkr wrap -- /path/to/your-batch ...`
    l 上記のようにして本来実⾏したいコマンド( your-batch )を実⾏すると、コマンドが失敗
    (⾮ゼロで終了)した場合に、Mackerel上でアラートを発⽣させることができます
    l ダブルダッシュ以降のコマンドの終了ステータスをもとに、チェック監視結果投稿API
    をリクエストしています

    View Slide

  38. 38
    ʜʜͱɺ͍͏Α͏ͳײ͡Ͱ͢
    ʢ͓ർΕ͞·Ͱͨ͠ʣ

    View Slide

  39. 39
    まとめ
    l Mackerel の持つ “ソフトウェアの梃⼦” について、いくつかご紹介しました
    • プラグイン
    • Web API
    • Webhook
    • チェック監視の `action`
    • コマンドラインツール
    l ひとつひとつの仕組みはシンプルでありながら、それぞれを汎⽤的なものにして利⽤しやすい
    仕組みにしておくことで、あれこれと組み合わせしやすくなっていること・その組み合わせ
    次第で様々なことを柔軟に、効果的に実現できること......がおわかりいただけたかと思います

    View Slide

  40. 40
    まとめ
    l コードを書く、ということは極めて創造的な活動であり、思い通りのプログラムが
    できたらとても楽しいと思います
    l それと同じく、いくつかのコード(モジュールやライブラリなども含む)を組み合
    わせて⼤きな結果を出す、その組み合わせ⽅を考えるということにも、創意⼯夫や
    アイデアを凝らすことのできる、とてもクリエイティブな作業(=楽しい!)だと
    感じています
    l 様々な仕組みを理解・把握した上で使いこなす、という楽しさもありますね!

    View Slide

  41. 41
    まとめ
    l 「Mackerel」「サーバーの監視」「オペレーションの⾃動化」といったテーマで、「あれは
    できないだろうか」「こうするにはどうすればいいだろうか」とワクワクしてみませんか?

    View Slide

  42. 42
    最後に【PR】
    l 今回紹介したほかにも、 Mackerel は様々な監視・便利で先進的な機能を有しています
    Ø 任意のグラフ、数値を⾃由に配置可能なカスタムダッシュボード
    Ø ECS、k8s などの監視が可能な専⽤エージェント、mackerel-container-agent
    Ø 機械学習アルゴリズムによりサーバーの異変を検知できる、ロール内異常検知機能
    l 監視対象としてサーバー1台、⽉々約1800円から利⽤可能です
    l 岡⼭・岡⼭近隣の⽅・関⻄以⻄のお客さまで Mackerel に興味がある、という⽅は
    ぜひお気軽にご連絡・お声がけください!
    Ø できる限り直接ご訪問の上、より詳しくご紹介させていただきます!
    Ø [email protected]

    View Slide

  43. 43

    View Slide