Top 25 Nginx Tips and Tricks From Practical Experience

Эта статья удобна для новичков, поскольку данные представлены от простого к сложному. Когда я начинал свою карьеру DevOps-инженера, мне не хватало таких материалов. Я постараюсь рассказать о том, как работает Nginx, а также о некоторых советах и рекомендациях из практического опыта. Читать дальше.

​Multi-site monitoring with HA and dynamic scale using VictoriaMetrics. A Practical guide

Это продолжение предыдущего поста What makes VictoriaMetrics the next leading choice for open-source monitoring. Цель этой статьи — рассказать, как спроектировать и развернуть многосайтовую кластерную архитектуру VictoriaMetrics в Kubernetes, которая работает на узлах Spot и On-demand и обеспечивает высокую доступность, динамическую масштабируемость, высокую производительность и экономию средств. Читать дальше.

​Filtering files and folders in Linux using find and grep

Фильтрация файлов и директорий при помощи пайпов, паттернов, match, find, grep и других инструментов. Читать дальше.

https://rclone.org/

☁️ Rsync для вашего Cloud

​Karma — единый событийный дашборд для кучи Alertmanager'ов

Агрегация, дедупликация, фильтрация и много других фич в этом полезном в хозяйстве инструменте.

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

​Performance testing with Iter8, now with custom metrics

Iter8 — это оптимизатор релизов приложений и моделей машинного обучения, развернутых с помощью Kubernetes, на основе метрик с открытым исходным кодом. Можно использовать Iter8 для проведения экспериментов, которые решают различные задачи, такие как сбор метрик из разных версий сервиса, проверка этих метрик на соответствие SLO, определение наиболее эффективной версии и многое другое. Читать дальше.

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

​Creating A Basic Load Test Infrastructure Via Using K6/Grafana/InfluxDB

В этой статье описано создание тестового окружения для тестирования производительности с помощью K6/Grafana/InfluxDB. Читать дальше.

​How to Handle Terabytes of Metrics in Kubernetes Monitoring

Мы использовали Prometheus, Thanos и Grafana для обрабатки около 40 000 метрик, генерируемых каждую секунду. В этом посте наша команда инженеров делится некоторыми мыслями и знаниями о нашем пути по настройке мониторинга. Читать дальше.

​Who monitors the monitoring system? — Is my Prometheus alive at all

Пока система жива и здорова, отправляйте heartbeat. Если мы какое-то время не получаем heartbeat, можно смело считать, что система мертва. Это самый надежный способ получить уведомление о сбое системы. Главный недостаток этого подхода заключается в том, что действительно трудно понять, что вызвало сбой. Читать дальше.

Consul Load-Balancing made simple

https://github.com/fabiolb/fabio

#consul #vault #loadbalancer

​Checkov: Security and Compliance for Infrastructure as Code

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

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

Squzy - opensource monitoring, incident and alerting system

Squzy высокопроизводительный открытый инструмент для мониторинга и алертинга, написанный на Golang.

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

🛠 External Debugging Tools 1: dtrace and strace - о работе с dtrace и strace, с примерами использования.

https://talktotheduck.dev/external-debugging-tools-dtrace-strace

#strace #dtrace #фидбечат

​How Grafana Mimir helped Pipedrive overcome Prometheus scalability limits

Около восьми месяцев назад мы начали замечать проблемы с Prometheus, который начал падать без видимой причины. Увеличение ресурсов помогло только до 32 vCPU и 256 ГБ памяти, далее это оказалось бесполезным и не решило проблемы. Перезапуск Prometheus занимал до 15 минут, мы не могли позволить себе эти задержки, так как наша стратегия обеспечения наблюдаемости и алертинга зависела от доступности Prometheus.

Для агрегированного экземпляра Prometheus проблемы начались, когда мы достигли ~8 миллионов активных серий, ~20 миллионов чанков и ~200 тысяч пар меток.

Принимая во внимание все функции, которые представил Mimir, такие как высокая производительность запросов, а также наш предыдущий опыт работы с инструментами Grafana, мы решили сразу же внедрить Mimir в наш стек. Читать дальше.

​Exploring the Linux proc file system

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

​Debugging Distributed Trace Gaps

