Введение

Ни для кого не секрет, что на текущий момент регуляторы занимаются активным внедрением отечественных операционных систем на базе Linux/Unix в инфраструктуры государственных компаний. Это создает головную боль для рядовых пользователей, привыкших к интуитивно понятному интерфейсу Windows, работающих с соответствующими текстовыми редакторами и привычными за годы программами, а также для сетевых инженеров, годами работающих с Windows инфраструктурой. Перед ними стоят задачи миграции сервисов на другую ОС и, часто, обучение пользователей работе в новой среде.

Как правило, рано или поздно система приходит к равновесному состоянию: часть пользователей работает на рабочих станциях Windows, специалисты — на Unix-подобных операционных системах. Наша инфраструктура становится гетерогенной, и для её устойчивой работы важно обеспечить мониторинг.

В этой статье мы рассмотрим достоинства и недостатки популярных систем мониторинга, а также развернем их в гетерогенной среде Windows-Linux.

Немного теории

Что дает мониторинг?

1. Вовремя обнаружить проблемы

2. Оценить производительность серверов и хостов и не дать им "упасть"

3. Обнаружить аномальную активность и среагировать на попытки вторжения

4. Анализировать тренды и своевременно планировать оптимизацию хостов и сети

5. Подготовить отчеты и аналитику для руководства, чтобы аргументированно доказать необходимость в денежных инвестициях

Как и всегда выбор средства зависит от задач. Сравним систему Zabbix с Prometheus (для визуализации метрик будем использовать Graphana ).

Zabbix

Преимущества:

1. Полное решение из одного источника: Zabbix является комплексным решением, которое предлагает мониторинг, оповещения и построение отчетов в одной системе.

2. Готовность к использованию из коробки: Имеет множество предустановленных шаблонов и интеграций, что облегчает его настройку и развертывание.

3. Сбор данных в реальном времени: Поддерживает длинные задержки между запросами и может отслеживать данные в реальном времени.

4. Поддержка различных типов данных: Может работать с агентами для различных платформ, поддерживать SNMP, IPMI, JMX, и др.

5. Разветвлённая система оповещений: Поддержка различных каналов уведомлений и гибких условий срабатывания триггеров.

Недостатки:

1. Сложность настройки: Несмотря на наличие шаблонов, интеграции и адаптация для специфических нужд могут требовать значительных усилий.

2. Хранение данных: Использует реляционные БД для хранения данных, что в больших масштабах может требовать серьёзных ресурсов.

3. Масштабируемость: На больших объемах данных может возникнуть проблема масштабируемости и производительности.

Prometheus + Grafana

Преимущества:

1. Модульность и гибкость: Prometheus отвечает за сбор, хранение и обработку метрик, тогда как Grafana используется для их визуализации, обеспечивая гибкость в выборе инструментов.

2. Хорошая масштабируемость: Prometheus разработан для сбора метрик на больших и динамических системах, обеспечивая высокую производительность и масштабируемость.

3. Мощный язык запросов: PromQL позволяет выполнять сложные аналитические задачи и получать необходимую информацию из собранных метрик.

4. Интеграция с облачными сервисами: Поддержка для облаков и контейнерных сред, таких как Kubernetes.

5. Сообщество и экосистема: Большая экосистема и сильное сообщество разработчиков и пользователей.

Недостатки:

1. Кратковременное хранение данных: Преимущественно ориентирован на кратковременное хранение данных, хотя интеграция с внешними хранилищами позволяет решить эту проблему.

2. Отсутствие интегрированной системы оповещений: Хотя Prometheus включает механизм alertmanager, он меньше интегрирован по сравнению с Zabbix.

3. Сложность настройки и эксплуатации: Нужно настраивать и администрировать два или больше отдельных компонента (Prometheus и Grafana) плюс Alertmanager.

Практика

Последовательно развернем системы в соответствии с со схемами

Zabbix

