こんにちは！ m.uriuです。
今回は統合モニタリング・エージェント（Unified Monitoring Agent、以降UMA)の正常性やログ送信の状態を確認できる、操作メトリックの紹介と運用についてのお話です。
はじめに
UMAとは、コンピュートインスタンスなどにインストールするログ収集エージェントソフトウェアで、サーバ上のログをOracleCloudのカスタム・ログへ送信します。
また、OracleCloudのエージェント構成というリソースでUMAを制御し、
「どのホストのログを収集するか」「どこのパスのログを収集するか」「どこのログ/ログ・グループにログを送信するか」等を設定します。
このUMAですが、エージェント構成の作成時に、操作メトリックを生成するオプションを有効にして、UMAの生存確認などのメトリックを生成できます。
メトリックなので、モニタリングサービスでアラームを設定し、UMAの死活監視も可能です。
※操作メトリックはカスタム・メトリックとして生成されるので、無料枠（5億データ・ポイント/月）を超えた場合は課金が発生する点に注意。
https://speakerdeck.com/oracle4engineer/oracle-cloud-observability-and-management-platformgai-yao?slide=20
運用監視で、カスタム・ログを経由したログファイルの監視を行う際、ログを収集するUMAの監視も、OracleCloudの機能だけで実現できます。
操作メトリックの設定
操作メトリックの有効化の手順です。
操作メトリックの有効化は、エージェント構成の設定画面から行います。
エージェント構成を新規作成した場合や、既存のエージェント構成の編集画面からでも設定は可能です。
まず「ロギング・エージェントの操作メトリック」を有効化します。
生成の宛先が表示されるので「ネームスペース」「リソース・グループ」に任意の値を入力します。
リソースグループは、値を指定しなければ自動的に「defaultGroup」になります。
有効化する操作メトリックを選択して有効化します。※Heatbeatは無効化できない。
メトリックの詳細については、こちらを参照してください。
有効化する操作メトリックを決めたら、エージェント構成の作成/編集の保存をして設定を反映します。
操作メトリックを有効化し、カスタム・ログの収集とUMAの起動が始まれば、メトリック・エクスプローラ等で操作メトリックを確認できるようになります。
操作メトリックの種類
操作メトリックは7つあり、この中から任意のメトリックを有効化できます。
| メトリック | メトリックの値 |
| Heartbeat（ハートビート） | UMA稼働中で1、停止中で0を出力 ※無効化不可 |
| RestartMetric（メトリックの再開） | UMA起動/再起動で1を出力 |
| EmitRecords（レコードの発行） | UMA起動以降に送信したログの行数 ※UMA停止/再起動で値はリセットされる |
| BufferSpaceAvailable （使用可能なバッファ領域） | 使用可能なバッファ領域の割合（％） |
| SlowFlushCount（低速フラッシュ数） | 低速フラッシュ（ログ転送の遅延）が発生した合計数 |
| RollbackCount（ロールバック数） | UMAがトランザクションをロールバックした回数 |
| RetryCount（再試行数） | 障害発生等でUMAがデータ送信失敗に失敗し、再試行した回数 |
バッファ領域の容量やデータ送信再試行の設定は、UMAのConfファイル「fluentd.conf」の <buffer tag> セクション等に記載されているので、そちらを確認してみてください。
# more /etc/unified-monitoring-agent/conf.d/fluentd_config/fluentd.conf
==========================================================================
<buffer tag>
@type file
path /opt/unified-monitoring-agent/run/buffer/
retry_timeout 3h
disable_chunk_backup true
chunk_limit_size 5m
flush_thread_burst_interval 5s
retry_forever false
flush_interval 30s
total_limit_size 100MB
overflow_action drop_oldest_chunk
retry_type exponential_backoff
</buffer>操作メトリックの運用方法について
操作メトリックで何が可視化できるのか分かったところで、各メトリックをどう使うのが良いか、「アラーム向き」「情報収集向き」といった視点で（私個人の意見ですが）考えてみました。
「Heartbeat」はUMAの死活監視になるので、アラームに使えそうです。
「EmitRecords」は、取得するログの種類によって評価が変わりそうです。
このメトリックは、UMAが起動して以降に送信されたログの件数を記録し、サーバ停止や再起動を行うまで無尽蔵に値が増え続けます。
一日一回再起動するバッチ処理が組まれているサーバで、通常時で一日に出力されるログ数が分かっているのであれば、異常なログ出力数を検知する用途には使えそうです。
情報収集としては、ログが送信できているのか確認するのには使えそうですが、ロギングで事足りるので、要らないかもしれません。
他のメトリックですが、直接アラームと紐づけるよりは、有効化して常にメトリックを取得し続け、UMAが原因の障害が起きた際の情報源として活用するのが向いていそうです。
さいごに
UMAの操作メトリックと運用についての話でした。
カスタム・ログでサーバからログをOraclecloudに送信する、UMAの死活監視やログ転送の状態確認をOracleCloud内部のサービスだけで行えるのは、運用監視を簡略化する上でもいい機能だと思いました。
ただ、直接アラームに組み込めるメトリックが少ないので、（EmitRecordは使いずらいので）ログ転送が行われたときに記録するメトリックが欲しいなとも思いました。
障害発生時の情報収集で役に立つメトリックは多いので、アラームで使わずとも、操作メトリックの有効化は検討しても良いでしょう。