Возможности:
— поддерживает аутентификацию с помощью пароля, NTLM-хеша, тикетов Kerberos или сертификата PEM/PKCS#12
— преобразует дату/время, логические значения и другие категориальные атрибуты в читаемый текст
— красивые цвета и крутые эмодзи
— поддержка LDAPS и StartTLS
— быстрый проводник, загружающий объекты по запросу
— рекурсивный поиск объектов в сочетании с полезными сохраненными поисковыми запросами
— гибкий поиск участников групп и групп пользователей
— поддерживает создание, редактирование и удаление объектов и атрибутов
— поддерживает перемещение и переименование объектов
— поддерживает поиск удаленных и переработанных объектов
— поддерживает экспорт определенных поддеревьев каталога в файлы JSON.
— интерактивный редактор userAccountControl
— интерактивный просмотрщик + редактор DACL
— интерактивный просмотрщик + редактор ADIDNS (базовый)
— просмотрщик групповых политик
— поддержка SOCKS

<gitlab_domain_name> : <timestamp> ,<gitlab_domain_name> : <timestamp>, <gitlab_domain_name> : <timestamp>

vector(${gitlab:value} - time())

- job_name: gitlab-access-token-exporter
  kubernetes_sd_configs:
    - role: endpoints
  relabel_configs:
    - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
      action: keep
      regex: monitoring;gitlab-access-token-exporter;http
    - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name]
      replacement: ${1}/${2}
      target_label: kubernetes_service
    - target_label: gitlab
      replacement: <you gitlab domain name>

gitlab_project_access_token_expires_in_seconds > 0 and gitlab_project_access_token_expires_in_seconds < 14 * 24 * 3600

Немного контекста о воркшопе: Пять команд, каждой достался свой кейс для работы в группе – описание некого высоконагруженного сервиса, его архитектуры, требований SLA и сценарий инцидента. За 30 минут командам предстояло спроектировать систему наблюдаемости своего продукта: описать метрики, логи, трейсы и SLO для сервисов, придумать алерты и дашборды. Каждому столу дали по 5 минут на презентацию и защиту своего решения, затем оценка от соперников и экспертного жюри. Нашей задачей, как экспертов, стала фасилитация обсуждения – мы помогали участникам, направляя их в нужную сторону, не давая растекаться мыслью по древу и углубляться в лишние детали.

Наблюдаемость – это свойство системы, его характеристика. Мониторинг – это процесс обеспечения непрерывности этой системы, основанный в первую очередь на реагировании на сигналы и события от ваших систем наблюдаемости.

Упала самописная приложенька в местном PaaS-е, потянув за собой продакшн, но клиенты ничего не заметили, потому что отработал Circuit Breaker

Следуя нашему правилу вносить изменения в инфраструктуру максимально осторожно, мы сперва выкатили всё на стейдж. Развёртывание прошло успешно. Но спустя несколько недель начались спорадические сбои: примерно раз в неделю один из агентов Cilium падал так, что приходилось полностью перезагружать весь узел. Никаких явных паттернов или очевидных причин. Баг случался редко, но бил слишком больно, чтобы пускать такое в production.

Первая мысль — скорее всего, намудрили с конфигурацией, ведь Cilium — серьёзный, проверенный в бою проект, который используют тысячи компаний по всему миру. Наверняка мы допустили ошибку в конфигурации или столкнулись с пограничным случаем. Забегая вперед — догадка оказалась и верной, и неверной одновременно, причём весьма неожиданным образом.
. . .
Заметил кое-что интересное: упавшие агенты Cilium потребляли аномально много памяти во время запуска узлов, на которых они размещались. Причём потребление памяти не росло постепенно — на графиках были видны резкие всплески прямо при инициализации узла.
. . .
Я начал экспериментировать с различными параметрами Cilium: лимитами памяти, размерами eBPF-карт, различными настройками производительности. Затем попробовал отключить одну специфическую опцию, связанную с производительностью (bpf-distributed-lru: false), и перезапустил тест. Сбои прекратились. Включил её обратно — сбои вернулись. Снова отключил — всё стабильно. Многочисленные перезапуски теста показали: закономерность сохраняется.
Это была первая реальная зацепка: баг был напрямую связан с некой оптимизацией, которую мы включили, руководствуясь официальными гайдами Cilium.
. . .
При включённом distributed LRU ядро округляет вверх количество записей в карте до значения, кратного num_possible_cpus().
Вот где скрывалась проблема! Ядро автоматически корректировало размер любой карты так, чтобы он был кратен количеству ядер процессора. В конфиге Cilium мы жёстко прописали статический размер карты, как рекомендует официальная документация: bpf-ct-global-tcp-max: 131072

Это степень двойки (131 072 = 217), как и рекомендуют гайды. И оно отлично работало… пока количество ядер тоже было степенью двойки. Но вот в случае 36, 48 или 72 ядер значение округлялось вверх, создавая несоответствие.

Последовательность событий, которая приводила к проблеме, выглядит следующим образом:

- Cilium настраивает карту на 131 072 записи.

- Ядро округляет это значение до 131 076 (на узле с 36 ядрами).

- Цикл согласования (reconciliation) Cilium проверяет размер карты.

- Обнаружено расхождение: в карте 131 076 записей, а должно быть 131 072.

- Cilium удаляет карту и пересоздаёт её с размером 131 072 записи.

- Ядро округляет значение до 131 076… и так до бесконечности!