Установить Zabbix сервер очень просто. На официальном сайте есть конфигуратор со всеми необходимыми командами с помощью которых можно подготовить Linux хост, подробно рассматривать этот вопрос не будем.

Конфигурация сервера

Если мы хотим автоматизировать процесс подключения агентов к серверу, группировать их по типу операционной системы и привязывать к конкретным шаблонам, то следует настроить авторегистрацию. Для этого проходим в:

Оповещение - действие - действие авторегистрации

Создать - имя - autoreg_linux
Условия - Метаданные узлов сети - содержит - Linux
Операции:

1. Добавить узел сети

2. Активировать узел сети

3. Отправить сообщение пользователям: Admin через все способы оповещения

4. Добавить в группы узлов сети: Station_linux

5. Присоединить к шаблонам: Linux by Zabbix agent

Создать - имя - autoreg_windows
Условия - Метаданные узлов сети - содержит - Windows
Операции:

1. Добавить узел сети

2. Активировать узел сети

3. Отправить сообщение пользователям: Admin через все способы оповещения

4. Добавить в группы узлов сети: Station_Windows

5. Присоединить к шаблонам: Windows by Zabbix agent

Не забываем заранее создать соответствующие группы.

Подготовка хостов - Linux

Установка в ручном режиме так же проста как сервера.

Давайте лучше рассмотрим, как произвести установку централизованно в автоматическом режиме. Я использую Puppet и Ansible для этих целей. Первый для поддержки долговременной инфраструктуры, где хосты не являются рабочими машинами и периодически могут быть недоступны, второй преимущественно для виртуальных хостов и серверов.

Почему так? Puppet использует агентов на хостах, периодически сверяющих конфигурацию системы с конфигурацией на сервере. Сверка происходит регулярно и рано или поздно все машины будут приведены к единообразию. Для Ansible же важно чтобы хост в текущий момент времени был включен и готов принять автономный пакет python который ему шлет сервер. Агентов у Ansibe нет, что является его преимуществом и одновременно недостатком в определенных случаях.

В нашем случаем используем Ansible и для работы мы должны создать 3 каталога со своей структурой:

• инвентарь (как создавать подробно описал в статье)

• роль

• плейбук

Из особенностей укажем в глобальных переменных адрес сервера Zabbix. Заранее извиняюсь, если непривычно, но для компактности и без того длинной статьи укажу все команды и комментарии в кодовой строке в таком вот специфичном формате:

touch inventory/group_vars/all.yml
#>
---
zabbix_server_addr: 192.168.2.101
#<>

Роль

mkdir roles
# создание каталогов роли
ansible-galaxy role init roles/zabbix_agent

# редактируем:
roles/zabbix_agent/tasks/main.yml
#>
---
- name: Add repo Zabbix
  ansible.builtin.template:
    src: zabbix.list.j2
    dest: /etc/apt/sources.list.d/zabbix.list
    owner: root
    group: root
    mode: '0644'

- name: Add Zabbix GPG Key
  ansible.builtin.copy:
    src: zabbix-official-repo.gpg
    dest: /etc/apt/trusted.gpg.d/
    owner: root
    group: root
    mode: '0644'
  notify: Update_apt_cache

- name: Install Zabbix
  ansible.builtin.apt:
    name: zabbix-agent
    state: present

- name: Config Zabbix-agent
  ansible.builtin.template:
    src: zabbix_agentd.conf.j2
    dest: /etc/zabbix/zabbix_agentd.conf
    owner: zabbix
    group: zabbix
    mode: '0755'
  vars:
    current_hostname: "{{ ansible_facts.hostname }}"

- name: Ensure log directory exists
  ansible.builtin.file:
    path: /var/log/zabbix
    state: directory
    owner: zabbix
    group: zabbix
    mode: '0755'

- name: Start, autostart Zabbix-agent
  ansible.builtin.service:
    name: zabbix-agent
    state: restarted
    enabled: true

