Ansibleを使用してPrometheusでシステム監視を設定する方法

2017年の夏に、Ansibleの使用に関する2つのハウツー記事を書きました。最初の記事の後、 copyの例を示す予定でした 、 systemd 、 service 、 apt 、 yum 、 virt 、および user モジュール。ただし、 yum の使用に焦点を当てるために、2番目の部分の範囲を狭めることにしました。 およびuser モジュール。基本的なGitSSHサーバーを設定する方法を説明し、コマンドについて調べました。 、ファイル 、 authorized_keys 、 yum 、および user モジュール。この3番目の記事では、Prometheusオープンソース監視ソリューションを使用したシステム監視にAnsibleを使用する方法について説明します。

これらの最初の2つの記事を読んだ場合は、次のようになります。

1. Ansibleコントロールホストをインストールしました
2. AnsibleコントロールホストにSSHキーを作成しました
3. Ansibleで管理するすべてのマシンにSSHキーを伝播しました
4. すべてのマシンでのSSHアクセスの制限
5. GitSSHサーバーをインストールしました
6. gitを作成しました ユーザー。GitSSHサーバーにコードをチェックインおよびチェックアウトするために使用されます

ビジネスの観点から、あなたは今持っています：

1. 簡素化されたホスト管理
2. これらのホストを管理するための監査可能、反復可能、自動化された方法を作成しました
3. （Ansibleプレイブックを介して）ディザスタリカバリのパスの作成を開始しました

企業が必要とするスキルを構築するには、時間の経過に伴うリソース使用率の傾向を確認できる必要があります。最終的に、これはある種の監視ツールを設定することを意味します。 Zabbix、Zenoss、Nagios、Prometheusなど、たくさんの選択肢があります。私はこれらすべてを扱ってきました。どのソリューションを選択するかは、主に次の機能です。

• 予算
• 時間
• 親しみやすさ

Nagiosなどのエージェントレス監視ツールは、SNMPなどを使用してホストを監視し、メトリックを公開する場合があります。このアプローチには多くの利点があります（エージェントをインストールする必要がないなど）。ただし、Prometheusはエージェントベースでありながら、セットアップが非常に簡単で、すぐに使用できるメトリックがはるかに多いことがわかりました。そのため、この記事ではそれを使用します。

Prometheusのセットアップ

役割の概要

Ansibleの詳細

• Ansibleのクイックスタートガイド
• Ansibleチートシート
• 無料のオンラインコース：Ansibleの必需品
• Ansibleをダウンロードしてインストールする
• eBook：自動化された企業
• eBook：DevOps用のAnsible
• 無料のAnsible電子書籍
• 最新のAnsible記事

残念ながら、Prometheusで利用できるLinuxパッケージマネージャーリポジトリ（Arch User Repositoryの外）がないか、Prometheusダウンロードページに少なくとも何もリストされていません。利用可能なDockerイメージがあります。これは場合によっては望ましいことですが、Dockerがターゲットマシンにまだ存在しない場合は、追加のサービスを実行する必要があります。この記事では、コンパイル済みのバイナリを各ホストにデプロイします。これに必要なファイルは、バイナリ自体と systemdの2つだけです。 またはupstart 初期化ファイル。

このため、1つのPrometheusインストールプレイブックが非常に複雑になる可能性があります。したがって、Ansibleロールへの移行について話し合う良い機会です。簡単に言えば、できる 1つの巨大なYAMLファイルがあり、役割は、より大きなプレイに含めることができる小さなタスクのコレクションを持つ方法です。 。これは、例を通してより簡単に説明されます。たとえば、すべてのホストに存在する必要のあるユーザーIDがあり、管理するサーバーの中にはWebサーバーが必要なものもあれば、ゲームサーバーが存在するものもあるとします。これを処理するために2つの異なるプレイブックがあるかもしれません。次のプレイブックを検討してください：

例1：Create_user_with_ssh_key.yaml

