Статья на Хабре про партиционирование MySQL под нужды Zabbix. Проблема партиционирования, конечно, решается использованием TimescaleDB, но, если по каким-то причинам её использование невозможно, статья будет полезна.

​Хоум Кредит унд Финанс банк пишет как они прикрутили к своему мониторингу на Zabbix и ELK машинное обучение. Вот теперь дежурные могут расслабиться 🙂

​Если не знаешь о чём написать — напиши как настроить Заббикс. Х5 пишет как они сделали мониторинг складских помещений. Интересно почитать, если вы видите Заббикс в первый раз. Ну хотя бы узнали как выглядит их склад.

В бытность работы в Евросети я как-то подрабатывал под новый год на складе компании, когда там проводилась инветаризация и требовались люди. Самый кайф — это разогнаться как следует на рохле и прокатиться между стеллажами. Электрическую технику работники склада пришлым не доверяли. А зря! Так веселья было бы ещё больше.

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

​Популярная, говорят, штука этот service mesh. В комментариях к статье резонно подмечают:

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

Резонно, чо уж там.

Что такое service mesh?

Несмотря на весь хайп, структурно service mesh устроена довольно просто. Это всего лишь куча userspace-прокси, расположенных «рядом» с сервисами (потом мы немного поговорим о том, что такое «рядом»), плюс набор управляющих процессов. Прокси в совокупности получили название data plane, а управляющие процессы именуются control plane. Data plane перехватывает вызовы между сервисами и делает с ними «всякое-разное»; control plane, соответственно, координирует поведение прокси и обеспечивает доступ для вас, т.е. оператора, к API, позволяя манипулировать сетью и измерять её как единое целое.

​Машинное обучение — горячая тема. В мониторинге предсказания аутаджей особенно важно. Читайте в этой статье о поиске аномалий в данных мониторинга. Кстати, используемый стек у них во многом аналогичен используемому в Яндекс-деньгах (см. видео Дмитрия Комарова на несколько постов выше).

​ЦИАН рассказывает как у них устроен сбор и анализ логов. На Elastic Stack.

Ого, нас уже тысяча человек! 🔥 Раз нас уже так немало, давайте проведём небольшой опрос. Конечно, про мониторинг. Проголосуйте за ваше мнение. А ещё можно оставить развёрнутый комментарий.

Вендоры, которые выпускают коммерческие продукты, обычно пишут у себя нечто такое:

Put simply, there is a lot of work involved with implementing open-source distributed tracing. Even if you’re capable of doing that work, you should ask yourself if all of that time and effort might be better spent developing business functionality.

Что переводится как:

Проще говоря, если вы используете open-source, нужно выполнить много работы, связанной с трассировкой распределённого приложения. Даже если вы можете выполнять эту работу, не стоит ли спросить у себя: «а не лучше ли потратить это время на разработку бизнес-функций?»

Вам слово.

💩 удавлюсь, но не буду платить проклятым капиталистам и пусть часть команды занимается поддержкой мониторинга на prometheus/zabbix/…
😏 начинаю поглядывать в сторону платных решений, не хочу утилизировать время команды непрофильным занятием
💰 заплатил деньги и доволен платным решением, пусть мои ребята занимаются разработкой
💣 заплатил деньги, но лучше бы я этого не делал и остался на бесплатном решении

​Ребзики, это комбо! Видео, текстовое описание и ссылка на Github. 3в1. Речь о elastiflow — расширении Elastic Stack для мониторинга и анализа flow-трафика. Это набор дашбордов для Kibana, обвес Logstash для разбора Netflow и советы как это всё использовать. Расширение распознаёт трафик flow различных версий и от различных вендоров. Все подробности в репозитории Github.

Разбор специализированных вендорских полей в flow-трафике — это большая проблема при работе с коммерческими решениями мониторинга (вроде Solarwinds или PRTG). Доработка парсера своими силами там обычно невозможна и остаётся дожидаться когда сам вендор решения для мониторинга наконец-то расширит воспринимаемые коллектором поля. Но к тому времени во flow-трафике появится что-то новое. Вот такой круговорот полей в природе. В Logstash же можно самостоятельно настраивать коллектор на необходимый набор полей.

→ выступление Rob Cowart — содателя расширения
→ описание решения в блоге Koiossian
→ репозиторий на Github

