Про систему мониторинга, которая строит графы из элементов приложения, а потом при помощи искусственного интеллекта ищет корневую причину проблемы уже писал в канале. То был Fixstream, кстати. Основа для работы алгоритма — netflow-трафик от сетевых устройств. Кроме netflow, конечно, ещё используются данные из CMDB и события из других систем мониторинга.
Сегодня расскажу про кое-что попроще. На просторах гитхаба обнаружил репозиторий с клёвой штукой, которая называется skydive. Чем она хороша? Помимо бесплатности еще много чем.
Skydive в режиме реального времени достаёт данные по netflow из базы данных Elasticsearch. Есть коннекторы к OpenStack, Docker, OpenContrail и Kubernetes.
Я уже давно считаю, что анализ netflow — недооценённая технология мониторинга и её стоило бы использовать активнее. А тем более это делать для распределённых приложений.
Сегодня расскажу про кое-что попроще. На просторах гитхаба обнаружил репозиторий с клёвой штукой, которая называется skydive. Чем она хороша? Помимо бесплатности еще много чем.
Skydive в режиме реального времени достаёт данные по netflow из базы данных Elasticsearch. Есть коннекторы к OpenStack, Docker, OpenContrail и Kubernetes.
Я уже давно считаю, что анализ netflow — недооценённая технология мониторинга и её стоило бы использовать активнее. А тем более это делать для распределённых приложений.
Поднимите руки кто знает Instana. Это observability-система для контроля распределённых (=микросервисных) приложений. Очень крутая и динамично развивающаяся, как говорится. Самое охрененское — это их визуализации. Больше так никто не делает. Причём все технологии контролируются одним единственным агентом, который после установки на сервер сам распознает что там и как работает. Распространение агентов заточено под использование CI/CD. По деньгам они получаются дешевле Appdynamics или New Relic, если посчитать стоимость за агента.
А сама новость заключается в том, что Instana теперь начала поддерживать мониторинг стека vmware. И это очень позитивная новость, т.к. добавляет дополнительный уровень абстракции в рамках одной системы.
Если хотите пилот на вашей инфре или просто узнать больше — пишите в личку.
👍 — слышал про Instana и считаю интересным решением
👎 — я свой Jaeger, OpenTracing или <свой вариант> не променяю на платное решение
👀 — у меня монолитное приложение, работает на физическом сервере в кладовке и мне не до ваших распределённых глупостей
А сама новость заключается в том, что Instana теперь начала поддерживать мониторинг стека vmware. И это очень позитивная новость, т.к. добавляет дополнительный уровень абстракции в рамках одной системы.
Если хотите пилот на вашей инфре или просто узнать больше — пишите в личку.
👍 — слышал про Instana и считаю интересным решением
👎 — я свой Jaeger, OpenTracing или <свой вариант> не променяю на платное решение
👀 — у меня монолитное приложение, работает на физическом сервере в кладовке и мне не до ваших распределённых глупостей
Посмотрите на эту картинку. Да, это из известной сказки, в которой лживый мальчик кричал «Волки! Волки!» в то время, когда волки доедали каких-то других козлят. А когда волки пришли за его козлятами — никто не прибежал с вилами на помощь.
Если из мониторинга прилетают алерты без повода через какое-то время на них перестанут реагировать. Очень много таких ситуаций возникает когда нет ответственного за мониторинг и каждая группа администраторов добавляет туда свои метрики и алерты. Ниже несколько рекомендаций, чтобы не выпускать ситуацию из под контроля.
1️⃣ Выгружать отчёты по событиям/алертам. Выявлять повторяющиеся. В идеале каждое событие должно появляться из-за какого-то нового бага в коде или настройках.
2️⃣ События должны быть только по тому, что требует вмешательства. Если можно автоматизировать реакцию на событие — это нужно сделать как можно скорее и никого об этом не оповещать. Это касается повторяющихся событий, причину которых невозможно пофиксить.
3️⃣ В системах мониторинга или алертинга есть (или должен быть) такой Duration. Это позволит не реагировать на разовые всплески. Важно уточнить у администраторов информационных систем насколько долго эти системы могут работать в «красной зоне».
4️⃣ По каждому событию/алерту в системе мониторинга должна фиксироваться реакция ответственного сотрудника. Если на какие-то события реакции нет — нужно выяснить кто заказывал мониторинг. Может это уже никому не нужно.
5️⃣ Этот список не означает, что нужно собирать только минимальный набор ключевых метрик. Нужно собирать их как можно больше и различными технологиями (встривание в код, синтетические транзакции, анализ трафика и т.д.). Важно отключить генерацию событий и оповещения на то, на что некому реагировать.
6️⃣ Создавайте связанные триггеры. В системах Zabbix и Prometheus это можно делать. Не нужно плодить 100500 событий из-за отказавшего коммутатора на удалённой площадке.
7️⃣ Если есть мониторинг приложения, которое разрабатывается парнями через стенку, важно, чтобы они поучаствовали в определении метрик мониторинга, на которые должна реагировать эксплуатация (да они сами что-то могли записать в баг-репорт).
Хотел написать 10, но на 7 мысль дальше не идёт. Если хотите небольшое продолжение — я как-то писал на Медиуме о борьбе с событийной усталостью. Малую толику информации можно посмотреть там.
Если из мониторинга прилетают алерты без повода через какое-то время на них перестанут реагировать. Очень много таких ситуаций возникает когда нет ответственного за мониторинг и каждая группа администраторов добавляет туда свои метрики и алерты. Ниже несколько рекомендаций, чтобы не выпускать ситуацию из под контроля.
1️⃣ Выгружать отчёты по событиям/алертам. Выявлять повторяющиеся. В идеале каждое событие должно появляться из-за какого-то нового бага в коде или настройках.
2️⃣ События должны быть только по тому, что требует вмешательства. Если можно автоматизировать реакцию на событие — это нужно сделать как можно скорее и никого об этом не оповещать. Это касается повторяющихся событий, причину которых невозможно пофиксить.
3️⃣ В системах мониторинга или алертинга есть (или должен быть) такой Duration. Это позволит не реагировать на разовые всплески. Важно уточнить у администраторов информационных систем насколько долго эти системы могут работать в «красной зоне».
4️⃣ По каждому событию/алерту в системе мониторинга должна фиксироваться реакция ответственного сотрудника. Если на какие-то события реакции нет — нужно выяснить кто заказывал мониторинг. Может это уже никому не нужно.
5️⃣ Этот список не означает, что нужно собирать только минимальный набор ключевых метрик. Нужно собирать их как можно больше и различными технологиями (встривание в код, синтетические транзакции, анализ трафика и т.д.). Важно отключить генерацию событий и оповещения на то, на что некому реагировать.
6️⃣ Создавайте связанные триггеры. В системах Zabbix и Prometheus это можно делать. Не нужно плодить 100500 событий из-за отказавшего коммутатора на удалённой площадке.
7️⃣ Если есть мониторинг приложения, которое разрабатывается парнями через стенку, важно, чтобы они поучаствовали в определении метрик мониторинга, на которые должна реагировать эксплуатация (да они сами что-то могли записать в баг-репорт).
Хотел написать 10, но на 7 мысль дальше не идёт. Если хотите небольшое продолжение — я как-то писал на Медиуме о борьбе с событийной усталостью. Малую толику информации можно посмотреть там.
Мониторинг – это очень важная штука, которую нужно иметь. Это все понимают. Но в то же самое время мониторинг не относится к бизнес-продукту и на напрямую не влияет на прибыль компании, поэтому на мониторинг всегда уделяют время по остаточному принципу. Если у нас есть время, то мы занимаемся мониторингом, если времени нет, то ОК, поставим в бэклог и когда-нибудь вернемся к этим задачам.
Согласны? Голосуйте в конце поста: 👍 — согласен, 👎 — не согласен. В комментах можно написать развёрнутый ответ.
По этой ссылке вы найдёте расшифровку доклада и сам доклад Алексея Лесовского — PostgreSQL DBA в компании Data Egret. Он рассказывает об информативных точках мониторинга БД PostgreSQL.
В конце статьи вы найдёте ссылки на репозитории проектов на гитхабе для мониторинга PostgreSQL.
Согласны? Голосуйте в конце поста: 👍 — согласен, 👎 — не согласен. В комментах можно написать развёрнутый ответ.
По этой ссылке вы найдёте расшифровку доклада и сам доклад Алексея Лесовского — PostgreSQL DBA в компании Data Egret. Он рассказывает об информативных точках мониторинга БД PostgreSQL.
В конце статьи вы найдёте ссылки на репозитории проектов на гитхабе для мониторинга PostgreSQL.
Подвезли стафф для линукс-администраторов. Ещё одна интересная статья от уже известного вам Антуана Солничкина, на которую стоит обратить внимание. Пишет про мониторинг MySQL при помощи специализированного экспортера для Prometheus и создании бизнес-дашборда в Grafana. Там есть список ключевых метрик и парав видосов с объяснениями.
И ещё вдогонку к предыдущему посту. Статья о мониторинге DIsk I/O на Linux-системах при помощи Prometheus c небольшим рассказом о том, как устроена файловая система в Linux.
Medium
Monitoring Disk I/O on Linux with the Node Exporter
Monitoring disk I/O on a Linux system is crucial for every system administrator.
Посмотрите расшифровку и 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
1️⃣ Использование Zabbix для слежения за базой данных MS SQL Server
2️⃣ Некоторые аспекты мониторинга MS SQL Server. Рекомендации по настройке флагов трассировки
3️⃣ Реализация индикатора производительности запросов, хранимых процедур и триггеров в MS SQL Server. Автотрассировка
4️⃣ Пример реализации общего индикатора производительности MS SQL Server
5️⃣ Автоматизация по сбору данных о росте таблиц и файлов всех баз данных MS SQL Server
Написал в блоге на Медиуме о своих впечатления от Слёрм DevOps. Почитайте, если ищете быстрый путь вхождения в тему.
Слёрм ещё и про нетворкинг. Познакомились там с Димой Бубновым — автором канала @mikrotikninja. Советую также посмотреть его блог на Медиуме. Обнаружил там интересную статью про автоматизацию управления сетевыми устройствами через NetBox. Через эту же штуку можно автоматизировать мониторинг сетевых устройств.
Слёрм ещё и про нетворкинг. Познакомились там с Димой Бубновым — автором канала @mikrotikninja. Советую также посмотреть его блог на Медиуме. Обнаружил там интересную статью про автоматизацию управления сетевыми устройствами через NetBox. Через эту же штуку можно автоматизировать мониторинг сетевых устройств.
Grafana — это мейнстрим. Много готовых коннекторов и туча разных дашбордов для каждого источника данных. С файлами в формате json, которыми описываются дашборды в Grafana, не всегда удобно работать. Чтобы как-то упростить работу с json-файлами, в Grafana Labs придумали специальную библиотеку Grafonnet. Посмотрите на приложенный скриншот. Именно так это библиотека и работает. Теперь, если вместе со сборками генерируются дашборды в Grafana, их будет легче описывать.
Репозиторий Grafonnet на Github
Видео с Fosdem 2020: Grafana-As-Code: Fully reproducible Grafana dashboards with Grafonnet
Репозиторий Grafonnet на Github
Видео с Fosdem 2020: Grafana-As-Code: Fully reproducible Grafana dashboards with Grafonnet
Забавно в книге SRE Workbook ссылаются на фразу Льва Толстого из Анны Карениной:
All happy families are alike; each unhappy family is unhappy in its own way.
Все счастливые семьи счастливы одинаково, каждая несчастливая несчастна по-своему.
В контексте SRE они переиначили это как:
Effective operations approaches are all alike, whereas broken approaches are all broken in their own way.
Эффективные подходы к эксплуатации одинаковы, неэффективные подходы все разные.
Можно с таким согласиться? Я больше склоняюсь к согласиться при условии, что эффективные подходы — это те, про которые пишут книгах, содержащих слова DevOps, SRE или Agile, а неэффективные — это результат подходов к работе внутри организации, которые появились без оглядки на опыт других (типа разработки собственного велосипеда без педалей).
Обращаю внимание, что под каждым постом есть кнопка для комментариев.
👍 — согласен.
👎 — не согласен.
👀 — а что такое SRE?
All happy families are alike; each unhappy family is unhappy in its own way.
Все счастливые семьи счастливы одинаково, каждая несчастливая несчастна по-своему.
В контексте SRE они переиначили это как:
Effective operations approaches are all alike, whereas broken approaches are all broken in their own way.
Эффективные подходы к эксплуатации одинаковы, неэффективные подходы все разные.
Можно с таким согласиться? Я больше склоняюсь к согласиться при условии, что эффективные подходы — это те, про которые пишут книгах, содержащих слова DevOps, SRE или Agile, а неэффективные — это результат подходов к работе внутри организации, которые появились без оглядки на опыт других (типа разработки собственного велосипеда без педалей).
Обращаю внимание, что под каждым постом есть кнопка для комментариев.
👍 — согласен.
👎 — не согласен.
👀 — а что такое SRE?
Goodreads
A quote from Anna Karenina
All happy families are alike; each unhappy family is unhappy in its own way.
В эту пятницу на Хабре вышла статья в блоге Фланта, в которой они пишут как проходили свой путь работы с событиями. Это расшифровка выступления Дмитрия Столярова с прошлогодней конференции DevOops.
Давайте я тут приведу свои комментарии к мыслям из этой статьи, которые мне особенно понравились.
1️⃣ Центральное хранилище. Нельзя слать алерты разными путями — все они должны приходить в одно место.
Речь о единой точке сбора событий из разных систем. Из этой точки события уже должны уходить в виде оповещений в Service Desk, Slack или куда вы там ещё их отправляете. В традиционных категориях это можно назвать зонтичной системой мониторинга. У такого подхода невероятное количество плюсов: защита от дупликации событий, возможность навернуть логику на события из разных систем, обогащать события данными из CMDB, базы знаний и т.д. и т.п.
2️⃣ Транспорт. <…>Мы решили, что существующие способы транспорта для алертов не подходят и сделали свою систему. В ней ответственный сотрудник вынужден для каждого алерта нажимать на кнопку «я увидел(а)»: если этого не происходит, к нему приходят запросы по другим каналам.
Общий телеграм-канал или канал в Slack, конечно, нужны только как вспомогательный инструмент. Основной — это прямое уведомление дежурного. В Флант решили сразу не беспокоить дежурных, а вываливать им уведомление в интерфейсе. Может и были какие-то на это причины, но для экономии времени лучше б сразу уведомить дежурного.
3️⃣ Инцидент не равен алерту. Чтобы это окончательно осознать, у нас ушло несколько лет. Алерт — это сообщение о проблеме, а инцидент — это сама проблема. Инцидент может содержать много сообщений о проблеме с разных сторон, и мы стали их объединять.
Я бы написал так: инцидент != событию != алерту. Инцидент — сущность системы тикетов (Service Desk — хороший пример этого семейства), событие — системы мониторинга, а алерт это да, сообщение о проблеме.
4️⃣ Лейблы. Всю идентификацию алертов надо строить на лейблах (key=value) — это стало особенно актуальным с приходом Kubernetes. Если алерт с физического сервера — в лейбле указано название этого сервера, а если с DaemonSet'а — там его название и пространство имён.
Лейблы нужны. Например, в Zabbix можно навесить тэги на хосты или триггеры. В Prometheus, соответственно, лейблы, которые навешиваются на временные ряды при экспозиции.
5️⃣ Чтобы избавиться от подобного психологического эффекта, «полупотушенные» инциденты надо попросту убрать, но сделать это правильно. Я называю это умный игнор, а его идея сводится к операции «отложить инцидент».
Тут речь идёт о событиях типа отказал диск, заказали новый. Т.е. о тех, по которым ожидается какой-то результат, не зависящий от эксплуатации. События при таком умном игноре должны висеть в открытых (т.к. в консоли обычно выполняется сортировка по времени, они будут в хвосте ленты) и на еженедельных ревью по мониторингу (если они у вас, конечно, есть) по всем таким должны быть проведены апдейты.
6️⃣ В компаниях, где часто что-то меняется, весьма актуальна ещё одна проблема: документация.
Документацию еще можно назвать контекстом. По каждому событию в системе мониторинга должен быть доступен контекст. Это может быть страница на вики, история возникновения аналогичных событий и т.д. Дежурному должна быть доступна эта информация по ссылке из события.
В один пост всё не влезло, поэтому п.7 будет идти следом.
Давайте я тут приведу свои комментарии к мыслям из этой статьи, которые мне особенно понравились.
1️⃣ Центральное хранилище. Нельзя слать алерты разными путями — все они должны приходить в одно место.
Речь о единой точке сбора событий из разных систем. Из этой точки события уже должны уходить в виде оповещений в Service Desk, Slack или куда вы там ещё их отправляете. В традиционных категориях это можно назвать зонтичной системой мониторинга. У такого подхода невероятное количество плюсов: защита от дупликации событий, возможность навернуть логику на события из разных систем, обогащать события данными из CMDB, базы знаний и т.д. и т.п.
2️⃣ Транспорт. <…>Мы решили, что существующие способы транспорта для алертов не подходят и сделали свою систему. В ней ответственный сотрудник вынужден для каждого алерта нажимать на кнопку «я увидел(а)»: если этого не происходит, к нему приходят запросы по другим каналам.
Общий телеграм-канал или канал в Slack, конечно, нужны только как вспомогательный инструмент. Основной — это прямое уведомление дежурного. В Флант решили сразу не беспокоить дежурных, а вываливать им уведомление в интерфейсе. Может и были какие-то на это причины, но для экономии времени лучше б сразу уведомить дежурного.
3️⃣ Инцидент не равен алерту. Чтобы это окончательно осознать, у нас ушло несколько лет. Алерт — это сообщение о проблеме, а инцидент — это сама проблема. Инцидент может содержать много сообщений о проблеме с разных сторон, и мы стали их объединять.
Я бы написал так: инцидент != событию != алерту. Инцидент — сущность системы тикетов (Service Desk — хороший пример этого семейства), событие — системы мониторинга, а алерт это да, сообщение о проблеме.
4️⃣ Лейблы. Всю идентификацию алертов надо строить на лейблах (key=value) — это стало особенно актуальным с приходом Kubernetes. Если алерт с физического сервера — в лейбле указано название этого сервера, а если с DaemonSet'а — там его название и пространство имён.
Лейблы нужны. Например, в Zabbix можно навесить тэги на хосты или триггеры. В Prometheus, соответственно, лейблы, которые навешиваются на временные ряды при экспозиции.
5️⃣ Чтобы избавиться от подобного психологического эффекта, «полупотушенные» инциденты надо попросту убрать, но сделать это правильно. Я называю это умный игнор, а его идея сводится к операции «отложить инцидент».
Тут речь идёт о событиях типа отказал диск, заказали новый. Т.е. о тех, по которым ожидается какой-то результат, не зависящий от эксплуатации. События при таком умном игноре должны висеть в открытых (т.к. в консоли обычно выполняется сортировка по времени, они будут в хвосте ленты) и на еженедельных ревью по мониторингу (если они у вас, конечно, есть) по всем таким должны быть проведены апдейты.
6️⃣ В компаниях, где часто что-то меняется, весьма актуальна ещё одна проблема: документация.
Документацию еще можно назвать контекстом. По каждому событию в системе мониторинга должен быть доступен контекст. Это может быть страница на вики, история возникновения аналогичных событий и т.д. Дежурному должна быть доступна эта информация по ссылке из события.
В один пост всё не влезло, поэтому п.7 будет идти следом.
Продолжение предыдущего поста.
7️⃣ Отправляя множество алертов, мы на них по сути вручную не реагируем — спасибо автоматизации разбора.
Где-то на десяток постов выше я писал про работу с событийной усталостью:
События должны быть только по тому, что требует вмешательства. Если можно автоматизировать реакцию на событие — это нужно сделать как можно скорее и никого об этом не оповещать.
Это один из важных моментов автоматизации. Второй момент касается событий, на которые всё-таки нужно реагировать. Важно попытаться собрать максимум диагностической информации до того, как дежурный приступит к работе над событием. Диагностикой могут являться хелс-чеки смежных сервисов, проверка доступности БД и аналогичные проверки связанных с проблемных сервисом вещей.
В комментариях к статье на Хабре я задал пару вопросов. Посмотрим ещё, что на них ответят. Могу позже сюда тоже их ответ запостить.
7️⃣ Отправляя множество алертов, мы на них по сути вручную не реагируем — спасибо автоматизации разбора.
Где-то на десяток постов выше я писал про работу с событийной усталостью:
События должны быть только по тому, что требует вмешательства. Если можно автоматизировать реакцию на событие — это нужно сделать как можно скорее и никого об этом не оповещать.
Это один из важных моментов автоматизации. Второй момент касается событий, на которые всё-таки нужно реагировать. Важно попытаться собрать максимум диагностической информации до того, как дежурный приступит к работе над событием. Диагностикой могут являться хелс-чеки смежных сервисов, проверка доступности БД и аналогичные проверки связанных с проблемных сервисом вещей.
В комментариях к статье на Хабре я задал пару вопросов. Посмотрим ещё, что на них ответят. Могу позже сюда тоже их ответ запостить.
Подключение производственного календаря к системе мониторинга — ещё один шаг на пути к снижению количества шумовых событий. В этой статье рассказывают об интеграции Zabbix с производственным календарём и даже дают ссылку на репозиторий на Github.
Если у вас один только Zabbix, описанный подход выглядит логично. Когда систем мониторинга больше единицы, более правильным выглядит подход к обработке событий на уровне консолидатора событий. Тем более, так будет проще рассчитывать SLO для всех SLI, чтобы обеспечить SLA. 🙂
А ваш мониторинг меняет своё поведение в зависимости от выходных и праздничных дней?
👍 — да, есть интеграция с производственным календарём или аналогом.
👎 — нет, но стоит этим заняться.
👀 — поведение систем, которые стоят у меня на мониторинге не меняется в зависимости от выходных/праздничных дней.
.
Если у вас один только Zabbix, описанный подход выглядит логично. Когда систем мониторинга больше единицы, более правильным выглядит подход к обработке событий на уровне консолидатора событий. Тем более, так будет проще рассчитывать SLO для всех SLI, чтобы обеспечить SLA. 🙂
А ваш мониторинг меняет своё поведение в зависимости от выходных и праздничных дней?
👍 — да, есть интеграция с производственным календарём или аналогом.
👎 — нет, но стоит этим заняться.
👀 — поведение систем, которые стоят у меня на мониторинге не меняется в зависимости от выходных/праздничных дней.
.
Если нужно быстро поставить на мониторинг Weblogic при помощи готового решения — на Хабре подсказывают решение. Речь про утилиту WLSDM. Там внутри есть дашборды и уже даже проставлены рекомендуемые пороги. Хоть сейчас выводи на телевизор.
В комментариях к статье пророчат набег адептов Prometheus, которые запинают автора из-за использования нишевого решения в мониторинге. Пока никто не пришёл и не набросил.
В комментариях к статье пророчат набег адептов Prometheus, которые запинают автора из-за использования нишевого решения в мониторинге. Пока никто не пришёл и не набросил.
Хабр
Как при помощи большого монитора и консольной утилиты WLSDM смотреть за Oracle WebLogic Server
На просторах утилит консольных расширений Oracle WebLogic Server встретилась одна очень полезная — WLSDM , как ее позиционируют сами авторы — утилита мониторинга WebLogic Server с большим набором...
Подробная статья о том, как работает Istio. Начиная с основ и к практическому применению. Если говорить по-простому, Istio — дополнительный уровень абстракции микросервисного приложения, при помощи которого можно собирать статистику по взаимодействию сервисов, настраивать дополнительную логику их взаимодействию (повторные передачи пакетов и т.д.), изменять потоки трафика (например, в случае канареечных релизов). Короче, полезная такая штука. И так доступно объясняется.
So, what is latency? Latency is how long it takes to do something. How long does it take to have a response back? How long does it take to process a message in a queue?
Итак, что же такое задержка? Задержка — это как много времени заняло выполнение чего-либо. Как долго возвращался ответ? Как долго обрабатывалось сообщение в очереди?
А ещё задержка — входит в четвёрку золотых сигналов, о которых Google рассказывал в своей книге SRE (Site Reliability Engineering).
В статье на Медиуме, инженер из Google Джаана Доган рассказывает почему критически важно измерять задержку по каждому запросу к системе.
Посмотрите на звёздочки на приложенной картинке. Это тестовые запросы, которые пуляют намеренно, чтобы расставлять некие рэперные точки для будущего возможного дебага излишней задержки запросов. Подробнее о таких тестовых запросах в этом видео.
Итак, что же такое задержка? Задержка — это как много времени заняло выполнение чего-либо. Как долго возвращался ответ? Как долго обрабатывалось сообщение в очереди?
А ещё задержка — входит в четвёрку золотых сигналов, о которых Google рассказывал в своей книге SRE (Site Reliability Engineering).
В статье на Медиуме, инженер из Google Джаана Доган рассказывает почему критически важно измерять задержку по каждому запросу к системе.
Посмотрите на звёздочки на приложенной картинке. Это тестовые запросы, которые пуляют намеренно, чтобы расставлять некие рэперные точки для будущего возможного дебага излишней задержки запросов. Подробнее о таких тестовых запросах в этом видео.
Как-то был я на митапе по Elastic Stack в Озоне. Ребята рассказывали как у них устроен поиск на сайте с использованием Elasticsearch. Особенно запомнились примеры плохих поисков. Например, при поисковом запросе «товары для взрослых», выводились товары для взрослых кошек, собак и других животных. Среди них, конечно, были реально товары для взрослых, но как-то немного. Митап был несколько месяцев назад, сразу после него я проверил этот поисковый запрос — всё было точно также как и на слайдах: много товаров для взрослых животных. Проверил этот запрос сегодня — вуаля, реально товары для взрослых. Чего там только нет🙂
В самом Elastic в последнее время озаботились развитием продукта, чтобы его было удобно использовать в качестве поискового движка и добавляют фишки вроде AppSearch. По этой ссылке вы найдёте небольшой DIY-гайд, где рассказано как быстро раскатать поиск на базе Elasticsearch. Может он пригодится, а может и нет, но хотя бы будете знать, что для поиска Elastic вполне себе можно использовать.
В самом Elastic в последнее время озаботились развитием продукта, чтобы его было удобно использовать в качестве поискового движка и добавляют фишки вроде AppSearch. По этой ссылке вы найдёте небольшой DIY-гайд, где рассказано как быстро раскатать поиск на базе Elasticsearch. Может он пригодится, а может и нет, но хотя бы будете знать, что для поиска Elastic вполне себе можно использовать.
Medium
Elasticsearch: Building the Search Workflow
A tutorial to build working search of SQL entities via Elasticsearch
❤1
Пост для тех, у кого Kubernetes. В этой статье Ким Вюсткамп (сертифицированный по k8s, кстати) рассказывает о подходах к мониторингу через Prometheus потребления памяти и CPU подами kubernetes.
Менеджер по инфраструктуре Netflix рассказывает почему он решил попробовать поработать в дежурной смене и что из этого узнал.