#docker #troubleshooting #одинденьизжизни

"Тревога-тревога, волк унёс зайчат!"
"Алекс, не работает VPN"
И сразу от нескольких человек.

Ну не работает, ну ладно.
Чего хоть не работает? Спрашиваем.
Ага, с ресолвами.
Ага, с доступом до ресурсов. Снова днс.
Пробую сам сделать коннект - ошибка.
Захожу в аминку впн - ошибка в UI.
Ладно.

Хер знает как у нас работает впн, сам никогда не лез.
Сам только тыкал мышкой в "коннект" на клиенте и всё.
Заходим в репозиторий с VPN/infra.
Ага, виртуальная машина, внутри докеры-полупокеры, юзердата шелл скрипт и tailscale админка.

Ну в целом понятно.
Всё на виртуалке, никаких кубернетисов.
Логи вряд ли мне, несведущему, чему-то помогут, пойдём сперва попроще.
Что может быть? Может диск заполнился.
Графана, дашборд node exporter - всё ок. Ни скачков по диску, ни по IOPS, ни по сети.
Эм, ну ок.
Может ажур поднасрал? Ни автоапдейтов, ни ивентов, ничего по ажуру.
Жаль, а так хотелось поху*сосить ажур снова.

Ну чо, впн это блокер для команды, нет времени разбираться.
Семь бед - один ресет.
Захожу в ажур, выбираю VM, делаю рестарт.
Помогло, но лишь частично - админка UI заработала и начали работать коннекты, но проблема с днс осталась.
Копаем дальше.
Дальше нырнув в код, вижу есть и пара других VM в инфре для впн.
У них так же явный трабл с DNS.
Ну я же синёр - повторяем семь бед - один ресет обеих тачек.
После рестарта всё заработало, клиенты довольны, команда больше не в блокере, днс ресолвит.

Теперь можно налить чай и дебажить "а чо было", да и надо куда-то часы трекера списать.
На час окунулся в логи приложения - ничего особо не понял, я половины терминов и компонентов даже не знаю, ну так же про днс что-то.
Пошли на виртуалки. Джампхост, ссш, шелл.
Смотрим какие у нас services есть, доступны ли все.
Все есть, все доступны.
Однако логи докера(компоуз) дали наводку.

~$ sudo journalctl -u docker
...
****** 02 14:41:32 ******-vm-us-3 dockerd[1989830]: time="20**-06-02T14:41:32.495924354Z" level=error msg="[resolver] failed to query external DNS server" client-addr="udp:127.0.0.1:57484" dns-server="udp:12>
****** 05 05:43:42 ******-vm-us-3 dockerd[1989830]: time="20**-06-05T05:43:42.432809963Z" level=error msg="[resolver] failed to query external DNS server" client-addr="udp:127.0.0.1:60244" dns-server="udp:12>

И так по кругу на миллион сообщений.
Значит проблема не со стороны аппликейшна в докере(компоузе), а с сетью - уровень докер лейера или операционной системы(скорее всего).
Ладно, а чо у нас с остальными логами.
Видим, что утром начался авто апдейт (unattended-upgrades в убунту).
То есть авто апдейт не на уровне ажура, а самой операционке.

******-06-10 06:17:03,994 INFO Starting unattended upgrades script
******-06-10 06:17:03,995 INFO Allowed origins are: o=Ubuntu,a=jammy, o=Ubuntu,a=jammy-security, o=Docker,a=jammy, o=UbuntuESMApps,a=jammy-apps-security, o=UbuntuESM,a=jammy-infra-security
******-06-10 06:17:03,995 INFO Initial blacklist: 
******-06-10 06:17:03,995 INFO Initial whitelist (not strict): 
******-06-10 06:17:09,777 INFO Packages that will be upgraded: apport libnss-systemd libpam-systemd libsystemd0 libudev1 python3-apport python3-problem-report systemd systemd-sysv udev
******-06-10 06:17:09,777 INFO Writing dpkg log to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
******-06-10 06:18:00,563 INFO All upgrades installed

И.. и всё, компонент systemd-resolved не захотел подниматься после апдейта.

