Ваш запуск находится на стадии планирования уже 11 минут, и вы не можете понять, продолжает ли загружаться провайдер AWS или у GitHub снова неудачный день. Логи показывают лишь общее время выполнения без разделения на init, plan и apply, поэтому вы перезапускаете процесс с флагом TF_LOG=DEBUG и прокручиваете вывод в надежде, что вторая попытка даст больше информации, чем первая.
В ходе нашего опроса 60 пользователей Spacelift 86% отметили, что каждую неделю сталкиваются с устранением неполадок медленных или завершившихся с ошибкой запусков, а почти половина копирует логи запусков во внешние ИИ-инструменты вроде ChatGPT для поиска причины. У команд разработки эти ответы благодаря распределенной трассировке были под рукой годами. Инфраструктурные запуски все еще остаются «слепой зоной».
OpenTofu продолжает выпускать то, о чем просят практики, и встроенная трассировка OpenTelemetry напрямую решает эту проблему, генерируя спаны для init, plan и apply. Мы внесли свой вклад в эту разработку на уровне исходного кода, и Spacelift стала первой платформой, которая применила ее на практике. Теперь каждый запуск в нативном стеке OpenTofu подскажет вам, почему произошло замедление или сбой и что именно нужно исправить.
Самое приятное то, что вам не нужно делать ничего особенного для работы этой функции в Spacelift. Она уже настроена и включена. Просто перейдите на вкладку Observability («Наблюдаемость») и оцените ее в действии. Это кардинально отличается от использования OpenTofu в чистом виде, где требуется выполнить несколько дополнительных шагов для достижения тех же результатов.
Spacelift Run Observability считывает трассировки OpenTofu OpenTelemetry, чтобы предоставить вам аналитику о производительности ваших запусков, причем каждая находка указывает на источник проблемы.
Допустим, GitHub падает в середине запуска, и этап init зависает на загрузке провайдера или модуля. Временная шкала фаз показывает, что инициализация значительно превышает базовые показатели, а список самых медленных установок провайдеров указывает на зависшую загрузку.
Крупным провайдерам часто требуется больше времени на установку, чем вашему плану на выполнение, именно поэтому время установки вынесено в отдельную разбивку вместе с рекомендацией, указывающей на кэш плагинов провайдера (актуально для организаций с частными воркерами). Одна из бета-команд даже не подозревала, что их установки происходят медленно, пока это не стало очевидно благодаря детальной разбивке. Если какой-то один ресурс затягивает фазу apply, список самых медленных ресурсов отображает его по адресу, и база данных, занявшая большую часть восьмиминутного применения, оказывается на самом верху.
Spacelift сопоставляет каждый запуск со стандартным временем выполнения для данного стека, что позволяет легко обнаруживать регрессии. Когда запуск завершается с ошибкой, вы видите сбойную фазу и сообщение об ошибке, извлеченное из трассировки, и можете обойтись без повторного запуска в режиме отладки.
Получите ответ и доказательства на одной вкладке
Каждый запуск в нативном стеке OpenTofu получает вкладку Observability, которая предоставляет аналитические данные о производительности на основе фактов. Вот что на ней находится:
В ходе тестирования 87% пользователей быстрее находили ответ с помощью находок, чем при анализе «сырой» трассировки, однако 90% все равно хотели иметь под рукой исходные данные для проверки. Именно поэтому Run Observability располагает каждую находку рядом с данными о времени ее выполнения.
В нативном стеке OpenTofu воркер Spacelift автоматически собирает спаны OpenTofu по мере выполнения запуска и формирует единую трассировку на один запуск. В отличие от использования Open Source OpenTofu, где для этого требуется развернуть бэкенд наблюдаемости или коллектор OpenTelemetry.
Spacelift оценивает эту трассировку на основе набора правил и истории запусков стека, а затем записывает результаты на вкладку Observability в виде находок (findings). Стеки Terraform не получают таких находок, поскольку Terraform не предоставляет данные об установке провайдеров или времени работы отдельных ресурсов.
Spacelift является одним из основателей проекта OpenTofu, и более половины всех запусков в Spacelift теперь выполняются на базе OpenTofu. Мы помогли внедрить трассировку непосредственно в сам OpenTofu, поэтому функция Run Observability лучше всего работает именно на нативных стеках OpenTofu, где доступны все виды находок.
Следующий шаг, который мы планируем реализовать, — это поддержка экспорта по протоколу OpenTelemetry Protocol (OTLP), который позволяет отправлять трассировки запусков в Datadog, Grafana Tempo, Honeycomb, New Relic или любой другой бэкенд, совместимый с OTLP, чтобы ваши привычные алерты распространялись и на IaC.
Функция Run Observability уже доступна в общем доступе (GA) для нативных стеков OpenTofu. Мы подробно разберем ее в прямом эфире во время OpenTofu Day на KubeCon и на вебинаре OpenTofu Observability 19 ноября.
Если вы все еще используете стеки Terraform на базе OpenTofu, мигрируйте их на нативные стеки OpenTofu, чтобы начать использовать Run Observability.
Тим Дэвис (Tim Davis)
Тим — технический менеджер по продуктовому маркетингу в компании Spacelift. Он обладает многолетним опытом работы в сфере инфраструктуры, ИТ-оперирования и автоматизации. Он выступал с докладами на многочисленных мировых конференциях, создавал технические сообщества и управлял ими, а также выпустил огромное количество технического контента за годы своей работы.
![Как импортировать существующие ресурсы в OpenTofu [Руководство]](/_next/image?url=%2Fapi%2Fuploads%2Farticles%2F959228ac34584bfc1a7416d4541e12d8.webp&w=1920&q=75)
