Рубрика «Grafana»

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

У нас уже была страница смены пароля, но механизм работы был не оптимальным. Вот как всё происходило. Пользователь оставлял заявку в домене на смену пароля. В ответ система, в свою очередь, оставляла заявку, которую администратор обрабатывал вручную. Он генерировал пароль в домене, после чего приписывал его в заявке. Пользователю приходило 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
Читать полностью »

В своей практике я достаточно много времени посвящаю проектированию и администрированию облачных инфраструктур различного назначения. В основном это Apache CloudStack. Данная система обладает отличными возможностями, но в части мониторинга, функциональности явно недостаточно (читайте — отсутствует), особенно, если на мониторинг смотреть шире чем мониторинг индивидуального объекта наблюдения (сервер, виртуальная машина).

В целом, в связи с более широкими требованиями к систем визуального анализа информации и потребностями в части интеграции с источниками данных стали распространяться специализированные решения для ad-hoc анализа данных, такие как Kibana, Grafana и иные. Данные системы могут интегрироваться со специализированными хранилищами временных рядов данных, одним из которых является InfluxDB. Статья расскажет о готовом решении, распространяемом в виде образа Docker, использующем LibVirt API, Grafana и InfluxDB, предназначенном для сбора и анализа параметров исполняющихся VM для гипервизора KVM. Читать полностью »

Очень долго хотел написать статью, но не хватало времени. Нигде (в том числе на Хабре) не нашёл такой простой альтернативы munin, как описанная в этой статье.

Обзор систем мониторинга серверов. Заменяем munin на… - 1
Читать полностью »

Мониторинг Docker Swarm с помощью cAdvisor, InfluxDB и Grafana - 1

Чтобы отслеживать состояние работающих приложений, необходимо проводить их постоянный мониторинг. А если приложения выполняются в таком хорошо масштабируемом окружении, как Docker Swarm, то потребуется также и хорошо масштабируемый инструмент мониторинга. В этой статье говорится о настройке именно такого инструмента.

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

Для построения кластера мы будем использовать Docker Swarm Mode и развернем необходимые сервисы в виде стека. Это позволит организовать динамическую систему мониторинга, которая способна автоматически начинать мониторинг новых нод по мере их добавления в рой (swarm). Файлы проекта можно найти здесь.

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

enter image description here

Привет! Объявляем регистрацию на митап открытой. Мы в очередной раз принимаем в нашем офисе сообщество Zabbix. Ниже – описание выступлений. Начало мероприятия в 12:00.

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