-ホスト： "{{hostname}}" 
 collect_facts：false 
タスク：
-名前：{{username}}のパスワードを作成および/または変更
ユーザー：
名前： "{{username}}" 
パスワード：<<パスワードハッシュ> 
-名前：sshキーをコピー
 authorized_key：
キー： " {{item}} "
 user：" {{username}} "
状態：present 
 Exclusive：False 
 with_file：
-../files/user1_ssh_key .pub 
-../files/user2_ssh_key.pub 

この問題を検討する際に利用できるオプションがいくつかあります。

1. このコードを、さまざまなサーバーの作成に使用される各プレイブックの先頭にコピーします
2. このプレイブックを手動で実行します。前 サーバー構成プレイブックの実行
3. create_user_with_ssh_key.yamlをオンにします タスクに追加し、標準のAnsibleプラクティスを使用してロールに含めることができます

オプション1は大規模に管理できません。作成したパスワードまたはユーザー名を変更する必要があるとします。このコードを含むすべてのプレイブックを見つける必要があります。

オプション2は正しい方向への一歩です。ただし、サーバーを作成するたびに、追加の手動手順が必要です。ホームラボでは、これで十分な場合があります。ただし、複数の人が同じプロセスに従ってサーバーを作成する可能性がある多様な環境では、オプション2は管理者に依存して、機能するサーバーを正確な仕様で作成するために必要なすべての手順を文書化し、正しく実行します。

これらの欠点を補うために、オプション3はAnsibleの組み込みソリューションを使用します。これには、簡単に再現可能なサーバー構築プロセスを使用できるという利点があります。また、ビルドプロセスを監査する場合（ 以前に設定したソース管理を使用すると、監査人は単一のファイルを開いて、サーバービルドを生成するためにAnsibleによって自動的に使用されたタスクファイルを特定できる可能性があります。結局のところ、これは長期的な最善のアプローチであり、役割の使用方法を学び、役割を早期に頻繁に使用する習慣を身に付けることをお勧めします。

適切なディレクトリ構造で役割を整理することは、簡単な監査と自分の成功の両方にとって重要です。 Ansibleのドキュメントには、ディレクトリ構造とレイアウトに関するいくつかの提案があります。私はこれに似たディレクトリレイアウトを好みます：

└──制作
├──プレイブック
└──役割
├──一般的な
│├──デフォルト
─│├ br/>│├──ハンドラー
│├──タスク
│└──vars
 ─ハンドラー
│├──タスク
│└──vars
├──モニタリング
ハンドラー├──ファイル
 │├──タスク
│├──テンプレート
│└──vars

ロールを設計するためのAnsibleシステムは、特に変数を定義できる場所が複数あるため、最初は少し混乱する可能性があります。上記の状況では、上記の状況では、 group_varsを作成できます。 productのディレクトリ そのようなフォルダ：

└──production/
└──group_vars/
└──all/
└──vars.yaml

このファイルに変数を配置すると、 productに配置されているすべてのロールに変数にアクセスできるようになります。 フォルダ。 varsを持つことができます 各役割（ git_server など） ）したがって、特定の役割のすべてのタスクでそれらを使用できるようにします：

└──environments/
└──production/
└──roles/
└──git_server/
└──vars/
 ─main.yaml

最後に、演劇自体で変数を指定できます。これらは、特定のタスクまたはプレイ自体にローカルでスコープできます（したがって、同じプレイ内の複数のタスクにまたがります）。

要約すると、変数を宣言できます：

1. 特定の役割のすべてのタスクの役割レベルで
2. プレイ内のすべてのタスクのプレイブックレベルレベルで
3. 個々のタスクの内部
4. Ansible hostsファイル（別名インベントリ）内。これは主にマシン変数に使用され、この説明では取り上げません

