Пишем свои метрики для Zabbix по-быстрому

В том числе. А еще иногда бывает так, что исторически сложилось что первая линия смотрит только в zabbix

Пишем свои метрики для Zabbix по-быстрому

Хорошее замечание, спасибо.

Да, через node_exporter и его textfile collector такие задачи действительно можно решать. По сути это тот же самый паттерн: локальный скрипт (grep, awk и т.д.) считает какое-то значение и сохраняет его в файл .prom, после чего node_exporter забирает эту метрику. Репозиторий с примерами скриптов как раз хорошо показывает этот подход.

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

1. добавить UserParameter

2. создать item

3. повесить trigger

И проверка начинает работать.

В Prometheus-подходе это тоже реализуемо, но обычно появляется несколько дополнительных шагов: нужно договориться о формате .prom, где будет лежать файл, чем он будет обновляться (cron/systemd timer), и дальше уже описывать alerting через PromQL.

То есть тут скорее не вопрос «можно / нельзя», а вопрос операционного пути внедрения.
Для некоторых задач (например, host-level метрик или периодических health-checks) textfile collector действительно отличный инструмент. Для быстрых ad-hoc проверок вроде поиска паттернов в логах Zabbix иногда оказывается чуть прямолинейнее.

Оба подхода рабочие, просто из разных экосистем 🙂

Установка Redis и мониторинг с помощью Zabbix

Добрый день! А чем sentinel в составе редиса мониторите ?

Как выжать из СУБД больше производительности? Подкручиваем параметры по урокам Майка Вазовски

Добрый день. Подскажите пожалуйста - может быть есть в планах внедрить формулы из данной утилиты в бандо инсталлятора Pangolin?

Не используйте теги в Ansible

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

Не используйте теги в Ansible

Я тут порефлексировал перечитывая статью. Очень хочется пожелать автору и всем читателям пореже сталкиваться с описанной в статье легаси-дичью

Как написать годную роль Ansible

ознакомился. спасибо за мнение

Не используйте теги в Ansible

Теги провоцируют императивный подход

Теги предполагают императивный подход к организации кода вместо декларативного. Использование тегов легко скатывается в подход «быстро и грязно». Вместо того чтобы задуматься над хорошей структурой ролей и плейбуков, правильно разделить код на осмысленные части и логически их включать в нужные места в соответствии с задачей, мы просто обвешиваемся тегами, а потом пытаемся получить предсказуемый результат, запуская их в неком произвольном сочетании.

теги не несут императивности. Императивность провоцирует необдуманное использование кучи локальных скриптов и плэйбуков.
Использование идемпотентного кода (в любых сочетаниях) предполагает предсказуемый результат. Это достигается кровью и потом соблюдением правил (относится как к ролям так и к плэйбукам):

• роль должна проходить в dryrun (check_mode) перед установкой полностью, а после установки, с использованием любого из тегов.

• роль с использованием любого сочетания тегов или без них должна приводить к идемпотентному выполнению без тегов (полностью).

Не используйте теги в Ansible

поддерживаю. но там тоже надо понимать, что и как применяется.

- name: Check variables
  include_tasks:
    file: pre_task.yml
    apply:
      tags: check # применяет тег ко всем таскам в файле
  tags: [check, vars]

при таком исполнении с использованием тега vars игра провалится в плэйбук pre_task, но выполнит только таски помеченные тегом vars

Не используйте теги в Ansible

а зачем использовать непротестированное? тестируйте - на то есть молекула и код ревью при мерже

Не используйте теги в Ansible

в целом поддерживаю мнение. но надо всё-таки предоставлять возможность провалиться в кишки роли. например, зачем каждый раз дергать архив инсталлятора, если нужно поменять сертификаты или дополнить конфиг? Если теги не ломают идемпотентность (после работы с тегами прогон без тегов пройдет идемпотентно) - это сэкономит кучу времени.

Как мы автоматизировали обновление, развёртывание и настройку Postgres-like СУБД для пользователей

Второй вопрос - как вы реализовали

При разработке метода обновления мы придерживались подхода, где обновление только обновляет (но не исправляет и не переконфигурирует СУБД и компоненты).

при обновлении пакетов ОС (кастомные конфиги сформированные ansible при таких манипуляциях перетираются значениями по умолчанию из пакета)?

Как мы автоматизировали обновление, развёртывание и настройку Postgres-like СУБД для пользователей

Добрый день. Спасибо за статью.

Такой вопрос - что Вы имели ввиду написав ?

Отмечу, что мы имеем две точки пользовательского конфигурирования — inventory и пользовательский конфигурационный файл.

Как написать годную роль Ansible

С удовольствием ознакомлюсь. Я считаю, что правильно построенная структура тегов сильно ускоряет и упрощает рутину.

Как написать годную роль Ansible

На вкус и цвет все фломастеры разные. При выборе из этих двух модулей я ориентируюсь на то что было написано до меня, стараясь писать понятные условия-проверки.

Учёл. Исправил.

Как написать годную роль Ansible

Можно использовать переменные

no_log: "{{ rolename_env_nolog }}"

Меняем на деве - радуемся. На проде можно в CI проверку вставить.

Как написать годную роль Ansible

Роль не знает ничего об окружении и других ролях. Про вспомогательный пакет я уже писал. apt yum dnf rmp не удаляют "чужие" используемые зависимости.

Как написать годную роль Ansible

Да. Именно версионирование я и исповедую. Поменялся урл - в новой версии инвентаря - задам новый. Хранить вечно - избыточно, но иметь возможность отката - необходимо.

Кстати, спасибо за идею.

Как написать годную роль Ansible

С рутом

Как написать годную роль Ansible

Опять по порядку, на основании собственно опыта.

Например, в ходе установки какого-то ПО понадобилось включить ip_forward. На первый раз решил включить руками

Один раз включаю руками, второй отлаживаю плэйбук, третий качу новой версией роли. Любой чих должен быть описан - так документируется инфраструктура как код.

Например, вам необходимо установить ПО, которое деплоится только через Docker Compose

Значит ставим Compose как зависимость. Вызывать тегами отдельную роль - для меня странно. Я придерживаюсь подхода в котором в любой роли теги имеют одинаковое именование. При вашем подходе, вместо изолированного конфигурирования роли А ( тег config) я пройдусь по по всему кластеру.

Про мультироли наверное самый яркий пример - установка отказоустойчивого кластера postgres. В некоторых случаях наверное это более понятная концепция, нежели вязать через CI/tower последовательный деплой.