# --- тест службы
- name: Pause
  ansible.builtin.pause:
    seconds: 3
  tags: test

- name: Test service status
  ansible.builtin.systemd:
    name: zabbix-agent
    state: started
  register: service_status
  tags: test

- name: Message service fail
  ansible.builtin.fail:
    msg: "Служба не запущена!"
  when: service_status.status.ActiveState != 'active'

- name: Message service success
  ansible.builtin.debug:
    msg: "Служба запущена успешно!"
  when: service_status.status.ActiveState == 'active'

#<>

touch roles/zabbix_agent/templates/zabbix.list.j2
#>
# Generate for Ansible
{% for repo in zabbix_agent__repo %}
{{ repo }}
{% endfor %}
#<>

roles/zabbix_agent/defaults/main.yml
#>
---
zabbix_agent__repo:
  - deb https://repo.zabbix.com/zabbix/6.4/debian bookworm main
  - deb-src https://repo.zabbix.com/zabbix/6.4/debian bookworm main
#<>

# переносим ключ репозитория в роль
cp /etc/apt/trusted.gpg.d/zabbix-official-repo.gpg roles/zabbix_agent/files/

# обработчик
roles/zabbix_agent/handlers/main.yml
#>
---
# обновление кеша пакетного менеджера
- name: Update_apt_cache
  ansible.builtin.apt:
    update_cache: true
#<>

# шаблон конфига zabbix agent
touch roles/zabbix_agent/templates/zabbix_agentd.conf.j2
#>
# Generate for Ansible
PidFile=/run/zabbix/zabbix_agentd.pid
LogFile=/var/log/zabbix/zabbix_agentd.log
LogFileSize=0
Server={{ zabbix_server_addr }} 
ServerActive={{ zabbix_server_addr }}
Hostname={{ current_hostname }}
# Include=/etc/zabbix/zabbix_agentd.d/*.conf
HostMetadataItem=system.uname
#<>

Что делает роль:

1. Подключает репозитории через шаблон и добавляет соответствующий ключ, который нужно загрузить заранее (он появится у вас при установке zabbix сервера)

2. Устанавливает агента и конфигурирует также через шаблон jinja (в конфигурации агента строка HostMetadataItem=system.uname позволяет службе авторегистрации сервера понять с какой операционной системой ему работать)

3. Проверяет что служба агента работает без ошибок.

Не забываем открыть порт 10050 на хосте и 10051 на сервере.

Плейбук

mkdir playbooks
touch playbooks/zabbix.yml
playbooks/zabbix.yml
#>
- name: Zabbix
  hosts: station
  roles:
    - zabbix_agent
#<>

После запуска плейбука указанные хосты появятся на нашем сервере подключатся к необходимым шаблонам.

Подготовка хостов - Windows

Качаем пакет msi с официального сайта, проверяем чтобы версия установщика совпадала с версией сервера. Распространять пакет удобнее всего через групповые политики домена Active Directory, подробно описывать не буду, так как это момент простой и материалов на эту тему много. Скажу лишь, что перед распространением наш пакет msi необходимо модифицировать с применением редактора Orca. Можно править и конфигурационной файл, но лично мне такой способ нравится больше.

Для этого в таблицу Property вводим строки со значениями:
SERVER = 192.168.2.101
SERVERACTIVE = 192.168.2.101
LISTENPORT = 30001

Не забываем что для авторегистрации на сервере нам нужно передать метаданные в конфигурационный файл агента, для этого готовим скрипт и организуем его запуск чрез групповые политики

Обновляем политики, убедимся что нужные порты открыты и идем на сервер

Prometheus + Grafana

Тут все немного сложнее, поскольку Prometheus предназначен больше для легковесного запуска в контейнерах, для запуска в качестве сервера мониторинга нам нужно создать службы для работы соответствующих исполняемых файлов, подключить необходимые компоненты для оповещений. Руками делать все это крайне долго, развернем сервер через Ansible с помощью роли

