operation alerting prt1

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

Мы даже испытваем некоторое волнение, когда получаем репорт об ошибках прода. Примерно как то так.

Ведь не далеко не всегда причина не 200 ответа вашего сервиса связана с вашим приложением. Смежники тоже могут деплоить баги в прод и потом извиниться за то, что зависимость вашего сервиса портит вам метрики.

Как бы вернуть их баги им да еще через ITSM?

На этом моменте мы пристально посмотрели на опенсерч с его братьями близнецами и запаслись терпением.

opensearch

сводка для нетерпеливых

опция	особенность	субъективно
слать в почту	без проблем	прекрасно
слать в slaсk	без проблем	прекрасно
слать в телеграм	красиво нельзя, можно через веб хуки	да и не нужен он нам
накапливать батч за интервал времени	можно. Но нужно бдить что бы логов было не слишком много	прекрасно
группировать алерты по критичности	можно и отдельным атрибутом. И явным перечислением кодов, но используя эльфийский DSL	могли бы и нормальный GUI сделать, но и так сойдет

лирика

Алёртинг можно делать через и плагин Job Scheduler - сразу хуками дергать API жиры.
Вот только жиру так можно положить, нужно накопление за интервал времени, агрегация однотипных эксепшенов/инцидентов, и наконец приоритезация перед заведием задачи на разработку. В общем можно, но ненужно.

А вот связка плагинов Alerting и Notification все это позволяет. Правда эта тема коряво раскрыта в мануалах.

Но если подходить постепенно, то все складно получается.

формализация адресатов

Нужно определить команды L2 и L3 которые будут получать письма счаться. У нас, кстати, это было не фигуральное выражение. ITSM систему разворотили под нужды каждого так, что API по заведению инцидентов было изветно только 1 разрабу этой системы. И работать оно могло неожиданно. Так что все приходили к ним и останавливались на том, что на входящий ящик отпарвляет письмецо, которое парсится и специальным захардкоженным процессом (наверняка на башизмах, как же еще) создается нужный инцидент на нужную группу исходя из регулярки для email subject.

В итоге, в термнах opensearch, у нас нарисовалось 2 типа каналов интеграция smtp и slack. Естественно везде были проблемы с сетевой доступностью от хостов, куда же без продырявливания в iperf.

формализация приоритетов

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

1. Какие алерты чисто статистические. Типа накопить компромат на смежников, что б он зафиксил наконец свой тупой баг. Ну или скриптеры к вам ломятся в авторизацию и вы это видите.
2. Какие алерты высоко приоритетные. Наверняка есть то, над чем все трясутся.
3. Остальное барахло. Может у кого-нибудь из нижестоящих сервисов есть вменяемые коды ошибок. Отично к коду ошибке пририсовать по коду алерта. Может вам выдают какое-нибудь странное собщение к ответу о неуспешности раз в месяц - сюда же его.

Это простое советское медитативное упражнение позволит достроить логическую цепочку: кому отправлять, через какой канал, с каким интервалом накопления.

Мы еще в чудо табличку пытались вкорячить "способ решения", но толку от этого было 0, там в 99% было наисано на усмотрения L2 смежников.
А если писали для себя (L3), то... Это уже был не инцидент, а история на разрабтоку. Надежда оставлась на нашу L2, но они решили не отмечаться в нашей конфле, постестялись наверное.
Куда больше пользы было от 2х других полей: интерпритация ситуация и текст сообщения.
Бывало так, что переписывали тексты по нескольку раз, что бы это был полноценный сторителлинг: кто что пытался сделать с каким объектом и какой эксепшен словил. Смежникам зашло.

выбор монитора

Если открывали первые ссылки, то заметили что там есть несколько доступных типов для использования. У нас подход был минималистичный: должен быть не разрозненный список лог-документов, а 1 информативный лог-документ. Под документами подразувается https://opensearch.org/docs/latest/getting-started/intro/#document
По этому нам улыбнулись типы per document и per query. Возможно, у вас какая то особая инфраструктура системы логгирования и вам попробовать остальные типы. Но мы остановились на per query.

