Каковы требования для медицинской системы контроля приложения?
Поскольку Silverlight не поддерживает параметр MidpointRounding, вы должны написать свой собственный. Что-то вроде:
public double RoundCorrect(double d, int decimals)
{
double multiplier = Math.Pow(10, decimals);
if (d < 0)
multiplier *= -1;
return Math.Floor((d * multiplier) + 0.5) / multiplier;
}
Для примеров, в том числе о том, как использовать это как расширение, см. Сообщение: Окно .NET и Silverlight
9 ответов
- Работает ли приложение.
- Необычный CPU/память/использование сети.
- Сообщите о любых необработанных исключениях.
- Состояние различных модулей (если применимо).
- Состояние внешних компонентов (базы данных, веб-сервисы, файловые серверы, и т.д.)
- Количество незаконченных фоновых задач (если применимо).
- Возможно, отследите использование статистики приложения и отчета по больше всего/меньше используемым техническим возможностям, таким образом, Вы знаете, где оптимизация является самой выгодной.
Ответ, 'он зависит'. Почему необходимо контролировать? Насколько большой Ваш операционный штат? Вам нужно создание отчетов? Какова среда приложения? Кто заботится, перестало ли приложение работать? Кто заботится, происходит ли исключение? Действительно ли какая-либо из ошибок является восстанавливаемой? Я мог задать вопросы как они в течение долгого времени.
Это - такой открытый законченный вопрос, но я запустил бы с физических измерений.
1. Все машины, я думаю, размещают этот дающий отклик на ping-запрос сайт?
2. Все машины, которые должны служить содержанию, на самом деле служащему некоторому содержанию? (Идеально это было бы поражено от внешней сети.)
3. Каждый - ожидаемый сервис на каждое выполнение машины?
3a. Те услуги недавно работали?
4. Каждая машина имеет пространство на жестком диске в запасе? (Не забывайте дб),
5. Эти машины были сохранены? Когда был прошлый раз?
После того как каждый размечает физический контроль систем, можно обратиться к характерным для системы?
1. Автоматизированный сценарий может войти в систему? Сколько времени это брало?
2. Сколько пользователей живо? Был миллион поддельных добавленных учетных записей?
...
Эти виды вопросов становятся более туманными, и могут быть очень конкретной системой. Они также обычно могут получаться реактивным образом при ответе на phsyical измерения. Жесткий диск заполняется, возможно, журналы веб-сервера были заполнены, потому что набор агентов создал слишком много поддельных пользователей. Такая вещь.
В то время как план A не должен обязательно быть реактивным, это - путь много установок сайта система контроля.
Минимум: удостоверьтесь, что это работает :)
Однако некоторый другой материал был бы очень полезен. Например, загрузка ЦП, Использование оперативной памяти и (в многопользовательских системах), какой пользователь работает что. Кроме того, для приложений, что сеть доступа, список сетевых соединений для каждого приложения. И (если бы у Вас есть доступ к клиентскому компьютеру (компьютерам)) было бы здорово смочь видеть, что 'заголовок окна' приложения - возможно, проверяет каждые 2-3 минуты, изменился ли он, и сохраните его. Кроме того, список файлов, открытых приложением, мог быть очень полезным, но это не необходимость.
Я думаю, что это довольно просто - монитор так, чтобы Вас можно было предупредить достаточно рано, прежде чем что-то пойдет не так, как надо. Это означает зависимости от монитора и само приложение.
Действительно трудно обеспечить специфические особенности, если бы Вы не собираетесь сообщать подробности относительно приложения, Вы контролируете, таким образом, я сказал бы что использование это как правило.
Как минимум Вы хотите знать, что система здорова. Это субъективно в том, что определяет Вашу систему, здорово. Это - компьютеры, произошли, необходимые ресурсы существуют, данные текут через систему, данные правильно приводят к результатам, и т.д., и т.д.
В моем проекте мы делаем контроль большей части из этого и затем некоторых. Это действительно сводится к тому, что является высшим уровнем, который можно использовать для анализа этого, все работает. В нашем случае мы должны знать вниз к выводу данных. Если просто необходимо знать вниз к этих машин, он сохраняет Вас при попытке показать неопытного конечного пользователя что не так.
Существуют также "с полки" инструменты, которые сделают большую тяжелую работу для Вас, если Вы просто слишком трудно изучите результаты данных. Мне особенно понравился Nagios, когда я озирался, но нам были нужны больше, чем он мог легко показать, таким образом, я записал нашу собственную систему контроля. В основном мы также наблюдаем за "особенностями" в системе, память / пики нагрузки ЦП, и т.д...
спасибо все для входа, я действительно искал контроль прикладного уровня не контроль инфраструктуры, но хорошо знать об обоих
различие:
- контроль инфраструктуры был бы серверами плюс MS Exchange Server, Apache, IIS, и т.д
- мониторинг приложений был бы пользовательскими машинами и определенными программами, которые они используют, чтобы делать их работы и/или серверы плюс data-moving/backend приложения, которые они запускают для хранения течения данных
иногда трудно разграничить - упрощенное определение могло бы быть, "если бы Ваша команда записала это, это - приложение; при покупке его это - инфраструктура"
я думаю, на практике лучше контролировать обоих
Что вам нужно сделать, так это разбить бизнес-процесс приложения на части, а затем заставить программное обеспечение испускать события в основных бизнес-компонентах. Кроме того, вам нужно будет создать сквозные синтетические транзакции (например, эмулировать переход конечного пользователя на веб-сайт). Все эти данные будут поступать в инструмент мониторинга. В прошлом я использовал JMX для приложений, которые поступали в JMX-адаптер Tivoli Monitoring, а затем я создавал сценарии, реализующие "поддельного пользователя", и передавал результаты в адаптер сценариев Tivoli Monitoring. Tivoli Monitoring принимает данные и затем создает графики состояния и производительности приложений из этих необработанных данных.
Отличный вопрос.
Некоторое время назад мы искали какое-нибудь решение для мониторинга на уровне приложений, но безуспешно. Популярные решения для мониторинга в основном предназначены для мониторинга инфраструктуры и, на мой взгляд, слишком сложны для требований большинства малых и средних компаний.
Нам требовались (в основном) следующие функции:
- оповещения – мы хотели знать о инцидент как можно быстрее
- безболезненное управление - служба хостинга будет лучшие
- визуализации — хорошо знать, что происходит, и извлекать некоторые знания из данных
Поскольку мы не нашли подходящего решения, мы начали писать свое собственное. Наконец, мы закончили работу с готовым сервисом под названием AlertGrid. (Конечно, вы можете проверить это бесплатно.)
Идея заключается в том, чтобы предоставить простой способ обработки пользовательских сценариев мониторинга. API интеграции очень простой (одна функция с двумя обязательными параметрами).На данный момент мы и другие используем его для:
- мониторинга запланированных задач (заданий cron)
- мониторинга выполнения всей логики приложения
- предупреждения об ошибках в приложениях
- мы также работаем над примерами базового мониторинга инфраструктуры используя AlertGrid