変数を作成するスコープを決定することは、特に保守性の容易さとバランスが取れている場合、難しい場合があります。すべての変数をグローバルレベルに置くことができます。これにより、変数を簡単に見つけることができますが、大規模な環境では最適なアイデアではない場合があります。これとは逆に、すべての変数を個々のタスク内に配置しますが、変数が多い場合、これは大きな頭痛の種になる可能性があります。特定の状況でのトレードオフを検討する価値があります。

上記の例1の小さなプレイブックに戻ると、次のようにファイルが分割される可能性があります。

├──本番
│├──プレイブック
│└──役割
│├──一般的な
││├──ファイル
││ │├──user1_ssh_key.pub
││└──user2_ssh_key.pub
││├──tasks
│─ ├──copy_ssh_key.yaml

タスクの内容 ファイルは、単一のモノリシックプレイブックの行と同じです：

例2：create_user.yaml

-name：{{username}}のパスワードを作成および/または変更します
 user：
 name： "{{username}}" 
 password：<> 

例3：copy_ssh_key.yaml

-name：copy ssh keys 
 authentication_key：
 key： "{{item}}" 
 user： "{{username}}" 
 state：present 
排他的：False 
 with_file：
 --user1_ssh_key.pub 
 --user2_ssh_key.pub 

ただし、（潜在的に）変更されたのは、変数がAnsibleに渡される方法です。 -extra-varsは引き続き使用できます オプション。ただし、別のアプローチを示すために、 vars / main.yamlを使用します ファイル。 vars / main.yaml ファイルには次の内容が含まれています：

ユーザー名：'git' 
パスワード：6 $ cmYTU26zdqOArk5I $ WChA039bHQ8IXAo0W8GJxhk8bd9wvcY.DTUwN562raYjFhCkJSzSBm6u8RIgkaU8b3.Z3EmyxyvEZt8.OpCC 

 パスワードは、クリアテキストのパスワードではなくハッシュである必要があります。 Linuxのほとんどのバージョンでハッシュを生成するには、次のPythonコマンドを実行できます。
 
  python2.7 -c'import crypt、getpass; print crypt.crypt（getpass.getpass（）、 "$ 1 $ awerwass"）' 
 

 上記のコマンドでは、パスワードソルトは awerwassで示されています 。これらは私がキーボードで叩いたランダムな文字です。 同じ塩を生産に使用しないでください。 
 

 これらのタスクを一緒に実行するには、 main.yamlを作成する必要があります タスクで ディレクトリ。次の内容が含まれている必要があります：
 
 --- 
-インクルード：create_user.yaml 
-インクルード：copy_ssh_key.yaml 
 

 最後に、次の内容のプレイブックを作成します。
 
-ホスト：git 
 collect_facts：false 
ロール：
 43-ロール：../roles/common 
 

 ディレクトリ構造は次のようになります。
 
├──本番
│├──プレイブック
││├──common.yaml
│└──役割
│├──common
 ││├──ファイル
│││├──user1_ssh_key.pub
│││└──user2_ssh_key.pub
│ ──main.yaml
││├──tasks
│││├──copy_ssh_key.yaml
│││ ─main.yaml
││└──vars
││└──main.yaml
 
プロメテウスの役割を設定する
 

 役割の作成の基本について説明したので、Prometheus役割の作成に焦点を当てましょう。前述のように、各エージェントの実行に必要なファイルは、サービス（またはアップスタート）ファイルとPrometheusバイナリの2つだけです。それぞれの例を以下に示します。
 
例4：systemdprometheus-node-exporter.serviceファイル
 
 [Unit] 
 Description =Prometheus Exporter formachinemetrics。
After =network.target 
 
 [Service] 
 ExecStart =/ usr / bin / prometheus_node_exporter 
 
[インストール]
WantedBy =multi-user.target 
 
例5：upstartinitファイル
 
＃prometheus_node_exporterを実行します

起動時に開始します

 script 
 / usr / bin / prometheus_node_exporter 
 end script 
 