В простых случаях (читай на мелких сервисах) хватит визивиг мордочки что бы агрегировать документы, из которых делать алерты.
Прямо берешь, упражняешься в discover режиме и повторяешь все те же фильтры в режиме создания монитора. Лепота.
А что за фильтры то?

подкостылить в приложении

Смотри, команда разработки делает вменько в log.message (который поедет в MDC) и добавляет в MDC кастом атрибут alert_code с нужным кодом . Если не пропустили упражнение с табличкой, то коды уже формализованы и в коллектор опенсерча уезжает документ вида

{
  "_index": "appname-log-2024.08.07",
  "_id": "c3-JLZEBGYL_3my02s04",
  "_score": 1,
  "_source": {
    "stream": "stdout",
    "logtag": "F",
    "kubernetes": {
      "pod_name": "b2c-info-659cbb559-dkrj8",
      "namespace_name": "super-services",
      "pod_id": "23940aa1-be8f-4623-b185-c339da6a0276",
      "labels": {
        "app": "appname-app",
        "app-kubernetes-io/component": "unknown",
        "app-kubernetes-io/instance": "appname",
        "app-kubernetes-io/managed-by": "Helm",
        "app-kubernetes-io/name": "appname",
        "app-kubernetes-io/part-of": "unknown",
        "app-kubernetes-io/version": "1-0-50",
        "chart": "chart-1.0.49",
        "cluster": "k8s-platform-prod",
        "date": "2024-07-29T083328Z",
        "deploy_type": "basic",
        "env": "production",
      }
    },
    "@timestamp": "2024-08-07T15:50:17.134083434Z",
    "level": "WARN",
    "level_value": 30000,
    "x-trace-id": "ca23e22c58c14055a6b9bec65d1446cd",
    "x-span-id": "d8f4255533e4eb5e",
    "alert_code": "appname-13",
    "message": "appname can not update order with PK=blablabla and number=123456, root cause: смежникапп: апп-011: апп-011 заказ с номером 123456 кем то редактируется я не смог открыть транзакцию"
  },
  "fields": {
    "@timestamp": [
      "2024-08-07T15:50:17.134Z"
    ]
  }
}

Нужно только проиндексировать кастомный атрибут alert_code в на стороне OS и дело в шляпе. Это кстати делается через настройку Index pattern, но спека там как обычно не раскрывает нужные детали. Иди в Dashboards Management → Index patterns → appname → alert_code → edit. Нужно сделать его searchable.
Если ты не можешь, то значит девопсы не отсыпали тебе прав, пришло время жира задачи/заявки на обслуживание.

Если присмотреться к документу, видно что проблема кроется на стороне смежникапп, но инцидент заводить им бессмысленно. Складываем в папку и в конце месяца несем (или накроем) на стол.
Т.е. если в дисковер режиме (в проде конечно же!) можно найти логи с запросом alert_code:appname-13 то так же можно подсунуть и в монитор. Кстати контринтуитивно, но без ковычек надо, там DQL так задуман.

Но, есть важный аспект: как часто собирать подобные документы?
В этом примере - можно и раз в день, если там не больше 10к документов. Луче - меньше что б за интервал времени собиралось 500-2к.

Звучит просто? Да. Есть недосказанность? Кончено. Еще ж надо собирать пачку что бы не ITSM не загнулась. А еще есть предельные случаи. Но продолжим по порядку.

каналы отправки

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

Если почта - то на стадии редактирования Notifications → Email senders → yourapp нужно заполнить вашу заранее подготовленную email учетку с кредами.

А потом в Notifications → <канал пинания от вас до смежника> → выбрать Sender type= SMTP sender, а в SMTP sender - тот самую учетку.
Если чего то не видно: заявка, девопсы, права доступа или что б саи заполнили.

В случае mattermost нужно немного по присядать. Сначала создать канал, потом не ошибиться и не использовать его публичную ссылку для инвайтов (обычно отображается в url браузера), а в администрировании канала отковырять ссылку для хуков
вида https://mattermost.company.domain/hooks/blablaololo
Если у вас нет административного интерфейса, то вспомните про злобных админов отбирающих у всех права и включайте зноопс.