****** 10 06:17:24 ******-vm-us-3 systemd-resolved[2663737]: Positive Trust Anchors:
****** 10 06:17:24 ******-vm-us-3 systemd-resolved[2663737]: . IN DS 20326 8 2 e06d44b80b8f1d3457104237c7f8ec8d
****** 10 06:17:24 ******-vm-us-3 systemd-resolved[2663737]: Negative trust anchors: home.arpa *.in-addr.arpa *.172.in-addr.arpa ***.192.in-addr.arpa d.f.ip6.arpa corp home internal intranet lan local private test
****** 10 06:17:24 ******-vm-us-3 systemd-resolved[2663737]: Using system hostname '******-vm-us-3'.
****** 10 06:17:24 ******-vm-us-3 systemd-resolved[2663737]: Failed to connect to system bus: Permission denied
****** 10 06:17:24 ******-vm-us-3 systemd-resolved

#zalando #kubernetes #troubleshooting

"Алекс, у нас там проблемы с БД, которая у вас в кубере - приложение не подключается к нему, пишет всякое".

Не в первой диагностировать что-либо, но сперва вводные:
все базы у нас в кубернетисе, всё через оператора. в аргосиди репо в приложениях мы просто клеймим бд/юзера и приложением забирает адрес, логин и пароль из секретов кубера. Всё достаточно просто.

Лезу в тикет джиры, тред в слаке - коллеги разработчики жалуются, что в случайное время бизнес приложением не может писать в базу. Где-то ошибка, что не возможно подключится, где-то пишет, что база данных находится в ридонли.

Читаю поверхностно логи приложения, оператора, кластера БД - всё вроде ок.
Через разрешение рестартую приложение - проблема уходит.
Закрываю тикет, с лицом Дукалиса-солнышко объясняю деткам-разработчикам, что магии не бывает - у вас приложение говно, раз рестарт POD-a с бизнесовым приложением помогает. БД я не трогаю вообще.

Спустя несколько дней ситуация повторяется, но я, как умный синёр самоуверенный помидор, делаю рестарт пода приложения и снова снисходительно поясняю неразумным коллегам - проблема на вашей стороне.

Не, ну правда - если я вообще не трогаю БД и рестарт бизнес апп помогает - как я мог решить, что виновата инфра?
И потом ситуация ещё пару раз.

А при повторе на другом стеке, другого бизнес приложения подобной ошибки, у нас в команде начинают появляться подозрения, что мы не такие уж и синёры, а обычные мартышки.
В команде всего двое, кто любит нырять глубоко в траблшутинг, ныряю я.

Логи логи логи. Не буду тратить время на описание, но я бессмысленно потратил несколько дней - и ничего не нашёл. Не зная, что искать - ничего и не находишь.
Жалобы время от времени всё поступали и мы совсем сникли.

Для помощи самому себе так же подняли, не моими силами, сбор метрик не только PostgreSQL, но и Patroni.
Однако метрики ничем не помогли.

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

demoting self because DCS is not accessible and I was a leader

Это была первая зацепка, и следом начал цепляться за всякое типа

20**/12/06 11:30:18 main.go:127: Connection stats - max: 200, used: 12, available: 185 (6.0% used)
20**/12/06 11:30:18 main.go:130: Connection states - active: 3, idle: 6, idle in transaction: 0
20**/12/06 11:30:18 main.go:274: Database in recovery mode: true

Зацепка, отписываем промежуточное мнение:
кластер делает свичовер но НЕ переключает на реплику(мы это видим по IP при ресолвинге)
наши бизнес приложения продолжают сидеть в том же пуле, их не выкидывает и не переключают на мастера
появляются новые пиды, у которых лайфсайкл времени идёт от времени свичовера.

Складывая в пул все найденные логи, какие-то новые для себя слова, я прихожу к
https://patroni.readthedocs.io/en/master/dcs_failsafe_mode.html
О, как это было похоже на то, что у нас происходило.
Не буду пояснять тут, в документации отлично всё расписано.

Проверяем: а есть ли у нас эта алупа:

root@test-db-2:/home/postgres# curl http://localhost:8008/config | jq
...
{
  "failsafe_mode": false,
...

Бл, а оно у нас и не включено.
Иду у чарт
https://github.com/zalando/postgres-operator/blob/master/docs/reference/operator_parameters.md#patroni-options
https://github.com/zalando/postgres-operator/blob/master/manifests/configmap.yaml#L52

В общем обосратушки, в операторе это выключено.
Для теста включаю в чарте в отдельном теге.
Затем в dev контуре перевожу все аппликейшны на новый чарт.

Проверяем применилось ли это:

kubectl exec -it test-db-0 -- curl http://localhost:8008/config | jq .failsafe_mode
true

и

kubectl get postgresql test-db -o yaml | grep -A 2 patroni
  patroni:
    failsafe_mode: true

Где не применилось, там спасибо оператору, пилим костыль

kubectl rollout restart statefulset test-db

Пару недель тестов - ошибка больше не повторялось. Ура, победа!

#kubernetes #azure #aks #troubleshooting #argo #dapr #api

Ныряем в Azure AKS API.

Часть 1 из 2.

У нас болел кубернетис апи.
Болел долго, со вкусом.
Словно мужчина 30+ лет с температурой 37.2, с опекой рядом кудахтающей супруги.

Мы честно хотели его вылечить, но у меня лично никогда не было глубокого опыта дебага апи, часть команды было просто пофиг. Вроде работает? Хорошо. Бизнес, само собой, такими вещами и не интересуется.
Это вызывало массу сайд эффектов: 4 или 5 из моих историй это следствие загрузки K8S API.
Работа операторов, работа кеды и dcs демоушн.

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

Путь первый. Невежественность.

В кластере много компонентов, которые работают с кубернетес апи.
ArgoCD, Kyverno, десятки операторов. Много всего.
Первый мой шаг - поэтапно вырубать контроллеры
То есть я тупо один за одним вырубал какие-то компоненты.

kubectl scale --replicas 0 sts/name
kubectl scale --replicas 0 deploy/name

и ждал. 30-60 минут, есть ли эффект.
Конечно же предупреждая коллег, и в случае необходимости тут же скейлил вверх.

Эта идея была тупая, я убил несколько часов/дней.
Никакого результата.

Путь второй. Наивность.

Дальше я выбрал путь наивности - ходил по приложениям, операторам и где мог, подкручивал параметры, чтобы обращения к АПИ был реже. Всякие реконсилейшн у арго, демоушн патрони, частота запросов кеда оператора и так далее.
Помогло ли это? Нет. Стало ли лучше? Глобально - да, ведь я просто оттюнил к лучшему.

К пункту наивности я бы добавил все мои попытки разобраться "что не так с апи по метрикам".
Метрики никак и никогда не дают информации кто же даёт основную нагрузку.

Путь третий. Просветление.

Очевидно предыдущие попытки были унылы и тупы.
Почитал интернет, нейронки, документацию.
Первым делом включаю аудит-лог.
Azure-Kubernetes-Monitoring-Diagnostic settings.
Дальше включаю для Kubernetes API и сохранение в Log Analytics workspace.
Сохраняю, иду в Log Analytics workspace.
Там выбираю Logs и ищу сперва все ошибки.

AKSControlPlane
| where Category == "kube-apiserver" and Level == "ERROR"
| limit 40
| project TimeGenerated, Level, Message

Вижу кучу ошибок.
Ок, начнем с рандом частой ошибки:

cacher (subscriptions.dapr.io): unexpected ListAndWatch error: failed to list dapr.io/v1alpha1, Kind=Subscription: conversion webhook for dapr.io/v2alpha1, Kind=Subscription failed: Post "https://dapr-webhook.replaceme.svc:443/convert?timeout=30s": service "dapr-webhook" not found; reinitializing...

Не заостряю внимание на продукте, мне он знаком (можно почитать на https://github.com/dapr/dapr/).
По ошибке проблема сервиса(хоть и странный адрес), а есть ли он?

kubectl get svc -n dapr-system | grep webhook
dapr-webhook            ClusterIP   10.0.12.141   <none>        443/TCP                                

Он есть.
Почему возникает эта ошибка?Сперва смотрю валуес

helm show values dapr/dapr --version 1.14.2

Нет ничего интересно, как и в нашем values файле.
Иду в чарт и качаю его к себе https://github.com/dapr/helm-charts/blob/master/dapr-1.14.2.tgz
Вижу кучу темплейтов, хелперсов, CRD.
В CRD указано, что сам оператор реплейсит CRD.

---
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
...
spec:
  group: dapr.io
  conversion:
    strategy: Webhook
    webhook:
      clientConfig:
        service:
          namespace: replaceme # Patched by post-install webhook

То есть оператор время от времени должен реплейсить неймспейс внутри CRD с replaceme на реальный dapr-system.
А он не реплейсит. Хорошо, меняю сам руками, смотрю результат.

kubectl edit crd subscriptions.dapr.io
customresourcedefinition.apiextensions.k8s.io/subscriptions.dapr.io edited

kubectl get crd subscriptions.dapr.io -o yaml | grep namespace
          namespace: dapr-system

Радуюсь, иду в логи - а там снова ошибка.
Непонятно. Возвращаюсь обратно а там

kubectl get crd subscriptions.dapr.io -o yaml | grep namespace
          namespace: replaceme

Да камон.

#kubernetes #azure #aks #troubleshooting #argo #dapr #api

Часть 2 из 2.

Думаю ну может я дурак, Меняю снова, уже не иду в логи, А проверяю на месте.
И картина там такая:

kubectl edit crd subscriptions.dapr.io
customresourcedefinition.apiextensions.k8s.io/subscriptions.dapr.io edited

kubectl get crd subscriptions.dapr.io -o yaml | grep namespace
          namespace: dapr-system

kubectl get crd subscriptions.dapr.io -o yaml | grep namespace
          namespace: replaceme

Бррр, как такое возможно.
Иду в гугл, нейронку, мне говорят "а ты посмотри - кто последний то меняет объект?".
Смотрю

kubectl get crd subscriptions.dapr.io -o jsonpath='{.metadata.managedFields[*].manager}' | tr ' ' '\n' | sort | uniq -c
      1 argocd-controller
      1 kube-apiserver
      1 kubectl-edit
      1 operator

Пффф, а арго то тут причем?
Снова меняю, снова смотрю - да, арго меняет обратно неймспейс на дефолт.
Иду в репозиторий арго, но там просто

---
name: dapr
namespace: dapr-system
repoURL: https://dapr.github.io/helm-charts/
targetRevision: 1.14.2
chart: dapr

Ну и applicationset есть.
А больше мы ничего не меняем.
Снова документация, гугл.
Оказалось вот что:
- арго выкачивает ВЕСЬ чарт, внутри есть директория CRD и там внутри дефолт(путь к чарту был выше, внутри есть CRD директория с манифестами).

Промежуточное описание проблемы:
каждый N период времени оператор DAPR меняет namespace в CRD, тут же сам applicationset DAPR переходит в OutOfSync, арго начинает резко синкать, подтягивает весь чарт, видит, что поменялся CRD и меняет на дефолт. И так по кругу. Насилие ради насилия.

Я и коллега начали фиксить это несколькими вариантами через applicationset, типа

---
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
...
  template:
...
    spec:
...
      ignoreDifferences:
...
        - group: apiextensions.k8s.io
          kind: CustomResourceDefinition
          name: subscriptions.dapr.io
          jqPathExpressions:
            - .spec.conversion.webhook.clientConfig.service.namespace

Затем снова руками меняю неймспейс, смотрю - ура.
Неймспейс больше не ревратится, в аудит логе АПИ ошибки(этой) больше нет.
Да, арго больше не меняет.

Нагрузку снизили на ... на 4%. Мало, но уже что-то.
Выключаю аудит лог(он оооооооооочень дорогой), закрываю одну из саб-тасок касательно АПИ.

Ещё раз описание ишшуи:
- задеплоили арго аппликейшнсет через сторонний чарт с DAPR
- арго создаёт все сущности через хелмп темплейт (даже те, о которых мы в явном виде не знали)
- затем вебхук от оператора дапр переписывает CRD
- арго при синке видит дифф по CRD и переписывыает его снова
- и так по кругу
Пока не глянешь в кишки и не добавишь в игнор - насилие над апи кубера, так как весь функционал арго и дапра - через кубер апи.

Итог:
- я научился смотреть в логи аудита по Azure AKS API
- сгорел от дурости DAPR оператора и ArgoCD оператора в попытках переписать друг за другом CRD
- узнал про игноры в арго (вообще есть и иные решения для проблемы, но игнор самый простой)
- снизил нагрузку на 4% лишь с одним фиксом

Впереди ещё несколько подходов к апи, есть десятки других ошибок, буду с каждой разбираться отдельно.
Это оказалось интересно.

#пятница #байки #troubleshooting

Задолго до работы в айти я был простым советским инженером спутниковой связи.
Тарелки, антенны, модемы, кабели, бесконечные командировки. В то время случалось масса странных историй.

Мы разрабатывали спутниковое оборудование - модем.
Ну, типа коробочка: в один конец втыкается ethernet, в другой - кабель для спутниковой антенны. Если объяснять совсем упрощённо.

Однажды поступил сигнал, что в одном месте, куда мы поставляли железо, периодически перестаёт работать связь. Там уже меняли всё: и внешнее оборудование (LNB, передатчик), и кабели, и внутреннее - модемы и блоки питания. Не помогало.
Основная гипотеза была: враги, конкуренты или радиолюбители мешают на спутнике.
Короче, время от времени канал тупил.
Худшая гипотеза - наше оборудование овно, а это тревожный звонок для бизнеса.

Сначала я пытался разобраться удалённо.
Соорудил наспех snmp-monitoring-схему, даже просил людей записывать на бумажке время, когда "глючит". Получилось, что срывы происходят утром, днём и вечером - плюс-минус в одно и то же время.
Но удалённо разобраться не вышло.
А это клиенты, так что надо было срочно решать проблему.
В итоге меня отправили в командировку на три дня.

Меня поселили в гостинице рядом, но на саму территорию связи просто так не пускали.
Утром провели внутрь для диагностики.
Я весь день таскался со своим измерительным оборудованием (два ящика, кстати!), слонялся туда‑сюда, выглядел, наверное, как идиот-“следящий”. Но одного дня мне хватило.

К концу первого дня я понял, в чём дело.
За стеной пункта связи оказалось другое помещение - кухня.
Там сотрудники по утрам грели еду, потому что дома не успевали.
Включали самую паршивую китайскую микроволновку, которая фонит во всех, бл… диапазонах - даже в L band!
Излучение пробивало стену и било прямо по стойке с оборудованием.
Влиял не только наш модем, но и соседнее железо, просто про это никто даже не догадывался.
Днём они грели обед, вечером - кофе.

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

Я добавил, что если все они не хотят получить рак через полгода, то пусть заменят это дерьмо на нормальное оборудование.
Народ так перепугался, что рванул на кухню и выкинул микроволновку ещё до того, как я закончил проверку и вышел из кабинета.

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

#aws #eks #kubernetes #bottlerocket #troubleshooting

Case:
AWS EKS, Bottlerocket AMI. Случайно уронили коллектор логов, сбора не было несколько часов, но логи нужны прям сейчас. Если коллектор починить, то ждать долго(кстати какого фига долго я хз).
Нужных логов в поде нет, в ArgoCD их тоже нет(логично же).
Как быть?

Можно слить с EKS node(s), но этот путь не очевидный, ведь у нас Bottlerocket.

Для начала нужно быть уверен, что вы включали админ доступ в TOML конфиге.*

# Доступ к системным логам, получению root-оболочки (sheltie), запуску journalctl, logdog и пр.
[settings.host-containers.admin]
enabled = true

# Доступ к Bottlerocket API для настроек и диагностики, но без глубокого доступа к логам и файловой системе ноды.
[settings.host-containers.control]
enabled = true

Ок, админ доступ включён.
Смотрим на какой ноде запущен наш под.

kubectl get pods -o wide | grep podname
...  ip-10-1-114-226.ec2.internal ...

Узнаем айди инстанса.

kubectl get node -o yaml ip-10-1-114-226.ec2.internal | grep -A4 -i "nodeid"
... "i-09cd72826bee50209" ...

Подключаемся к инстансу через SSM

aws ssm start-session --target i-09cd72826bee50209

Сейчас нет никаких прав, переходим в админа.

enter-admin-container

Ок, мы стали админами(через контейнер), теперь нам нужен шелл - шелти.

[root@admin]# sudo sheltie

Дальше просто смотрим в /var/log/

ls /var/log/containers/
argo-cd-argocd-application-controller-0_argo-cd_application-controller-dfb4d12f601e71ac373b30bfaad8d02b56141218e7bcc5f1358f3a7d8f7df7f7.log
...

Ну и смотрим логи

cat argo-cd-argocd-application-controller-0_argo-cd_application-controller-dfb4d12f601e71ac373b30bfaad8d02b56141218e7bcc5f1358f3a7d8f7df7f7.log

"но Алекс, нам нужны все логи, как их слить к себе локально?"
Ок, запускаем сборку логов в шелти

bash-5.1# logdog

После коллекции у нас логи хранятся на ноде в

logs are at: /var/log/support/bottlerocket-logs.tar.gz

Теперь со своей локальной машины дёргаем их к себе через k8s API (да-да, я тоже не знал)

kubectl get --raw "/api/v1/nodes/ip-10-1-114-226.ec2.internal/proxy/logs/support/bottlerocket-logs.tar.gz" > ./bottlerocket-logs.tar.gz

У нас локально теперь все логи в bottlerocket-logs.tar.gz
Задача решена.**


* Если изначально админ доступ не включён, то всё не ок. По идее если его включаешь в момент задачи, то ноды пересоздаются и старые логи с нод исчезают в пучине небытия и бездны. Тогда уж лучше ждать окончания работы починенного коллектора логов.

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

#troubleshooting #aws #ssh #retool #paranoia #linux

Ок, что же говорит ошибка. Текст типа

Test connection failed (120.327s):(SSH) Channel open failure: open failed
{query: "Connect Request", error: Object}
query: "Connect Request"
error: Object
message: "(SSH) Channel open failure: open failed"
data: Object
reason: 1
name: "Error"
message: "(SSH) Channel open failure: open failed"

и дальше огромная простыня трейса.
А ничего она не говорит, и так понятно, ясно понятно, нет подключения.
Прохожу снова по инструкции - всё ок.
Проверяю не менялся ли паблик ключ? Не менялся.
Не менялся ли пул публичных адресов? Не менялся.
Блин, ну я же не дурак.
Добавляю руками свой IP на секьюрити группу, подключаюсь на бастион хост и оттуда делаю телнет и подключение через cli к PostgreSQL.
Сетевая связность есть, коннект.
Проверяю ещё раз все секьюрити группы, поиск по коммитам, всё отлично.
Так, стоп, а предыдущие то ресурсы работают?
Захожу в retool, в давно созданные ресурсы - тест проходит ок.

Чешу репу, гуглю решения, закидываю в 3 нейронки - решения нет.
Общие предположения, да и только.
В общем в траблшутинге и логах я просидел долго.
Чтобы не было стыдно, не буду говорить сколько, но много.

В итоге я просто начал смотреть все журналы, все конфиги и даже трейсы, мне было очень интересно.
Очевидно же, что у меня что-то не так, иначе бы ранее добавленные ресурсы не работали.

Спустя время дошёл до конца файла /etc/ssh/sshd_config перебирая по одному все включённые параметры, а там.... а там парам-пам-пам!
А там паранойя, ну прям рили паранойя.

# bastion host 1.2.3.4

cat /etc/ssh/sshd_config |grep -v "^#"
...
Match User retool
  PermitTTY no
  AllowTcpForwarding yes
  PermitOpen mysql.amazonaws.com:3306 docdb.amazonaws.com:27017
  ForceCommand /bin/echo "Shell disabled!"

Я даже сам забыл про эту паранойю!

В общем добавляю очевидное

...
PermitOpen mysql.amazonaws.com:3306 docdb.amazonaws.com:27017 postgresql.amazonaws.com:5432
...

Перезапускаю

sudo systemctl restart ssh

и Voilà! - коннект от retool есть.

Описываюсь ребятам, они подтверждают, закрываю задачу.

Какая же мораль? Как обычно:
- не думай, что остальные глупее тебя, если пишут ошибка есть - значит она есть!
- вспоминай о своих параноидальных привычках, прежде, чем тратить время
- держи конфиг sshd в IaC (ansible например), а не руками заполняй, баран. Поиском по iac я быстро увидел бы причину

* адреса endpoints к БД само собой должны быть полными и длинными, короткие URL лишь для примера

#troubleshooting #billing #CostOptimization #newrelic

Внезапно вырос ценник на newrelic.
Заметили не сразу, не было настроены алерты по биллингу.
Увидели лишь в начале месяца, при выставлении счёта.

Я не сильно тогда был знаком с newrelic, этой штукой обычно пользовались коллеги-разработчики, я больше по инфре и стеку с VM/Prometheus/Grafana, но деньги есть деньги, надо разбираться.

Поковырявшись в интерфейсе и немного документации, обнаружил, что деньги начали списываться в раздел логирования.
А ведь это странно, все логи у нас пишутся в ELK стек в самом кубе, зачем ещё и в newrelic писать, а там за каждый чих деньги просят.

Первым делом смотрю в ньюрелике кто именно пишет логи - ага, одно единственное приложение.
Иду в git, захожу в раздел PR, вижу там миллиард PR, закрываю, ибо даже с поиском ничего не найти.
Клонирую репозиторий, смотрю локально.
Ага, у нас агент newrelic ставится через Dockerfile

ENV NEWRELIC_VERSION 11.6.0.19
...
ADD https://download.newrelic.com/php_agent/archive/${NEWRELIC_VERSION}/newrelic-php5-${NEWRELIC_VERSION}-linux.tar.gz /tmp/
RUN export NR_INSTALL_USE_CP_NOT_LN=1 NR_INSTALL_SILENT=1 \
    && tar -xf /tmp/newrelic-php5-${NEWRELIC_VERSION}-linux.tar.gz -C /tmp \
    && /tmp/newrelic-php5-*/newrelic-install install \
    && rm -rf /tmp/*
...

Дальше ковыряюсь в конфигах самого приложения, но там ничего интересного.
Нет в явном виде "логирование енаблед тру" или подобного. Странно.
Ладно, ну поехали, смотрим через git кто когда вносил изменения в докерфайлэ, всё равно другой зацепки нет.

git log Dockerfile

И буквально через несколько коммитов вижу зацепку - коллега разработчик обновил версию newrelic.
Само собой нашёл и его PR и того, кто его аппрувил.
Но была обновлена только версия, больше ничего не менялось.
Херня какая.

Ладно, иду в POD, смотрю конфиг, а что внутри

cat /usr/local/etc/php/conf.d/newrelic.ini

и поиском вижу там нечто типа

newrelic.application_logging.enabled = true

Пилю себе ветку, в этой ветке делаю даунгрейд до старой версии newrelic, собираю имадж, смотрю в нём конфиг

newrelic.application_logging.enabled = false

Да бл.

Бегу в документацию и нахожу
https://docs.newrelic.com/docs/apm/agents/php-agent/configuration/php-agent-configuration/

PHP agent version 10.1.0 lets you forward your PHP logs with APM logs in context. As of version 10.3.0, the logging metrics and agent log forwarding features are enabled by default. The value newrelic.application_logging.enabled controls whether or not the logs in context feature is active or inactive.

От суки, ладно, пилю быстрофикс (не удивлюсь, если он до сих пор там в докерфайле, лол).

RUN sed "s/^.*;newrelic.application_logging.enabled.*/newrelic.application_logging.enabled = false/" \
    -i /usr/local/etc/php/conf.d/newrelic.ini

Качу PR, аппрув, мерж, логи перестали идти в newrelic, прайс не растёт.

Ну а дальше как обычно: оповещение коллегам, ата-та так не делайте плиз, читайте доки перед апдейтом(да ладно, кому я вру, я бы тоже не читал), вот рут коз, вот фикс, вот ссылки, вот пруфы.
Все виновато покивали и сделали вид, что запомнили и не повторят ошибок. Да.

Потеря денег всего $460 за пару недель.
Идём работать дальше.