LINUX.ORG.RU

Snuba init: job failed при деплое sentry в k8s кластер, падает python скрипт

 , ,


0

1

Доброго времени суток! Столкнулся с проблемой, что при деплое sentry в k8s падает одна из джоб, из-за чего весь деплой фейлится.

helm install sentry ./sentry-20.0.0.tgz --namespace sentry -f sentry-values.yaml

Название джобы - sentry-snuba-db-init. На этапе где она падает она должна предсоздать топики в кафке, типа provisioning.

Вот параметры с которыми поднимаются контейнеры джобы:

      containers:
        - name: snuba-init
          image: getsentry/snuba:23.6.1
          command:
            - snuba
            - bootstrap
            - '--no-migrate'
            - '--force'
          envFrom:
            - secretRef:
                name: sentry-snuba-env
          env:
            - name: LOG_LEVEL
              value: debug
            - name: SNUBA_SETTINGS
              value: /etc/snuba/settings.py
            - name: DEFAULT_BROKERS
              value: 10.43.132.22:9092
            - name: CLICKHOUSE_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: sentry-clickhouse
                  key: admin-password

Но прикол в том, что если я поднимаю свою поду с образа getsentry/snuba:23.6.1 и запускаю команду

LOG_LEVEL=debug DEFAULT_BROKERS=10.43.132.22:9092 snuba  bootstrap --no-migrate --force

То команда отрабатывает без ошибок и создаёт топики в кафке.

При деплое же, джоба фейлится с ошибкой

2024-03-24 07:02:50,370 Initializing Snuba...
2024-03-24 07:02:52,932 Snuba initialization took 2.560879148542881s
2024-03-24 07:02:52,933 Using Kafka with ()
2024-03-24 07:02:52,933 Attempting to connect to Kafka (attempt 0)...
2024-03-24 07:02:52,943 Connected to Kafka on attempt 0
2024-03-24 07:02:52,943 Adding topic events to creation list
Traceback (most recent call last):
  File "/usr/local/bin/snuba", line 33, in <module>
    sys.exit(load_entry_point('snuba', 'console_scripts', 'snuba')())
  File "/usr/local/lib/python3.8/site-packages/click/core.py", line 1130, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.8/site-packages/click/core.py", line 1055, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.8/site-packages/click/core.py", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.8/site-packages/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.8/site-packages/click/core.py", line 760, in invoke
    return __callback(*args, **kwargs)
  File "/usr/src/snuba/snuba/cli/bootstrap.py", line 87, in bootstrap
    create_topics(client, [t for t in Topic])
  File "/usr/src/snuba/snuba/utils/manage_topics.py", line 21, in create_topics
    num_partitions=topic_spec.partitions_number,
  File "/usr/src/snuba/snuba/datasets/table_storage.py", line 62, in partitions_number
    return settings.TOPIC_PARTITION_COUNTS.get(self.__topic.value, 1)
AttributeError: 'str' object has no attribute 'get'

То есть в переменной settings.TOPIC_PARTITION_COUNTS оказывается строка вместо словаря, насколько помню по коду там что-то вроде ИМЯ ТОПИКА - КОЛИЧЕСТВО ПАРТИЦИЙ.

Но почему команда падает только при деплое из helmа?

Я думаю что я делаю что-то не так, потому что у коллеги получалось задеплоить эту же версию сентри.

Кафку я пробовал деплоить как отдельно, так и ту что sentry тянет по зависимостям. Одинаковый результат.

Я пробовал обеспечить этот provisioning через сам деплой кафки, отключив эту snuba init job. Но тут опять прикол

  snubaInit:
    # As snubaInit doesn't support configuring partition and replication factor, you can disable snubaInit's kafka topic creation by setting `kafka.enabled` to `false`,
    # and create the topics using `kafka.provisioning.topics` with the desired partition and replication factor.
    # Note that when you set `kafka.enabled` to `false`, snuba component might fail to start if newly added topics are not created by `kafka.provisioning`.
    kafka:
      enabled: false

Ясно написано, что выставление этого параметра в false должно отключить создание топиков, но этого не происходит. snuba init всё равно пытается их создать и падает…

Что думаете об этом? Приветствую любые идеи как это можно ещё расковырять.. Я думал может какой-то питоновский инструмент засунуть, со всякими стек дампами и т.д., чтоб посмотреть где по функциям что не так идёт..

2024-03-24 07:02:52,943 Adding topic events to creation list

То есть тут этап, что он просто сначала формирует список топиков на создание, которые статически прописаны.. И вылетает

https://github.com/getsentry/snuba/blob/master/snuba/utils/streams/topics.py

https://github.com/getsentry/snuba/blob/master/snuba/utils/manage_topics.py

NeedHelpImInTrouble
() автор топика
settings.TOPIC_PARTITION_COUNTS.get(self.__topic.value, 1) AttributeError: 'str' object has no attribute 'get'

Заднее чутье говорит что проблема в конфиге. Этот самый partitions count должен быть dict (словарь/объект/map, короче ключ-значение), а он строка

Скорее всего должно быть не просто, например, 10, а topic1: 10, topic2: 10 и так для каждого

upcFrost ★★★★★
()
Последнее исправление: upcFrost (всего исправлений: 1)
Ответ на: комментарий от upcFrost

Очень странно settings.TOPIC_PARTITION_COUNTS вроде никак не заполняется, но при этом используется. А заполнен только в тестовых скриптах.

https://i.ibb.co/HxjK5fY/photo-2024-03-24-11-37-44.jpg

Это же получается уже косяк в самом коде? Я не вижу как через values.yaml и прочее это можно было бы прописать. Нет ни комментов, ничего..

NeedHelpImInTrouble
() автор топика
Ответ на: комментарий от NeedHelpImInTrouble

Получилось задеплоить.. Там похоже что-то с values было напутано. Использовал со свежего репозитория дефолтные + свои айпи для сервисов выставил, и нормально задеплоилось всё.

NeedHelpImInTrouble
() автор топика