Как устроен прикладной и бизнес-мониторинг сервисов НСПК

Zabbix, Elastic и Splunk.

​Announcing Grafana Tempo, a massively scalable distributed tracing system

И целого Jaeger мало! В семействе Grafana пополнение. Перейти на распределенный трейсинг.

​Pktvisor: Open source tool for network visibility

NS1 announced that pktvisor, a lightweight, open source tool for real-time network visibility, is available on Github. Читать дальше.

Репыч на Гитхабе.

​Выбор SLO: пошаговая инструкция в блоге Гугл на примере интернет-магазина.

How to use relabeling in Prometheus and VictoriaMetrics

Prometheus supports relabeling, which allows performing the following tasks:

⚡️ Adding new label

⚡️ Updating existing label

⚡️ Rewriting existing label

⚡️ Updating metric name

⚡️ Removing unneeded labels

⚡️ Removing unneeded metrics

⚡️ Dropping metrics on certain condition

⚡️ Modifying label names

⚡️ Chaining relabeling rules

Lets’ looks at how to perform each of these tasks. Читать дальше.

Если у вас TICK или нечто похожее, есть хорошая новость:

InfluxDB 2.0 Open Source is Generally Available

Today, we are proud to announce that InfluxDB Open Source 2.0 is now generally available for everyone. It’s been a long road, and we couldn’t have done it without the amazing support and contributions of our community. This marks a new era for the InfluxDB platform, but it truly is just the beginning. Читать дальше.

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/