次世代Mackerelの アーキテクチャ / Mackerel Meetup #14 Next Generation Architecture

Transcript

1. 次世代Mackerelの アーキテクチャ id:onk 2023-07-11 Mackerel Meetup #14 Tokyo 1

2. 自己紹介 • 大仲 能史 a.k.a. id:onk • 株式会社はてな ◦ Mackerel開発チーム

   ◦ エンジニアリングマネージャー ◦ 今日は京都から来ました 2

3. 3 今日の話

4. 4 次世代Mackerelの アーキテクチャ

5. 5 次世代 #とは

6. 6 今のメトリック投稿

7. メトリック投稿 7 https://mackerel.io/ja/docs/entry/advanced/custom-metrics

8. メトリック投稿 • GraphiteのCarbon Plaintextに似ている ◦ <metric name>\t<metric value>\t<epoch> • データをかき集める

   ◦ pluginを実装する • 投稿する ◦ pluginがHTTPでCarbon形式で投げる 8

9. メトリック投稿 9 • 我々もpluginを作っているし、競合他社も pluginを作っている ◦ https://github.com/mackerelio/mackerel-agent- plugins • 例えばホストメトリックではそれぞれ

   /proc/meminfoをパースしている

10. メトリック投稿 • 集めるところは共通化されていない • 投げるところも共通化されていない 10

11. 11 メトリックのメタデータ

12. メトリックのメタデータ • ホスト単位のメトリックは扱いづらい ◦ ホストはデプロイのたびに切り替わるようになった • 理想のダッシュボードには式グラフが必須 ◦ role()はともかく、host()はメンテが非常に難しい 12

13. メトリックのメタデータ • ホスト以外の絞り込みもしたい • 例えばアクセスログ 13

14. メトリックのメタデータ • 特定のステータスコードのリクエスト数 ◦ これは今でも取れている • AZごと＆ステータスコードごと ◦ ホストのメタデータに含まれているのでやればできる •

    PATHごと＆ステータスコードごと ◦ これは今のMackerelではまず無理な例 ◦ メトリック名に詰め込んで頑張ればできる……？ 14

15. 15 メトリックのメタデータ

16. メトリックのメタデータ • 投げるときにメタデータ付きで投げておいて 16 access_num;status=200;path=/api 53 1689025057 access_num;status=200;path=/ 70 1689025057

    access_num;status=503;path=/api 20 1689025057 access_num;status=401;path=/api 1 1689025057

17. メトリックのメタデータ • 引くときに自由に絞り込みたい • Observabilityの文脈 ◦ アプリケーションの状態を、出力から推定したい 17 seriesByTag('name=access_num', 'status=200')

18. 余談：Observability(可観測性) • システムの現在の状態を出力 から推定できる特性 ◦ 初見の状態に対しても調査可能 ▪ 現代の複雑なシステムは、毎回原因が 違う不具合が発生する ◦

    デプロイすることなく対応できる 18

19. 19 OpenTelemetry

20. OpenTelemetry • ざっくり言うと「テレメトリーの取り方を標 準化してみんなで使えるものを作ろうぜ」 • CNCF Incubating Project ◦ コンテナ技術の推進と、その進化を取り巻くテクノロ

    ジー業界の足並みを揃えるために2015年に創設され た財団である。 20 https://ja.wikipedia.org/wiki/Cloud_Native_Computing_Foundation

21. OpenTelemetry • otel-collectorに投げておくと、任意の exporterに出力できる • fluentdのような仕組み（ざっくり) 21 https://opentelemetry.io/docs/collector/

22. OpenTelemetry • アプリケーションがログやメトリックを出す ならOTelが標準になるだろう ◦ アプリはどのベンダーの形式で出すか考えなくて良い ◦ ベンダーはプラグインを作る必要がなくなる • メトリックのメタデータも対応している

    22

23. 23 対応中です

24. OpenTelemetry対応(writer) • エンドポイントはOTLPで受け付ける • メタデータ付きのメトリックを取る ◦ 次元数が変わる • 実装 ◦

    メタデータも含めてhash化してTSDBのkeyにする 24

25. OpenTelemetry対応(reader) • ラベルで引く ◦ access_num{status=200} ▪ access_num;status=200;path=/ ▪ access_num;status=200;path=/api •

    ラベル→メトリックの転置インデックス 25

26. OpenTelemetry対応(reader) • ラベル付きメトリックを自在に引くための PromQL Engineを実装した ◦ 算術演算、集合演算、集計演算、比較演算、関数、... 26

27. OpenTelemetry対応(graph) 27 • 補完機能付きクエリエディタ • 凡例表示の工夫 • 開発中の画面 ◦ https://mackerel.io/ja/blog/entry/meetup14-1

28. 28 まとめ

29. まとめ • 現代ではメトリックのメタデータが必要 • OpenTelemetryでプラグイン競争が終わる • メタデータ対応を実装した ◦ 転置インデックスと新たなEngineが必要になるのが大 きな違い

    29

30. まとめ • 今後のMackerelはマルチディメンジョン ◦ 任意の次元で引ける新しいダッシュボードが主役 • OpenTelemetry＝入力データは競合間で同じ ◦ いかに見やすく、使いやすくするかの勝負 ◦

    チームで取り組むためのベストプラクティスを提供す るプロダクトとして、引き続き開発していきます 30