Slide 1

Slide 1 text

1 “ソフトウェアの梃⼦” と 〜 柔軟でワクワクするサーバー監視を⼿に⼊れる 株式会社はてな 井上 ⼤輔(id:a-know )

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

4

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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) ②

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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"]

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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ʹͳ͍ͬͯΔͷͰ͝஫ҙ͍ͩ͘͞

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

43