例6：systemd prometheus.service（サーバーサービス）ファイル
 
 [Service] 
 User =prometheus 
 Group =prometheus 
 ExecStart =/ usr / bin / prometheus -config.file =/ etc / prometheus /prometheus.yaml-storage.local。 path =/ var / lib / prometheus / data -storage.local.retention =8928h -storage.local.series-file-shrink-ratio =0.3 
 ExecReload =/ bin / kill -HUP $ MAINPID 
 
[インストール]
WantedBy =multi-user.target 
 

 私の環境では、Ubuntuマシンを使用しています（システムの有無にかかわらず） ）および多数のRed HatおよびArchマシンでは、正しい起動スクリプトをそれぞれのボックスに配布するためのプレイブックを作成する必要がありました。  upstartをデプロイするかどうかを決定する方法はいくつかあります。 またはsystemd サービスファイル。 Ansibleには、 ansible_service_mgrというファクトが組み込まれています。 これを使用して、適切なサービスマネージャーを検討することができます。
 

 ただし、 Gather Facts 中に、スクリプトを使用してAnsibleにファクトを提供する方法を示すことにしました。 ステージ。これは、AnsibleLocalFactsとして知られています。これらのファクトは、 /etc/ansible/facts.d/から読み取られます。 ディレクトリ。このディレクトリ内のファイルは、JSON、INI、またはJSONを返す実行可能ファイルにすることができます。また、ファイル拡張子が .factである必要があります。 。私が書いた単純なBashスクリプトは、 systemdのチェックを行います PIDは、見つかった場合、値が trueのJSONを返します。 、例7に示すように：
 
例7：systemd_check.fact 
 
＃！/ bin / bash 
＃systemdが存在するかどうかを確認return {'systemd'：'true'} 
 
 systemd_pid =`pidof systemd` 
 if [- z "$ systemd_pid"]; then 
 echo'{"systemd"： "false"}' 
 else 
 echo'{"systemd"： "true"}' 
 fi 
 

 これを念頭に置いて、Prometheusエージェントの展開を支援する簡単なタスクの作成を開始できます。これを実現するために、ローカルの facts  ファイルを各サーバーにコピーし、バイナリスクリプトと起動スクリプトをデプロイして、サービスを再起動する必要があります。以下は、 systemd_check.factをデプロイするタスクです。 スクリプト。
 
例8：copy_local_facts.yaml 
 
-名前：存在しない場合はファクトディレクトリを作成します
ファイル：
パス：/etc/ansible/facts.d 
状態：ディレクトリ
 
-名前：systemdファクトファイルをコピーします
コピー：
 src：systemd_check.fact 
 dest：/etc/ansible/facts.d/systemd_check.fact 
モード：0755 
> 

 カスタムファクトがデプロイされたので、必要なバイナリをデプロイできます。ただし、最初に、これらのタスクに使用される変数ファイルを見てみましょう。この例では、 vars /を使用することを選択しました 個々の役割にローカライズされたディレクトリ。現在は次のようになっています：
 
例9：vars / main.yaml 
 
 exporter_binary：'prometheus_node_exporter' 
 exporter_binary_dest：'/usr/bin/prometheus_node_exporter' 
 exporter_service：'prometheus-node-exporter.service' 
 exporter_service_dest：'/ etc / systemd / system /prometheus-node-exporter.service'
 exporter_upstart：' prometheus-node-exporter.conf'
 exporter_upstart_dest：' /etc/init/prometheus-node-exporter.conf'
 
 server_binary：'prometheus' 
 server_binary_dest：'/usr/bin/prometheus' 
 server_service：'prometheus.service' 
 server_service_dest：'/etc/systemd/system/prometheus.service' 
 
 prometheus_user：'prometheus' 
 prometheus_server_name：'prometheus' 
 
 client_information_dict：
'conan'： '192.168.195.124:9100' 
'confluence'： '192.168.195.170:9100' 
'smokeping'： '192.168.195.120:9100' 
 '7-repo'： '192.168.195.157:9100' 