А что там с предельными случаями?
Так бывает, что нужно собрать пачку документов за час с разными алерт кодам. Ну что бы среднеприоритетное барахло сунуть в смежника. И мы случайно попали на минное поле.
В discover режиме есть множественный выбор для значений атрибута, а в мониторе такого нет. Можно только 1 выбрать.
Но там есть https://opensearch.org/docs/latest/query-dsl/
Проблема в том, что спека там размашистая, подробно описывает типы, сравнения вот это все. Но нет хаутушки, с чего начнать то.

подсказки по dsl

Начанать стоит с того, что заполнить все остальное, что можно заполнить. А потом в Monitor defining method можно переключить с Visual editor в Extraction query editor. Там будет json простыня, которой таки придется повыжигать глаза.
Там на 3 уровне есть узел filter , который как раз используется для отбора документов.
Если не тупили в визивиг редакторе, то там уже должно быть немного вложенных объектов вида

{
    "match_all": {
        "boost": 1
    }
}, {
    "match_phrase": {
        "kubernetes.labels.app": {
            "query": "appname-app",
            "slop": 0,
            "zero_terms_query": "NONE",
            "boost": 1
        }
    }
}, 
blabla

После него должен быть (если не тупили) узел range который описывает временные интервалы. Между ними можно вставить свои дополнительные предикаты, что бы отбирались документы с определенными алерт кодами appname-13 и appname-14:

{
    "bool": {
        "should": [{
            "match_phrase": {
                "alert_code": {
                    "query": "appname-13",
                    "slop": 0,
                    "zero_terms_query": "NONE",
                    "boost": 1
                }
            }
        }, {
            "match_phrase": {
                "alert_code": {
                    "query": "appname-14",
                    "slop": 0,
                    "zero_terms_query": "NONE",
                    "boost": 1
                }
            }
        }],
        "adjust_pure_negative": true,
        "minimum_should_match": "1",
        "boost": 1
    }
}, 

Ну и там же рядом есть "отладчик": жмешь на run смотришь находится ли какие документы. А потом ниже в триггерах на отпарвку эти же найденные документы можно использовать для превью шаблонов сообщений. Там все интуитивно просто, пропустим.

Есть только 1 очень важная деталь. При переходе из визивиг редактора в DSL, там по какой то причине переопределяется лимит на максимальное количество документов для поиска. На очень маленькое число. На пример в нашей инсталляции, был лимит 0. Его можно заметить здесь

{
    "size": 0,
    "query": {
        "bool": {
            "filter": [
                {
                    "match_all": {
                        "boost": 1
                    }

Это дурацкое поведение кладет на лопатки на пару дней. Мы даже думали может надо какой-нибудь плагин в opensearch обновить, но нет, олени тут не мы.

bonus track

Если у вас в логах красуются персональные данные пользователя или вообще PCI DSS контур, могут начаться поползновения со стороны ИБ.
Что бы скрывать сенситивную информацию в теле документов, можно сделать отдельный индекс (индекс-паттерн) с чуствительными данными и отдельный - без них.

Тут может начаться жжение у инфраструктурщиков, диски то не резиновые.
Так что есть более изящное решение маскировать поля

Но у обоих подходов есть пререквизит в виде разграничения прав доступа.
И тут обычно начинается треш и содомия. При использовании OpenID, они предлагают маппить пользаков и роли руками.
А вот в SAML и AD можно вытягивать роли, но с огромной долей вроятности они ведутся в компании как попало. Как и у всех.
Просто потому что мы живем в таких реалиях, когда не только оргструктура, но еще и функциональные обязанности людей и отделов динамически меняются. Проще выдавать по головам vip доступы на сенситивную информацию.
Так что мы забили на составление километровой эксельки с правами и заехали с "некоторым долгом".

трагедия

Как это часто бывает при трагедии общих ресурсов, смежники могут утилизировать общую подсистему логгирования как не в себя. И даже если вы живете на своем отдельном индексе и конкретно ваши логи на пропадают на час другой, мониторы могут тупить. Прям есть документ в дисковере, есть документ в "отладчике", но он не отправляется.
Первое время девопсы перезапускали fluentD но это не всегда помогало. А потом перестало помогать.
Мы было задумались для создания отдельных бакетов, и per bucket monitor, но судьба распорядилась иначе.