Мониторинг. Алёртинг. Трейсинг.

Мы любим всё мониторить и алёртить.
Смотрим на показатели kube-state-metrics и его метриками, чтобы узнать как часто поды рестартились kube_pod_container_status_restarts_total.
Смотрим в node-exporter, чтобы оценить нагрузку ЦПу на нодах node_cpu_seconds_total.
Иногда выбираемся из своих сетей и смотрим на blackbox exporter чтобы прочекать доступностьт внешних сайтов через probe_success.

Когда базовые вещи покрыты и делать нечего мы растём дальше, у каждого из нас наступает момент развития.
Добавляются всякие шутки типа:
- кросс мониторинг алертинг
- срок действия кредов для azure service principle для разных тенантов
- мониторинг срока действия сертификатов SSL
и так далее.

Сегодня встала задача следить за токенами(PAT) в GitLab.
Не секрет, что, что эти токены могут использоваться везде, да хотя бы даже в sidecar контейнерах для gitsync, например, у airflow с DAGs. Когда токены протухают становится больно и мы страдаем.

Я потратил некоторое время на изучение как мне лучше их мониторить:
- собирать метрики напрямую из гитлаба. не подошло, он не отдаёт ничего по expired/revoke токенам
- обратиться к API гитлаба, удалить все старые/expired/неактивные токены. не прошло - гитлаб НЕ удаляет токены, он их ревоукает, если метод delete использовать. то есть нельзя вот так просто удалить токены, а потом написать свой собственный инструмент для мониторинга новых токенов, кто протухает.
Кстати можете глянуть сколько старых токенов у вас в гитлабе

token="glpat-***"
gitlab_url="https://gitlab***"

page=1
while true; do
    response=$(curl -s --header "PRIVATE-TOKEN: $token" "$gitlab_url/api/v4/personal_access_tokens?page=$page&per_page=50")
    if [[ -z "$response" || "$response" == "[]" ]]; then
        break
    fi
    echo "$response" | jq -r '.[] | select(.expires_at < "2025-01-01") | .id' >> expired_token_ids.txt
    ((page++))
done

В общем много изучал и читал, в итоге отказался от идеи работать с метриками.
Решил просто написать скрипт.
Как это работает:
- создаём новый репозиторий в гитлабе
- пилим пайплайн

# .gitlab-ci.yml
check-tokens:
  image: python:3.11-slim
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"
      when: always
    - if: $CI_PIPELINE_SOURCE == "web"
      when: always
  before_script:
    - pip install --no-cache-dir -r requirements.txt
  script:
    - python3 check_tokens.py
  variables:
    GITLAB_TOKEN: ${GITLAB_API_TOKEN}
    GITLAB_URL: "https://gitlab.****" #на самом деле тут есть CI дефолт переменная, надо переделать после написания заметки
    SLACK_WEBHOOK_URL: ${SLACK_WEBHOOK_URL}
  tags:
    - docker

- пилим requirements.txt

python-gitlab>=3.15.0
requests>=2.31.0
python-dateutil>=2.8.2

- ну и сам скрипт check_tokens.py
https://gist.github.com/kruchkov-alexandr/354cf4500f0471d10717c2f9197d08e2
* скрипт писла нейронка, мне было лень, все претензии к моей лени

- затем добавляем две переменные в гитлаб CICD, masked, protected

GITLAB_API_TOKEN
SLACK_WEBHOOK_URL

- не забывает включить крон для пайплайна 0 10 * * *

Что же всё это делает:
- раз в сутки запускается пайплайн в самом же гитлабе
- скрипт использует креды для подключения к апи гитлаба
- при помощи пагинации собирает инфу по всем токенам всех пользователей
- проверяет дифф между "текущая дата" и "срок действия токенов"
- если в течении ближайших 10 дней будет протухание - отправляет в слак уведомление