mkdir roles
# создание каталогов роли
ansible-galaxy role init roles/prometheus_server

# редактируем:
roles/prometheus_server/tasks/main.yml
#>
---
# Promrtheus
- name: Create Prometheus directory
  ansible.builtin.file:
    path: /etc/prometheus
    state: directory
    mode: '0755'

- name: Download Prometheus
  ansible.builtin.get_url:
    url: "{{ prometheus_server__url }}"
    dest: "{{ prometheus_server__archive_path }}"
    mode: '0644'
    force: no

- name: Extract Prometheus
  ansible.builtin.unarchive:
    src: "{{ prometheus_server__archive_path }}"
    dest: /tmp/
    remote_src: true

- name: Move Prometheus binaries
  ansible.builtin.copy:
    src: "{{ prometheus_server__extract_path }}/{{ item }}"
    dest: /usr/local/bin/
    mode: '0755'
    remote_src: true
  with_items:
    - prometheus
    - promtool

- name: Move Prometheus configs
  ansible.builtin.copy:
    src: "{{ prometheus_server__extract_path }}/{{ item }}"
    dest: /etc/prometheus/
    remote_src: true
    mode: '0644'
  with_items:
    - consoles
    - console_libraries

- name: Create Prometheus user
  ansible.builtin.user:
    name: prometheus
    shell: /bin/false

- name: Change ownership of Prometheus directories
  ansible.builtin.file:
    path: /etc/prometheus
    owner: prometheus
    group: prometheus
    recurse: true

- name: Create Prometheus directory
  ansible.builtin.file:
    path: /var/lib/prometheus/
    state: directory
    mode: '0755'
    owner: prometheus
    group: prometheus

# Alertmanager
- name: Create configuration directory Alertmanager
  ansible.builtin.file:
    path: /etc/alertmanager
    state: directory
    mode: '0755'

- name: Download Alertmanager
  ansible.builtin.get_url:
    url: "{{ prometheus_server__alertmanager_url }}"
    dest: "{{ prometheus_server__alertmanager_archive_path }}"
    mode: '0644'

- name: Extract Alertmanager
  ansible.builtin.unarchive:
    src: "{{ prometheus_server__alertmanager_archive_path }}"
    dest: /tmp/
    remote_src: true

- name: Move Alertmanager binaries
  ansible.builtin.copy:
    src: "{{ prometheus_server__alertmanager_extract_path }}/{{ item }}"
    dest: /usr/local/bin/
    mode: '0755'
    remote_src: true
  with_items:
    - alertmanager
    - amtool

- name: Create Alertmanager user
  ansible.builtin.user:
    name: alertmanager
    shell: /bin/false

- name: Change ownership of Alertmanager directories
  ansible.builtin.file:
    path: /etc/alertmanager
    owner: alertmanager
    group: alertmanager
    recurse: true

- name: Create Alertmanager directory
  ansible.builtin.file:
    path: /var/lib/alertmanager/
    state: directory
    mode: '0755'
    owner: alertmanager
    group: alertmanager

# config files 
- name: Deploy config alert_rules
  ansible.builtin.copy:
    src: "files/{{ item }}"
    dest: /etc/prometheus/
    owner: prometheus
    group: prometheus
    mode: '0644'
  with_items:
    - alert_rules.yml

- name: Deploy config prometheus
  ansible.builtin.template:
    src: "prometheus.yml.j2"
    dest: /etc/prometheus/prometheus.yml
    owner: prometheus
    group: prometheus
    mode: '0644'

- name: Deploy config alertmanager
  ansible.builtin.template:
    src: "alertmanager.yml.j2"
    dest: /etc/alertmanager/alertmanager.yml
    owner: alertmanager
    group: alertmanager
    mode: '0644'

# service
- name: Template Prometheus service
  ansible.builtin.template:
    src: templates/prometheus.service.j2
    dest: /etc/systemd/system/prometheus.service
    mode: '0644'

