Trace discovery in Grafana Tempo using Prometheus exemplars, Loki 2.0 queries, and more

Let’s dig into some examples with a live playground to try it out! Читать дальше.

Попытка побороть шумовые события при помощи ML. Получилось результативно.

One Grafana Dashboard With Multiple Prometheus Datasources

In this article, the following aspects of using Prometheus and Grafana will be demonstrated:

⚡ One Grafana server presenting data from multiple Prometheus resources.

⚡ Each dashboard would show only selected Prometheus datasources (not all configured datasources are relevant to all of the dashboards).

⚡ Present only the relevant data from each datasource according to the dashboard content. (For example in case the dashboard panel present one storage mount which has a different mount requirements per server).

⚡️ Useful dashboards for your needs:
- Host / VM Resources ( CPU, RAM, Storage and I/O, Network).
- Docker Containers (Use of resources per container).

Читать дальше.

🔍 How to use dig - пара полезных советов от Julia Evans о том, как можно использовать dig. #dns #dig #напочитать

Когда я делал тесты на основе библиотеки Jepsen для Tarantool, то планировал добавить в тестирование сбои на файловой системе. Почему-то так сложилось, что в самой библиотеке Jepsen нет сбоев для файловых систем и даже Кайл в одном из своих комментариев написал, что было бы здорово, если бы кто-то добавил их в Jepesen. Я знаю, что есть две файловые системы на основе FUSE: CharybdeFS от разработчиков ScyllaDB и PetardFS, но у меня есть вопросы к интерфейсам для описания сбоев в этих файловых системах. CharybdeFS при запуске поднимает сервер и по протоколу Thrift можно включать и выключать различные виды сбоев, а PetardFS использует XML для конфигурации при запуске. Ни первый ни второй вариант мне не понравился и я сделал свою файловую систему с тем же подходом, но конфигурацию можно описывать с помощью файла в формате INI (как конфиги в Windows). Это такой компромисс формата удобного и для чтения машиной и человеком. Файл с конфигурацией лежит на самой ФС и перечитывается каждый раз, когда его обновляют (мы же ФС и знаем какие операции и с какими файлами происходят). Как оказалось, такая тестовая ФС полезна не только при тестировании распределенных систем или баз данных. В тикеты пришёл парень, который тестирует парсер и ему нужно, чтобы за одно чтение возвращался ровно 1 байт из файла. Поэтому ассортимент возможных сбоев я ещё буду расширять.

https://github.com/ligurio/unreliablefs

🔐 Иллюстрация и объяснение каждого байта TLS-соединения: https://proglib.io/w/e0f20879

Для Амазона/Гугла есть много рекомендаций по настройке безопасности. Вот чеклист по безопасности и для Yandex.Cloud. Он достаточно простой, если у кого-то есть более подробные инструкции или чеклисты для Яндекса — присылайте его нам, опубликуем в канале тоже.
http://a.e42.link/jYoY7

Кафка с медом (простите):
О том как говорят Кафку в Honeycomb.io

- решили делать свое, так как не хотят ждать ответа от суппорта, если что-то сломается у их клиентов
- переехали из AK 0.11 в Confluent Community (5.3/AK 2.3)
- переехали на Confluent Platform 6.0 (enterprise): Tiered Storage (в их паттерне надо держать 24-48 часов в быстром доступе NVMe, чтобы можно было быстро replay. И Self-balancing Kafka (Cruise Control сразу зашит))
- так же Кафка нормально живет на arm-е (они используют graviton от AWS).
- много правильных рассуждений на тему sizing - выбор на каком instance type бежать еще пол беды, надо понять сколько это будет стоить.

Не знаю, кому будет полезно. Копировать as is не надо, но я рекомендую как минимум разобраться с их ходом мыслей Liz Fong-Jones и ее команды (из зафолловить ее).
Там много правильных идей на тему цена-производительность-заплатить вендору

Вдогонку к предыдущему сообщению, тредик из Твитера Liz
- видео и код с прибаутками как запустить это дело на Graviton2
- в блоге еще сказано не юзать стоковую OpenJDK, а юзать Correto
- ZStandard compression можно юзать в проде

irate() vs rate() — What’re they telling you?

Prometheus makes available great functions for data aggregation by timeline. Among these functions, I focused my analysis on irate() and rate() which give us similar outcomes but they work in different way. Читать дальше.

Оказывается у AWS есть альтернативная (честная) версия их AWS Service Health Dashboard. Потому что, как мне сказали оригинальный продукт - bullshit. Поэтому, если у вас AWS то вам бует полезно добавить в закладки https://stop.lying.cloud/

Introducing Prometheus Agent Mode

The Agent mode optimizes Prometheus for the remote write use case. It disables querying, alerting, and local storage, and replaces it with a customized TSDB WAL. Everything else stays the same: scraping logic, service discovery and related configuration.

Нормально! 💪

https://prometheus.io/blog/2021/11/16/agent/

Production Readiness Review (PRR)

Несколько лет назад Google рассказал миру о том кто такие SRE (Site Reliability Engineers) и как они помогут обеспечить надежность приложения в продакшене. Кто-то из вас наверняка слышал, что SRE реализуют практики DevOps, а сам по себе DevOps это больше философия чем роль в команде. PRR это процесс, который позволяет подготовить приложение к продакшену. На первом этапе рождается чеклист, лучше всего если чеклист отражает опыт команды и учитывает нюансы эксплуатации продукта. Когда чеклист готов, начинается процесс ревью, человек от команды и ревьюер встречаются и на коротких митингах проходят чеклист, сфокусированно, не распыляясь, качественно. Сам факт прохождения PRR обещает значительно уменьшить количество проблем в продакшене, как минимум благодаря тому что к некоторым из них мы уже готовы и зафиксировали как риски

Вот небольшая статья от GrafanaLabs: https://grafana.com/blog/2021/10/13/how-were-building-a-production-readiness-review-process-at-grafana-labs/

#practice #sre

Не повторяйте: мои инфраструктурные ошибки / Хабр
https://habr.com/ru/company/ispsystem/blog/594819/