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

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

Transcript

1. 1 “ソフトウェアの梃⼦” と 〜 柔軟でワクワクするサーバー監視を⼿に⼊れる 株式会社はてな 井上 ⼤輔（id:a-know ）
2. 2 ⾃⼰紹介 ⽒名：井上 ⼤輔（a-know / @a_know） 所属：株式会社はてな Mackerelチーム 職種：CRE（Customer Reliability Engineer） 主な業務 l テクニカルサポート l テクニカルコミュニケート l カスタマーサクセス推進 l プロダクト改善への貢献 • VoC（Voice of Customer）の吟味・検討・提案 l セールス
3. 3 ⾃⼰紹介 略歴 l 2006年 〜 2016年 l システムエンジニア・Webアプリケーションエンジニア 等の肩書きで、システム・アプリケーション開発に従事 l 2016年 〜 l 株式会社はてな にセールスエンジニアとして⼊社 l 2017年より CRE に改称 l 岡⼭県出⾝です l 2012年〜2019年6⽉まで東京に l 今年7⽉から岡⼭県倉敷市へ・リモート勤務 l 趣味 l Webサービスの個⼈開発
5. 5 https://classmethod.jp/news/hatena_mackerel_dealer/
6. 6 サーバー監視の重要性 l 1⼈あたり1台以上のスマートフォン端末が普及している時代 Ø 様々な機能、サービスがサーバーから提供されることも当たり前に。 Ø サーバーの安定稼働を維持することの重要性が増している l 提供サービスの改善についても、早さや確実性がより求められるように。 Ø プログラムが壊れないように・壊れてもすぐに気がつけるようにテストを 常に実⾏するのと同じく…… Ø サーバーに対して怖がることなくデプロイ、設定変更をしていくために、 という意味でも、サーバー監視は重要なものに。
7. 7 ここでいう “サーバー監視” l 監視対象リソースの死活・負荷・リソース状況を⼀定間隔でチェックし つづけ、問題が観測されたら適切に通知をおこなうこと l 監視の結果を継続的に記録し続け、その内容をいつでも参照・閲覧可能 な状態にしておくこと
8. 8 “ソフトウェアの梃⼦（テコ）”
9. 9 ソフトウェアの梃⼦ l『UNIXという考え⽅』という本の中での表現 （Mike Gancarz 著・芳尾 桂 監訳（オーム社、2001年）） Ø “よいプログラマはよいコードを書く。偉⼤なプログラマはよいコードを借りてくる” Ø “⼩さなプログラムをいくつもつなぎ合わせるコツを⼼得る” Ø “コードを他者が梃⼦として使うのを認める” Ø “すべてを⾃動化する” l 私の好きな考え⽅のひとつです
10. 10 ソフトウェアの梃⼦ ü ü 独⾃技術や規格などではない、標準的なI/Fにより、他の仕組みとの連携を⾮常 にしやすくすること Ø 標準出⼒、終了ステータス、ASCIIフラットファイル（プレーンテキスト）、HTTP リクエスト、シェルスクリプト、 …… Ø API や Webhook なども “梃⼦” であるよなぁ、と思っています ü それらを組み合わせて使うことで、⼤きな仕事を達成できる……という考え⽅
11. 11 ソフトウェアの梃⼦ l コードを書く、ということは極めて創造的な活動。 • 思い通りのプログラムができたらとても楽しい l いくつかのコード（モジュールやライブラリなども含む）を組み合わせて⼤きな 結果を出す・その組み合わせ⽅を考えるということも、創意⼯夫やアイデアを凝 らすことのできる、とてもクリエイティブな作業（＝楽しい！）
12. 12 .BDLFSFM
    ͸ɺ lιϑτ΢ΣΞͷᑏࢠz
    Λ ඇৗʹ͏·͘׆༻͍ͯ͠Δͳʙʙɺͱ ೔ʑ࣮ײ͍ͯ͠·͢