- name: Template Alertmanager service
  ansible.builtin.template:
    src: templates/alertmanager.service.j2
    dest: /etc/systemd/system/alertmanager.service
    mode: '0644'

- name: Reload systemd
  ansible.builtin.systemd:
    daemon_reload: true

- name: Enable and restart Prometheus service
  ansible.builtin.systemd:
    name: prometheus
    enabled: true
    state: restarted

- name: Enable and restart Alertmanager service
  ansible.builtin.systemd:
    name: alertmanager
    enabled: true
    state: restarted

# --- tests
- name: Pause
  ansible.builtin.pause:
    seconds: 3
  tags: test

- name: Test service status prometheus
  ansible.builtin.systemd:
    name: prometheus
    state: started
  register: service_status_prometheus
  tags: test

- name: Test service status alertmanager
  ansible.builtin.systemd:
    name: alertmanager
    state: started
  register: service_status_alertmanager
  tags: test

- name: Message service fail prometheus
  ansible.builtin.fail:
    msg: "Служба не запущена! - prometheus"
  when: service_status_prometheus.status.ActiveState != 'active'

- name: Message service fail alertmanager
  ansible.builtin.fail:
    msg: "Служба не запущена! - alertmanager"
  when: service_status_alertmanager.status.ActiveState != 'active'

- name: Message service success prometheus
  ansible.builtin.debug:
    msg: "Служба запущена успешно! - prometheus"
  when: service_status_prometheus.status.ActiveState == 'active'

- name: Message service success alertmanager
  ansible.builtin.debug:
    msg: "Служба запущена успешно! - alertmanager"
  when: service_status_prometheus.status.ActiveState == 'active'
#<>

# создаем шаблоны служб и конфигурационных файлов prometheus и alertmanager
roles/prometheus_server/templates/alertmanager.service.j2
#>
[Unit]
Description=AlertManager Service
After=network.target

[Service]
User=alertmanager
ExecStart=/usr/local/bin/alertmanager \
--config.file=/etc/alertmanager/alertmanager.yml \
--storage.path=/var/lib/alertmanager

Restart=always

[Install]
WantedBy=multi-user.target
#<>

roles/prometheus_server/templates/alertmanager.yml.j2
#>
   route:
     group_by: ['alertname', 'instance', 'severity']
     group_wait: 20s
     group_interval: 20s
     repeat_interval: 12h
     receiver: 'telepush'
   
   receivers:
     - name: 'telepush'
       webhook_configs:
         - url: '{{ prometheus_server__url_telepush }}'
           http_config: {}  
   
   inhibit_rules:
     - source_match:
         severity: 'critical'
       target_match:
         severity: 'warning'
       equal: ['alertname', 'dev', 'instance']
#<>

roles/prometheus_server/templates/prometheus.service.j2
#>
[Unit]
Description=Prometheus
Wants=network-online.target
After=network-online.target

[Service]
User=prometheus
ExecStart=/usr/local/bin/prometheus \
  --config.file=/etc/prometheus/prometheus.yml \
  --storage.tsdb.path=/var/lib/prometheus/ 

[Install]
WantedBy=multi-user.target
#<>

roles/prometheus_server/templates/prometheus.yml.j2
#>
global:
  scrape_interval: 20s
  evaluation_interval: 10s

rule_files:
  - alert_rules.yml
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      - localhost:9093

# server
scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

# --- lup
  - job_name: 'linux'
    static_configs:
      - targets: ['192.168.2.101:9100']
      - targets: ['192.168.2.103:9100']

# windows
  - job_name: 'windows'
    static_configs:
      - targets: ['192.168.2.100:9182']
      - targets: ['192.168.2.102:9182']
#<>

