Вопросы Теги

Incident reporting and logging

I am looking into tool (or advice) that would allow me to track and log all incidents that happen on my infrastructure.

We have a few servers (50+) and that number is going to increase in the future, so I want to have a better overview of things that are going or could go wrong in one month or so and to help me improve those parts of the system or service that are prone to failures.

For example - if a web server has failed on some instance or the backup has not finished because there was no space available on a backup server or there was a DDoS attack, I would like to note that (when, why, where, how did we fixed it and so on).

We have central monitoring systems (Check_MK, Logstash + Kibana, network flow analyzers...) and alerting in place and I can generate availability reporting directly from Check_MK, but that report is not accurate and we share it with our customers. I need this to be for our internal use.

I have researched a little bit and have not found a lot - there is no real standard for this or a tool, so I need an advice from someone who is already dealing with this what tool to use or, if there is no tool (we are pretty much capable of developing one by ourself) what is the best practice when it comes to logging things like this? What do you log?

3
задан 14 October 2016 в 11:58
2 ответа

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

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

    Плюсы:

    • Каждая заинтересованная сторона вовлечена (или, по крайней мере, проинформирована) с самого начала
    • служба поддержки клиентов имеет центральный пункт для поиска информации при жалобах клиентов
    • билетная система позволяет вести журнал работы и обсуждения
    • у нас есть архив для будущих обращений
    • мы можем использовать встроенные функции отчетности jira, чтобы иметь отчеты по KPI как "время на восстановление", например
0
ответ дан 3 December 2019 в 08:01

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

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

Например:

  • logstash (который вы уже знаете)
  • graylog
  • Prometheus

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

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

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

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

  • Host/Service Up/Down
  • Process Running
  • Load over x.xx,x.xx,x. xx
  • Дисковое пространство под x.xx
  • Скорость роста данных больше x.xx MB/day
  • http 500 ответов > x/second
  • etc
0
ответ дан 3 December 2019 в 08:01

Теги

Похожие вопросы