Как вы мониторите CI/CD пайплайны?

Давай я тебе на пальцах объясню, как за мониторинг CI/CD браться, а то иначе можно в дебри уйти, как слепой крот. Это ж не просто посмотреть, зелёный пайплайн или красный — это целая наука, чтобы понять, где у тебя бутылочное горлышло и почему всё тормозит, как черепаха в патруле.

1. Сбор метрик — основа основ, без них ты слепой Нужно всё инструментировать, чтобы Prometheus мог эти данные хавать. Без цифр — ты просто гадаешь на кофейной гуще.

Вот как в Jenkins это прикрутить:

pipeline {
  agent any

  options {
    timestamps()
  }

  stages {
    stage('Build') {
      steps {
        script {
          def startTime = System.currentTimeMillis()
          // Шаги сборки
          sh 'mvn clean package'

          def duration = System.currentTimeMillis() - startTime
          // Экспорт метрики
          prometheusMetric(
            name: 'jenkins_build_duration_seconds',
            type: 'GAUGE',
            labels: [
              project: env.JOB_NAME,
              branch: env.GIT_BRANCH
            ],
            value: duration / 1000
          )
        }
      }
    }
  }

  post {
    always {
      // Метрика успешности
      prometheusMetric(
        name: 'jenkins_build_status',
        type: 'GAUGE',
        labels: [
          project: env.JOB_NAME,
          status: currentBuild.currentResult
        ],
        value: currentBuild.currentResult == 'SUCCESS' ? 1 : 0
      )
    }
  }
}

Суть в чём? Ты засекаешь, сколько сборка жрёт времени, и выплевываешь это в метрики. Потом смотришь — о, этот проект собирается 20 минут, ёпта, это же пиздец какой-то, надо разбираться.

В GitLab CI попроще, там текстовый формат:

build_job:
  script:
    - start=$(date +%s)
    - mvn clean package
    - end=$(date +%s)
    - duration=$((end - start))
    - echo "gitlab_ci_job_duration_seconds{job="$CI_JOB_NAME", pipeline="$CI_PIPELINE_ID"} $duration" > metrics.txt
  artifacts:
    reports:
      metrics: metrics.txt

Записал время в файлик — и всё, GitLab сам его подхватит. Красота.

2. Дашборды в Grafana — тут твои глаза и уши Накидал панелек, чтобы одним взглядом видеть всю картину. Что смотреть в первую очередь?

• Скорость: За сколько фича от коммита до продакшена доезжает. Если месяц — это пизда.
• Качество: Сколько сборок падает и главное — почему. Если из-за тестов — одно дело, а если из-за того, что кто-то криво код залил — другое.
• Производительность: Какие этапы самые долгие. Может, тесты по 40 минут бегут, а может, артефакты на Nexus полчаса грузятся.
• Ресурсы: Все ли воркеры живы, или половина легла, и задачи в очереди висят, как говно в проруби.

3. Логи в ELK — чтобы когда всё ебнулось, понять, кто виноват Настроил Filebeat на сбор логов с Jenkins, чтобы не лазить по сервакам и не гонять tail -f.

# Filebeat конфигурация для Jenkins
filebeat.inputs:
- type: log
  paths:
    - /var/jenkins_home/jobs/*/builds/*/log
  fields:
    source: jenkins
  json.keys_under_root: true
  json.add_error_key: true

Теперь все ошибки в одном месте, можно искать, фильтровать. Упала сборка — зашел в Kibana, нашёл по ID, и сразу видно, на каком шаге и какая ошибка вылезла. Волшебно, а не жизнь.

4. Алертинг — чтобы не проебать критическую проблему Настроил Alertmanager на вменяемые алерты, а не на каждый чих. Иначе заспамит так, что все уведомления в игнор улетят.

• Три фейла подряд за час — это уже не случайность, а закономерность, пора бить в колокола.
• Сборка дольше 30 минут — что-то пошло не так, возможно, зависло или утекло.
• Очередь из 10 задач — воркеров не хватает, пора масштабироваться.
• Агент офлайн 5 минут — возможно, он просто перезагружается, а возможно, сдох окончательно.

5. Уведомления — чтобы нужные люди знали в нужное время

• Slack: Зелёный пайплайн — в общий канал, для позитива. Красный — в канал команды, чтобы быстро среагировали. Критический алерт — лично в личку ответственным. Идеально.
• Jira: Если сборка упала из-за бага в тикете — автоматом создаётся подзадача или комментарий. Чтобы не потерялось.
• PagerDuty: Если всё совсем плохо и продакшн лежит — пусть дежурный инженер просыпается в три ночи. Зато быстро починят.

6. Отчеты и аналитика — для начальства и саморазвития Раз в неделю/месяц смотрю на эти ваши модные DORA-метрики. Не для галочки, а чтобы тренды видеть.

• Стали деплоить реже? Почему?
• Lead Time вырос? Где затык?
• Failure Rate подскочил? Что сломали?

Вот пример, как посчитать, сколько в среднем мерж-реквест висит:

-- Из базы данных GitLab
SELECT 
  EXTRACT(EPOCH FROM (merged_at - created_at)) / 3600 as lead_time_hours,
  COUNT(*) as merge_count
FROM merge_requests 
WHERE merged_at > NOW() - INTERVAL '30 days'
GROUP BY 1
ORDER BY 1;

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

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