Гугл и намеки
Гуглил нужные рефы для GitLab CI забытые (потому что пока используются у нас раз в пять лет). Рефы нашел сразу же, но выдача Гугла была прекрасна:
Кейс по алертам из Prometheus
Как известно Prometheus хранит метрики в временных рядах. Состоят они из имени метрики, лейблов со значением и собственно значением самой метрики. И при этом каждое сочетание лейблов и их значений порождает из метрики новый временной ряд. И вот здесь зарыта интересная собака. Предисловие:
Ansible, магия и смирение
Изучая вчерашний кейс с передачей переменных в Ansible, имею сказать, что вероятно проблема в том, что любая передаваемая через командную строку переменная передается как строка. Используем волшебные много "-vvvvvvvvv" при запуске (то есть дебаг-мод) и видим:
Ansible, списки, костыли и магия
В рамках задачи писал с нуля роль для Ansible, чтобы пользователями в БД управлять. Среди прочего - надо ей принять список из командной строки по запуску, а потом сравнить его с структурой данных из yml-файла и сделать действия. И вот на этот моменте нашлось забавное (нет) поведение Ansible, которые пришлось подпирать костылями.
GitLab Runners и неожиданные перевоплощения
У GitLab для выполнения его CI используются внешние сервисы - раннеры (runners). Про них можно написать много (и написано очень много), но у них есть среди их свойств одно, про которое и пойдет речь.
TTL пользователей в MongoDB
Решая задачу по выставлению TTL пользователей в MongoDB столкнулся с парой моментов ее специфики.
Глюк связки Grafana и Loki
У связки Grafana+Loki есть занятный глюк. Если вам надо получить значение какой-то метки в переменную в Grafana, то вы можете выбрать как источник данных свой Loki и использовать весьма простое выражение:
Хозяйке на заметку
Есть у Windows-версии клиента Git одно плохое-плохое свойство - страсть как любит при стягивании репозитория автоматом ставить там перевод строки CR/LF, Windows же, чо.
Про метрики, а именно - вычисление всяких SLA в Grafana + Prometheus
Бывает такая веселая задача, как посчитать SLA какого-нибудь сервиса. Это весьма легко для метрик, которые возвращают бинарное значение, 0 или 1, скажем какой-нибудь условный site_probe. Берем, суммируем за период, делим на количество записей и получаем наш SLA. Выглядеть это будет так: