Size: a a a

Архитектура ИТ-решений

2019 December 25

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
ещё немного звучит как попытка втянуть оргструктурные проблемы в технику )
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Alexey Pryanishnikov
ещё немного звучит как попытка втянуть оргструктурные проблемы в технику )
Не проблемы, а особенности. Типа одмины головных предприятий могут в филиалах что-то там чинить по заявке.
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
ну или по возникновению тревоги.
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
распределённое вычисление состояний тревоги нужно затем,чтоб регистрировать отказы вовремя на местах при отсутствии инфраструктурной связи.
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
типа, простые проблемы регионы сами починят, а сложные уже пусть следующий уровень разбирается?
Ну да, инциденты пулять в разные роли. Или алертить в разные списки получателей
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Alexey Pryanishnikov
типа, простые проблемы регионы сами починят, а сложные уже пусть следующий уровень разбирается?
Ну да, инциденты пулять в разные роли. Или алертить в разные списки получателей
Это всё понятно)) Меня интересует технически как поддержать это при условии, что ещё каналы связи слабые и ненадёжные.
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Я вот думал за репликацию заббиксовых баз и цепочку из серверов. Но из коробки такого нету.
источник

AP

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

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Alexander Luchkov
Это всё понятно)) Меня интересует технически как поддержать это при условии, что ещё каналы связи слабые и ненадёжные.
Нужна гарантированная доставка - стримить события в Kafka, разбирать на выходе и создавать инциденты в Help Desk
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Gennadiy Kruglov
Нужна гарантированная доставка - стримить события в Kafka, разбирать на выходе и создавать инциденты в Help Desk
У меня на мнемосхеме филиального админа должно высветиться "алярм", даже если центральный сервер недоступен.
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
ага, а мониторить упадения самой кафки будем другой кафкой)
Не, я за хардкор, мониторинг должен быть низкоуровневый, тем более в таких условиях
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Хотя как стримить, если каналов нет)) только опрос возможен
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Alexey Pryanishnikov
я бы логи собирал с удалённых систем. При возможности. При невозможности - поднимать аларм, что инфа старая
Это уже есть. Сислог поднят и работает)
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Я ж говорю, нужно распределённое вычисление алярмов с популяцией конфигурации)
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Вот тут товварищ @dreamore  про федеративное управление в прометее поминал.
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Alexander Luchkov
У меня на мнемосхеме филиального админа должно высветиться "алярм", даже если центральный сервер недоступен.
А, я понял. А если просто к одному источнику подключить несколько разных инстансов мониторинга? Один региональный, другой головной
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Alexey Pryanishnikov
А, я понял. А если просто к одному источнику подключить несколько разных инстансов мониторинга? Один региональный, другой головной
Сложно конфигурации распространять. Хотелось бы избежать. Но да, такой вариант рассматриваем.
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
так ли нужна честная федерация? не синхронизируется - и хрен бы с ним, всё равно мониторинг актуален минуты, потому это уже историческая статистика работы системы)
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Alexey Pryanishnikov
так ли нужна честная федерация? не синхронизируется - и хрен бы с ним, всё равно мониторинг актуален минуты, потому это уже историческая статистика работы системы)
У меня актуальность в часах.
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Т.е. 2 часа разрыва связи - в принципе ОК, если местные в курсе.
источник