こちらを参考にしてちょうど自分が困っている問題を解決できそうな見通しが立ったので紹介します。
ビルドマシンの監視とアラートをどこでやるか問題
昔はJenkins、最近ではGitHub Actionsのセルフホストランナーのためにビルドマシンを自前で用意することがあります。特にmacOSに関してはGitHub Actionsだと1分あたりの課金額がLinuxの10倍（！）になるため、GitHubがホストしているmacの代わりとしてオフィスにmac miniを用意してビルドマシンとして利用しているケースもあるのではないでしょうか。
自分で実機を用意すると意外に重要になるのがマシンの状態の監視です。特にビルドマシンの用途で長期的に重要なのはストレージ使用率です。気がついたらストレージを100%消費してしまい、ビルドができない状態になってしまうことがあります。100%になってしまうと復旧も難しく手遅れなので80%や90%の時点でSlackあたりにアラートを投げておきたいところです。
この手の監視やアラートを担当するOSSはいくらでもあるので既に自前で運用しているのであればそこに乗っかるのが簡単でしょう。ゼロから構築するのであれば自分でサーバーを運用する必要が無いDatadogのようなサービスや、AWSやGCPが提供しているマネージドなサービスの方が有力かもしれません。
GCPのCloud Monitroing用のエージェントにmacOS用が無い
自分のところではGCPで他のインフラを構築しておりビルドマシン用のLinuxもGCEで構築しています。監視したいのはビルドマシン用のGCEも同じですので、デフォルトでGCEのメトリクスを監視できるCloud MonitoringでオンプレのmacOSの監視も行わせたいと考えました。
Cloud Monitoringのドキュメントを見た感じではOpsAgentと呼ばれるものをインストールして動かすことで様々なメトリクスを送れるようなのですが、なんと対応しているOSの一覧にmacOSが存在しません！GCPはLinuxの有名なディストリビューションやWindowsは提供していますがmacOSマシンは提供していないからでしょうか・・・。
ちなみにCloudWatchやDatadogなども調べてみたのですが、これらのサービスはmacOS用のエージェントも提供しているようです。というわけで、これらのサービスを利用されている場合はここから先の本編は全く不要な話となります。
OpenTelemetry Collector
以前からOpenTelemetryの名前は聞いたことがあったもののどういうものかよく分かっていなかったのですが、こちらの記事によってOpenTelemetry Collectorでマシンのメトリクスを収集できることを知りました。これを機にOpenTelemetryについて調べてみたところ、どうやらCloud MonitoringはOpenTelemetryの出力先としてサポートされており、先の記事ではUbutnuを使用されていましたがCollector自体はmacOS板も提供されているようです。
ということは、macOS版のCollectorによってビルドマシンのメトリクスを収集し、そのデータをCloud Monitoringに送れるのではないか？と推測できます。実際に試してみたところ、以下の設定ファイルでメトリクスを送ることができました。
receivers:
hostmetrics:
collection_interval: 30s
scrapers:
# cpu: # not implemented yet errorが出てしまう
# disk: # not implemented yet errorが出てしまう
# load:
filesystem:
include_mount_points:
# dfで見る限りではこれが実際の空き容量に一番近そう
mount_points:
- /System/Volumes/Data
match_type: strict
memory:
# network:
# paging:
# processes: # Linuxのみ
# process: # Linux & Windowsのみ
processors:
# Collectorを動かしているマシンのホスト名などの情報を追加する
resourcedetection/system:
detectors: ["system"]
system:
hostname_sources: ["os"]
exporters:
logging:
verbosity: normal
file/no_rotation:
path: ./log
googlecloud:
project: YOUR_PROJECT
service:
pipelines:
metrics:
receivers: [hostmetrics]
processors: [resourcedetection/system]
# デバッグ用 Cloud Monitoringの代わりに ./log ファイルに書き出す
# exporters: [logging, file/no_rotation]
exporters: [logging, googlecloud]
mac用の opentelemetry-collector-contrib をReleasesからダウンロードしてこのyamlをconfigファイルとして起動させます。
OpenTelemetry Collectorの概念として receiver, exporter, processor を組み合わせてデータ取得、加工、出力の一連の流れを構築するのですが、そのあたりの説明はそれを専門に紹介しているブログに譲りましてここでは省きます。
Host Metrics Receiverの設定だけ解説をすると、まずCPUに関しては残念ながらmacOSでは指定するとエラーになってしまうので収集を諦めています（コメントアウト）。メモリは問題ないようですので収集しておきます。
ストレージ情報は filesystem が担当しているのですがデフォルトでは df で見える全ての情報を収集してそうです。正直macOSのファイルシステムに明るくないので各マウントポイントの意味を分かっていないのですが、容量の大きさとパスのそれっぽさから /System/Volumes/Data だけを収集するようにしてみました。
その他のメトリクスにはLinuxやWindowsしか対応できていないものがあるようですが、データが増えるほどCloud Monitoringの課金額が増えてしまうので本当に必要なもの以外は収集しないようにコメントアウトしています。
exporterのloggingやfileで実際にメトリクスを収集できていることを確認できたらgooglecloudも追加してCloud Monitoringにデータを送信します。GCEやGKEなどのGCP以外の環境では gcloud の認証が必要になりますので、ドキュメントを参照してCollectorを動かすマシンで認証を済ましておきましょう。
Cloud Monitoring
Collectorのログ上でエラーが出ていなければCloud MonitoringのUser-defined Metricsとしてデータが送れているはずです。執筆時点ではGCPコンソール画面のMonitoring > Metrics explorer > DIAGNOSTICS の画面から確認できます。またはEXPLORERのメトリクス検索で Generic Node > SystemにOpenTelemetryで送信している以下3つが登録されていることが確認できます。
- system.filesystem.inodes.usage
- system.filesystem.usage
- system.memory.usage
あとはこれらのメトリクスを見るためのダッシュボードを組んだり、アラートを組むことができるはずです。自分もまだ実験的にデータを送ったところまでしかできていないのですが、最終的にはダッシュボードやアラートをTerraformで管理できるようにして同様の構成をシュッと使い回せるようにしていきたいと思っています。
Discussion