Канал про мониторинг начал приносить дивиденды основателю. Слёрм выдал мне курс по Prometheus, чтобы я его прошел онлайн и дал фидбек. Как пройду, напишу, толково или так себе.

Они же позвали на интенсив по DevOps. Заявлены инструменты DevOps: командная работа с Git, CI/CD, IaC, тестирование, логирование, мониторинг, ChatOps. Предстоит посмотреть на эти инструменты с трёх сторон (своеобразный трипл-вижн): заказчика, разработчика и администратора. На интенсиве будет про реальные кейсы, эффективное взаимодействие между сторонами внутри процесса и вот это всё. Это не конференция, где диалог ограничен 1-2 вопросами, на интенсиве можно полноценно пообщаться со спикерами и прояснить многое. Больше всего интересует мониторинг, но для меня очень даже полезно будет увидеть весь процесс, чтобы понять что и зачем делается.

Интенсив будет с 30 января по 1 февраля. Возможно очное (в Москве) и удалённое участие. Рега по ссылке.

​Весточка для линукс-администраторов. Но и безопасников тоже заинтересует. Ещё один подход к сбору системных логов с линукс-серверов — rsyslog + logstash + elasticsearch + kibana. Некто Антуан Солничкин просто и пошагово пишет какие команды и зачем выполнять, чтобы конструкция взлетела. Мануал подойдёт, если нужно быстро запустить мониторинг.

P.S. Посмотрите другие статьи этого автора на Медиуме, пишет он преимущественно про мониторинг причём разными средствами и подробно.

​Трейсинг распределённых приложений в Jaeger (Егерь). Статья для тех, кто ещё не начал использовать Istio.

​Про систему мониторинга, которая строит графы из элементов приложения, а потом при помощи искусственного интеллекта ищет корневую причину проблемы уже писал в канале. То был Fixstream, кстати. Основа для работы алгоритма — netflow-трафик от сетевых устройств. Кроме netflow, конечно, ещё используются данные из CMDB и события из других систем мониторинга.

Сегодня расскажу про кое-что попроще. На просторах гитхаба обнаружил репозиторий с клёвой штукой, которая называется skydive. Чем она хороша? Помимо бесплатности еще много чем.

Skydive в режиме реального времени достаёт данные по netflow из базы данных Elasticsearch. Есть коннекторы к OpenStack, Docker, OpenContrail и Kubernetes.

Я уже давно считаю, что анализ netflow — недооценённая технология мониторинга и её стоило бы использовать активнее. А тем более это делать для распределённых приложений.

Вы только посмотрите какие интерактивные графы ↑

​Поднимите руки кто знает Instana. Это observability-система для контроля распределённых (=микросервисных) приложений. Очень крутая и динамично развивающаяся, как говорится. Самое охрененское — это их визуализации. Больше так никто не делает. Причём все технологии контролируются одним единственным агентом, который после установки на сервер сам распознает что там и как работает. Распространение агентов заточено под использование CI/CD. По деньгам они получаются дешевле Appdynamics или New Relic, если посчитать стоимость за агента.

А сама новость заключается в том, что Instana теперь начала поддерживать мониторинг стека vmware. И это очень позитивная новость, т.к. добавляет дополнительный уровень абстракции в рамках одной системы.

Если хотите пилот на вашей инфре или просто узнать больше — пишите в личку.

👍 — слышал про Instana и считаю интересным решением

👎 — я свой Jaeger, OpenTracing или <свой вариант> не променяю на платное решение

👀 — у меня монолитное приложение, работает на физическом сервере в кладовке и мне не до ваших распределённых глупостей

​Посмотрите на эту картинку. Да, это из известной сказки, в которой лживый мальчик кричал «Волки! Волки!» в то время, когда волки доедали каких-то других козлят. А когда волки пришли за его козлятами — никто не прибежал с вилами на помощь.

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

1️⃣ Выгружать отчёты по событиям/алертам. Выявлять повторяющиеся. В идеале каждое событие должно появляться из-за какого-то нового бага в коде или настройках.

2️⃣ События должны быть только по тому, что требует вмешательства. Если можно автоматизировать реакцию на событие — это нужно сделать как можно скорее и никого об этом не оповещать. Это касается повторяющихся событий, причину которых невозможно пофиксить.

