Cómo usar Ansible para configurar el monitoreo del sistema con Prometheus

En el verano de 2017, escribí dos artículos de procedimientos sobre el uso de Ansible. Después del primer artículo, planeé mostrar ejemplos de la copy , systemd , service , apt , yum , virt y user módulos. Pero decidí ajustar el alcance de la segunda parte para centrarme en usar yum y user módulos. Expliqué cómo configurar un servidor Git SSH básico y exploré el command , file , authorized_keys , yum y user módulos. En este tercer artículo, hablaré sobre el uso de Ansible para la supervisión del sistema con la solución de supervisión de código abierto de Prometheus.

Si siguió esos dos primeros artículos, debería tener:

1. Instalado un host de control de Ansible
2. Se creó una clave SSH en el host de control de Ansible
3. Propagó la clave SSH a todas las máquinas que desea que Ansible administre
4. Acceso SSH restringido en todas las máquinas
5. Instalado un servidor Git SSH
6. Creó el git usuario, que se utiliza para verificar la entrada y salida del código del servidor Git SSH

Desde una perspectiva comercial, ahora tiene:

1. Gestión de host simplificada
2. Produjo una forma auditable, repetible y automatizada de administrar esos hosts
3. Comenzó a crear un camino para la recuperación ante desastres (a través de libros de jugadas de Ansible)

Para desarrollar las habilidades que necesitan las empresas, debe poder ver las tendencias de utilización de recursos a lo largo del tiempo. En última instancia, esto significa configurar algún tipo de herramienta de monitoreo. Hay mucho para elegir, incluidos Zabbix, Zenoss, Nagios, Prometheus y muchos otros. He trabajado con todos estos; la solución que elija depende en gran medida de:

• Presupuesto
• Tiempo
• Familiaridad

Las herramientas de monitoreo sin agentes como Nagios pueden usar algo como SNMP para monitorear hosts y exponer métricas. Este enfoque puede tener muchas ventajas (como no tener que instalar un agente). Sin embargo, descubrí que Prometheus, aunque está basado en agentes, es muy fácil de configurar y proporciona muchas más métricas listas para usar, así que eso es lo que usaré en este artículo.

Configuración de Prometeo

Introducción a los roles

Más sobre Ansible

• Una guía de inicio rápido de Ansible
• Hoja de trucos de Ansible
• Curso en línea gratuito:conceptos básicos de Ansible
• Descargar e instalar Ansible
• eBook:La empresa automatizada
• Libro electrónico:Ansible para DevOps
• Libros electrónicos gratuitos de Ansible
• Últimos artículos de Ansible

Desafortunadamente, no hay un repositorio de administrador de paquetes de Linux disponible para Prometheus (fuera del repositorio de usuarios de Arch), o al menos ninguno aparece en la página de descarga de Prometheus. Hay una imagen de Docker disponible, que puede ser deseable en algunos casos, pero requiere ejecutar servicios adicionales si Docker aún no está presente en la máquina de destino. Para este artículo, implementaré los binarios precompilados en cada host. En realidad, solo se necesitan dos archivos para esto:el binario en sí y un systemd o upstart archivo de inicio.

Debido a esto, un solo libro de jugadas de instalación de Prometheus puede ser bastante complicado; por lo tanto, sería un buen momento para analizar la transición a un rol de Ansible. En pocas palabras, mientras puedas tienen un archivo YAML gigante, los roles son una forma de tener una colección de tareas más pequeñas que se pueden incluir en un juego más grande . Esto se explica más fácilmente a través de ejemplos. Por ejemplo, supongamos que tiene una identificación de usuario que debe estar en cada host, pero algunos de los servidores que administra requieren un servidor web, mientras que otros pueden tener un servidor de juegos en ellos. Es posible que tenga dos libros de jugadas diferentes para manejar esto. Considere el siguiente libro de jugadas:

Ejemplo 1:Create_user_with_ssh_key.yaml

- hosts: "{{ hostname }}"

  gather_facts: false

  tasks:

    - name: create and/or change {{ username}}'s password

      user:

        name: "{{ username }}"

        password: << some password hash>

    - name: copy ssh keys

      authorized_key:

        key: "{{ item }}"

        user: "{{ username }}"

        state: present

        exclusive: False

      with_file: 

        - ../files/user1_ssh_key.pub

        - ../files/user2_ssh_key.pub

