この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、坂巻です。
先日開催されたMackerel Meetup #13に関するレポートをお伝えします。
本イベントの前半は、Mackerelチームからのセッション、後半はユーザセッションという構成でした。こちらのエントリではMackerelチームからのセッションをレポートします。
Mackerel 2019
登壇者 : Mackerel 株式会社はてな プロダクトマネージャー 松木 雅幸 様
概要
Mackerelの2018年の振り返り及び2019年の展望、特にコンテナ運用周りの戦略についてお話します。
スライド
レポート
スライドに記載していない内容を中心にしたレポートになります。
アンバサダープログラム
- アンバサダープログラムはじめました
- 就任頂きたい方はまだいる
- 選定基準は非公開ではあるが、これまでMeetupに登壇した方や、OSSにプルリクしてくれた方を中心に選定中
最近のちょっといいアップデート
- mkr wrapによるcron/バッチ監視機能追加による喜びの声が多い
- Microsoft Teamsへ通知ができるようになった（多くの要望があり開発に至った）
- 要望ベースで開発に至ることがあるのでフィードバック求む
- AWSインテグレーション強化
- 直近では6つ増やした。外部の開発パートナー等へ依頼し、開発を加速させている
昨年のロードマップ
- アラートグループ
- アラートをまとめていい感じにグルーピング。時系列みえて便利だから利用お勧め
- カスタムダッシュボードリニューアル
- 前はマークダウンが書けるだけの素朴なものだったが、GUIでウィジェットを動かせる
- ウィジェットはまだ少ないので、要望求む
- コンテナサポート
- 昨年中にはだせなかったが、2/18にリリース
- 異常検知
- 昨年の12月にリリースを予定していたが、紆余曲折あり本日(3/1)リリース
今年のMackerel
ロール内異常検知
- 現状はmackerel-agentが入っているLinux環境のみサポート
- 設定は簡単でロールとsensitivity(感度)を設定するだけ
- 詳細は、前回のMeetupの資料に記載
- 前回のMeetupで話した内容から変更した箇所は、異常の根拠提示
- 以前は「このホストおかしそう？」といったテキストだった
- 普段と最も動きが異なるメトリックグラフを表示させアラートも発生させた
コンテナシフト
- 今年は本格的にコンテナに対応していく予定
- パブリックベーダ版だけど、ソースコード公開している
- コンテナの波及が進むと考えていて、開発運用のベストプラクティスをMackerelとしても処理していく予定
- mackerel-agentにはキャラクターがいる
- mackerel-agentをキャラクター化したエージェント氏
- mackerel-container-agentもキャラクターを作りたい
- Mackerelチームのデザイナーがコンペ中
Mackerelコンテナエージェントによるコンテナ監視について
登壇者 : Mackerel 株式会社はてな SRE 今井 隼人 様
概要
現在開発中のMackerelコンテナエージェントの仕様・特徴をご紹介し、その設計や実装を解説します。
スライド
レポート
スライドに記載していない内容を中心にしたレポートになります。
OSSとして公開
- DockerHub
- GitHub
- 開発はGitHub上のリポジトリで実施
- Mackerelユーザグループでslackチャンネルがある
- Mackerelチームも頻繁に確認しているから、そこで議論してからIssuesを送るでもよい
コンテナ専用の軽量エージェント
- コンテナ専用として再設計
- 現行のmackerel-agentにコンテナの機能を追加したものではない
- 監視対象はECSのタスク、KubernetesのPod
- 請求時のホスト台数は過去一ヶ月分の移動平均から算出
サイドカーコンテナとしてデプロイ
- プラットフォームによってデプロイ方法が異なり、3つのパターンがある
- ECS（EC2/Bridge、EC2/Host）
- ECS（EC2/awsvpc、Fargate）
- Kubernetes
- コンテナを監視するに詳細の記載あり
- デプロイ方法はコンテナエージェントのDockerイメージと、いくつかの環境変数を設定
- プラットフォームによっては、Data Volumeの設定も必要
Web UI/ホスト一覧
- 現在のMackerel UIでは、タスクやpodは通常のホストとして扱う
- ホスト一覧画面でも通常のホストと混在して表示
- ホスト名はタスクではARNのリソース名、PodではPod名となる
メトリック取得戦略解説
- コンテナエージェントのメトリック取得アーキテクチャ
- サイドカーとして配置したコンテンナエージェントが、プラットフォームが提供するAPIや、タスクやPodに同居するアプリケーションコンテナからメトリックを収集
ECS/Bridgeのネットワークスタック
- Bridgeではタスクのコンテナ毎に独立したネットワークスタックをもつ
- コンテナエージェントから他のコンテナのネットワークメトリックを取得するのがAPI以外の方法だと難しい
ECS/Hostのネットワークスタック
- タスクが乗っているホストのネットワークを、タスクのコンテナ間で共有
EC2/awsvpc,Fargateネットワークスタック
- pauseコンテナを中心にタスクのコンテナ間でネットワークを共有
- pauseコンテナについて詳しく知りたい方は懇親会で
Kubernetesのメトリック取得戦略
- cAdvisorが自身のノードのPodに含まれる各コンテナのメトリックを収集
- 収取したメトリックはkubelet APIを通して外部に公開
- Metrics Serverは全てのノードを検出して、各ノードのkubelet APIを呼び出しコンテナのメトリックを収集
- Metrics Serverは取得したメトリックをMetrics APIを通して外部に公開
さいごに
コンテナ監視の方法論が確立することで、Mackerelもコンテナも、より普及が進みそうですね。今回のセッションではところどころついていけない箇所があったので、ECS、Kubernetesをちゃんと学ばないとですね.. mackerel-container-agentのやってみた記事は既に上がっていますので、こちらも確認してみてください！
それはそうと、Meetup参加者の半数程度が「入門 監視」を購入しており、空前の監視ブームですね。
14