# внутренние переменные роли для создания ссылок для скачивания и директорий размещени файлов
roles/prometheus_server/vars/main.yml
#>
---
prometheus_server__url: "{{ prometheus_server__repo }}/v{{ prometheus_server__version }}/prometheus-{{ prometheus_server__version }}.linux-amd64.tar.gz"
prometheus_server__repo: "https://github.com/prometheus/prometheus/releases/download"
prometheus_server__archive_path: "/tmp/prometheus-{{ prometheus_server__version }}.linux-amd64.tar.gz"
prometheus_server__extract_path: "/tmp/prometheus-{{ prometheus_server__version }}.linux-amd64"

prometheus_server__alertmanager_url: "https://github.com/prometheus/alertmanager/releases/download/{{ prometheus_server__alertmanager_filename }}.tar.gz"
prometheus_server__alertmanager_filename: "v{{ prometheus_server__alertmanager_version }}/alertmanager-{{ prometheus_server__alertmanager_version }}.linux-amd64"
prometheus_server__alertmanager_archive_path: "/tmp/alertmanager-{{ prometheus_server__alertmanager_version }}.linux-amd64.tar.gz"
prometheus_server__alertmanager_extract_path: "/tmp/alertmanager-{{ prometheus_server__alertmanager_version }}.linux-amd64"
#<>

# обработчик для обновления кеша пакетного менеджера
roles/prometheus_server/handlers/main.yml
#>
---
- name: Update_apt_cache
  ansible.builtin.apt:
    update_cache: true
#<>

# конфиг с правилами алертменеджера разместил в директрии files из за ошибок при работе с шаблонами (нужно экранировать определенные символы, решил не мучать себя этим, тем более переменных не передаю)
roles/prometheus_server/files/alert_rules.yml
#>
groups:
  - name: Critical alerts  
    rules:
      - alert: InstanceDown
        expr: up == 0
        for: 5m
        labels:
          severity: critical
        annotations:
          description: '{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 1 minute.'
          summary: Instance {{ $labels.instance }} down
#<>

# ну и в дефолте разместил переменные которые можно переопределить при запуске плейбуков
roles/prometheus_server/defaults/main.yml
#>
---
prometheus_server__version: "2.54.0"
prometheus_server__alertmanager_version: "0.27.0"
#<>

В моем случае оповещение работает через телеграмм, поэтому добавляем в инвентарь файл sinventory/secrets.yml с переменной "prometheus_server__url_telepush" c url для связи с телеграмм ботом telepush. Не забываем шифровать данный файл с помощью Ansible Vailt. Как это делать, можно подсмотреть тут.

Оповещения о работе хостов в моем случае выглядят так.

Настройка станций Linux

Для настройки станций нужна роль, создающая службы для работы исполняемых файлов и устанавливающая Node Exporter

mkdir roles
# создание каталогов роли
ansible-galaxy role init roles/prometheus_nodeexporter

# редактируем:
roles/prometheus_nodeexporter/tasks/main.yml
#>
- name: Skip
  when: ansible_os_family != 'Debian'
  block:
    - name: Message
      ansible.builtin.debug:
        msg: "Skipping tasks ."

- name: Install Node Exporter
  when: ansible_os_family == 'Debian'
  block:
    - name: Download Node Exporter
      ansible.builtin.get_url:
        url: "{{ prometheus_nodeexporter_url }}"
        dest: "/tmp/node_exporter.tar.gz"
        mode: '0644'

    - name: Extract Node Exporter
      ansible.builtin.unarchive:
        src: "/tmp/node_exporter.tar.gz"
        dest: "/usr/local/bin"
        remote_src: true

    - name: Move Node Exporter binaries
      ansible.builtin.copy:
        src: /usr/local/bin/node_exporter-{{ prometheus_nodeexporter__exporter_version }}.linux-amd64/node_exporter
        dest: /usr/local/bin/node_exporter
        owner: root
        group: root
        mode: '0755'
        remote_src: true

    - name: Template service
      ansible.builtin.template:
        src: node_exporter.service.j2
        dest: /etc/systemd/system/node_exporter.service
        mode: '0644'

    - name: Reload systemd
      ansible.builtin.systemd:
        daemon_reload: true

    - name: Enable and start Node Exporter service
      ansible.builtin.systemd:
        name: node_exporter
        enabled: true
        state: restarted

    - name: Clean up
      ansible.builtin.file:
        path: /tmp/node_exporter.tar.gz
        state: absent

    # --- тест службы
    - name: Pause
      ansible.builtin.pause:
        seconds: 3
      tags: test

    - name: Test service status
      ansible.builtin.systemd:
        name: node_exporter
        state: started
      register: service_status
      tags: test

    - name: Message service fail
      ansible.builtin.fail:
        msg: "Служба не запущена!"
      when: service_status.status.ActiveState != 'active'

    - name: Message service success
      ansible.builtin.debug:
        msg: "Служба запущена успешно!"
      when: service_status.status.ActiveState == 'active'
