Datadogを使ったプロセス、サービス監視の設定手順

2021-01-11Azure,Datadog,Others

Datadogを利用したプロセスやサービスの監視設定手順です。

仮想マシン(Azure VM)にDatadog Agentをインストールして、プロセスやサービスのステータスを監視することができます。
仮想マシンだけでなく、さまざまなパブリッククラウドやオンプレミス環境のリソースも監視することができます。

今回は、Datadogを使ったLinuxのプロセス監視およびWindows Serverのサービス監視設定手順を確認しています。

    • Datadog Agentで監視対象のプロセスやサービスを設定
    • Datadog Monitorsでアラートルールを作成・監視

※本記事では、Azure Virtual Machines(Azure VM)を仮想マシンとして表記しています。
※Windows Server 2022を利用して確認しています。
※Linuxには、CentOS 7を利用して確認しています。

スポンサーリンク

Datadogを使ったLinuxのプロセス監視方法

プロセスやサービスの状態取得方法は2種類

Datadogでプロセスやサービス情報を取得する方法には、プロセスとライブプロセス(Live Process)の2つがあります。
今回は、プロセスを使用した手順を紹介しています。

ライブプロセス(Live Process)を利用した手順については、こちらで紹介しています。

Datadog Agentをインストール 

OSにDatadog Agentをインストールします。
インストール手順については、こちらで紹介しています。

conf.yamlを新規作成してprocess.dを設定

conf.yaml に取得するプロセスの情報を記載します。
監視したいプロセスごとに個別に指定します。

プロセス(Datadog公式)

ファイルの作成場所は、/etc/datadog-agent/conf.d/process.d/conf.yaml です。
今回は、chrony(chronyd)を監視します。

conf.yaml作成
conf.yamlを新規作成します。

[root@test-vm-01 ~]# vi /etc/datadog-agent/conf.d/process.d/conf.yaml

nameでプロセス名を定義します。
search_stringに検索対象となるプロセスの文字列を設定します。

init_config:

instances:
– name: chronyd
search_string: ['chrony’,’chronyd’]
Datadog Agentを再起動します。

[root@test-vm-01 ~]# systemctl restart datadog-agent

Processのステータスを確認

Datadog AgentでProcessのステータスを確認します。

ステータス確認
Datadog Agentのステータスを表示します。
processのステータスがOKになっていることが確認できます。
conf.yaml が正しく読み込まれていることも確認できます。

[root@test-vm-01 ~]# datadog-agent status

プロセスを監視するアラートルールを作成

Datadog Monitorsでアラートルールを作成します。
Datadog Agentで設定したchrony(chronyd)のプロセスを監視します。

アラートルールを作成
MonitorsでProcess Checkを選択します。

Pick a Process で監視対象のプロセスを選択します。
設定したchronydを選択します。
Pick monitor scopeで監視対象の仮想マシンを選択します。
今回は、test-vm-01 を選択しています。

Set alert conditionsでアラートの基準を選択します。
Warningのアラートは 3、Criticalは 5、OK (回復))は 3 を選択しています。
これらは、連続失敗回数や連続成功回数の指定となります。

アラートの条件を設定する

※監視対象が複数台にわたる場合は、alert for eachにHostを選択します。ホスト単位での検知となります。

Notify your team で通知方法を指定します。
タイトル部分がアラートルール名になります。
今回は、chronyd Process Check Ng {{host.name}}としています。

※{{host.name}} とすることで、アラート発生時にホスト名を表示することができます。
Createでアラートルールを作成します。

作成したアラートルールを確認

作成したアラートルールを確認します。

アラートルールを確認
Managed Monitor には、アラートルールの一覧とそれぞれのステータスが表示されます。
作成したアラートルールも確認できます。
選択して、アラートルールの詳細を表示します。
ステータスの状態(履歴)も表示されます。
OKとなっており、プロセスのステータスが取得できていることが確認できます。

プロセス停止してアラートの発生を確認

監視対象のプロセス(chronyd(デーモン))を停止して、アラートが発生することを確認します。

アラートの発生を確認
chronydのプロセスを停止します。

[root@test-vm-01 ~]# systemctl stop chronyd
しばらくすると、アラートルールのステータスがALERTになります。
Status & History でもAlertとなっていることが確認できます。
chronydのプロセスを起動します。

[root@test-vm-01 ~]# systemctl start chronyd
アラートルールのステータスがOKになります。
Status & History でもOKとなっており、ALERT 状態から回復していることが確認できます。
Eventsでアラートの履歴を確認します。
[Triggered]と[Recovered]の履歴が確認できました。

