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

Dffbff07156358d0b83f728a3b3b0b8c?s=47 Daisuke Inoue
November 02, 2019

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

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

Dffbff07156358d0b83f728a3b3b0b8c?s=128

Daisuke Inoue

November 02, 2019
Tweet

Transcript

  1. 2.

    2 ⾃⼰紹介 ⽒名:井上 ⼤輔(a-know / @a_know) 所属:株式会社はてな Mackerelチーム 職種:CRE(Customer Reliability

    Engineer) 主な業務 l テクニカルサポート l テクニカルコミュニケート l カスタマーサクセス推進 l プロダクト改善への貢献 • VoC(Voice of Customer)の吟味・検討・提案 l セールス
  2. 3.

    3 ⾃⼰紹介 略歴 l 2006年 〜 2016年 l システムエンジニア・Webアプリケーションエンジニア 等の肩書きで、システム・アプリケーション開発に従事

    l 2016年 〜 l 株式会社はてな にセールスエンジニアとして⼊社 l 2017年より CRE に改称 l 岡⼭県出⾝です l 2012年〜2019年6⽉まで東京に l 今年7⽉から岡⼭県倉敷市へ・リモート勤務 l 趣味 l Webサービスの個⼈開発
  3. 4.

    4

  4. 6.

    6 サーバー監視の重要性 l 1⼈あたり1台以上のスマートフォン端末が普及している時代 Ø 様々な機能、サービスがサーバーから提供されることも当たり前に。 Ø サーバーの安定稼働を維持することの重要性が増している l 提供サービスの改善についても、早さや確実性がより求められるように。

    Ø プログラムが壊れないように・壊れてもすぐに気がつけるようにテストを 常に実⾏するのと同じく…… Ø サーバーに対して怖がることなくデプロイ、設定変更をしていくために、 という意味でも、サーバー監視は重要なものに。
  5. 9.

    9 ソフトウェアの梃⼦ l『UNIXという考え⽅』という本の中での表現 (Mike Gancarz 著・芳尾 桂 監訳(オーム社、2001年)) Ø “よいプログラマはよいコードを書く。偉⼤なプログラマはよいコードを借りてくる”

    Ø “⼩さなプログラムをいくつもつなぎ合わせるコツを⼼得る” Ø “コードを他者が梃⼦として使うのを認める” Ø “すべてを⾃動化する” l 私の好きな考え⽅のひとつです
  6. 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) ②
  7. 18.

    18 l Assume Role などで Mackerel に対して Cloud Watch API

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

    19 mackerel-agent で監視ができる項⽬について l エージェント単体で監視ができる項⽬は以下の6項⽬。 • ロードアベレージ • CPU使⽤率 •

    メモリ使⽤量 • ディスクIOPS • ネットワークインターフェース I/O • ディスク使⽤量 l Q. それ以外にも監視したい項⽬がある場合はどうする? • 例1)アプリケーションログに出⼒されるエラーログの監視がしたい! • 例2)Webサーバーに対するリクエスト数などの状況の監視がしたい!
  9. 22.

    22 プラグイン利⽤例1)アプリケーションログに出⼒されるエラーログの監視 l 監視の結果をコマンドの終了ステータスで返却している Ø 0 : OK Ø 1

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

    26 (少し脱線)今回の nginx 監視はどのように実現されているのか? Ø モジュールを nginx に対して設定することで、nginx の内部状態が観測できるよう になったわけです

    ü HTTPを話す⼝を開ける ü パース可能なフォーマットでの HTTP レスポンス Ø Observability(可観測性) ü 「システムの内部状態が取得できる状態」 ü 観測するためには、観測可能にする必要がある(可観測性は監視の前提となる) ü ⾃社サービス、アプリケーションを開発する際に、Observability を考慮した開発が できること、というのは重要なスキルのひとつだと思います
  11. 31.

    31 障害対応の⾃動化 ① l これも Webhook リクエスト送信機能が利⽤可能。例えば...... 1. Mackerel で検知した障害を

    Webhook 連携で API Gateway にリクエスト 2. API Gateway から任意の Lambda を起動 3. コード化された、おこないたいオペレーションを Lambda で実⾏ • インスタンスの強制再起動をするとか • 発⽣した障害種類を判定して、種類に応じた担当者呼び出しを実⾏するとか
  12. 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ʹͳ͍ͬͯΔͷͰ͝஫ҙ͍ͩ͘͞
  13. 36.

    36 “mkr” もまた、ソフトウェアの梃⼦ l GUI や API からおこなえる操作を、簡単なコマンドを発⾏することでもおこなえるように しているツールです l

    内部的には Web API をリクエストしています l `mkr hosts` でホストの⼀覧取得、`mkr monitors` で監視ルールの⼀覧取得、`mkr status` でホストステータスの変更......などなど、様々なことがおこなえる l 中には、mkr でしかおこなえない便利なものも。
  14. 37.

    37 “mkr wrap” でバッチ処理の成否を監視する l `mkr wrap -- /path/to/your-batch ...`

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

    39 まとめ l Mackerel の持つ “ソフトウェアの梃⼦” について、いくつかご紹介しました • プラグイン •

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

    42 最後に【PR】 l 今回紹介したほかにも、 Mackerel は様々な監視・便利で先進的な機能を有しています Ø 任意のグラフ、数値を⾃由に配置可能なカスタムダッシュボード Ø ECS、k8s

    などの監視が可能な専⽤エージェント、mackerel-container-agent Ø 機械学習アルゴリズムによりサーバーの異変を検知できる、ロール内異常検知機能 l 監視対象としてサーバー1台、⽉々約1800円から利⽤可能です l 岡⼭・岡⼭近隣の⽅・関⻄以⻄のお客さまで Mackerel に興味がある、という⽅は ぜひお気軽にご連絡・お声がけください! Ø できる限り直接ご訪問の上、より詳しくご紹介させていただきます! Ø a-know@hatena.ne.jp
  17. 43.

    43