Рубрика «prometheus» - 3

в 14:53, , рубрики: devops, kubernetes, prometheus, sre, zabbix, бирюзовая компания, Блог компании Southbridge, интервью, искусственный интеллект, карьера, перспективы, управление проектами

В курсах Слёрм Kubernetes постепенно остается один Kubernetes. Смежные темы постепенно переходят в отдельные курсы.

Первыми были Docker, Ansible, Ceph. Двухчасовые лекции по ним сначала превратались в цикл вебинаров, а потом — в онлайн-курсы.

Пришел черед мониторинга. Тема «Мониторинг кластера» превратилась в онлайн-курс Слёрм Пром, целиком посвященный Prometheus. Как мы любим, с практикой на учебном стенде. Онлайн-курс — это записанные лекции, практические задания, стенд для выполнения практики, помощь саппортов. Прохождение Слёрма Пром занимает 12-16 часов.

Содержание курса:

  1. Основы Prometheus
  2. Exposition (Node exporter, Blackbox exporter, Custom exporter, Application library)
  3. Prometheus (Service Discovery, Labels, PushGateway)
  4. PromQL (Хранение данных, типы данных, выражения, Record Rules)
  5. Alerting (Alertrules, Alertmanager)
  6. Визуализация данных (Grafana)
  7. Продвинутое использование Prometheus (High Availability, Federation, Remote read/write, Thanos, HTTP API)
  8. Prometheus в Kubernetes

Курс стоит 15 000 ₽ (10 000 ₽ для тех, кто был на Слёрмах).

Пример лекции.

Автор курса — Владимир Гурьянов, специалист по мониторингу и спикер Слёрма. Я взял у него интервью про курс, жизнь и работу в нашей компании. Мне интересны люди, которые направляют свой корабль в моря, обозначенные на картах «Здесь живут драконы».

Слёрм Пром: первый курс по Prometheus на русском языке и его автор Владимир Гурьянов - 1

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

в 12:28, , рубрики: debug, debug log, devops, Grafana, prometheus, Блог компании Конференции Олега Бунина (Онтико), логи, отладка, Разработка веб-сайтов, системное администрирование

Разработка сильно изменилась за последние годы. Вместо монолитных приложений пришли микросервисы и функции. Базы данных из универсальных промышленных монстров переродились в узконаправленные. Docker изменил взгляд на деплой. Но изменилось ли наше представление о логах?

Одна из больших проблем в Яндекс.Вертикалях были логи — 18 ТБ в день и 250 000 логов в секунду, все пишется в файлы. Логи разнородные, потому что много языков: Scala, Java, Python, Go. Потом их собирает Fluent Bit, пишет в Kafka, на одной железной машине работают обработчики, собирают из Kafka и пишут всё на диск. При этом это уже третья версия логов.

Логи не нужны? - 1

Как следствие, возникает проблема долгого поиска. По этим логам поиск идет с помощью grep. На некоторых сервисах grep может достигать часов. Если у вас есть проблемы в продакшн, вы не будете часами искать свои логи. Чтобы решить проблему, в Яндекс решили написать свой велосипед доставки логов для поиска. Что из этого получилось, расскажет Алексей Данилов (danevge) — разработчик команды инфраструктуры в Яндекс.Вертикалях. Разрабатывает, пишет и поддерживает проекты auto.ru и Яндекс.Недвижимость.

Дисклеймер. Статья рассказывает о современной разработке и подходит для микросервисной архитектуры. Здесь представлены различные продукты — это инструменты, которые используют в Яндекс.Вертикалях. Под другие условия возможны аналоги удачнее, но они выполняют практически те же функции.Читать полностью »

в 7:11, , рубрики: devops, metrics, prometheus, ruby, Ruby gem, Tracer, Блог компании Southbridge, Серверное администрирование, системное администрирование

Как с Prometheus собирать метрики, не искаженные привязкой ко времени - 1
Многие сетевые приложения состоят из веб-сервера, обрабатывающего трафик в реальном времени, и дополнительного обработчика, запускаемого в фоне асинхронно. Есть множество отличных советов по проверке состояния трафика да и сообщество не перестает разрабатывать инструменты вроде Prometheus, которые помогают в оценке. Но обработчики порой не менее – а то и более – важны. Им также нужны внимание и оценка, однако руководства по тому, как осуществлять это, избегая распространенных подводных камней, мало.

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

Мы увидим, как использовать метрики таким образом, чтобы обеспечить точную оценку, а в заключении покажем эталонную реализацию prometheus-client-tracer с открытым исходным кодом, который и вы можете применить в своих приложениях.

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

в 6:28, , рубрики: cassandra, clickhouse, diy или сделай сам, influxdb, ITSumma, prometheus, TSBD, Администрирование баз данных, базы данных, Блог компании ITSumma, тест, тестирование, Тестирование IT-систем, хранение данных

Как мы тестировали несколько баз данных временных рядов - 1

За последние несколько лет базы данных временных рядов (Time-series databases) превратились из диковинной штуки (узкоспециализированно применяющейся либо в открытых системах мониторинга (и привязанной к конкретным решениям), либо в Big Data проектах) в «товар народного потребления». На территории РФ отдельное спасибо за это надо сказать Яндексу и ClickHouse’у. До этого момента, если вам было необходимо сохранить большое количество time-series данных, приходилось либо смириться с необходимостью поднять монструозный Hadoop-стэк и сопровождать его, либо общаться с протоколами, индивидуальными для каждый системы.

Может показаться, что в 2019-м году статья про то, какую TSDB стоит использовать, будет состоять лишь из одного предложения: «просто используйте ClickHouse». Но… есть нюансы.

