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

    Довольно часто приходится разбираться с причинами падения linux серверов (здесь сразу оговоримся - речь идет о железных серверах). Обычно что дальше происходит? Запрашиваем remote IP-KVM, немного ждем, подключаемся и пытаемся в маленьком окне консоли разглядеть что же явилось причиной падения (особенно будет "удобно" когда эти логи будут затерты какими-то не существенными записями и что-то понять уже не получится). После перезагрузки можно конечно смотреть логи/дашборды и вполне может быть удастся понять причину падения или хотя бы примерное направление куда копать. Но бывает в логах в момент падения может быть нечто такое:

/var/log/syslog:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@.....@@@@@@@

 Некий бинарный мусор, который абсолютно не проясняет причину. 

    Для решения получения логов перед падением сервера уже давно существует нужное средство - netconsole, топорный модуль ядра, который отправит во вне лог, даже если уже ничего не работает на сервере.  Мы до некоторого времени обычно действовали так: сервер начал падать, в IP-KVM не удается найти причину, настраиваем руками netconsole на источнике логов, на каком-то произвольном сервере в tmux-е открываем порт и начинаем ловить сообщения. Но хостер оказался такой, что уровень железного брака довольно высок (догадайтесь  с 1-го раза кто :) ), плюс довольно часто некие баги ядра и пришло понимание, что настройку netconsole обязательно нужно настраивать для всех серверов. У всех в инфраструктуре могут использоваться разные Iac, у нас это saltstack, поэтому мы это сделали как-то так (на приемнике не забудьте заранее настроить syslog-ng/other programm). Думаю и для ansible можно сделать нечто подобное. В общем посыл статьи такой - используйте netconsole для разбора причин падений linux сервера, заранее автоматизируйте активацию и настройку модуля на сервере, это значительно ускорит  разбор полетов, не потребуется снова ждать когда сервер упадет.

    Также может быть оказаться полезной статья https://access.redhat.com/articles/2642741 - с помощью указанных способов можно научиться заранее понимать - штатно или нет произошло выключение сервера. Да, можно мониторить аптайм сервера и если он будет сброшен, то будет алерт в системе мониторинга с письмом в почтовом ящике (как вариант). Но возможен вариант, что сервер был перезагружен штатно, но например в системе мониторинга забыли на время отключить алерты для данного хоста. В общем, это еще один дополнительный вариант мониторинга "правильности" последнего ребута/старта хоста, который вполне может пригодиться.

  

   Долгое время мы активно использовали только  один стек для  приема метрик - на базе graphite (carbon-c-relay, carbon-clickhouse, graphite-clickhouse, clickhouse). Что это за стек, можно посмотреть в другой статье (https://linux96.ru/index.php/30-graphite-based-monitoring) и гитхаб страницах проектов. Все бы ничего, но новый софт почти по дефолту выставляет свои метрики в формате для прометея и чтобы получать метрики софта, в наличии есть только экспортеры. Прометей - это почти дефолт в мире мониторинга (как ansible в мире IaC), cнимать метрики  хочется, но слазить с graphite стека очень трудно и времязатратно. Что можно придумать?

Статья о том, когда есть данные продукты (https://www.saltstack.com/ и https://www.atlassian.com/ru/software/bamboo) в текущей инфраструктуре и захотелось их как-то связать между собой (запускать стейты солта из бамбу). Когда начинаешь гуглить подобный кейс, то каких-то примеров не находишь, а при создании своей реализации хочется сначала изучить чужой опыт, может быть взять что-то за основу (особенно всё печально, если перед этим не было опыта в других CI/CD). В общем, чтобы восполнить данный пробел, опишу как их вместе можно относительно "удобно" состыковать.

    Была мысль написать заметку о настройке modsecurity v3 (https://github.com/SpiderLabs/ModSecurity) в связке с nginx. Есть небольшая книжка как данный софт настраивать, где всё более-менее ясно описано что необходимо сделать, чтобы данная связка заработала. Но жизнь все-таки немного отличается от написанного в книгах.  Оказалось, что modsecurity v3 по факту в производственной среде просто не годен (по состоянию на июль 2020 года). Там встретились настолько детские ошибки, что возникает резонный вопрос - как такой софт можно писать? Я не работал с версией 2 (которая глубоко связана с apache2), но версия 3 произвела печальное впечатление.  Но обо всем по порядку.

Для чего может быть понадобится делать столь странные вещи? Например, одной из причин может быть использование стека приема метрик на базе graphite (т.е. push метрик вместо pull). Это конечно, менее молодежно, чем prometheus, но все равно имеет право на жизнь :).  В нашем случае может существовать некий софт, который заточен отдавать свои метрики для prometheus. Мне, в частности, встретился такой на пути - minio  (https://github.com/minio/minio). Вот и будем рассматривать на его примере.

    Почему просто не поднять prometheus и жить с двумя системами мониторинга? Мой ответ:  тогда prometheus надо бекапить(метрики), настраивать свою систему алертинга, в графане использовать еще один datasource. Зачем это делать, если уже все это реализовано  в своем стеке?  Можно prometheus  использовать просто как некий переходник. Для решения данной задачи могут подойти 2 продукта:

  • graphite-remote-adapter (https://github.com/criteo/graphite-remote-adapter)
  • telegraf - не проверял, но говорят у него можно использовать prometheus как input, а graphite - как output.

 

    Чтобы восстановить moira из бекапа - нет ничего сложного: берем дамп редиса и переносим на другую машину. Некоторая особенность может быть с тем, что в развернутом бекапе могут отсутствовать настроенные notifications (сами триггеры на месте). Это все из-за security модели moira - https://moira.readthedocs.io/en/latest/installation/security.html и заголовка X-WebAuth-User.

Если виртуальный хост например имел такой вид:

server_name moira.test.ru;
listen 80;

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_read_timeout 120;
    proxy_set_header Host            moira.test.ru;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-WEBAUTH-USER  $cwd_user;
    proxy_set_header Authorization   '';
    ...
}

 где $cwd_user - это переменная, которая передается при crowd авторизации, соответственно, если  в новой moira начнем передавать в данном заголовке другое значение (нет crowd авторизации или предполагается передавать  в заголовке X-WEBAUTH-USER всегда одно значение ), то потеряем все настройки notifications и subscriptions. Как же можно восстановить все подписки  и уведомления? Достаточно заглянуть в дамп редиса следующим запросом:

redis-cli --scan --pattern 'moira-user-*'
moira-user-subscriptions:test1
moira-user-contacts:test1
moira-user-contacts:test2
moira-user-contacts:test3
moira-user-subscriptions:test2
moira-user-subscriptions:test3

Зная возможные значения moira-user-contacts, можно передавать их значения в заголовке X-WEBAUTH-USER, тем самым восстановить notifications и subscriptions.

В сети есть некоторое количество информации о том как две указанные вещи можно связать:

https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.vault.html

https://support.saltstack.com/Third-party_Solutions/HashiCorp/Quick_Guide_to_Vault_Integration

https://medium.com/@aratik711/saltstack-and-vault-integration-20eeb2e7ec9c

https://backbeat.tech/blog/secure-servers-with-saltstack-and-vault-part-2/

Интеграция предполагает множество вариантов, в которых не так-то просто разобраться.

Речь о проекте https://github.com/moira-alert/moira - системе алертинга для graphite monitoring (как alertmanager у prometheus). Небольшая заметка по advaced trigger: в документации есть совсем немного примеров по их использованию - https://moira.readthedocs.io/en/latest/user_guide/advanced.html. Там приведен один пример и идет отсылка к чтению https://github.com/Knetic/govaluate/blob/master/MANUAL.md для дальнейшего написания таких триггеров. У меня возникло небольшое непонимание по данному синтаксису (как правильно прочитать выражение, которое идет после знака вопроса ?), в моем случае я хотел создать триггер, которые сработает как ERROR, если у сервера №1 или сервера №2 потребляемая память будет больше некоторого порога (42G):

создал 2 таргета:

T1 - stats.berlin.memory.memory.used,
T2 - stats.moscow.memory.memory.used

 Триггер:

(t1 > 45097156608 || t2 > 45097156608) ? ERROR:OK

 Составил выражение больше по наитию, но спасибо, что в телеграм канале https://t.me/moira_alert  быстро подсказали как читать это выражение и как правильнее это загуглить - Тернарная_условная_операция в Си:

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

 Соответственно, можно таким же образом оперировать всеми 4-мя состояниями метрик у moira - OK, WARN, ERROR, NODATA.

Может случиться так, что в вашу систему мониторинга на основе graphite + clickhouse попало что-то лишнее/неправильно сформированная метрика или вдруг метрики от приложения/сервера вам стали больше не нужны.

На самом деле многое зависит от схемы именования метрик, если она хорошо спроектирована, то удаление может и не понадобиться. Например, у нас она не очень удачна - все базируется на имени хоста (по-хорошему надо отталкиваться от имени application, которое шлет метрики, например, stats.collectd.my-server1.load):

stats.my-server1
stats.my-server1.load
stats.my-server1.load.midterm
stats.my-server1.load.longterm
stats.my-server1.load.shortterm
stats.my-server1.memory
stats.my-server1.nginx
...
stats.my-server2
stats.my-server2.load
stats.my-server2.load.midterm
...
 

    Есть 2 подхода для съема метрик - pull (яркий представитель - prometheus) и push (яркий представитель - graphite).  Graphite - это мониторинг, состоящий из целой пачки различных микросервисов, некоторые уже почили в бозе, некоторые еще живы. Я по приходу в компанию, где сейчас работаю, застал такую расстановку сил: brubeck (для агрегации метрик), go-carbon ( занимается тем, что принимает метрики от всех и отдаёт их carbonapi), carbonapi (демон отдаёт метрики клиентам (в частности grafana)).

Предполагается, что читающий знаком с saltstack (https://www.saltstack.com/), писал для него стейты, подключал пиллары или еще чего-нибудь). В этой заметке попробуем реализовать свой state через cmd.run - он будет изменять данные только в случае необходимости плюс покажет нам, что он будет менять в режиме test=true.

Есть стандартная схема для работы нескольких сайтов

 

Начальные данные:

  • Site1 открывается приемлемое время, Site2 - долго (4-5 сек).
  • В браузере задержка  открытия проблемного сайта связана с высоким Waiting TTFB
  • Site1 и Site2  запущены  на одинаковых движках CMS (wordpress),
  • Site1 и Site2 уже имеют готовый контент
  • Трафик на оба сайта отсутствует

    Всем привет. Предположим, мы настроили связку https://github.com/ableev/Zabbix-in-Telegram . Получаем в telegram события с графиками по событиям триггеров, классно. Можно чуть развить идею и самим заставить ботa telegram отправлять нам графики из заббикса.

Схема пусть будет следующая:

 

 

 

После длительной нормальной работы ldap сервера вдруг начала появляться ошибка при старте:

Oct 18 10:47:22 server slapd[1416]: daemon: bind(10) failed errno=2 (No such file or directory)
Oct 18 10:47:22 server slapd[1416]: slapd stopped.

 

Выяснилось, что slapd не нравился путь до ldapi URL. Решения два: в файле /etc/default/slapd указать просто ldap URL или для ldapi указать путь до файла:

SLAPD_SERVICES="ldap:///"

или

SLAPD_SERVICES="ldap:/// ldapi://%2Fvar%2Frun%2Fopenldap%2Fldapi"

Если на компе с линуксом установлен обычный firefox без доп. плагинов (например в дефолтной установке ubuntu), настроен tor в режиме прозрачного прокси, то для доступа к onion доменам необходимо указывать в конце url точку, например:

https://3g2upl4pq6kufc4m.onion  - такое не пройдет (напишет, что сайт недоступен и необходимо проверить сетевое подключение)

https://3g2upl4pq6kufc4m.onion.  - с точкой в конце адреса сайт загрузится.

Если поставить другой браузер, то все работает как и ожидается.

Если прочитать статью https://habrahabr.ru/post/173045/ , то получается, что firefox, видимо,  воспринимает такой домен как относительный.

Сообщение в багзилле: https://bugzilla.mozilla.org/show_bug.cgi?id=1394756

В 9 (stretch) дебиане убрали пакет libmyodbc из репозитория. Теперь даже при установке пакета mysql-server  в качестве сервера БД поставится mariadb-server:

apt-get install mysql-server

ps uax | grep mysql
mysql     2893  1.1  7.2 653456 73824 ?        Ssl  10:01   0:00 /usr/sbin/mysqld

dpkg -S /usr/sbin/mysqld
mariadb-server-core-10.1: /usr/sbin/mysqld

 Значит необходимо настроить odbc для mariadb, благо ничего сложного.

    Цель: хотим автоматизировать генерирование виртуалок из шаблона в vcenter, используя какую-либо систему управления конфигурациями (ansible) или утилиту управления облачными ресурсами (terraform). Что получим в итоге - развернутую виртуалку и основное ради чего это затевалось - ее ip адрес. В документации по обоим продуктам все в принципе расписано, просто скомпоную в одном месте + некоторые свои пометки.

 

    Для расширения кругозора решил попробовать  jenkins  как  GUI для ансибла. ПО Jenkins - это все больше для девопсов и программистов, но почему его не попробовать офисному админу, периодически использующего ансибл?

  1. отправка почтового сообщения с русскими буквами в астериске
  2. Быстрая установка рабочей станции линукс из шаблона
  3. Мысли по настройке asterisk ч.2

Please publish modules in offcanvas position.