Hay algunas opciones disponibles al considerar este problema.

1. Copie este código al comienzo de cada libro de jugadas que se usará para crear los diferentes servidores
2. Ejecute este libro de jugadas manualmente, antes ejecutando el manual de configuración del servidor
3. Active create_user_with_ssh_key.yaml en una tarea, que luego se puede incluir en un rol utilizando la práctica estándar de Ansible

La opción 1 no es manejable a escala. Supongamos que tuviera que cambiar la contraseña o el nombre de usuario que estaba creando. Tendrías que encontrar todos los libros de jugadas que incluyen este código.

La opción 2 es un paso en la dirección correcta. Sin embargo, requiere un paso manual adicional cada vez que crea un servidor. En un laboratorio casero, esto puede ser suficiente. Sin embargo, en un entorno diverso con la posibilidad de que varias personas sigan el mismo proceso para crear servidores, la opción 2 confía en que el administrador documente y siga correctamente todos los pasos necesarios para producir un servidor que funcione según las especificaciones exactas.

Para compensar esas deficiencias, la opción 3 utiliza la solución integrada de Ansible. Tiene la ventaja de utilizar un proceso de creación de servidor fácilmente reproducible. Además, al auditar el proceso de compilación (usted está utilizando el control de código fuente que configuramos anteriormente, ¿no?), el auditor puede potencialmente abrir un único archivo para determinar qué archivos de tareas utilizó automáticamente Ansible para producir una compilación de servidor. Al final, este será el mejor enfoque a largo plazo, y es una buena idea aprender a usar roles y adquirir el hábito de usarlos pronto y con frecuencia.

Organizar sus roles con una estructura de directorio adecuada es fundamental tanto para una fácil auditabilidad como para su propio éxito. La documentación de Ansible tiene algunas sugerencias con respecto a la estructura y el diseño del directorio. Prefiero un diseño de directorio similar a este:

└── production

    ├── playbooks

    └── roles

        ├── common

        │   ├── defaults

        │   ├── files

        │   ├── handlers

        │   ├── tasks

        │   └── vars

        ├── git_server

        │   ├── files

        │   ├── handlers

        │   ├── tasks

        │   └── vars

        ├── monitoring

        │   ├── files

        │   ├── handlers

        │   ├── tasks

        │   ├── templates

        │   └── vars

El sistema de Ansible para diseñar roles puede ser un poco confuso al principio, especialmente porque hay varios lugares donde se pueden definir las variables. En la situación anterior, en esta situación anterior, podría crear un group_vars directorio en la production carpeta así:

└── production/

    └── group_vars/

        └── all/

            └── vars.yaml

Colocar variables en este archivo las hará accesibles para cualquier rol que se coloque en la production carpeta. Podrías tener vars debajo de cada rol (como git_server ) y así tenerlos disponibles para todas las tareas de un determinado rol:

└── environments/

    └── production/

        └── roles/

        └── git_server/

            └── vars/

                └── main.yaml

Finalmente, puede especificar variables en el juego mismo. Estos pueden tener un alcance local para la tarea específica o para el juego en sí (por lo tanto, abarcan múltiples tareas en el mismo juego).

En resumen, puede declarar variables:

1. A nivel de rol para todas las tareas en un rol determinado
2. Al nivel del libro de jugadas para todas las tareas de una obra
3. Dentro de las tareas individuales
4. Dentro del archivo de hosts de Ansible (también conocido como inventario); esto se usa principalmente para variables de máquina y no se cubre en esta discusión

Decidir qué alcance crear variables puede ser difícil, especialmente cuando se equilibra con la facilidad de mantenimiento. Puede poner todas sus variables a nivel global, lo que las hace fáciles de encontrar, pero puede que no sea la mejor idea para entornos grandes. Lo contrario de esto es colocar todas las variables dentro de tareas individuales, pero esto puede convertirse en un verdadero dolor de cabeza si tiene muchas variables. Vale la pena considerar las compensaciones en su situación específica.

