Рубрика «Grafana»

Всё ближе момент, когда мы выпустим в свет наше решение, свежее, новенькое и сияющее. Волнительно? Не очень, ведь мы его уже проверили со всех сторон.

Мы составили чек-лист для проверки, насколько решение готово к выкатыванию в продакшн. В нём перечислили всё самое важное, что проверяем в инфраструктуре, первоначальном наполнении, интеграции, обучении пилотной группы пользователей, передаче решения, пользовательской документации, бизнес-мониторинге и выборе момента для релиза.

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

Рецепт гладкого релиза: PMy на заметку - 1
Читать полностью »

Содержание

  • Предыстория
  • Сбор статистики
  • Отображение статистики
  • Визуализация и ведение статистики
  • Развертка
  • Заключение

Предыстория

Привет хабр, телеграм сейчас на пике популярности, все скандалы, интриги, блокировки вертятся вокруг него, в связи с чем телеграм выкатил свой вариант прокси под названием MTProto Proxy который призван помочь с обходом блокировки. Однако предоставленные телеграмом сервисы для мониторинга MTProto Proxy не дают возможности наблюдать статистику в реальном времени и собирать её для наблюдения за её изменениями, потому мы будем решать проблему своими силами.
Читать полностью »

Введение

Всем привет! Сегодня мы поговорим о real-time мониторинге Atlassian продуктов.

Для начала давайте определим, что такое мониторинг, и зачем он необходим для Atlassian продуктов.

Мониторинг программ применяется для отслеживания хода и результатов работы программы. Другими словами — это процесс, который в режиме реального времени может отображать информацию о состоянии программного продукта.

Когда это может быть полезно для Atlassian продуктов?

Рассмотрим примеры:

  • Вы хотите знать, как обновление продукта или плагина влияет на производительность системы;
  • Вы хотите знать о состоянии железа и памяти при различных условиях и в определенные моменты времени. Например, как увеличение числа пользователей или смена времени суток влияет на систему;
  • Вы хотите наблюдать, насколько активно используется система в целом. Например, общее количество задач в Jira или за 1 час;
  • Вы хотите поставить напоминание на дату истечения срока лицензии;
  • Вам бы хотелось знать объем дискового пространства, используемого для хранения документов.

Также хотелось бы не только получать информацию в подготовленном виде, но и иметь возможность отправлять уведомления, если что-то происходит по ошибочному сценарию. Здесь нам и помогут Prometheus и его экспортеры для Atlassian продуктов.
Читать полностью »

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

Пишем свой источник данных для Grafana - 1
Читать полностью »

У нашего заказчика есть интернет-портал и пользователи, данные которых заведены в домене. Доступ в личный кабинет — по паролю, а где пароль, там и людская забывчивость.

У нас уже была страница смены пароля, но механизм работы был не оптимальным. Вот как всё происходило. Пользователь оставлял заявку в домене на смену пароля. В ответ система, в свою очередь, оставляла заявку, которую администратор обрабатывал вручную. Он генерировал пароль в домене, после чего приписывал его в заявке. Пользователю приходило email-уведомление: “Ваш пароль изменён на такой”.

Смена пароля: 10 шагов к хорошей реализации - 1

Нас смущали три момента:

  1. Sharepoint, от которого мы уходим в тех местах, где он не нужен.
  2. Потребность в участии администратора. Нам не хотелось отвлекать квалифицированного специалиста на подобные рутинные и частые операции.
  3. Мы присылали пароль прямо в письме, что не очень-то безопасно. Такой пароль можно прочесть с экрана. Появляется много вариантов, как он может утечь.

И ещё был психологический момент: система создавала такие сложные пароли, что их было сложновато запомнить, оставалось только где-то записать.Тоже небезопасно. Зато такой пароль очень просто забыть. Можем предположить, что это обстоятельство тоже влияло на количество заявок на смену пароля.

Итак, стало понятно, что механику смены пароля пора изменить.

Читать полностью »

Для своих ETL (Extract, Transform, Loading) процессов, на этапах E и T, то есть извлечение и преобразование данных мы используем Apache Storm, и, так как большинство ошибок, связанных с инвалидацией сырых данных, происходит именно на этом этапе, — появилось желание централизованно логировать всё это, используя ELK стэк (Elasticsearch, Logstash, Kibana).

Каким же было моё удивление, что нигде не то, что на русском языке, но даже в оригинальных туториалах не было описана работа с логами в формате log4j2, который является дефолтом в мире Java-приложений.

Исправляя это упущение — под катом туториал по настройке централизованного сбора любых log4j2 логов на основе:

  • ELK внутри Docker
  • Настройка log4j для работы с Logstash
  • Настройка Logstash для правильной индексации логов
  • Немного бонусов, в виде краткой настройки Storm и интеграции Elasticsearch с Grafana

image
Читать полностью »

Меня зовут Евгений Жиров, я разработчик в инфраструктурной команде Контур.Экстерна. Этот пост — текстовая версия моего доклада с недавнего митапа Perm Tech Talks.

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

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

Я расскажу о нескольких примерах из своей работы и поделюсь советами.

Какие бывают метрики?

Как обложить сервис метриками и не облажаться - 1

Метрика requests.count.byhost.*

Читать полностью »

Мониторинг с Prometheus в Kubernetes за 15 минут - 1

Прим. перев.: Автор статьи Giancarlo Rubio — DevOps-инженер из ИТ-компании LINKIT (Нидерланды) — через онлайн-ресурс ITNEXT делится лаконичным рецептом по настройке мониторинга с Prometheus в Kubernetes с помощью Prometheus Operator. Инструкция появилась как следствие недавнего опыта выбора и внедрения системы проактивного мониторинга после миграции проекта с bare metal на облачную инфраструктуру. Рецепт отлично подходит для быстрого теоретического (первая половина статьи) и практического (вторая половина) знакомства. Для некоторых команд исправлены URL'ы, которые в оригинальном материале, по всей видимости, были преобразованы движком medium.Читать полностью »

Продолжение публикации, здесь первая часть

Инженерные системы наших дата-центров и их мониторинг, часть вторая - 1

В этой заключительной части я расскажу о программной составляющей нашей системы мониторинга.
Читать полностью »

Сегодня на нашем проекте, помимо монолитного кода, функционируют десятки микросервисов. Каждый из них требует того, чтобы его мониторили. Делать это в таких объемах силами DevOps проблематично. Мы разработали систему мониторинга, которая работает как сервис для разработчиков. Они могут самостоятельно писать метрики в систему мониторинга, пользоваться ими, строить на их основании дашборды, прикручивать к ним алерты, которые будут срабатывать при достижении пороговых значений. С DevOps — только инфраструктура и документация.
Этот пост — расшифровка моего выступления с нашей секции на РИТ++. Многие просили нас сделать текстовые версии докладов оттуда. Если вы были на конференции или смотрели видео, то не найдете ничего нового. А всем остальным — добро пожаловать под кат. Расскажу, как мы пришли к такой системе, как она работает и как мы планируем её обновлять.
Мониторинг как сервис: модульная система для микросервисной архитектуры - 1
Читать полностью »