Сами по себе логи, трейсы, метрики - это очень узкие артефакты состояния нашего объекта наблюдения и обслуживания. Для понимания общей картины нужен взгляд сверху, сбор всех важных сигналов в одну систему и работа с большими данными в ней. Зонтичный подход близок по своим целям к RED и Golden Signals, но по своей сути является противоположным по принципу работы с данными. В Golden Signals мы отслеживаем Latency, Traffic, Errors отдельных сервисов и по ним можем быстро, но очень поверхностно определить их состояние. В случае зонтичного мониторинга или AIOps мы собираем данные о всех логах, событиях систем мониторинга метрик и трейсов, далее выстраиваем там топологию сервиса и определяем алгоритмически состояние здоровья, основываясь на сотнях и тысячах событий, метрик и трейсов. И два подхода, кстати, друг друга не исключают. В этой статье я постараюсь сравнить четыре бесплатных инструмента, которые могли бы дать такую зонтичную картину: ELK, Graylog, Grafana Loki и Monq.

Меня зовут Дмитрий Масленников, и я руковожу Центром надёжности информационных систем в Тинькофф. Недавно я выступал на вебинаре Слёрма «Особенности SRE в России». В поддержку своего курса по «SRE: внедряем DevOps от Google» Слёрм собирает интересные кейсы внедрения SRE в российских компаниях. Я рассказал, как устроена наша экосистема SRE, зачем мы используем самописные сервисы, почему в SRE должна работать инженерная элита и как примкнуть к этой элите за один день. А теперь делюсь этим здесь. 

Привет, хабр! Меня зовут Алексей и я системный инженер в компании Constanta, мы с командой занимаемся практиками DevOps, развиваем процессы ci/cd и мониторинга.

Представьте, что у вас есть 10 серверов и 20 микросервисов на них, а релизы проходят каждую неделю. Вы уже мониторите жизнеспособность сервисов и докера с помощью zabbix или prometheus, а с помощью ELK или grailog собираете логи. Кажется, что хорошо, но в таком потоке релизов, хотфиксов и строчек кода нужно быстро ориентироваться в ошибках внутри приложения, которые не влияют на жизнеспособность сервиса, но мешают его правильной работе.

Стоп! Есть же Sentry, скажете вы. И будете правы. Он удобен, хорошо описан, есть документация, комьюнити и поддержка. Однако, есть одно "но".

Привет! Хочу поделиться историей миграции сервисов логирования и трейсинга с компонентов Elastic Stack на Grafana Stack и тем, что из этого вышло. До миграции у нас в М2 использовались достаточно классические схемы:

1. host-tracker.com
2. monitis.com
3. monitorus.ru
4. pingup.ru
5. site24x7.com
6. uptimerobot.com
7. webopulsar.ru

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

Короткий итог — 30000 статей, десятки изменений в логике и интерфейсе сайта, 2 больших конкурса, 85 человек в команде, 359 дней нонстопа. Ещё в начале года мы твёрдо знали: надо продолжать делать крупнейший русскоязычный сервис для IT-специалистов и для этого мы задействуем все свои ресурсы. Были дни и даже недели, когда значительная часть команды работала 24/7, были бессонные ночи, были жалобы и благодарности. В некоторых моментах последняя нервная клетка команды пыталась сорваться в бездну, но мы знали — да что там, видели и видим в аналитике, — в нас верят 10 млн тех, кто ежемесячно читает Хабр и больше миллиона зарегистрированных. Эти люди дают и поглощают крутой контент, спорят, дискутируют, грубят и хвалят, устраивают баталии и присылают крутые идеи, сообщают о багах и уязвимостях. Ну что же, перед тем, как идти вперёд, осмелимся вместе оглянуться?

Эта история началась с того, что к нам пришел клиент, которому нужна была система распознавания речи. Да не простая, а качественно распознающая разговоры с микрофонов на АЗС, то есть речь в сильных шумах. Цель заказчика простая – контролировать, упоминают ли кассиры акции, предлагают ли установить мобильное приложение и выпить кофе. Вы наверняка все это сами слышали на заправках.

Но есть проблема. Хорошо распознать простую чистую речь могут почти все известные решения. Но речь, где на фоне играет радио, слышны звуки с других касс, громкость речи говорящих разная и присутствует много отраслевой лексики (бренды сигарет, марки топлива), качественно распознать не смогло ни одно «коробочное» решение.

Вызов принят! Мы решили за ограниченное время справиться с этим кейсом.

Шаг 1 – транскрибируем несколько файлов и замеряем качество распознавания на своем решении и решении конкурентов.

Для измерения качества распознавания используем метрику WER.

В этом году Учи.ру исполняется 10 лет. За это время компания пережила технологические и архитектурные трансформации. Она выросла из простого сайта, где можно было решать примеры на счёт столбиком, до группы компаний с курсами по школьным и внешкольным предметам, олимпиадами и многим другим. Команда научилась справляться с внезапным усилением трафика, одновременно запускать несколько задач и «распиливать» огромный монолит на кусочки.

Сейчас может показаться, что все используемые нами решения стандартны, но в далеком 2012 году мы внедряли их одними из первых. Я, Алексей Вахов, директор по инновациям Учи.ру, расскажу о ключевых технологиях и архитектурных принципах, которые лежат в основе платформы.

Подводим итоги работы Российских аналогов за ноябрь 2022 года и рассказываем о том, каких-же сервисов и продуктов больше всего не хватало в условиях введённых санкций.

С появлением в 2020 году нейронной сети GPT3 и других архитектур – трансформеров, генерируемые тексты стали невероятно правдоподобными. Такими правдоподобными, что отдельно взятый текст, не несущий большой смысловой нагрузки, стало сложно отличить от написанного человеком. В статье мы разберем подход к определению сгенерированных текстов. И заодно выясним, является ли, по мнению алгоритма, Пушкин (и другие деятели искусства) искусственной нейронной сетью.

Суть подхода

У фотографов есть Photoshop, у архитекторов — AutoCAD, а у инженеров машинного обучения — Kubeflow. Каждый получает свои преимущества от использования специализированного программного обеспечения, инженеры ML — не исключение.

В этой статье разберем чем полезен и как работает Kubeflow.

В продуктовой разработке нередко случается, что из кастомного проекта для конкретной компании рождается самостоятельный продукт. Так случилось и с Cloud IoT Platform: из небольшого пилотного проекта мы создали облачную промышленную платформу интернета вещей.

Database by Julian-Faylona

Многие облачные платформы предлагают базы данных как сервис (Database as a Service, DBaaS). Базу можно создать в облаке в несколько кликов, не тратя время на настройку и поддержку. Но не всем приложениям облачные базы данных подходят.

Мы расскажем, как на старте проекта не ошибиться с выбором облачной СУБД. Эта статья — вольная переработка нашего вебинара (видео тут).

Мы разберем, когда стоит и не стоит использовать DBaaS, какие особенности нужно учесть при работе с ними и как выбрать подходящую базу данных с учетом особенностей ИТ-инфраструктуры, объема и специфики задач. В конце посмотрим, как устроено создание базы данных в облаке и какие операции с ней доступны, на примере DBaaS Mail.ru Cloud Solutions.