Volviendo al pequeño libro de jugadas del Ejemplo 1 anterior, podríamos dividir nuestros archivos de esta manera:

├── production

│   ├── playbooks

│   └── roles

│       ├── common

│       │   ├── files

│       │   │   ├── user1_ssh_key.pub

│       │   │   └── user2_ssh_key.pub

│       │   ├── tasks

│       │   │   ├── create_user.yaml

│       │   │   ├── copy_ssh_key.yaml

El contenido de las tasks los archivos son idénticos a las líneas del libro de jugadas único y monolítico:

Ejemplo 2:crear_usuario.yaml

- name: create and/or change {{ username}}'s password

  user:

    name: "{{ username }}"

    password: << password hash >>

Ejemplo 3:copy_ssh_key.yaml

- name: copy ssh keys

  authorized_key:

    key: "{{ item }}"

    user: "{{ username }}"

    state: present

    exclusive: False

  with_file: 

    - user1_ssh_key.pub

    - user2_ssh_key.pub

Sin embargo, lo que ha cambiado (potencialmente) es la forma en que las variables se pasan a Ansible. Todavía puede usar --extra-vars opción. Sin embargo, para demostrar otro enfoque, usaremos vars/main.yaml expediente. El vars/main.yaml archivo tiene el siguiente contenido:

username: 'git'

password: 6$cmYTU26zdqOArk5I$WChA039bHQ8IXAo0W8GJxhk8bd9wvcY.DTUwN562raYjFhCkJSzSBm6u8RIgkaU8b3.Z3EmyxyvEZt8.OpCCN0

La contraseña debe ser un hash y no una contraseña de texto claro. Para generar un hash en la mayoría de las versiones de Linux, puede ejecutar el siguiente comando de Python:

python2.7 -c 'import crypt,getpass; print crypt.crypt(getpass.getpass(), "$1$awerwass")'

En el comando anterior, la contraseña salt se indica en awerwass . Estos son solo caracteres aleatorios que golpeé en el teclado. NO USE LA MISMA SAL EN LA PRODUCCIÓN.

Para que estas tareas se ejecuten juntas, debe crear un main.yaml en las tasks directorio. Debe tener el siguiente contenido:

---

- include: create_user.yaml

- include: copy_ssh_key.yaml

Finalmente, cree un libro de jugadas con el siguiente contenido:

- hosts: git

  gather_facts: false

  roles:

    43- role: ../roles/common

La estructura de su directorio debería verse así:

├── production

│   ├── playbooks

│   │   ├── common.yaml

│   └── roles

│       ├── common

│       │   ├── files

│       │   │   ├── user1_ssh_key.pub

│       │   │   └── user2_ssh_key.pub

│       │   ├── handlers

│       │   │   └── main.yaml

│       │   ├── tasks

│       │   │   ├── copy_ssh_key.yaml

│       │   │   ├── create_user.yaml

│       │   │   ├── main.yaml

│       │   └── vars

│       │       └── main.yaml

Configurar un rol para Prometheus

Ahora que hemos cubierto los aspectos básicos de la creación de un rol, concentrémonos en crear un rol de Prometheus. Como se mencionó anteriormente, solo se requieren dos archivos para que se ejecute cada agente:un archivo de servicio (o upstart) y el binario de Prometheus. A continuación se muestran ejemplos de cada uno:

Ejemplo 4:archivo systemd prometheus-node-exporter.service

[Unit]

Description=Prometheus Exporter for machine metrics.

After=network.target



[Service]

ExecStart=/usr/bin/prometheus_node_exporter



[Install]

WantedBy=multi-user.target

Ejemplo 5:archivo de inicio advenedizo

# Run prometheus_node_exporter



start on startup



script

/usr/bin/prometheus_node_exporter

end script

Ejemplo 6:archivo systemd prometheus.service (el servicio del servidor)