13. 13 『Mackerel とソフトウェアの梃⼦』という観点を意識しつつ、 Mackerel で実現できる様々な “監視” をご紹介します ：テコ・ポイント
14. 14 Mackerel の監視アーキテクチャ ΤʔδΣϯτ͔Β ϝτϦοΫΛ౤ߘ （API 経由（HTTPS）） 44-ূ໌ॻͷ ༗ޮظݶ؂ࢹ ΋0,ʂ
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） ②
16. 16 ⾃動のスケールイン / スケールアウトにも対応 Ø initd / systemd によるシャットダウンをトリガーにホスト退役処理を実⾏ スケールアウト スケールイン
17. 17 Q. エージェントのインストールができない対象の場合は？ • 例えば AWS の各種マネージドサービス、サーバーレス環境の場合。 • Amazon RDS • AWS Lambda • など
18. 18 l Assume Role などで Mackerel に対して Cloud Watch API へのリクエストを 許可（移譲）。 l Mackerel が⾃動的に⼀定間隔で Cloud Watch API をリクエストし、 得た情報（メトリック）を Mackerel に対して投稿 A. 『AWSインテグレーション』を使う
19. 19 mackerel-agent で監視ができる項⽬について l エージェント単体で監視ができる項⽬は以下の6項⽬。 • ロードアベレージ • CPU使⽤率 • メモリ使⽤量 • ディスクIOPS • ネットワークインターフェース I/O • ディスク使⽤量 l Q. それ以外にも監視したい項⽬がある場合はどうする？ • 例1）アプリケーションログに出⼒されるエラーログの監視がしたい！ • 例2）Webサーバーに対するリクエスト数などの状況の監視がしたい！
20. 20 A. プラグインを使って監視できる項⽬を増やせます Ø エージェント単体では取得しないメトリック項⽬を追加で取得させられるよう にできたり、監視のための処理を追加でおこなわせることができるようになる 仕組みがあります Plugin Target ② get values ③ return values by stdout Host ④ POST by API Mackerel ① exec mackerel-agent
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"]
22. 22 プラグイン利⽤例1）アプリケーションログに出⼒されるエラーログの監視 l 監視の結果をコマンドの終了ステータスで返却している Ø 0 : OK Ø 1 : WARNING Ø 2 : CRITICAL Ø それ以外: UNKNOWN l つまり、「なんらかの監視処理をして、その結果を終了ステータスとして返す」 プログラムでありさえすれば、チェックプラグインとして利⽤可能！ l シェルスクリプト、Ruby、Java、……お好きな⾔語でどうぞ l 今回の check-log は公式提供しているもので、簡単に利⽤可能です
23. 23 プラグイン利⽤例2） Webサーバーに対するリクエスト数などの状況の監視 Ø 同じくプラグインを利⽤することで対応可能。 Ø “mackerel-plugin-nginx” も、単体で実⾏可能なコマンド！ # mackerel-agent.conf [plugin.metrics.nginx] command = "mackerel-plugin-nginx"
24. 24 プラグイン利⽤例1）アプリケーションログに出⼒されるエラーログの監視 l 監視の結果を特定フォーマットでの標準出⼒として返却している Ø メトリック名・メトリック値・タイムスタンプ（unixtime）をタブ区切りで l 「監視対象のメトリックを取得するための処理をして、その結果を所定の フォーマットで標準出⼒する」プログラムでありさえすれば、メトリックを 追加で取得・送信するためのプラグインとして利⽤可能！ l mackerel-plugin-nginx も公式提供しているもので、簡単に利⽤可能です
25. 25 （少し脱線）今回の nginx 監視はどのように実現されているのか？ l “ngx_http_stub_status_module” というモジュールを nginx に対して 設定することで、nginx からのメトリックの取得を可能にしています nginx.conf
26. 26 （少し脱線）今回の nginx 監視はどのように実現されているのか？ Ø モジュールを nginx に対して設定することで、nginx の内部状態が観測できるよう になったわけです ü HTTPを話す⼝を開ける ü パース可能なフォーマットでの HTTP レスポンス Ø Observability（可観測性） ü 「システムの内部状態が取得できる状態」 ü 観測するためには、観測可能にする必要がある（可観測性は監視の前提となる） ü ⾃社サービス、アプリケーションを開発する際に、Observability を考慮した開発が できること、というのは重要なスキルのひとつだと思います
27. 27 ͍ΖΜͳ؂ࢹ͕Ͱ͖Δ͜ͱ͸Θ͔ͬͨ
28. 28 ؂ࢹͷ݁Ռͱͯ͠ͷΞϥʔτͷ௨஌ɺ ͦͷରॲʹ͍ͭͯ͸Ͳ͏ͳͷʁ
29. 29 アラートの通知 Ø メール通知をはじめとして、 様々な通知インテグレーション に対応しています
30. 30 アラートの通知 Ø インテグレーションとして対応していない通知先であっても、汎⽤的なWebhook リクエス トを任意の送信先に送信することができるので、これで対応が可能 https://blog.a-know.me/entry/2018/06/03/211757
31. 31 障害対応の⾃動化 ① l これも Webhook リクエスト送信機能が利⽤可能。例えば...... 1. Mackerel で検知した障害を Webhook 連携で API Gateway にリクエスト 2. API Gateway から任意の Lambda を起動 3. コード化された、おこないたいオペレーションを Lambda で実⾏ • インスタンスの強制再起動をするとか • 発⽣した障害種類を判定して、種類に応じた担当者呼び出しを実⾏するとか
32. 32 障害対応の⾃動化 ② l 実は、チェックプラグインを利⽤する場合には `action` オプションが利⽤可能 https://mackerel.io/ja/blog/entry/weekly/20171027
33. 33 障害対応の⾃動化 ② l `action` オプションを⽤いることで、例えば「プロセスの死活監視をおこない、プロセスの ダウンが検知されたらすかさずプロセス再起動コマンドをエージェントに実⾏させる」…… といったことも可能に。 l チェック監視処理⾃体の実⾏結果は各種環境変数にセットされており、actionコマンドでも 参照可能
34. 34 【応⽤】action を使ってログ出⼒を Mackerel に連携する
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
    ʹͳ͍ͬͯΔͷͰ͝஫ҙ͍ͩ͘͞
