⏺ готовит в каждому видео тестовые стенды в AWS
⏺ бенчмарки на Go и Python к каждому видео https://github.com/antonputra/tutorials/tree/main/lessons
⏺ демонстрирует графики Grafana
⏺ использует анимированные слайды с темным фоном, на слайдах оставляет место в правом нижнем углу, чтобы потом вставить туда круг с видео
⏺ если показывает рабочий стол или среду разработки или браузер, то не накладывает кружок с видео на демо

⏺ делает много экспериментов
⏺ использует профессиональный звук и свет, так как занимался музыкой отдельно, использует профессиональное оборудование
⏺ использует полноразмерные слайды или слайды на половину экрана, использует разделение экрана на две равные части
⏺ использует сложный монтаж, где включает стоковое видео в ролик, собирает историю из кусочков стокового видео
⏺ возможно использует услуги специалиста по монтажу

"ретроспективный" канал от создателя лучших курсов по Gatling:
⏺ можно видеть как 5 лет назад он использовал простой монтаж и только демонстрацию экрана
⏺ как два года назад он использовал маркерную доску и несколько камер с несложным монтажом
⏺ как он начал использовать screen.studio год назад

⏺ использует много анимации и демонстрацию экрана
⏺ не использует видео с рассказчиком, использует только голос, демонстрацию экрана и анимацию

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

⏺ использует какое-то популярное решение для записи demo, может быть camtasia или prezi для наложения слайдов на видео
⏺ использует хромокей и анимированный фон, анимированный фон его фишка
⏺ снимает на GoPro и не использует сложное оборудование и свет

⏺ использует несложный монтаж с borumi

⏺YourKit Java Profiler поддерживается примерно тремя людьми, но это не точно
⏺ JProfiler поддерживался одним человеком (я пока только один контакт нашел)
⏺ jvm-tools/sjk активно поддерживается одним человеком, на github есть 26 участников проекта
⏺ AsyncProfiler судя по коммитам создавался двумя инженерами, потом долго-долго поддерживался одним инженером, и теперь в разработке участвуют 4 человека
⏺ VisualVM активно разрабатывается тремя инженерами, но всего 7 участников на github
⏺ Java Mission Control, где JFR используется как бекенд, активно разрабатывали около 20 человек, и 49 участников проекта есть на github
⏺ Grafana Pyroscope или Pyroscope, где AsyncProfiler используется как бекенд, имеет более 10 активных разработчиков и 221 участников на github

⏺YourKit Java Profiler: https://www.yourkit.com/forum/ — посмотрел на тех, кто отвечает на вопросы, заглянул в контакты на сайте и на linkedin
⏺ JProfiler: https://www.ej-technologies.com/company — посмотрел на контакты и на linkedin
⏺ jvm-tools/sjk: https://github.com/aragozin/jvm-tools/graphs/contributors оценил по github
⏺ AsyncProfiler: https://github.com/async-profiler/async-profiler/graphs/contributors
⏺ VisualVM: https://github.com/oracle/visualvm/graphs/contributors
⏺ Java Mission Control: https://github.com/openjdk/jmc/graphs/contributors
⏺ Grafana Pyroscope: https://github.com/grafana/pyroscope/graphs/contributors

Создать такой one pager и провести онбординг пользователей для такой страницы — важная и не самая очевидная задача

Где-то такую страницу называют Иконостас. Это страница Grafana с отражением статусов и основными графиками:

🟦🟦🟥🟦
🟦🟥📉📈
📊📈🟦🟦
🟦🟦🟥🟦

Я пробовал создавать много досок с большим количеством графиков и таблиц:
📊📈📉📈
🗂📊📊📊
🗂📈🗓📉
Это сложно читать и она может медленно грузиться

Пробовал доски с интерактивными диаграммами:
🖼🖼🖼🖼
📊📈📉📈
🗓📉🗓📉
Это круто, но почти никто не кликает по частям диаграмм — это неочевидно, что они интерактивные и по ним можно кликать.

Пробовал создавать страницу только со статусами:
🟦🟦🟥🟦
🟦🟥🟥🟦
и ссылками на детали при клике по статусам. Но видимо не хватило разнообразия статусов на такой доске. На моей версии пока только статусы по загрузке страниц, и нет запросов или подсистем или системных метрик или транзакций или чего-то ниже уровнем, чем страницы. Такой высокий уровень, возможно, слишком высокий. И не хватает деталей

А самую популярную доску мониторинга в мире — Node Exporter Full
https://grafana.com/grafana/dashboards/1860-node-exporter-full/
не считаю удачным примером one pager-а. Она конечно умещается в одну страницу, но она довольно большая и сложная. Она изначально компактная за счет строк (row). Но если строки раскрыть, то там много деталей. Безусловно, такой формат распространения очень удачный — достаточно установить одну доску, и все сразу видно. Но добавляется сложность

⏺ Буду пробовать делать что-то между просто статусами со ссылками и большим количеством графиков
⏺ И попробую посмотреть, что пользователи делают на доске и что ждут от мониторинга. Пользователи — коллеги

А кеширующий прокси-сервер между Grafana и хранилищем метрик позволяет решить проблему для более общего случая, в котором и обновление страницы дозагружает только сбойные панели

Большинство хранилищ метрик и логов доступны по HTTP и подключаются к Grafana по HTTP. Поэтому можно выставить вместо цепочки:
⏺ Grafana => Хранилище
Цепочку:
⏺ Grafana => Nginx => Хранилище

Так для InfluxDB использовал Nginx вот с такой конфигурацией:
⏺ https://gist.github.com/polarnik/cb6f22751e8d1590342198609243c529