'server '：' 192.168.195.9:9100'' 
'ark'： '192.168.195.2:9100' 
'kids-tv'： '192.168.195.213:9100' 
'medi a-centre'：' 192.168.195.15:9100'
' nas'：' 192.168.195.195:9100'
' nextcloud'：' 192.168.199.117:9100'
' git'： '192.168.195.126:9100' 
'nuc'： '192.168.195.90:9100' 
'デスクトップ'： '192.168.195.18:9100' 
 

 今のところ、 client_information_dictは無視してかまいません。;後で機能します。
 
例10：tasks / setup_prometheus_node.yaml 
 
 --- 
-name：バイナリを{{exporter_binary_dest}}にコピーします
 copy：
 src： "{{exporter_binary}}" 
 dest： "{{ exporter_binary_dest}} "
モード：0755 
 
-名前：systemdサービスファイルを配置します
コピー：
 src：" {{exporter_service}} "
 dest： "{{exporter_service_dest}}" 
 when：
 --ansible_local.systemd_check.systemd =='true' 
 
-name：upstartconfを{{exporter_upstart_dest }} 
 copy：
 src： "{{exporter_upstart}}" 
 dest： "{{exporter_upstart_dest}}" 
 when：
 --ansible_local.systemd_check.systemd =='false' 
 
-名前：systemdを更新し、エクスポーターsystemdを再起動します
 systemd：
デーモンリロード：true 
有効：true 
状態：再起動
name： "{{exporter_service}}" 
 when：
 --ansible_local.systemd_check.systemd =='true' 
 
-name：start exporter sysv service 
サービス：
名前： "{{exp orter_service}} "
 enabled：true 
 state：restarted 
 when：
 --ansible_local.systemd_check.systemd =='false' 
 

 上記のタスクで注意すべき最も重要なことは、 ansible_local.systemd_check.systemdを参照していることです。 。これは、次の命名規則に分類されます。 <ファクトファイルの名前>。 <取得するファクト内のキー> 。 Bashスクリプトsystemd_check.fact  Gather Facts中に実行されます ステージングしてからansible_localに保存します すべてのGatherFactsのセクション 。この事実に基づいて決定を下すために、それが trueであるかどうかを確認します またはfalse 。 Ansible When句は、特定の条件が満たされた場合にのみその特定のタスクを実行するようにAnsibleに指示します。このタスクの残りの部分はかなり簡単なはずです。 systemdモジュールとサービスモジュールの両方を使用して、適切なサービスマネージャーが prometheus_node_exporterを開始するように構成されていることを確認します。 。
 

 サーバーをセットアップするタスクは非常に似ています：
 
例11：tasks / setup_Prometheus_server.yaml 
 
 --- 
-name：サーバーバイナリを{{server_binary_dest}}にコピーします
 copy：
 src： "{{server_binary}}" 
 dest： "{ {server_binary_dest}} "
 mode：0755 
 when：
 --inventory_hostname ='prometheus' 
 
-name：/ etc/prometheusが存在することを確認します
ファイル：
状態：ディレクトリ
パス：/ etc / prometheus 
所有者： "{{prometheus_user}}" 
グループ： "{{prometheus_user}}"
モード：0755 
 when：
 --inventory_hostname ='prometheus' 
 
-name：place prometheus config 
 template：
 src：prometheus.yaml.j2 
 dest：/etc/prometheus/prometheus.yaml 
 when：
 --inventory_hostname ='prometheus' 
 
-name：create / var / lib / promtheus / data 
ファイル：
状態：ディレクトリ
パス：/ var / lib / prometheus / data 
再帰：true 
所有者： "{{prometheus_user}}" 
グループ： "{{prometheus_user}}" 
モード：0755 
いつ：
-in ventory_hostname ='prometheus' 
 
-name：systemdサービスファイルを配置します
 copy：
 src： "{{server_service}}" 
 dest： "{{ server_service_dest}} "
 when：
 --ansible_local.systemd_check.systemd =='true' 
 --inventory_hostname ='prometheus' 
 