※一部の画面は、別のアラート発生時のものを使用しています。

Datadogを使用したリソース監視の手順については、こちらで紹介しています。
アラート発生時のメール通知設定の手順は、こちらで紹介しています。

—広告—

Datadog Agent使ったWindows Serverのサービス監視方法

Windows Server に Datadog Agent をインストールします。
インストール手順については、こちらで紹介しています。

conf.yamlを新規作成してservicesを設定

サービス監視用の conf.yaml を作成します。
Datadog公式サイトを参考に設定を進めます。

Windows Service(Datadog公式)

サービス名は、PowerShell の Get-Service コマンドレットで確認できます。
今回は W32Time (Windows Time) を監視対象とします。

今回はDatadog Agent Managerを利用してファイル編集をしています。
ファイルを直接操作する場合は、以下のパスに新規ファイル(conf.yaml)を新規作成します。

ファイル作成場所(例)
C:\ProgramData\Datadog\conf.d\windows_service.d\conf.yaml

conf.yamlを新規作成
conf.yamlを新規作成します。

Datadog Agent ManagerのChecksを選択します。
Manage Checksで conf.yaml を作成・編集できます。
Add a Checkでファイルを追加します。
作成するディレクトリ(windows_service)内のservicesでサービス名を定義します。

設定後、Datadog Agent を再起動します。

instances:
 – services
  – W32Time
Datadog Agent ManagerでStatus を選択します。
Collectorで取得状況を確認できます。

コマンドプロンプトでDatadog Agentを再起動

コマンドプロンプトで Datadog Agent を再起動する場合は、restart-serviceとします。

C:\> cd “C:\Program Files\Datadog\Datadog Agent\embedded"
C:\Program Files\Datadog\Datadog Agent\embedded> agent.exe restart-service

Datadog Agentのステータスを確認する場合は、statusとします。

C:\Program Files\Datadog\Datadog Agent\embedded> agent.exe status

アラートルールを作成

Datadog Monitorsでアラートルールを作成します。
Datadog Agentで設定した W32Time(Windows Time)を監視します。

アラートルールを作成
MonitorsでService Checkを選択します。

Pick a Service Checkでは windows_service.state を選択します。
Pick monitor scopeで監視対象のサービス名を選択します。

※監視対象のホストを限定する場合は、Pick monitor scopeにホスト名を設定します。

Set alert conditionsでアラートの基準を選択します。
Warning のアラートは3、Criticalは5、OK(回復)は3を選択しています。
連続失敗回数や連続成功回数の指定になります。

アラートの条件を設定する

※監視対象が複数台に渡る場合は、alert for eachで Host を選択します。ホスト単位での検知になります。

Notify your teamで通知方法を指定します。
タイトル部分がアラートルール名になります。
今回は、Windows Time Ng Service {{host.name}}としています。

※{{host.name}} とすることで、アラート発生時にホスト名を表示することができます。
Createでアラートルールを作成します。

作成したアラートルール確認

作成したアラートルールを確認します。

アラートルールを確認
Managed Monitor には、アラートルールの一覧とそれぞれのステータスが表示されます。
作成したアラートルールも確認できます。
選択して、アラートルールの詳細を表示します。
ステータスの状態(履歴)も表示されます。
OKとなっており、サービスのステータスが取得できていることが確認できます。

サービスを停止してアラートの発生を確認

監視対象のサービスを停止して、アラートが発生することを確認します。

アラート確認
W32Time(Windows Time)のサービスを停止します。
しばらくすると、アラートルールのステータスがALERTになります。
Status & HistoryでもAlertとなっていることが確認できます。
W32Time(Windows Time)のサービスを起動します。
アラートルールのステータスがOKに戻ります。
Status & HistoryでもOKとなっており、ALERT状態から回復していることが確認できます。
Eventsでアラートの履歴を確認します。
[Triggered]と[Recovered]の履歴が確認できました。

※一部の画面は、別のアラート発生時のものを使用しています。

—広告—

最後に

Datadog を使ったプロセスやサービスの監視設定手順について確認しました。
今回は1つのホストで実施していますが、複数のホストを1つのアラートルールで監視することもできます。
また、1つの設定ファイルで複数のプロセスやサービスの監視設定も可能です。

引き続き、Datadogについていろいろ試してみたいと思います。

仮想マシンのメトリクス(リソース)監視設定手順については、こちらで紹介しています。
アラート発生時のメール通知設定についても確認しています。

Datadog Agentを使ったログ転送手順については、こちらで紹介しています。

スポンサーリンク

Azure,Datadog,Others