Комментарии 2
В комментариях к оригинальной статье в вашем блоге мне так и не ответили, попробую здесь спросить:
Fail: Мы не смогли обеспечить третье важное условие — наблюдаемость. Оказалось, в режиме, когда FIO проигрывает записанные трейсы, утилита не умеет проверять целостность данных. Мы можем запустить сценарий, но не увидим, сломалось ли что-то и, если сломалось, то где и как. Мы теряем одно из этих условий, и поэтому данный подход нам тоже никак не использовать для анализа нашей несчастной проблемы.
Я не знаю, может "наблюдаемость" уже устоявшийся термин в нагрузочном тестировании, но вероятно здесь подходит термин "корректность". То есть СХД должна корректно и полностью записать данные.
Наша команда в свое время остановилась на LTTng. Это довольно интересный инструмент, который позволяет собирать большое количество отладочной информации в единицу времени без существенного влияния на систему.
Почему не ebpf? На SO есть сравнение ebpf vs lttng (https://stackoverflow.com/a/74 114 798/3665613), но интересно ваш ответ услышать.
eBPF - очень гибкий и мощный инструмент - можно использовать как динамические, так и статические трейспоинты, производить предварительную обработку прямо во время сбора информации. Но, насколько мне известно, для eBPF нет готовых средств для сбора большого количества информации о событиях, происходящих с очень высокой частотой, при этом не оказывающего существенного влияния на исследуемую систему. На этом поле LTTng играет гораздо более уверенно. Конечно, ему требуются заранее расставленные по коду точки трассировки. Но оно того стоит, так как во время сбора трасс замедление работы исходной системы минимально, что для нас является определяющим.
Уравнение с тремя неизвестными: как отлавливать баги в системах хранения данных