3️⃣ В системах мониторинга или алертинга есть (или должен быть) такой Duration. Это позволит не реагировать на разовые всплески. Важно уточнить у администраторов информационных систем насколько долго эти системы могут работать в «красной зоне».

4️⃣ По каждому событию/алерту в системе мониторинга должна фиксироваться реакция ответственного сотрудника. Если на какие-то события реакции нет — нужно выяснить кто заказывал мониторинг. Может это уже никому не нужно.

5️⃣ Этот список не означает, что нужно собирать только минимальный набор ключевых метрик. Нужно собирать их как можно больше и различными технологиями (встривание в код, синтетические транзакции, анализ трафика и т.д.). Важно отключить генерацию событий и оповещения на то, на что некому реагировать.

6️⃣ Создавайте связанные триггеры. В системах Zabbix и Prometheus это можно делать. Не нужно плодить 100500 событий из-за отказавшего коммутатора на удалённой площадке.

7️⃣ Если есть мониторинг приложения, которое разрабатывается парнями через стенку, важно, чтобы они поучаствовали в определении метрик мониторинга, на которые должна реагировать эксплуатация (да они сами что-то могли записать в баг-репорт).

Хотел написать 10, но на 7 мысль дальше не идёт. Если хотите небольшое продолжение — я как-то писал на Медиуме о борьбе с событийной усталостью. Малую толику информации можно посмотреть там.

​Мониторинг – это очень важная штука, которую нужно иметь. Это все понимают. Но в то же самое время мониторинг не относится к бизнес-продукту и на напрямую не влияет на прибыль компании, поэтому на мониторинг всегда уделяют время по остаточному принципу. Если у нас есть время, то мы занимаемся мониторингом, если времени нет, то ОК, поставим в бэклог и когда-нибудь вернемся к этим задачам.

Согласны? Голосуйте в конце поста: 👍 — согласен, 👎 — не согласен. В комментах можно написать развёрнутый ответ.

По этой ссылке вы найдёте расшифровку доклада и сам доклад Алексея Лесовского — PostgreSQL DBA в компании Data Egret. Он рассказывает об информативных точках мониторинга БД PostgreSQL.

В конце статьи вы найдёте ссылки на репозитории проектов на гитхабе для мониторинга PostgreSQL.

​Подвезли стафф для линукс-администраторов. Ещё одна интересная статья от уже известного вам Антуана Солничкина, на которую стоит обратить внимание. Пишет про мониторинг MySQL при помощи специализированного экспортера для Prometheus и создании бизнес-дашборда в Grafana. Там есть список ключевых метрик и парав видосов с объяснениями.

И ещё вдогонку к предыдущему посту. Статья о мониторинге DIsk I/O на Linux-системах при помощи Prometheus c небольшим рассказом о том, как устроена файловая система в Linux.

​Посмотрите расшифровку и 30-минутное выступление суровых мужиков из Челябинска, которые трудятся в местном интернет-провайдере Интерсвязь. Рассказывают про свой опыт оптимизации производительности Zabbix. Выступление 2018 года, но их подходы к оптимизации с тех не перестали быть актуальным Мне, кстати, известна не одна компания где до сих пор используют Zabbix версии 2.2. «Работает — не трогай» тоже принцип, но риски использования устаревшего ПО никто ж не отменял.

Каким Заббиксом сами пользуетесь?

​Это пост 5в1. Дальше будет 5 ссылок на статьи по подходам к обеспечению доступности MS SQL. Там про специализированные точки мониторинга: флаги трассировки, рост таблиц и баз данных, производительность запросов, хранимых процедур, триггеров и вот этого всего . Все статьи — это опыт Евгения Грибкова, который MS SQL Server and .NET Developer да ещё и DBA. В его профиле на Хабре найдёте ссылки на англоязычные статьи.

1️⃣ Использование Zabbix для слежения за базой данных MS SQL Server

2️⃣ Некоторые аспекты мониторинга MS SQL Server. Рекомендации по настройке флагов трассировки

3️⃣ Реализация индикатора производительности запросов, хранимых процедур и триггеров в MS SQL Server. Автотрассировка

4️⃣ Пример реализации общего индикатора производительности MS SQL Server

5️⃣ Автоматизация по сбору данных о росте таблиц и файлов всех баз данных MS SQL Server