Forwarded from Записки админа
🛠 External Debugging Tools 1: dtrace and strace - о работе с dtrace и strace, с примерами использования.
https://talktotheduck.dev/external-debugging-tools-dtrace-strace
#strace #dtrace #фидбечат
https://talktotheduck.dev/external-debugging-tools-dtrace-strace
#strace #dtrace #фидбечат
Forwarded from Мониторим ИТ
How Grafana Mimir helped Pipedrive overcome Prometheus scalability limits
Около восьми месяцев назад мы начали замечать проблемы с Prometheus, который начал падать без видимой причины. Увеличение ресурсов помогло только до 32 vCPU и 256 ГБ памяти, далее это оказалось бесполезным и не решило проблемы. Перезапуск Prometheus занимал до 15 минут, мы не могли позволить себе эти задержки, так как наша стратегия обеспечения наблюдаемости и алертинга зависела от доступности Prometheus.
Для агрегированного экземпляра Prometheus проблемы начались, когда мы достигли ~8 миллионов активных серий, ~20 миллионов чанков и ~200 тысяч пар меток.
Принимая во внимание все функции, которые представил Mimir, такие как высокая производительность запросов, а также наш предыдущий опыт работы с инструментами Grafana, мы решили сразу же внедрить Mimir в наш стек. Читать дальше.
Около восьми месяцев назад мы начали замечать проблемы с Prometheus, который начал падать без видимой причины. Увеличение ресурсов помогло только до 32 vCPU и 256 ГБ памяти, далее это оказалось бесполезным и не решило проблемы. Перезапуск Prometheus занимал до 15 минут, мы не могли позволить себе эти задержки, так как наша стратегия обеспечения наблюдаемости и алертинга зависела от доступности Prometheus.
Для агрегированного экземпляра Prometheus проблемы начались, когда мы достигли ~8 миллионов активных серий, ~20 миллионов чанков и ~200 тысяч пар меток.
Принимая во внимание все функции, которые представил Mimir, такие как высокая производительность запросов, а также наш предыдущий опыт работы с инструментами Grafana, мы решили сразу же внедрить Mimir в наш стек. Читать дальше.
Forwarded from /usr/bin
Exploring the Linux proc file system
Представление каждого объекта операционной системы в виде файла означает, что вы можете найти в файловой системе всевозможные вещи, такие как, например, процессы операционной системы. Запущенные процессы находятся в каталоге /proc, и сегодня мы поговорим о том, что мы можем там найти. Читать дальше.
Представление каждого объекта операционной системы в виде файла означает, что вы можете найти в файловой системе всевозможные вещи, такие как, например, процессы операционной системы. Запущенные процессы находятся в каталоге /proc, и сегодня мы поговорим о том, что мы можем там найти. Читать дальше.
Forwarded from /usr/bin
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
Ранее в этом году мы заметили странные пробелы примерно в 0,5% трассировок наших распределенных приложений. Эти перерывы длились до нескольких секунд и приводили к ухудшению обслуживания пользователей и почти ежедневным оповещениям в течение нескольких недель. Мы подозревали, что причина этих пробелов лежит вне кода приложения, где-то в сети или еще в слоях программного обеспечения, поверх которых работают наши приложения.
В этом цикле из 3 статей команда Teachers Pay Teachers разбирается с трассировкой вызовов внутри операционной системы.
Debugging Distributed Trace Gaps with tcpdump
Debugging Distributed Trace Gaps with ftrace
Monitoring Linux Audit
Forwarded from Записки админа
🔧 An Incident Command Training Handbook - занятное чтиво для тех, кто сталкивается (или будет сталкиваться) в своей работе с инцидентами, и встаёт у руля в процессе их распространения и решения, становясь так называемым Incident Commander'ом.
#sre #напочитать #incident
#sre #напочитать #incident
Forwarded from Experimental chill
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, все дела.
Приятная для чтения статья, много всяких примеров можно придумать в голове
Я как-то тут писал про метастабильные падения с конференции 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, все дела.
Приятная для чтения статья, много всяких примеров можно придумать в голове
Forwarded from /usr/bin
Structured Logging in a Shell Script with jq
Доработка скриптов для структурированного ведения логов означает, что вы можете себе помочь сократить среднее время решения проблем. Мы напишем простую функцию-оболочку вокруг jq, чтобы улучшить сообщения в логе. Читать дальше.
Доработка скриптов для структурированного ведения логов означает, что вы можете себе помочь сократить среднее время решения проблем. Мы напишем простую функцию-оболочку вокруг jq, чтобы улучшить сообщения в логе. Читать дальше.
Forwarded from Cybershit
Сегодня частично затронем тему EndpointSecurity и поговорим про инструмент osquery. Исторически osquery сделали инфраструктурщики в Facebook, под свои задачи еще в 2013, а после публикации в опенсорс он завоевал сердечки и остальных.
Эта штука способа превратить ОС в реляционную базу данных, а вас вооружить всей мощью SQL чтобы с этими данными работать.
Глянуть историю процессов в динамике, найти стремные файлы используя YARA-правила или отобразить открытые порты — проще простого, собрать все недавние http запросы, включая JA3 от TLS — изи, нужно что-то посложнее? На самом деле все ограничивается вашей фантазией потому что у osquery есть свой SDK и возможность подключения расширений, написанных на плюсах, go или python.
Модель взаимодействия может быть тоже разной, агент может ждать запросы от мастера, или отгружать нужную инфу по шедулеру. Можно также организовать отправку всего этого добра в SIEM, напрямую в Elastic или еще какие IR системы.
Для тех, кто любит чтобы еще и красиво было можно сразу ставить в связке с fleetdm или osctrl для понятного и единого UI.
К слову для MacOS это вообще наверное лучшее, что существует на сегодняшний день для аналитики и мониторинга.
Помимо классики, osquery умеет в k8s, с помощью плагина kubequery, и частично в облака, но для этих целей уже лучше будет посмотреть в сторону cloudquery, правда это уже проект от других авторов и отдельная тема для разговора.
osquery > https://osquery.io/
cloudquery > https://www.cloudquery.io
k8s plugin > https://github.com/Uptycs/kubequery
UI > https://fleetdm.com, https://osctrl.net/
Overview > https://blog.palantir.com/osquery-across-the-enterprise-3c3c9d13ec55
QueryCon 2019 > http://www.youtube.com/watch?v=oaxappbTc2A&list=PLciHOL_J7IwoYxJ7FwJ-aomCBZViDBMas
osquery в мире AppSec > https://2019.zeronights.ru/wp-content/themes/zeronights-2019/public/materials/2_ZN2019_igor_grachev_evgenij_sidorov_andrej_kovalevOsquery_AppArmor.pdf
Старенькие конфиги для примера > https://github.com/palantir/osquery-configuration
Эта штука способа превратить ОС в реляционную базу данных, а вас вооружить всей мощью SQL чтобы с этими данными работать.
Глянуть историю процессов в динамике, найти стремные файлы используя YARA-правила или отобразить открытые порты — проще простого, собрать все недавние http запросы, включая JA3 от TLS — изи, нужно что-то посложнее? На самом деле все ограничивается вашей фантазией потому что у osquery есть свой SDK и возможность подключения расширений, написанных на плюсах, go или python.
Модель взаимодействия может быть тоже разной, агент может ждать запросы от мастера, или отгружать нужную инфу по шедулеру. Можно также организовать отправку всего этого добра в SIEM, напрямую в Elastic или еще какие IR системы.
Для тех, кто любит чтобы еще и красиво было можно сразу ставить в связке с fleetdm или osctrl для понятного и единого UI.
К слову для MacOS это вообще наверное лучшее, что существует на сегодняшний день для аналитики и мониторинга.
Помимо классики, osquery умеет в k8s, с помощью плагина kubequery, и частично в облака, но для этих целей уже лучше будет посмотреть в сторону cloudquery, правда это уже проект от других авторов и отдельная тема для разговора.
osquery > https://osquery.io/
cloudquery > https://www.cloudquery.io
k8s plugin > https://github.com/Uptycs/kubequery
UI > https://fleetdm.com, https://osctrl.net/
Overview > https://blog.palantir.com/osquery-across-the-enterprise-3c3c9d13ec55
QueryCon 2019 > http://www.youtube.com/watch?v=oaxappbTc2A&list=PLciHOL_J7IwoYxJ7FwJ-aomCBZViDBMas
osquery в мире AppSec > https://2019.zeronights.ru/wp-content/themes/zeronights-2019/public/materials/2_ZN2019_igor_grachev_evgenij_sidorov_andrej_kovalevOsquery_AppArmor.pdf
Старенькие конфиги для примера > https://github.com/palantir/osquery-configuration
Forwarded from /usr/bin
Linux: how to add a filesystem to fstab the right way
Если имя устройства для хранения /dev/sdb1, это означает, что это первый раздел второго жесткого диска, но нет гарантии, что /dev/sdb1 всегда будет именован /dev/sdb1. В зависимости от порядка подключения жестких дисков к материнской плате он может меняться, а использование внешних USB-накопителей может еще более усложнить присвоение имен устройствам. Если это произойдет, ваши жесткие диски могут быть смонтированы в неправильных точках монтирования, что приведет к потере или повреждению данных.
Решение этой проблемы состоит в том, чтобы смонтировать диски, используя их метки или их UUID. Я предпочитаю использовать метки, потому что у меня есть возможность установить специальную метку, чтобы увидеть метки дисков. В этой статье расскажу про утилиту blkid. Читать дальше.
Если имя устройства для хранения /dev/sdb1, это означает, что это первый раздел второго жесткого диска, но нет гарантии, что /dev/sdb1 всегда будет именован /dev/sdb1. В зависимости от порядка подключения жестких дисков к материнской плате он может меняться, а использование внешних USB-накопителей может еще более усложнить присвоение имен устройствам. Если это произойдет, ваши жесткие диски могут быть смонтированы в неправильных точках монтирования, что приведет к потере или повреждению данных.
Решение этой проблемы состоит в том, чтобы смонтировать диски, используя их метки или их UUID. Я предпочитаю использовать метки, потому что у меня есть возможность установить специальную метку, чтобы увидеть метки дисков. В этой статье расскажу про утилиту blkid. Читать дальше.
Forwarded from Мониторим ИТ
Monitoring errors in your A/B tests
A/B-тестирование — важный инструмент для улучшения продукта. В Preply, мы запускаем сотни тестов ежеквартально, доставляя наш продукт с невероятной скоростью. Но запуск теста всегда связан с некоторыми рисками — вы никогда не можете быть уверены, что протестировали каждый отдельный кейс и не создадите проблем, особенно если вы двигаетесь быстро. Некоторые проблемы могут возникнуть из-за различных взаимодействий A/B-тестов, которые не всегда можно предсказать. Какое решение? Правильный мониторинг. И я говорю не о стиле «подождите, пока кто-нибудь свяжется со службой поддержки», а о автоматизированном подходе, основанном на данных. Читать дальше.
A/B-тестирование — важный инструмент для улучшения продукта. В Preply, мы запускаем сотни тестов ежеквартально, доставляя наш продукт с невероятной скоростью. Но запуск теста всегда связан с некоторыми рисками — вы никогда не можете быть уверены, что протестировали каждый отдельный кейс и не создадите проблем, особенно если вы двигаетесь быстро. Некоторые проблемы могут возникнуть из-за различных взаимодействий A/B-тестов, которые не всегда можно предсказать. Какое решение? Правильный мониторинг. И я говорю не о стиле «подождите, пока кто-нибудь свяжется со службой поддержки», а о автоматизированном подходе, основанном на данных. Читать дальше.
Forwarded from Мониторим ИТ
Distributed Tracing for RabbitMQ with OpenTelemetry
В этой статье вы узнаете, как использовать OpenTelemetry для инструментирования RabbiMQ. Затем увидите, как визуализировать трейсы в Jaeger и Aspecto. В статье используется Node.js для всех примеров кода. Читать дальше.
В этой статье вы узнаете, как использовать OpenTelemetry для инструментирования RabbiMQ. Затем увидите, как визуализировать трейсы в Jaeger и Aspecto. В статье используется Node.js для всех примеров кода. Читать дальше.
Forwarded from Мониторим ИТ
AIOPs: Anomaly detection in Prometheus Time Series data with Prophet library
..используя Prophet, чтобы заглянуть в прошлое и найти аномалии
Prophet — библиотека прогнозирования временных рядов с открытым исходным кодом.
Prophet — это процедура прогнозирования данных временных рядов на основе аддитивной модели, в которой нелинейные тренды соответствуют годовой, недельной и ежедневной сезонности.
Он следует концепции точек изменения; то есть он меняет аппроксимацию кривой на основе точек перегиба, которые он идентифицирует в данных временного ряда. Мы можем нанести точки изменения, чтобы визуально увидеть точки перегиба, которые он идентифицирует. Следовательно, он очень хорошо вычисляет тренды.
Мы можем использовать это свойство, чтобы подогнать данные временных рядов из Prometheus или Grafana и использовать его для обнаружения выбросов, которые являются точками аномалий.
Читать дальше.
..используя Prophet, чтобы заглянуть в прошлое и найти аномалии
Prophet — библиотека прогнозирования временных рядов с открытым исходным кодом.
Prophet — это процедура прогнозирования данных временных рядов на основе аддитивной модели, в которой нелинейные тренды соответствуют годовой, недельной и ежедневной сезонности.
Он следует концепции точек изменения; то есть он меняет аппроксимацию кривой на основе точек перегиба, которые он идентифицирует в данных временного ряда. Мы можем нанести точки изменения, чтобы визуально увидеть точки перегиба, которые он идентифицирует. Следовательно, он очень хорошо вычисляет тренды.
Мы можем использовать это свойство, чтобы подогнать данные временных рядов из Prometheus или Grafana и использовать его для обнаружения выбросов, которые являются точками аномалий.
Читать дальше.
Forwarded from /usr/bin
A curated list of “Top” based monitoring tools for use in Linux and Unix terminals.
В этой статье ссылки на репозитории инструментов для мониторинга Linux.
Для мониторинга статуса процессов: htop, bpytop, btop, bashtop, atop, vtop, gtop, gotop, ytop, treetop, tiptop, pytop, mintop, ntop, below, hegemon, glances, nmon.
Для мониторинга GPU: nvtop, intel_gpu_top, radeontop, gltop.
Для мониторинга сети: iftop, sntop, jnettop, dnstop, nats-top, nettop, pingtop, iptraf-ng.
Для мониторинга дисковой подсистемы: iotop, drbdtop, nfstop, hdtop, viotop.
Для мониторинга контейнеров: ctop, ktop, kube-top.
И много других.
В этой статье ссылки на репозитории инструментов для мониторинга Linux.
Для мониторинга статуса процессов: htop, bpytop, btop, bashtop, atop, vtop, gtop, gotop, ytop, treetop, tiptop, pytop, mintop, ntop, below, hegemon, glances, nmon.
Для мониторинга GPU: nvtop, intel_gpu_top, radeontop, gltop.
Для мониторинга сети: iftop, sntop, jnettop, dnstop, nats-top, nettop, pingtop, iptraf-ng.
Для мониторинга дисковой подсистемы: iotop, drbdtop, nfstop, hdtop, viotop.
Для мониторинга контейнеров: ctop, ktop, kube-top.
И много других.
Forwarded from Мониторим ИТ
5 tips on implementing Observability
⚡️ Tip 1. Productionize your programming languages
⚡️ Tip 2. Alert on most important service metrics
⚡️ Tip 3. Add some blackbox monitoring into the mix
⚡️ Tip 4. Learn querying your metric database
⚡️ Tip 5. Invest in tracing
Читать дальше.
⚡️ Tip 1. Productionize your programming languages
⚡️ Tip 2. Alert on most important service metrics
⚡️ Tip 3. Add some blackbox monitoring into the mix
⚡️ Tip 4. Learn querying your metric database
⚡️ Tip 5. Invest in tracing
Читать дальше.
Forwarded from Мониторим ИТ
Displaying Real-Time Sensor Data in Grafana using MQTT
Начиная с Grafana 8.0 можно выполнять обновления данных в реальном времени с помощью нового потокового API. Это означает, что теперь можно создавать диаграммы, которые обновляются в режиме реального времени и по запросу.
Чтобы использовать эту функцию, можно использовать плагин MQTT, который позволяет пользователям Grafana визуализировать данные MQTT в режиме реального времени. В этой статье о том, как использовать датасорс MQTT для отображения данных датчиков в режиме реального времени. Читать дальше.
Начиная с Grafana 8.0 можно выполнять обновления данных в реальном времени с помощью нового потокового API. Это означает, что теперь можно создавать диаграммы, которые обновляются в режиме реального времени и по запросу.
Чтобы использовать эту функцию, можно использовать плагин MQTT, который позволяет пользователям Grafana визуализировать данные MQTT в режиме реального времени. В этой статье о том, как использовать датасорс MQTT для отображения данных датчиков в режиме реального времени. Читать дальше.
Forwarded from Мониторим ИТ
ioping
Инструмент для мониторинга задержки ввода-вывода в режиме реального времени. Он показывает задержку диска так же, как ping показывает задержку сети.
Репыч на Гитхабе.
Инструмент для мониторинга задержки ввода-вывода в режиме реального времени. Он показывает задержку диска так же, как ping показывает задержку сети.
Репыч на Гитхабе.
Forwarded from DevBrain
Как работает Redis? Узнать можно тут: https://bit.ly/3pIbA5b
architecturenotes.co
Redis Explained
A deep technical dive into all things Redis. Covering various Redis topologies, data persistence and process forking.