Комментарии 4
Так и не понял почему это формально вынесено за рамки планирования мощностей, хотя является его задачами (мониторинг, взаимодействие между отделами, диагностика).
Вариант с мониторингом трафика интересный, но почему не использовать логи приложений?
Вариант с мониторингом трафика интересный, но почему не использовать логи приложений?
Добрый день.
Спасибо за вопрос.
Согласен, утверждение про Capacity management можно назвать спорным. Однако, мы здесь опять сталкиваемся с неопределённостью в определении что есть «оптимальная (или допустимая) производительность». Насколько медленно должно работать приложение, чтобы бизнес счёл его недоступным? Предоставляя средства оперативного мониторинга производительности мы можем определить эти границы в свих метриках и далее использовать их том числе и для Availability management.
В своей работе мне приходится сталкиваться с ситуациями, когда команды поддержки устраняют (ну или думают что устраняют) проблемы с производительностью своих приложений при помощи хаотического увеличения мощностей инфраструктуры. Это, как правило, не даёт желаемого результата или приводит лишь к временному облегчению. APA анализ помогает обнаружить наиболее оптимальные и дешёвые средства устранения проблем: изменение настроек приложения или его кода, оптимизация инфраструктуры. Многие рекомендации APA можно лишь с большой натяжкой отнести к области capacity management.
Конечно же, мы анализируем и логи, но в нашей практике они, как правило, не сильно помогают. Логи хороши, если что-то совсем не работает. Подавляющее большинство производителей приложений не предоставляют достаточное логирование проблем с производительностью. Могу также сказать, что если проблема может хоть как-то идентифицироваться в логах – ко мне не приходят, однако, без работы я не сижу.
Спасибо за вопрос.
Согласен, утверждение про Capacity management можно назвать спорным. Однако, мы здесь опять сталкиваемся с неопределённостью в определении что есть «оптимальная (или допустимая) производительность». Насколько медленно должно работать приложение, чтобы бизнес счёл его недоступным? Предоставляя средства оперативного мониторинга производительности мы можем определить эти границы в свих метриках и далее использовать их том числе и для Availability management.
В своей работе мне приходится сталкиваться с ситуациями, когда команды поддержки устраняют (ну или думают что устраняют) проблемы с производительностью своих приложений при помощи хаотического увеличения мощностей инфраструктуры. Это, как правило, не даёт желаемого результата или приводит лишь к временному облегчению. APA анализ помогает обнаружить наиболее оптимальные и дешёвые средства устранения проблем: изменение настроек приложения или его кода, оптимизация инфраструктуры. Многие рекомендации APA можно лишь с большой натяжкой отнести к области capacity management.
Конечно же, мы анализируем и логи, но в нашей практике они, как правило, не сильно помогают. Логи хороши, если что-то совсем не работает. Подавляющее большинство производителей приложений не предоставляют достаточное логирование проблем с производительностью. Могу также сказать, что если проблема может хоть как-то идентифицироваться в логах – ко мне не приходят, однако, без работы я не сижу.
Спасибо за статью, очень интересный организационный подход. Можете еще поделится информацией о используемых Вами продуктах мониторинга.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Анализ производительности приложений как отдельное направление в IT