-name：systemdを更新して再起動prometheus server systemd 
 systemd：
 daemon-reload：true 
 enabled：true 
 state：restarted 
 name： "{{server_service}}" 
 when ：
 --ansible_local.systemd_check.systemd =='true' 
 --inventory_hostname ='prometheus' 
 
通知：restart_prometheus_server 
 

 熱心なオブザーバーは、サーバータスクにいくつかの新しいことに気付くでしょう。
 
 
 通知： セクション
 
 テンプレート： モジュール
 
 

 通知 セクションは、特定の基準が満たされたときに特定のタイプのイベントをトリガーする方法です。 Ansibleハンドラーは、サービスの再起動をトリガーするために最も頻繁に使用されます（これはまさに上記で起こっていることです）。ハンドラーはハンドラーに保存されます ロール内のディレクトリ。私のハンドラーは非常に基本的です：
 
例12：handler / main.yaml 
 
-名前：restart_iptables 
サービス：
名前：iptables 
状態：再起動
有効：true 
 
-名前：restart_prometheus_server 
サービス：
名前： "{{server_service}}" 
状態：再起動
有効：true 
 

 これにより、 prometheus.serviceを再起動できます。 Prometheusサーバー上。
 

  setup_prometheus_server.yamlの2番目の注目点  template：です セクション。 Ansibleでテンプレートを作成すると、いくつかの非常に優れた利点が得られます。 AnsibleはテンプレートエンジンにJinja2を使用しています。ただし、Jinjaの完全な説明は、このチュートリアルの範囲外です。基本的に、Jinja2テンプレートを使用して、Ansibleの再生中に値が計算および置換される変数を含む1つの構成ファイルを作成できます。 Prometheus構成テンプレートは次のようになります：
 
例13：templates / prometheus.yaml.j2 
 
 global：
 sparke_interval：15s＃スクレイプ間隔を15秒ごとに設定します。デフォルトは1分ごとです。
evaluation_interval：15s＃15秒ごとにルールを評価します。デフォルトは1分ごとです。

 external_labels：
 monitor：'codelab-monitor' 
 
 scrape_configs：
＃ジョブ名はとして追加されます`job =`を、この構成から取得した任意のタイムシリーズにラベル付けします。
 --job_name：'prometheus' 
 
 static_configs：
 --targets：['localhost：9090'] 
 --job_name：'nodes' 
 static_configs：
 {％for hostname、ip in client_information_dict.iteritems（）％} 
 --targets：['{{ip}}'] 
ラベル：{'host'：'{{hostname}}'} 
 {％endfor％} 
 

 テンプレートセクションが処理されると、 .j2  ファイルをリモートシステムに配置する前に、拡張子は自動的に削除されます。テンプレートの小さなforループは、 client_information_dictを繰り返し処理します 、以前に変数ファイルで定義しました。 Prometheusにメトリックを収集させたい仮想マシンのリストを作成するだけです。
 

 注：Prometheusにホスト名を表示させ、DNSが正しく設定されている場合は、代わりにこれを使用してください：
 
 {％for hostname、ip in client_information_dict.iteritems（）％} 
 --targets：['{{hostname}}：9100'] 
ラベル：{'host'：'{{hostname }}'} 
 {％endfor％} 
 

 Prometheusのセットアップを完了するには、残りの仕上げがいくつかあります。  prometheusを作成する必要があります ユーザーは、（潜在的に）iptablesを調整し、 main.yamlですべてを結び付けます 、実行するプレイブックを作成します。
 

  Prometheusのセットアップ ユーザーはかなり単純で、以前のAnsibleの記事に従えば非常に馴染み深いでしょう：
 
例14：tasks / create_prometheus_user.yaml 
 
 --- 
