Splunk Observability Cloudでサービス/プロセス監視
はじめに
アプリケーションの監視どうしましょうか？と言う問いに「APM使いましょう！」と即答できる方はオブザーバビリティ力が高いです。是非そうしましょう。
・・・とは言っても色々な事情で難しいこともあり、代替手段としてサービス監視、プロセス監視という昔ながらの方法を取ることも多いです。
じゃあSplunk Observability Cloudのような、今どきのオブザーバビリティプラットフォームでできるのか、と言うことで試してみました。
結果として問題なくできることが分かりました。
テスト環境・ターゲット
-
OS
Linux (Ubuntu 22.04) とWindows (Windows Server 2022) -
対象サービス/プロセス
Nginx
※本来であればJavaであったりアプリのプロセス複数になると思います -
サービス監視
サービスのステータスがActiveであること -
プロセス監視
稼働プロセス数がx以上であること
事前準備
- それぞれのOSにSplunk Distributed OpenTelemetry Collectorをインストール
- 適当にNginxをインストール
サービス監視
LinuxとWindowsで使用するReceiverが異なりますのでそれぞれ見ていきます。
Linux
Otel設定
これでsystemdのステータスを監視できます。
receivers:
smartagent/systemd:
type: collectd/systemd
services:
- nginx
service:
pipelines:
metrics:
receivers: [<既存のreceiver>, smartagent/systemd]
Otelを再起動して有効化。
sudo systemctl restart splunk-otel-collector
IMで確認
メトリクス名はgauge.substate.runningです。
ちゃんと取れてますね。
ValueについてはStatusがactive (running)の場合は1、その他の場合は0になりますので、Detectorでアラートを仕込むときはStatic Thresholdで1未満を指定すればよいでしょう。
Windows
Otel設定
これでWindows Serviceのステータスを監視できます。
receivers:
smartagent/win_services:
type: telegraf/win_services
serviceNames:
- nginx
service:
pipelines:
metrics:
receivers: [<既存のreceiver>, smartagent/win_services]
Otelを再起動して有効化。
Stop-Service splunk-otel-collector
Start-Service splunk-otel-collector
IMで確認
メトリクス名はwin_services.stateです。
取れてます。
Valueについては以下の通りです。
The state of the windows service. Possible values are: 1 (Stopped), 2 (Start Pending), 3 (Stop Pending), 4 (Running), 5 (Continue Pending), 6 (Pause Pending), and 7 (Paused).
4が稼働中のステータスなので、DetectorではStatic Thresholdを使い、Alert when=Out Of Range、Lower threshold=4、Upper threshold=4にしてあげれば4から外れるとアラートしてくれます。
プロセス監視
プロセス監視についてはLinux、Windowsで共通です。
プロセス起動数を直接取得することはできませんが、子プロセス含めた各プロセスのリソース状況（CPUなど）が取得できます。
その情報をもとにプロセスがいくつかあるかカウントして監視すれば良いということになります。
Otel設定
Host metrics receiverのprocessを使用します。
Splunk Otelの場合はデフォルトでコメントアウトされています。
コメントアウトを外して有効化しましょう。
receivers:
hostmetrics:
process:
include:
names:
- nginx
match_type: regexp
# pipelineにはhostmetricsはデフォルトで設定されているため変更不要
IMで確認
メトリクス名はprocess.cpu.timeです。
まず取得した値を確認すると、LinuxとWindowsでそれぞれ複数のnginxプロセスが確認できます。
プロセス数をまとめましょう。
簡単にはCount by process.executable.name, host.nameにすると、プロセス名、ホスト名ごとのカウントが取れます。
DetectorではStatic ThresholdでAlert when=Below、Threshold=<稼働していてほしいプロセス数>にすることで監視ができます。
※メトリクスには複数ホストが存在していても大丈夫です。その中で閾値を下回ったホストに関してのみアラートが発報されます。
Metrics Pipeline Managementによるバックエンド側でのフィルタリング
上記ではOtelの設定でプロセス名を指定していました。
もちろんこれでもいいですが、もし配布対象ホストが多数であったり、監視対象プロセスが変わるときに各Otelの設定をすぐに変えるのが難しいと言う場合は、Metrics Pipeline Managementという機能が便利です。
メトリクスについてフィルタをかけたりDimensionを削減することができ、処理済みのデータに対してカスタムメトリクス数がカウントされます。
そのため、Otelではフィルタせずにプロセスデータを全量送り、その中で監視に必要なデータのみを絞り込むということができます。
receivers:
hostmetrics:
process:
Settings > Metrics pipeline management > Create new rulesからルールを作ります。
こんな感じです。
プロセス名でフィルタして、Dimensionはすべての残し（不要なものを落とすのもできます）、process.cpu.time.filteredという新しいメトリクス名で出力します。
元のprocess.cpu.timeはドロップします。
そうすると、もともと1,612件だったカスタムメトリクスが21件まで落とせました。
process関係のメトリクスは他にもあるので同様に設定します。
- process.cpu.time
- process.memory.physical_usage
- process.memory.virtual_usage
- process.cpu_time_seconds
- process.disk.io
まとめ
Splunk Observability Cloudでサービス監視、プロセス監視について試してみました。
APMを使えないにせよ、プロセスの生き死にだけじゃなくてメトリクス（jmxとかMWだと今回のようなNginxとか）も取っていきたいところですね。
Discussion