#<>

roles/prometheus_nodeexporter/templates/node_exporter.service.j2
#>
[Unit]
Description=Node Exporter

[Service]
User=nobody
ExecStart=/usr/local/bin/node_exporter

[Install]
WantedBy=default.target
#<>

roles/prometheus_nodeexporter/vars/main.yml
#>
---
prometheus_nodeexporter_url: "https://github.com/prometheus/node_exporter/releases/latest/download/{{ prometheus_nodeexporter_file }}"
prometheus_nodeexporter_file: "node_exporter-{{ prometheus_nodeexporter__exporter_version }}.linux-amd64.tar.gz"
#<>

roles/prometheus_nodeexporter/files/prometheus.yml
#>
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']
#<>

roles/prometheus_nodeexporter/defaults/main.yml
#>
---
prometheus_nodeexporter__exporter_version: "1.8.2"
#<>

Настройка станций Windows

Просто качаем msi последнего Windows Exporter с github и устанавливаем через GPO.

Не забываем открыть порт 9182 на Windows станциях через gpo. Можно для теста сделать это командой PowerShell.

New-NetFirewallRule -DisplayName "Allow Port 9182" -Direction Inbound -Protocol TCP -LocalPort 9182 -Action Allow

Graphana

Ставится просто через пакет с официального сайта.

sudo apt-get install -y apt-transport-https software-properties-common wget
wget https://dl.grafana.com/oss/release/grafana_8.4.2_amd64.deb
sudo dpkg -i grafana_8.4.2_amd64.deb
sudo systemctl enable grafana-server; systemctl start grafana-server
sudo apt --fix-broken install
sudo ufw allow 3000/tcp

Заходим в http://localhost:3000

Логин и пароль по умолчанию в Grafana: **admin : admin**

Для подключения Prometheus ищем в консоли Grafana - Connections - Data sources - Add data source - Prometheus - http://localhost:9090 - Save & Test

Как язык запросов PromQL (Prometheus Query Language) тут писать не буду, но он крайне мощный. Это точно тема отдельной статьи.

Поэтом просто импортируем дашборд из библиотеки:

Dashboard - Import dashbord - Data Source: Prometheus

Для Windows мне понравился - id 20763

Для Linux - id 11074

В нашем случае полезно будет в перспективе модифицировать дашборд из готовых, сделав источником не только Node Exporter, но и Windows Exporter, чтобы наблюдать за всеми станциями разом.

Prometheus и приложения

Отдельно хочу отметить что prometheus имеет множество клиентских библиотек. Например в приложении, разработанном мной на Python для инвентарного учета технических средств

я собираю такие вот метрики:

Выводы

Обе системы мониторинга имеют свои преимущества и недостатки, "идеального" решения как всегда нет.

Zabbix - комплексное решение с мощной системой оповещения и поддержкой множества стандартов из коробки, но менее гибок в работе с метриками.

Prometheus - обладает отличной масштабируемостью, гибок, удобен для контейнерных или облачных технологий, а также приложений, однако сложнее в настройке.