-名前：prometheusユーザーが存在することを確認します
 user：
 name： "{{prometheus_user}}" 
 shell：/ bin / false 
 

 ここでの唯一の大きな違いは、シェルを / bin / falseに設定していることです。 そのため、ユーザーはサービスを実行できますが、ログインすることはできません。
 

 iptablesを実行している場合は、Prometheusがクライアントからメトリックを収集できるように、必ずポート9100を開く必要があります。これを行うための簡単なタスクは次のとおりです。
 
例15：tasks / iptables.yaml 
 
 --- 
-name：Open port 9100 
 lineinfile：
 dest：/ etc / sysconfig / iptables 
 insertbefore： "-A INPUT -j OS_FIREWALL_ALLOW" 
行： "-A INPUT -p tcp -m state --dport 9100 --state NEW -j ACCEPT" 
 notify：restart_iptables 
 when：
 --ansible_os_family =="RedHat" 
 

 注：RedHatファミリーのVMでのみiptablesを実行しています。すべてのVMでiptablesを実行する場合は、 when：を削除してください セクション。
 

  main.yaml  次のようになります：
 
例16：tasks / main.yaml 
 
 --- 
-インクルード：create_prometheus_user.yaml 
-インクルード：setup_prometheus_node.yaml 
-インクルード：setup_prometheus_server.yaml 
-インクルード：prometheus_iptables.yaml 
 

 最後のピースは、タスクを完了するために必要な役割を網羅したプレイブックを作成することです。
 
例17：playbooks / monitoring.yaml 
 
-ホスト：すべて
役割：
-役割：../roles/common 
-役割：../roles/monitoring 
 
すべてを結び付ける
 

 通過するテキストが多いように見えることは知っていますが、Ansibleを使用するための概念はかなり単純です。通常は、実行しようとしているタスクを実行する方法を理解し、それらを実行するのに役立つ適切なAnsibleモジュールを見つけるだけです。このウォークスルーを最後まで実行している場合は、次のようなレイアウトになっているはずです。
 
├──プレイブック
│├──git_server.yaml
│├──monitoring.yaml
└──役割
├──共通
│ ├──ファイル
││├──systemd_check.fact
││├──user1_ssh_key.pub
│││└──user2_ssh_key.pub
││└──main.yaml
│├──tasks
││├──copy_systemd_facts.yaml
││├──main。 ├──push_ssh_key.yaml
││├──root_ssh_key_only.yaml
│└──vars
│└──main.yaml
├ │├──ファイル
││├──prometheus
││├──prometheus_node_exporter
││ prometheus-node-exporter.service
│├──prometheus.service
││└──systemd_check.fact
│├──ハンドラー
 .yaml
│├──タスク
││├──create_prometheus_user.yaml
││├── main.yaml
││├──prometheus_iptables.yaml
││├──setup_prometheus_node.yaml
テンプレート│ />││└──prometheus.yaml.j2
└──vars
└──main.yaml
 

 プレイブックを実行するには、次のように入力します。
 
  [root @ ansible-host product]＃ansible-playbook-i<ホストファイルへのパス>playbooks/ monitoring.yaml  
 

 これで、ユーザーを作成し、sshキーを押して、 systemdの存在を確認できるようになります。 、 prometheus_node_exporterのいずれかをデプロイします または、適切なサーバーへのPrometheusサーバーバイナリ。 Prometheusは、 vars/main。で指定されたホストのリストを含む基本構成で初期化する必要があります。  yaml  監視の役割のファイル。
 

 おめでとう！これで、基本的なPrometheusサーバーのインストールと構成が自動化され、データの送信を開始するようにホストが構成されました。楽しい副作用として、目標を達成するために必要なすべてのステップを効果的に文書化しています。
 
 

 補遺：このシリーズを思いついたとき、OpenShiftにPrometheusをインストールする作業をしていました。ただし、OpenShiftのAnsibleインストーラーのドキュメントを確認したところ、これはすでにプレイブックに含まれており、インストーラーのオプションであることがわかりました。