[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



[Install]

WantedBy=multi-user.target

En mi entorno, con máquinas Ubuntu (con y sin system ) y una gran cantidad de máquinas Red Hat y Arch, necesitaba escribir un libro de jugadas para distribuir los scripts de inicio correctos a las cajas respectivas. Hay varias formas de determinar si implementar el upstart o systemd archivos de servicio. Ansible tiene un hecho incorporado llamado ansible_service_mgr que se puede utilizar para encontrar el administrador de servicios adecuado.

Sin embargo, decidí demostrar cómo usar scripts para proporcionar datos a Ansible durante la Gather Facts. escenario. Esto se conoce como Ansible Local Facts. Estos hechos se leen del /etc/ansible/facts.d/ directorio. Los archivos en este directorio pueden ser JSON, INI o archivos ejecutables que devuelvan JSON. También deben tener la extensión de archivo .fact . El simple script Bash que escribí verifica el systemd PID, y si lo encuentra, devuelve un JSON con el valor de true , como se ve en el Ejemplo 7:

Ejemplo 7:systemd_check.fact

#!/bin/bash

# Check for systemd if present return { 'systemd': 'true' } 



systemd_pid=`pidof systemd` 

if [ -z "$systemd_pid" ]; then

  echo '{ "systemd": "false" }'

else

  echo '{ "systemd": "true" }'

fi

Con esto en mente, podemos comenzar a crear una tarea simple para ayudar a implementar el agente de Prometheus. Para lograr esto, los facts locales el archivo debe copiarse en cada servidor, los scripts binarios y de inicio deben implementarse y el servicio debe reiniciarse. A continuación se muestra una tarea que implementará el systemd_check.fact guión.

Ejemplo 8:copy_local_facts.yaml

- name: Create the facts directory if does not exist

  file:

    path: /etc/ansible/facts.d

    state: directory



- name: Copy the systemd facts file

  copy:

    src: systemd_check.fact

    dest: /etc/ansible/facts.d/systemd_check.fact

    mode: 0755

Ahora que se han implementado nuestros hechos personalizados, ahora podemos implementar los binarios necesarios. Pero primero, echemos un vistazo al archivo de variables que se usará para estas tareas. En este ejemplo, he elegido usar vars/ directorio que está localizado en el rol individual. Actualmente se ve así:

Ejemplo 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'

    'media-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'

    'desktop': '192.168.195.18:9100'

Por ahora, puede ignorar el client_information_dict; eso entrará en juego más tarde.

Ejemplo 10:tareas/setup_prometheus_node.yaml

---

- name: copy the binary to {{ exporter_binary_dest }}

  copy:

    src: "{{ exporter_binary }}"

    dest: "{{ exporter_binary_dest }}"

    mode: 0755



- name: put systemd service file in place

  copy:

    src: "{{ exporter_service }}"

    dest: "{{ exporter_service_dest }}"

  when: 

    - ansible_local.systemd_check.systemd == 'true'



- name: copy the upstart conf to {{ exporter_upstart_dest }}

  copy:

    src: "{{ exporter_upstart }}"

    dest: "{{ exporter_upstart_dest }}"

  when:

    - ansible_local.systemd_check.systemd == 'false'



- name: update systemd and restart exporter systemd

  systemd:

    daemon-reload: true

    enabled: true

    state: restarted

    name: "{{ exporter_service }}"

  when: 

    - ansible_local.systemd_check.systemd == 'true'

   

- name: start exporter sysv service

  service:

    name: "{{ exporter_service }}"

    enabled: true

    state: restarted

  when:  

    - ansible_local.systemd_check.systemd == 'false'

Lo más importante a tener en cuenta en la tarea anterior es que hace referencia a ansible_local.systemd_check.systemd . Esto se divide en la siguiente convención de nomenclatura <how Ansible generates the fact> . <the name of the fact file> . <the key inside the fact to retrieve> . La secuencia de comandos de Bash systemd_check.fact se ejecuta durante la Gather Facts escenario y luego almacenado en el ansible_local sección de todos los Gather Facts . Para tomar una decisión basada en este hecho, compruebo si es true o false . La cláusula When de Ansible le dice a Ansible que ejecute esa tarea específica solo si se cumplen ciertas condiciones. El resto de esta tarea debería ser bastante sencillo. Utiliza tanto systemd como los módulos de servicio para garantizar que el administrador de servicios apropiado esté configurado para iniciar el prometheus_node_exporter .

La tarea de configurar el servidor es muy similar:

Ejemplo 11:tareas/setup_Prometheus_server.yaml

---

- name: copy the server binary to {{ server_binary_dest }}

  copy:

    src: "{{ server_binary }}"

    dest: "{{ server_binary_dest }}"

    mode: 0755

  when:

    - inventory_hostname = 'prometheus'



- name: Ensure that /etc/prometheus exists

  file:

    state: directory

    path: /etc/prometheus

    owner: "{{ prometheus_user }}"

    group: "{{ prometheus_user }}"

    mode: 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

  file:

    state: directory

    path: /var/lib/prometheus/data

    recurse: true

    owner: "{{ prometheus_user }}"

    group: "{{ prometheus_user }}"

    mode: 0755

  when:

    - inventory_hostname = 'prometheus'



- name: put systemd service file in place

  copy:

    src: "{{ server_service }}"

    dest: "{{ server_service_dest }}"

  when: 

    - ansible_local.systemd_check.systemd == 'true'

    - inventory_hostname = 'prometheus'



- name: update systemd and restart prometheus server systemd

  systemd:

    daemon-reload: true

    enabled: true

    state: restarted

    name: "{{ server_service }}"

  when: 

    - ansible_local.systemd_check.systemd == 'true'

    - inventory_hostname = 'prometheus'



  notify: restart_prometheus_server

El observador entusiasta notará un par de cosas nuevas en la tarea del servidor.

1. El notify: sección
2. La template: módulo

El notify La sección es una forma de desencadenar tipos específicos de eventos cuando se cumplen ciertos criterios. Los controladores de Ansible se usan con mayor frecuencia para desencadenar reinicios de servicios (que es exactamente lo que sucede arriba). Los controladores se almacenan en un handlers directorio dentro del rol. Mi manejador es muy básico:

Ejemplo 12:manejador/main.yaml

- name: restart_iptables

  service:

    name: iptables

    state: restarted

    enabled: true



- name: restart_prometheus_server

  service:

    name: "{{ server_service }}"

    state: restarted

    enabled: true

Esto simplemente me permite reiniciar prometheus.service en el servidor Prometheus.

El segundo punto de interés en el setup_prometheus_server.yaml es la template: sección. Las plantillas en Ansible ofrecen algunas ventajas muy interesantes. Ansible usa Jinja2 para su motor de plantillas; sin embargo, una explicación completa de Jinja está fuera del alcance de este tutorial. Esencialmente, puede usar una plantilla Jinja2 para tener un archivo de configuración con variables cuyos valores se calculan y sustituyen durante una reproducción de Ansible. La plantilla de configuración de Prometheus tiene este aspecto:

Ejemplo 13:plantillas/prometheus.yaml.j2

global:

  scrape_interval:     15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.

  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.



  external_labels:

      monitor: 'codelab-monitor'



scrape_configs:

  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.

  - job_name: 'prometheus'



    static_configs:

      - targets: ['localhost:9090']

  - job_name: 'nodes'

    static_configs:

{% for hostname, ip in client_information_dict.iteritems() %}

      - targets: ['{{ ip }}']

        labels: {'host': '{{ hostname }}' }

{% endfor %}

Cuando se procesa la sección de la plantilla, el .j2 La extensión se elimina automáticamente antes de colocar el archivo en el sistema remoto. El pequeño bucle for en la plantilla itera sobre el client_information_dict , que definí en mi archivo de variables anteriormente. Simplemente crea una lista de máquinas virtuales en las que quiero que Prometheus recopile métricas.

Nota:si desea que Prometheus muestre los nombres de host y su DNS está configurado correctamente, use esto en su lugar:

{% for hostname, ip in client_information_dict.iteritems() %}

      - targets: ['{{ hostname }}:9100']

        labels: {'host': '{{ hostname }}' }

{% endfor %}

Solo quedan algunos toques finales para completar la configuración de Prometheus. Necesitamos crear el prometheus usuario, (potencialmente) ajuste iptables, átelo todo en main.yaml y crea un libro de jugadas para ejecutar.

La configuración del Prometheus user es bastante sencillo y le resultará muy familiar si siguió mis artículos anteriores de Ansible:

Ejemplo 14:tareas/create_prometheus_user.yaml

---

- name: Ensure that the prometheus user exists

  user:

    name: "{{ prometheus_user }}"

    shell: /bin/false

La única diferencia importante aquí es que estoy configurando el shell en /bin/false para que el usuario pueda ejecutar servicios pero no iniciar sesión.

Si está ejecutando iptables, deberá asegurarse de abrir el puerto 9100 para que Prometheus pueda recopilar métricas de sus clientes. Aquí hay una tarea simple para hacer eso:

Ejemplo 15:tareas/iptables.yaml

---

- name: Open port 9100

  lineinfile:

    dest: /etc/sysconfig/iptables

    insertbefore: "-A INPUT -j OS_FIREWALL_ALLOW"

    line: "-A INPUT -p tcp -m state --dport 9100 --state NEW -j ACCEPT"

  notify: restart_iptables

  when: 

    - ansible_os_family == "RedHat" 

Nota:solo ejecuto iptables en mi familia de máquinas virtuales Red Hat. Si ejecuta iptables en todas sus máquinas virtuales, elimine el when: sección.

main.yaml se parece a esto:

Ejemplo 16:tareas/main.yaml

--- 

- include: create_prometheus_user.yaml

- include: setup_prometheus_node.yaml

- include: setup_prometheus_server.yaml

- include: prometheus_iptables.yaml

La pieza final es crear un libro de jugadas que abarque los roles que necesita para completar su tarea:

Ejemplo 17:libros de jugadas/monitoreo.yaml

- hosts: all

  roles:

    - role: ../roles/common

    - role: ../roles/monitoring

Unirlo todo

Sé que parece mucho texto, pero los conceptos para usar Ansible son bastante sencillos. Por lo general, solo se trata de saber cómo realizar la tarea que se propuso hacer y luego encontrar los módulos de Ansible adecuados para ayudar a realizarla. Si ha estado siguiendo este tutorial hasta el final, debería tener un diseño similar a este:

├── playbooks

│   ├── git_server.yaml

│   ├── monitoring.yaml

└── roles

    ├── common

    │   ├── files

    │   │   ├── systemd_check.fact

    │   │   ├── user1_ssh_key.pub

    │   │   └── user2_ssh_key.pub

    │   ├── handlers

    │   │   └── main.yaml

    │   ├── tasks

    │   │   ├── copy_systemd_facts.yaml

    │   │   ├── main.yaml

    │   │   ├── push_ssh_key.yaml

    │   │   ├── root_ssh_key_only.yaml

    │   └── vars

    │   └── main.yaml

    ├── monitoring

    │   ├── files

    │   │   ├── prometheus

    │   │   ├── prometheus_node_exporter

    │   │   ├── prometheus-node-exporter.conf

    │   │   ├── prometheus-node-exporter.service

    │   │   ├── prometheus.service

    │   │   └── systemd_check.fact

    │   ├── handlers

    │   │   └── main.yaml

    │   ├── tasks

    │   │   ├── create_prometheus_user.yaml

    │   │   ├── main.yaml

    │   │   ├── prometheus_iptables.yaml

    │   │   ├── setup_prometheus_node.yaml

    │   │   └── setup_prometheus_server.yaml

    │   ├── templates

    │   │   └── prometheus.yaml.j2

        └── vars

            └── main.yaml

Para ejecutar su libro de jugadas, ingrese:

[root@ansible-host production]# ansible-playbook -i <path to host file> playbooks/monitoring.yaml 

Ahora debería poder crear usuarios, presionar teclas ssh, verificar la existencia de systemd y desplegar el prometheus_node_exporter o el binario del servidor Prometheus a los servidores apropiados. Prometheus debe inicializarse con una configuración básica que incluya la lista de hosts que se especificaron en vars/main. yaml archivo en la función de supervisión.

¡Felicidades! Ahora ha automatizado la instalación y configuración de un servidor Prometheus básico y ha configurado sus hosts para comenzar a transmitir datos. Como efecto secundario agradable, también ha documentado de forma eficaz todos los pasos necesarios para lograr sus objetivos.

---

Anexo:Cuando concebí esta serie, iba a trabajar instalando Prometheus en OpenShift; sin embargo, al revisar la documentación del instalador de Ansible para OpenShift, descubrí que ya está incluido en un libro de jugadas y es una opción en el instalador.