Ранее в этом году мы заметили странные пробелы примерно в 0,5% трассировок наших распределенных приложений. Эти перерывы длились до нескольких секунд и приводили к ухудшению обслуживания пользователей и почти ежедневным оповещениям в течение нескольких недель. Мы подозревали, что причина этих пробелов лежит вне кода приложения, где-то в сети или еще в слоях программного обеспечения, поверх которых работают наши приложения.

В этом цикле из 3 статей команда Teachers Pay Teachers разбирается с трассировкой вызовов внутри операционной системы.

Debugging Distributed Trace Gaps with tcpdump

Debugging Distributed Trace Gaps with ftrace

Monitoring Linux Audit

🔧 An Incident Command Training Handbook - занятное чтиво для тех, кто сталкивается (или будет сталкиваться) в своей работе с инцидентами, и встаёт у руля в процессе их распространения и решения, становясь так называемым Incident Commander'ом.

#sre #напочитать #incident

https://www.usenix.org/system/files/osdi22-huang-lexiang.pdf

Я как-то тут писал про метастабильные падения с конференции HotOS. Как и ожидалось, академия тоже играет в индустрию, и по старой доброй традиции, если статья появляется на HotOS, то её решение или расширенная версия на OSDI. Одна статья на 2 конференции, как удобно!

Напомню, что про метастабильные падения можно думать как о падениях, из которых тяжело выйти откатив изменение -- вы что-то поменяли, откатываете, а проблема всё ещё осталась, так бывает из-за проблем retry, сброса кеша, который не может набраться, каскадные падения, невозможность обработать спайки ошибок (jitter).

В новой статье из интересного добавили группировку по реальным падениям в Cloud провайдерах, опыту твиттера и тд. Например, примерно половина из всех инцидентов возникла из-за плохой политики перезапросов, 35% из-за спайка ошибок. В статье хорошо разобраны тригеры таких состояний, которые можно применять как эвристики для их детекции и понижения нагрузки.

Хочется рассказать подробнее о _деградации_ (в статье её нет, в старом посте я её упомянул):

Что такое деградация? Деградация это достаточно редкий, но полезный трюк для того, чтобы сделать вашу систему неубиваемой, но для этого надо написать немного кода и иметь одно свойство -- возможность неполно читать данные. Иногда её ставят в ряд с congestion протоколами в сети, но редко тема выходит в сервисы.

В поисковых системах, в рекомендательных системах, в мониторинг системах, в не strongly consistent файловых системах вы можете придумать такие свойства

1. Искать по части поискового шарда
2. Задерживать показ viral постов/твитов/ютуб видосов или варьировать количество кластеров в поиске ближайших
3. Читать чуть-чуть старые данные, скажем, не для real time аналитики или mostly read only fs, a.k.a. stale reads
4. Увеличивать размеры временных корзин для сбора аналитики в мониторинг системах

Коэффициенты частичной обработки можно варьировать от очень консервативных чисел до очень неконсервативных. Можно сделать от 0 до 1 такой коэффициент.

Когда машина/система начинает испытывать трудности, коэффициент деградации можно понижать до нуля (в самом простом случае, выбирать бинпоиском число, более умно использовать всякие экспоненциальные формулы из congestion протоколов (об этом как-нибудь в другой раз)) и если есть много перезапросов или jitter из ошибок, то деградация поможет:

1. Плавно вытащить сервисы из типичных проблем перезапросов
2. Выиграть время для реагирования
3. Не сделать сильно плохо пользователям, искать по 80% поискового шарда не так уж и плохо
4. В случае критических глобальных проблем с датацентрами, мисконфигурацией, переживать неожиданное увеличение нагрузки намного легче

Другой пример, который мне пришёл на ум после прочтения статьи это time to live в файловых системах: хочется давать возможность людям ставить time to live на папки, но иногда бывает так, что кто-то решит удалить 3 миллиарда файлов и происходит следующее

1. Начинаем удалять папку
2. Не справляемся за сутки
3. Другие пользователи жалуются, что их файлы не удаляются

В итоге 3 недели удаляем 3 миллиарда файлов, другие файлы не удаляем. Чтобы сделать какой-то честный garbage collection, надо хитрить на клиентах (не показывать им файлы) или удалять в зависимости от редкости -- люди готовы подождать 3 недели для удаления 3 миллиардов файлов, но 3 недели для одного не очень. Тонкий баланс метастабильности как UX. И всё таки данные удалять надо, privacy, все дела.

Приятная для чтения статья, много всяких примеров можно придумать в голове

​Structured Logging in a Shell Script with jq

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