36. 36 “mkr” もまた、ソフトウェアの梃⼦ l GUI や API からおこなえる操作を、簡単なコマンドを発⾏することでもおこなえるように しているツールです l 内部的には Web API をリクエストしています l `mkr hosts` でホストの⼀覧取得、`mkr monitors` で監視ルールの⼀覧取得、`mkr status` でホストステータスの変更......などなど、様々なことがおこなえる l 中には、mkr でしかおこなえない便利なものも。
37. 37 “mkr wrap” でバッチ処理の成否を監視する l `mkr wrap -- /path/to/your-batch ...` l 上記のようにして本来実⾏したいコマンド（ your-batch ）を実⾏すると、コマンドが失敗 (⾮ゼロで終了)した場合に、Mackerel上でアラートを発⽣させることができます l ダブルダッシュ以降のコマンドの終了ステータスをもとに、チェック監視結果投稿API をリクエストしています
38. 38 ʜʜͱɺ͍͏Α͏ͳײ͡Ͱ͢ ʢ͓ർΕ͞·Ͱͨ͠ʣ
39. 39 まとめ l Mackerel の持つ “ソフトウェアの梃⼦” について、いくつかご紹介しました • プラグイン • Web API • Webhook • チェック監視の `action` • コマンドラインツール l ひとつひとつの仕組みはシンプルでありながら、それぞれを汎⽤的なものにして利⽤しやすい 仕組みにしておくことで、あれこれと組み合わせしやすくなっていること・その組み合わせ 次第で様々なことを柔軟に、効果的に実現できること......がおわかりいただけたかと思います
40. 40 まとめ l コードを書く、ということは極めて創造的な活動であり、思い通りのプログラムが できたらとても楽しいと思います l それと同じく、いくつかのコード（モジュールやライブラリなども含む）を組み合 わせて⼤きな結果を出す、その組み合わせ⽅を考えるということにも、創意⼯夫や アイデアを凝らすことのできる、とてもクリエイティブな作業（＝楽しい！）だと 感じています l 様々な仕組みを理解・把握した上で使いこなす、という楽しさもありますね！
41. 41 まとめ l 「Mackerel」「サーバーの監視」「オペレーションの⾃動化」といったテーマで、「あれは できないだろうか」「こうするにはどうすればいいだろうか」とワクワクしてみませんか？
42. 42 最後に【PR】 l 今回紹介したほかにも、 Mackerel は様々な監視・便利で先進的な機能を有しています Ø 任意のグラフ、数値を⾃由に配置可能なカスタムダッシュボード Ø ECS、k8s などの監視が可能な専⽤エージェント、mackerel-container-agent Ø 機械学習アルゴリズムによりサーバーの異変を検知できる、ロール内異常検知機能 l 監視対象としてサーバー1台、⽉々約1800円から利⽤可能です l 岡⼭・岡⼭近隣の⽅・関⻄以⻄のお客さまで Mackerel に興味がある、という⽅は ぜひお気軽にご連絡・お声がけください！ Ø できる限り直接ご訪問の上、より詳しくご紹介させていただきます！ Ø a-know@hatena.ne.jp