Действительно, ClickHouse активно развивается, пользовательская база растет, а поддержка ведется очень активно, но не стали ли мы заложниками успешной публичности ClickHouse-а, которая затмила другие, возможно, более эффективные/надежные решения?
В начале прошлого года мы занялись переработкой нашей собственной системы мониторинга, в процессе которой встал вопрос о выборе подходящей базы для хранения данных. Об истории этого выбора я и хочу здесь рассказать.
Читать полностью »

в 21:19, , рубрики: devops, gitlab, k8s, new release, opensourse, prometheus, Блог компании Southbridge, Серверное администрирование, системное администрирование

Новый GitLab 12.0 с визуальными ревью и списком зависимостей - 1

Dev, Sec и Ops

GitLab 12.0 — это ключевой выпуск на пути к реализации подхода, который будет охватывать все элементы DevSecOps и позволит всем вносить свой вклад.

У нас был очень увлекательный год — мы много работали над решением, которое объединило бы все команды. Сообщество внесло тысячи дополнений, чтобы GitLab стал еще круче.

Мы верим, что каждый может внести свой вклад, поэтому добавили функции для сотрудничества между разными командами, быстрой поставки отличного кода и объединения Dev, Sec и Ops.

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

в 12:35, , рубрики: kubernetes, prometheus, Блог компании OTUS. Онлайн-образование, Программирование

Салют! Перевод следующей статьи подготовлен специально для студентов курса «Инфраструктурная платформа на основе Kubernetes», занятия по которому стартуют уже завтра. Начнем.

Горизонтальное автомасштабирование подов Kubernetes и Prometheus для высокой доступности и работоспособности инфрастр-ры - 1

Автомасштабирование в Kubernetes


Автомасштабирование позволяет автоматически увеличивать и уменьшать рабочие нагрузки в зависимости от использования ресурсов.

У автомасштабирования в Kubernetes два измерения:

  • автомасштабирование кластера (Cluster Autoscaler), которое отвечает за масштабирование узлов;
  • горизонтальное автомасштабирование подов (Horizontal Pod Autoscaler, HPA), которое автоматически масштабирует количество подов в развертывании или наборе реплик.

Автомасштабирование кластера можно использовать в сочетании с горизонтальным автомасштабированием подов для динамического регулирования вычислительных ресурсов и степени параллелизма системы, необходимых для соблюдения соглашений об уровне обслуживания (SLA).Читать полностью »

в 13:24, , рубрики: Grafana, kubernetes, mixin, prometheus, Блог компании OTUS. Онлайн-образование

Всем привет! Сегодня мы продолжаем делиться материалом, переведенным специально для студентов курса «Инфраструктурная платформа на основе Kubernetes». Приятного прочтения.

Панели Grafana для администрирования Kubernetes - 1
Читать полностью »

в 16:36, , рубрики: devops, guide, monitoring, prometheus, prometheus monitoring, tsdb, Блог компании Southbridge, Серверное администрирование, системное администрирование

Полное руководство по Prometheus в 2019 году - 1

DevOps- и SRE-инженеры уже, наверное, не раз слышали о Prometheus.

Prometheus был создан на SoundCloud в 2012 году и с тех пор стал стандартом для мониторинга систем. У него полностью открытый исходный код, он предоставляет десятки разных экспортеров, с помощью которых можно за считанные минуты настроить мониторинг всей инфраструктуры.

Prometheus обладает очевидной ценностью и уже используется новаторами в отрасли, вроде DigitalOcean или Docker, как часть системы полного мониторинга.

Что такое Prometheus?
Зачем он нужен?
Чем он отличается от других систем?

Если вы совсем ничего не знаете о Prometheus или хотите лучше разобраться в нем, в его экосистеме и всех взаимодействиях, эта статья как раз для вас.

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

в 14:42, , рубрики: devops, etcd, fio, k8s, linux, prometheus, storage, Блог компании Southbridge, Серверное администрирование, системное администрирование

Скорость хранилища подходит для etcd? Спросим fio - 1

Короткая история о fio и etcd

Производительность кластера etcd во многом зависит от производительности его хранилища. etcd экспортирует некоторые метрики в Prometheus, чтобы предоставить нужные сведения о производительности хранилища. Например, метрику wal_fsync_duration_seconds. В документации к etcd сказано: чтобы хранилище считалось достаточно быстрым, 99-й процентиль этой метрики должен быть меньше 10 мс. Если вы планируете запустить кластер etcd на машинах Linux и хотите оценить, достаточно ли быстрое у вас хранилище (например, SSD), можно использовать fio — популярный инструмент для тестирования операций ввода-вывода. Запустите следующую команду, где test-data — это каталог под точкой подключения хранилища:

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

Нужно просто посмотреть результаты и проверить, что 99-й процентиль длительности fdatasync меньше 10 мс. Если да, у вас достаточно быстрое хранилище. Вот пример результатов:

  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentiles (usec):
   | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
   | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
   | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
   | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
   | 99.99th=[15795]

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

в 6:51, , рубрики: devops, Grafana, k8s, kubernetes, kubernetes engine, prometheus, Блог компании Southbridge, Серверное администрирование, системное администрирование

Мониторим ресурсы кластеров Kubernetes - 1

Я создал Kube Eagle — экспортер Prometheus. Оказалось, крутая штука, которая помогает лучше разбираться в ресурсах маленьких и средних кластеров. В итоге я сэкономил не одну сотню долларов, потому что подбирал правильные типы машин и настраивал ограничения ресурсов приложений под рабочие нагрузки.

Я расскажу о преимуществах Kube Eagle, но сначала объясню, из-за чего вышел сыр-бор и для чего понадобился качественный мониторинг.

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

1...234...6
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js