Назад | Перейти на главную страницу

Отчеты об инцидентах и ​​регистрация

Я ищу инструмент (или совет), который позволил бы мне отслеживать и регистрировать все инциденты, которые происходят в моей инфраструктуре.

У нас есть несколько серверов (50+), и это число будет увеличиваться в будущем, поэтому я хочу иметь лучший обзор того, что происходит или может пойти не так через месяц или около того, и помочь мне улучшить эти части система или сервис, подверженные сбоям.

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

У нас есть централизованные системы мониторинга (Check_MK, Logstash + Kibana, анализаторы сетевого потока ...) и оповещения на месте, и я могу создавать отчеты о доступности напрямую из Check_MK, но этот отчет неточен, и мы делимся им с нашими клиентами. Мне нужно, чтобы это было для внутреннего пользования.

Я немного исследовал и не нашел много - нет настоящего стандарта для этого или инструмента, поэтому мне нужен совет от кого-то, кто уже занимается этим, какой инструмент использовать или, если нет инструмента (мы в значительной степени способны разработать его самостоятельно) что лучше всего, когда дело доходит до регистрации таких вещей? Что вы регистрируете?

Для этого мы используем нашу систему тикетов (atlassian jira):

  • мы создали проект «Операционные инциденты» с получателями (наблюдателями), применяемыми на уровне проекта
  • и новый тип задачи «инцидент», где все эти элементы имеют свои собственные поля формы.

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

Плюсы:

  • каждая заинтересованная сторона вовлечена (или, по крайней мере, проинформирована) с самого начала
  • у службы поддержки есть центральный пункт поиска информации, когда клиенты жалуются
  • тикет-система позволяет вести журнал работы и обсуждать
  • у нас есть архив для использования в будущем
  • мы можем использовать встроенные функции отчетов jira, чтобы получать отчеты по ключевым показателям эффективности как «время восстановления», например

Старый ответ был не по теме из-за недопонимания. Сохраняя его для справки:

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

Например:

  • logstash (который вы уже знаете)
  • Graylog
  • Прометей

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

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

Сбор / мониторинг / агрегирование:

  • Доступность систем (оборудования, ПО, сервисов)
  • Ошибки во время работы этих систем (журналы, правильные ответы)
  • Изменения с течением времени (показатели системных параметров, то есть дисковое пространство и нагрузка, время отклика сервисов, развертывание новых версий)

Затем нужно будет определить уровни для оповещения:

  • Хост / Служба вверх / вниз
  • Процесс запущен
  • Загрузить через x.xx, x.xx, x.xx
  • Место на диске под x.xx
  • Скорость увеличения объема данных более xxx МБ / день
  • HTTP 500 ответов> раз в секунду
  • и т.д