Тут ключевые настройки были такие

Кеш на 20 минут в секции http { ... } :
⏺ proxy_cache_path /data/nginx/cache keys_zone=mycache:20m max_size=1g inactive=60m;

Указание этого кеша в http { server { location /query { ... } } } :
⏺ proxy_cache mycache;
⏺ proxy_cache_key "$host-$request_method-$request_uri";
⏺ proxy_cache_min_uses 1;
⏺ proxy_cache_methods GET;
⏺ proxy_ignore_headers Cache-Control;
игнорирование настроек кеширования от самого хранилища метрик тут обязательно, хранилище метрик будет говорить, что кешировать ответ не надо. Но если выбрать статический интервал времени:
⏺ 00:00:00 ... 12:00:00
но не динамический:
⏺ now-12h ... now
то кеширование будет успешно работать, потому что request_uri не изменится

Если хранилище метрик подключено к Grafana через POST-метод, то тогда в настройках кеширования можно указать:
⏺ proxy_cache_key "$host-$request_method-$request_uri-$request_body";
⏺ client_body_in_single_buffer on;
⏺ client_body_buffer_size 64k;
⏺ proxy_cache_methods GET POST;

Так как Nginx не будет выполнять авторизацию доступа к данным из кеша, то надо будет настроить Firewall так чтобы только IP-адрес Grafana Server имел доступ до Nginx Proxy. В этом случае авторизацию выполняет Grafana, и пользователи имеющие доступ до хранилища метрик там будут иметь доступ и кешу

Для всего остального есть Java. Если что-то не описано в документации библиотеки и не работает, то оно не заработает, скорее всего

Мне надо было обложить приложение разными агентами мониторинга. Агенты бывают для x64, arm64, musl, windows, … Я думал, что напишу в коде Dockerfile RUN IF … проверю переменные окружения и настрою то, что нужно. Это не работаем если контейнер собирает библиотека testcontainer, а не команда docker build

Если сделать слои и в каждом слое подготовить нужный агент, то команда копирования из слоя не работает для testcontainer

Но простая команда монтирования внешнего файла работает отлично. Поэтому всю сложную логику (какой агент выбрать, для какой архитектуры, …) делает Java, и потом монтирует нужный файл в оригинальный контейнер с приложением

⏺ в BeforeAll запустить небольшую систему и мониторинг к ней
⏺ в другом BeforeAll дождаться старта
⏺ нагрузить систему
⏺ проверить assertion-ы
⏺ в AfterAll все остановить и удалить

Я интроверт и начал активно ходить и выступать на конференциях с 2018 года. За семь лет прошёл путь от 🪫стресса до 🔋заряжения от митапов и конференций

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

А когда-то пробовал посетить максимум событий программы и мало общался. Думал не упустил ли что-то, а еще слушал комментарии других посетителей, они почти всегда были критическими. Это было время стресса

🔔Первый прилив энергии ощутил от вопросов. Я задавал вопросы, даже старался к каждому выступлению, все больше и больше и чувствовал что так мне нравится все больше и больше. Вопросы становились поводами для общения между докладами

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

Спонсор потерянного дня — старая версия библиотеки 🤦‍♂️

Ошибки были вот такие
[Test worker] ERROR org.testcontainers.dockerclient.DockerClientProviderStrategy - Could not find a valid Docker environment. Please check configuration.

🔴 И любые настройки не помогали для Docker Desktop 4.53.0, пока не обновился до testcontainers-java 2.0.2
🟠 Для предыдущей версии 4.52.0 помогало переключиться с docker context docker-linux на docker context default командой
docker cotext use default
🟢 А для версии Docker Desktop 4.51.0 просто работала библиотека testcontainers-java 1.21.1

Версии testcontainers: https://github.com/testcontainers/testcontainers-java/releases
Версии docker-desktop: https://docs.docker.com/desktop/release-notes/

Год назад работал над ускорением вот этой инсталляции
🕚https://qameta.io/our-customers/miro/
▶️3000 tests for each of the 400 pull requests being run every day
которая давала более 1млн новых launch за день

И делал доклад потом
🕚https://polarnik.github.io/Allure.TestOps.SpeedUp/slides.html
🕚https://www.youtube.com/watch?v=Bzs7cAweTLY

По результатам также появился вот этот раздел инструкции
🕚https://docs.qameta.io/allure-testops/install/database/#separating-connection-pools
▶️The analytics pool, if enabled, will be used for some of the read-only aggregated data queries. It is a common practice to use a separate database for analytics, with replication configured between the two databases.
Но честно говоря, именно для той инсталляции, нагрузка от аналитики не была такой огромной, что это требовало отдельной реплики.

Там нагрузка создавалась вставками и обновлениями в огромном количестве (1+ млн в день). А также запросами по API разных данных — интеграциями. И там хорошо помогло
🕚удалить некоторое количество индексов
🕚создавать partial-индексы только на новые данные, где launch >= ..., test_id >= ... — раз в неделю

Индексы все же были нужны, потому что свежие данные по API и через UI использовались. Но именно свежие

При этом удалять старые данные из системы было непроизводительно. Вот этот скрипт
🕚https://github.com/eroshenkoam/allure-testops-utils?tab=readme-ov-file#delete-launches-in-allure-testops
ставит много задач на удаление в очередь задач, а они тяжелые, тяжелее задач на выборку и вставку, поэтому если его запустить, то производительности конец. Его можно запускать по выходным. Если такие дни бывают у вашей системы. Но partial-индексы с фильтром по свежим id будут игнорировать все архивные записи, поэтому их наличие не будет сказываться на скорости