ECK: устанавливаем logstash

 Всем привет!

Устанавливаем логстеш в текущий кластер ELK. 

С помощью ранчера создаем простой конфиг (ConfigMap) для наcтройки логстеша (или можно через kubectl apply -f logstash-config.yaml ):

logstash-config

 Стандартный конфиг, ничего необычного. Отключаем SSL.

 

 Далее создаем модуль для логстеша:

Тоже все довольно просто, главное указать адрес сервера Elastic'a.

apiVersion: v1 kind: Pod metadata: labels: app: logstash name: logstash spec: containers: - image: docker.elastic.co/logstash/logstash:7.9.1 name: logstash ports: - containerPort: 25826 - containerPort: 5044 env: - name: ES_HOSTS value: "http://172.27.64.31:30949/" - name: ES_USER value: "elastic" - name: ES_PASSWORD valueFrom: secretKeyRef: name: quickstart-es-elastic-user key: elastic resources: {} volumeMounts: - name: config-volume mountPath: /usr/share/logstash/config - name: logstash-pipeline-volume mountPath: /usr/share/logstash/pipeline restartPolicy: OnFailure volumes: - name: config-volume configMap: name: logstash-configmap items: - key: logstash.yml path: logstash.yml - name: logstash-pipeline-volume configMap: name: logstash-configmap items: - key: logstash.conf path: logstash.conf - name: cert-ca secret: secretName: elasticsearch-es-http-certs-public status: {}

Теперь нужно прокинуть порты для сервиса или создать NodePort:

apiVersion: v1
kind: Service
metadata:
  labels:
    app: logstash
  name: logstash
spec:
  ports:
  - name: "5044"
    port: 5044
    targetPort: 5044
  selector:
    app: logstash
status:
  loadBalancer: {}

Далее направляем файлбит на логстеш.

ertwert
apiVersion: v1 kind: ConfigMap metadata: name: logstash-configmap data: logstash.yml: | http.host: "0.0.0.0" path.config: /usr/share/logstash/pipeline logstash.conf: | # all input will come from filebeat, no local logs input { beats { port => 5044 ssl => false } } filter { } output { elasticsearch { #index => "logstash-%{[@metadata][beat]}" hosts => [ "${ES_HOSTS}" ] user => "${ES_USER}" password => "${ES_PASSWORD}" #cacert => '/etc/logstash/certificates/ca.crt' } }

Разворачивание Elastic Cloud on Kubernetes

 Привет всем. 

 ЕСК - это сбор, анализ и корреляция журналов, метрик и трассировок из контейнеров, приложений и служб, работающих поверх Docker и Kubernetes, — все это в одном месте.

Установим ЕСК на работающий кластер кубернетеса. В моем примере кубернетес работает под управлением Rancher'a. 

Elastic Cloud on Kubernetes (ECK) построен на шаблоне оператора Kubernetes.
Оператор ECK расширяет базовые возможности оркестрации Kubernetes для поддержки, настройки и управления Elasticsearch, Kibana и APM-сервером.

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

Для установки оператора необходим работающий кластер Kubernetes с поддержкой RBAC и наличие командной утилиты kubectl, подключенной к кластеру.
Установка:
kubectl apply -f https://download.elastic.co/downloads/eck/1.2.1/all-in-one.yaml

Elasticsearch

С помощью kubectl выполним команду
cat <<EOF | kubectl apply -f -
apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
  name: quickstart
spec:
  version: 7.9.1
  nodeSets:
  - name: default
    count: 1
    config:
      node.master: true
      node.data: true
      node.ingest: true
      node.store.allow_mmap: false
EOF

Kibana

cat <<EOF | kubectl apply -f -
apiVersion: kibana.k8s.elastic.co/v1
kind: Kibana
metadata:
  name: quickstart
spec:
  version: 7.9.1
  count: 1
  elasticsearchRef:
    name: quickstart
EOF

Для примера созданы 2 модуля, посмотрим их в ранчере.

 

Для доступа из вне к кибане и эластику пробросим порты:

Готово! Можно подключать агенты сбора логов с приложений.

Ошибки во время установки

1. После установки модуля с кибаной появилась такая ошибка:

Readiness probe failed: Get https://10.41.1.44:5601/login: dial tcp : connect: connection refused

Смысл ее в том, что контейнер не успел задеплоиться из-за  HealthCkeck. Поэтому пришлось его отключить через настройки Workload модуля. 

Кубер включает в себя 2 типа проб(probes): liveness checks и readiness checks.

• Liveness Check: Проверяет, работает ли отслеживаемый контейнер. Если проба сообщает о сбое, Kubernetes убивает модуль, а затем перезапускает его в соответствии с политикой перезапуска развертывания (deployment restart policy).
• Readiness Check: Проверяет, готов ли контейнер принимать и обслуживать запросы. Если проба сообщает об отказе, модуль изолируется, пока не "починится".

2. Подключение к Elastic'у не выполняется по указаному порту. В логах такая ошибка:

Unable to revive connection: https://quickstart-es-http.default.svc:9200/

Проверьте протокол, скорей всего настроено на https, а не http

3. Для тестов можно отключить TLS. Требуется обновить конфиг эластика.

cat <<EOF | kubectl apply -f -
apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
  name: quickstart
spec:
  version: 7.9.1
  http:
    tls:
      selfSignedCertificate:
        disabled: true
  nodeSets:
  - name: default
    count: 1
    config:
      node.master: true
      node.data: true
      node.ingest: true
      node.store.allow_mmap: false
EOF

Успехов!

Dynatrace: ошибка захвата атрибутов PHP

Всем привет!
Столкнулся с ошибкой захвата атрибутов при мониторинге PHP-FPM. Созданные Request Attributes не захватывают данные из методов, которые точно вызываются. По идее вызов метода инициирует захват атрибутов с помощью Request Attribute, но этого не происходило. Общение с поддержкой ни к чему не привела.

Из выполненных работ:
1. Перезапуск PHP-FPM
2. Отключение - включение OpCache
3. Перезапуск PHP-CLI
4. Обновление агентов OneAgent до последней версии
5. Создание custom service

После очередного перезапуска PHP я заметил, что Dynatrace неверно определяет путь к файлу с классом. Плюс путь очень длинный, что не помещается в строку. Решил изменить путь и пересоздать Request Attributes. Не помогло.
Тогда создал отдельный Custom Service с указанием пути к классу, по которому класс точно располагался на этом хосте. И после этого атрибуты стали захватываться.
Dynatrace неверно определял путь с классом и методом, поэтому атрибуты не захватывались!

Успехов!

Dynatrace: воспроизведение сеанса пользователя

Session Replay используется для захвата и визуального воспроизведения полного цикла действий пользователя. Данный подход позволяет записывать каждый клик, касание и свайп пользователя. Вы можете записать все взаимодействия пользователя с веб приложением и воспроизводить в виде фильма. Данный анализ позволяет выявить проблемы в последовательностях действий, увидеть баги в форматировании страниц, плюс подумать как можно все улучшить.

Детализация ошибок
С помощью Session Replay можно более подробно детализировать обнаруженные ошибки:

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

К этим сеансам применяется стандартный срок хранения данных - 35 дней.

Удобство использования
Воспроизведение сеанса также может быть использовано для обнаружения и анализа следующих проблем:

• Дизайн UX недостаточно интуитивно понятен
• Процесс слишком сложен, и пользователи, как правило, оставляют ваше приложение на полпути
• Приложение работает медленно, и пользователь нажимает несколько раз, чтобы перейти к следующему экрану
• Приложение работает не так, как ожидалось, во всех браузерах
• Мобильные веб-приложения предлагают пользователю изменить ориентацию телефона, но пользователь не понимает этого запроса

Для включения User Sessions Replay необходимо:

• DEM Unit Licanse
• Агенты версии 157 или выше
• ASP.NET только
• Дополнительное хранилище под сессии

Все настройки расположены в настройках отдельных приложений Application Settings -> Session Replay.
Включаем.

В некоторых случая можно подключить дополнительные шрифты.
Записываются от 25 до 50% сессий. Это по умолчанию, если вы не изменили лицензию.
Opt-in-Mode и Form filed masking используется для сокрытия приватных данных.

Dynatrace: Openshift мониторинг

Red Hat OpenShift - это платформа следующего поколения, основанная на Kubernetes, для разработки, развертывания и запуска контейнерных приложений. Агент Dynatrace OneAgent работает как с контейнерами, так и имеет встроенную поддержку для внешнего мониторинга OpenShift, а именно обеспечивает мониторинг полного стека OpenShift, мониторинг от уровня приложения до уровня инфраструктуры. В случае, если у вас нет доступа к инфраструктурному уровню, Dynatrace также предоставляет возможность мониторинга только для приложений.

OpenShift мониторинг полного стека

1. Среды OpenShift, которые позволяют запускать привилегированные контейнеры на нодах
2. Готовый, автоматизированный кластер и мониторинг рабочей нагрузки
3. Один раз настроив получаешь мониторинг всего с помощью агента Dynatrace OneAgent 
4. Агент Dynatrace OneAgent автоматически добавляет свою кодовую базу в контейнеры для мониторинга полного стека
5. Деплой производится через нативные средства Kubernetes, такие как один OneAgent -оператор или набор демонов(DaemonSet)

OpenShift мониторинг только приложений

• Для заблокированных сред OpenShift без доступа к нодам
• Мониторинг рабочей нагрузки на основе каждого образа Docker, без видимости кластерных нод
• Модули кода агента Dynatrace OneAgent интегрированы с каждым образом Docker
• Деплой производится в рамках обычных рабочих нагрузок OpenShift

Поскольку Kubernetes может запускать любые контейнеры и позволяет выполнять горизонтальное масштабирование подов, фактическое использование ресурсов кластера будет очень изменчивым. Именно поэтому Dynatrace предлагает единую панель для наиболее важных метрик использования и производительности на уровне кластера. Эти показатели таковы:

- Фактическое использование процессора/памяти узлами кластера (мин, макс, медиана)

- Общее количество запросов процессора / памяти контейнеров, запущенных на узлах кластера (мин, макс, медиана)

- Общее количество ограничений процессора / памяти контейнеров, работающих на узлах кластера (Min, Max, Median)—ограничения могут быть превышены, в том числе и более чем на 100%.

- Доступные ресурсы процессора/памяти для запуска дополнительных подов / или других рабочих нагрузок на узлах кластера (Min, Max, Median)

- Общее количество ЦП, которое может быть выделено для модулей (но все равно часть ЦП обычно зарезервирована системой)

- Максимальная память, которая может быть выделена для модулей

Вы можете получить детальное представление о метриках узлов Kubernetes на уровне каждого узла, чтобы понять, как используются отдельные узлы. Страница анализа узлов также содержит информацию о том, сколько рабочей нагрузки все еще может быть развернуто на узлах (ЦП, память).

Отображение рабочей нагрузки отдельного узла

Dynatrace: приватность данных

Dynatrace соблюдает требования GDPR о конфиденциальности пользовательских данных.
Настройки приватности данных Preferences-> Data Privacy and Security
1. The Mask end-user IP addresses & GPS coordinates
Включен по умолчанию. Применяется для мониторинга реальных пользователей(Real User Monitoring) и для мониторинга серверных служб(server-side monitoring). Если этот параметр включен, IP-адреса конечных пользователей маскируются в момент обнаружения из веб-приложений, мобильных приложений, пользовательских приложений и серверных служб.
Вы можете выбрать, следует ли маскировать все или только общедоступные IP-адреса.
С другой стороны вы можете задать параметры конфиденциальности отдельно для приложения. Выбираете приложение, нажимаете редактировать и проваливаетесь в настройки.

User Tracking позволяет вам контролировать использование постоянных файлов cookie для обнаружения и отслеживания пользователей, которые ранее обращались к вашему приложению. Если этот параметр отключен, то Dynatrace не сможет обрабатывать метрики, т.к. не сможет отделить анонимные сессии от пользовательских.

Data collection and cookie Opt-In mode
Когда включено внедряемый код JavaScript для мониторинга реальных пользователей (Real User Monitoring) не будет захватывать данные или устанавливать куки. Однако вы можете управлять сбором данных для отдельных пользователей, с помощью JavaScript API вызываете метод dtrum.enable, который реализует настройку opt-in, позволяя вашим пользователям соблюдать конфиденциальность данных их региона.

'Do Not Track' end-user browser settingsБольшинство современных веб-браузеров имеют функцию конфиденциальности под названием "Не отслеживать"(браузеры добавляют дополнительный HTTP-хедер ко всем веб-запросам, отключая отслеживание пользователей.), которую отдельные пользователи могут включить на своих устройствах. Когда включено, Dynatrace будет отслеживать таких пользователей в рамках анонимной сессии. 

2. Mask personal data in URIs
Dynatrace захватывает полные URI запросов. Dynatrace может также захватывать полные URI и на стороне сервера, чтобы обеспечить детальный анализ производительности вашего приложения. Uri могут содержать персональные данные, например имена пользователей. Если этот параметр включен, Dynatrace автоматически определяет UUID, номера кредитных карт, адреса электронной почты, IP- адреса и другие идентификаторы и заменяет эти значения определенным плайсхолдером(placeholder).

3. Mask user actions(web app only)
Dynatrace маскирует действия пользователя, такие как перезагрузка страницы, запуск ява-агента и других скриптов.

Dynatrace: process group

Группа процессов(Process group)-это логический кластер процессов, запущенных на отдельных хостах, принадлежащих к одной группе процессов. Process group являются основными структурными элементами большинства современных приложений.
В больших динамических средах количество процессов, запущенных на ваших хостах, может быть огромным. По этой причине Dynatrace отслеживает только те типы группы процессов, которые считается важными(и которые вы определяете сами). К ним относятся процессы, которые являются хорошо известными приложениями, такими как Java и .NET, базы данных и веб-серверы, или которые работают на определенном порту.
Группы процессов остаются относительно постоянными даже при появлении новых версий или отката к старым. Они обеспечивают необходимую непрерывность, которая позволяет осуществлять постоянный мониторинг вашего окружения.

OneAgent автоматически отслеживает группы процессов, обнаруженные в вашей среде. Однако, вы можете создать исключения из правил. Если автоматический мониторинг отключен, вы можете назначить правила для конкретных процессов, подлежащих мониторингу. Например, включение функции игнорировать версии, сборки, даты и идентификаторы GUID в именах каталогов процессов не позволяет каждой новой версии приложения считаться вновь обнаруженным процессом. Это может полезно, если номер версии автоматически добавляется к имени каталога во время развертывания.

В разделе Processes на странице хоста показаны наиболее важные процессы, запущенные на этом хосте, разделенные на группы процессов.
Что бы посмотреть все процессы -> All process.

Список процессов содержит основные сведения о системных и сетевых ресурсах:

• ЦП (Процент потребляемый процессом)
• Память(Процентная доля системной памяти, потребляемая процессом)
• Трафик(Сетевой трафик)
• Ретрансляция
• Подключения(процент успешно установленных сеансов TCP, за вычетом суммы отказов и тайм- аутов подключения)

Помимо простого вычисления типов процессов в среде, Dynatrace понимает технологии, лежащие в основе этих процессов. Например, Dynatrace понимает, когда процесс Java состоит из Tomcat или Jetty, хотя во многих случаях он даже знает версии этих технологий.

Чтобы просмотреть свойства технологии, лежащие в основе процесса:

В меню навигации выберите хост, на котором выполняется интересующий вас процесс.

В разделе Processes на главной странице выберите интересующий вас процесс.

На странице процесс разверните панель свойств в верхней части страницы.

Свойство Type указывает основную технологию, лежащую в основе процесса. 

Dynatrace автоматически определяет процессы и группы процессов, запущенные на ваших хостах. Основные группы основаны на базовых технологиях, таких как Apache Tomcat, IIS, Java и NodeJS. Процессы, выполняющие одну и ту же функцию на одном или нескольких хостах, представлены в группах(Process group).

Вы также может управлять группами процессов: создать, задавать и изменять параметры.

Settings ->  Processes and Containers -> Process Group Detection 

Dynatrace: permissions

Система управления разрешениями Dynatrace позволяет легко управлять разрешениями для групп. Разрешения предоставляются на основе групп. Вы можете назначить группе заранее определенный набор разрешений. Добавленные пользователи затем наследуют разрешения назначенных им групп.
Dynatrace предоставляет 2 типа пользователей:

• Account users - управляют другими пользователями и контактной информацией. 

• Environment users - мониторят доступность хостов, служб и других инфрастуруктурных компонентов. 

По умолчанию, Dynatrace предоставляет 5 Environment  групп:

1. Monitoring admin - имеет полный доступ.
2. Deployment admin - может качать и устанавливать агента мониторинга(OneAgent).
3. Confidential data admin - может просматривать личные данные, такие как аргументы метода и настраивать правила мониторинга("захват данных"). 
4. Monitoring viewer - имеет доступ read-only.
5. Log viewer - имеет доступ только в лог файлы.

Что касается групп с учетными разрешениями(account permissions): 

1. Account manager - имеет полный доступ к учетным записям для просмотра и редактирования данных компании, ввода данных кредитных карт, просмотра накладных, создание и редактирование групп, а также добавление пользователей в группы.
2. Finance admin - может вводить данные кредитных карт организации и просматривать счета-фактуры, плюс права от Account Viewer. 
3. Account Viewer - имеет только доступ к потребляемым данным(environment consumption data), Help'у и Support'у. 

Dynatrace: Purepath

Всем привет. 

PurePath помогает найти иголку в стоге сена. Первый шаг в вашем анализе должен состоять в том, чтобы найти те запросы, которые вы хотите проанализировать на детальном уровне. Фильтры могут быть использованы для сужения многих тысяч запросов до тех немногих запросов, которые имеют отношение к вашему анализу. 

C помощью Serfice Flow определяем маршрут прохождения запроса, читай реквеста. 

В качестве примера возьмем какую-то ошибку. Далее посмотрим на него с помощью purepath.

Раздел summary показывает основную информацию о хосте, IP, процесс, выполненный запрос и др. атрибуты. Раздел с таймингом показывает все затраченное время. Code level & Errors служат для определения вызовов ну уровне кода (или других запросов) и отображения ошибок.
Механизм причинно-следственной связи Dynatrace, ИИ Davis, опирается на высокое качество и точность данных. Основным источником данных являются захваченные PurePaths. Чтобы проанализировать собранные данные Davis должен быть уверен, что качество данных соответствует определенному уровню, а это означает, что все службы, методы, тайминги, свойства были захвачены и переданы("отмониторины") правильно.
В случае, если некоторые данные записываются неправильно или теряются Dynatrace помечает пораженный PurePath диагностическим сообщением. Сообщение объясняет возможные причины и гарантирует, что Davis знает, на какие части информации он может положиться. Диагностическое сообщение показывает возможные причины ошибок.

Purepath не показывается для неопределенных служб.

Изменчивые или волатильные (Volatile services) сервисы направлены на предотвращение создания слишком большого количества сервисов. Изменчивая служба создается, когда очевидно, что слишком много отдельных служб будет обнаружено на основе информации о вызове. Примеры волатильных сервисов включают в себя:

• База данных, которая вызывается через множество различных строк подключения. Каждое соединение фиксируется как отдельная служба.
• Служба, которая вызывается через динамическую настройку портов. Вызов каждого порта записывается как отдельная служба.

Фильтры

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

 Меню анализа(drill-down menu), реализовано на основе таблиц, раскрывают все возможные варианты детализации и анализа.

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

Dynatrace также предлагает возможность обнаружения кластеризованных служб. Кластеризованные службы - это службы, которые обслуживаются с помощью нескольких процессов. Dynatrace позволяет анализировать распределение нагрузки, распределение времени отклика и частоту отказов каждого отдельного экземпляра службы. И еще - кластер не значит распределитель нагрузки(load balancer), поэтому нагрузка на разных сервисах может быть разная.

Dynatrace: service flow

Dynatrace отслеживает транзакции приложений от начала и до конца. Эта транзакционная последовательность визуализируется через поток обслуживания(service flow), который наглядно иллюстрирует последовательность вызовов служб, инициируемых каждым запросом на обслуживание в вашей среде.

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

Первая метрика показывает процент запросов, инициированных исходной службой и связанных с вызовом целевой службы, в примере - Booking service. Вторая метрика показывает среднее количество вызовов целевой службы, которые были включены в каждый запрос.

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

В приведенном выше примере потока обслуживания они помечены следующим образом:

1-среднее время отклика службы(Average response time service)
2-общий вызов (Call share)
3-вызов по запросу (Call per request)
4-среднее время отклика в целом(Average response time overall)

Небольшой пример для службы:
Среднее время отклика =288 МС
Процент вызовов= 36%
Количество вызовов на запрос = 3,5

Вклад времени отклика = (среднее время отклика) x (процент вызовов) x (вызовы на запрос)
Вклад времени отклика = 288 x .36 х 3,5
В этом случае вклад времени отклика =363 МС

С правой стороны экрана находится -> Side pane.
На вкладке проходящие транзакции(Passing transactions) отображается пропускная способность сервиса и его производительность—время отклика, количество запросов и др.
Вкладка инфраструктура(Infrastructure) показывает на каких хостах расположен и как распределяется пропускная способность между ними. Нажмите кнопку отфильтровать —будут показаны только вызовы, исходящие от выбранного хоста.

Dynatrace: атрибуты службы

Каждая служба содержит список наиболее важных показателей, которые расположены на  отдельных инфографиках. Каждая инфографика показывает вам, какие приложения или службы используют эту службу(или объединенную службу) и выполняет ли она какие-либо вызовы к другим службам или базам данных.
Откройте Transactions and services -> выберите любую службу.

Каждая область инфографики сервиса служит ссылкой, по которой вы можете щелкнуть, чтобы просмотреть подробную информацию, например, дополнительные диаграммы или особенности взаимодействия. Например, чтобы получить доступ к подробным диаграммам времени отклика(Response time) и частоты отказов во времени для выбранной службы, щелкните области Время отклика, самые медленные 10%(slowest 10%) или частота отказов в инфографике службы. Такие же вызовы касаются и ЦП(CPU), ошибок(Failure rate) и пропускной способности(Throughput).

На диаграммах на каждой странице сервиса есть ползунок" временные рамки анализа"(Analysis timeframe), который помогает анализировать всплески времени отклика. Временной интервал анализа, выбранный с помощью ползунка, отражается на кнопке просмотра времени отклика на определенной диаграмме.

Что посмотреть детально по выбранному временному интервалу(обращения к БД, выполненные запросы) выбираем View Response time hotspots

Нажмите Interaction with services and queues, чтобы посмотреть как происходят взаимодействия с другими службами.

Слева вы видите, как часто анализируемая служба вызывает другие службы и в какой степени эти вызовы влияют на время отклика. На правой стороне эта информация разбита на более подробные части. Можно выбрать и посмотреть детальную информацию по ним, стрелочка влево возвращает на предыдущий экран.
Database usage -> обращения к БД.
Service exetion -> время выполнения запросов.
Длина столбиков представляет собой количество времени, затраченного в каждой конкретной области. Щелкните по любому элементу, отображаемому в виде ссылки, чтобы просмотреть соответствующие горячие точки на уровне модуля или метода.

Посмотреть на горячие точки выполнение метода -> View method hotspots
Проверьте все классы и методы, которые были выполнены во время запуска службы в разделе дерево вызовов. Столбец образы трассировки(Stacktrace samples) стека показывает, сколько раз класс / метод был выполнен для службы в течение выбранного периода времени . Столбец вклад (Contribution)показывает долю потребления, которую класс/метод вносит в общее выполнение. Это позволяет определить, какой класс и / или метод занимает большую часть времени выполнения, и впоследствии оптимизировать код.

Посмотрим теперь по ошибкам(Failure rate), детально за 15 минут по ошибкам

Кнопка Hotspots (горячие точки) на каждой странице сервиса показывает наиболее важные точки(возникновение события) в вашем сервисе. Собирается на основе ИИ. 

Для оценки производительности ваших приложений крайне важно иметь возможность отслеживать время отклика каждого запроса в рамках каждой сквозной транзакции, выполняемой вашими приложениями. Dynatrace предоставляет такую функциональность для отслеживания времени отклика(response time) и анализа резко отличающихся параметров(outlier analysis). Понимая распределение времени отклика по всем запросам, вы можете сосредоточиться на тех запросах, которые имеют самое медленное время отклика. Анализ отличающихся значений времени отклика (те запросы, которые имеют либо необычно высокое, либо необычно низкое время отклика) значительно влияет на общее время отклика транзакций.
Для анализа этих значений кликаем по кнопке Analyze outliners

По данному графику видно. что время отклика высокое и 12% запросов выполнены с ошибками.
Zoom in -> для более детального просмотра. 

Выбираем Analyze backtrace, чтобы посмотреть запросы составляющие общую транзакционную картину данного периода. 

Нашли запросы с ошибками и определили причину их возникновения. 

Посмотрим поток обслуживания(View service flow), точки входа, основные запросы, время выполнения. 

Dynatrace: opaque services

Opaque services - непрозрачные службы, обнаруженные на вызывающей стороне Dynatrace, для которых видимость на уровне кода недоступна. Dynatrace может обнаруживать запросы к непрозрачным службам и определять, какими процессами они обрабатываются, но Dynatrace не может напрямую отслеживать эти службы.

Видимость на уровне кода невозможна, если

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

На следующем рисунке показан пример непрозрачной службы CouchDB-технологии, поддерживаемой Dynatrace, но для которой видимость на уровне кода недоступна. CouchDB-это поддерживаемая технология, но только на уровне метрик и процессов; Dynatrace не предоставляет информацию на уровне кода для CouchDB.

Тем не менее Dynatrace может обнаруживать все запросы к службам CouchDB, отправляемые службами, которые отслеживает Dynatrace. Dynatrace рассчитывает время отклика и частоту отказов и генерирует соответствующие предупреждения. Благодаря искусственному интеллекту Dynatrace понимает, какое влияние могут оказать проблемы службы на  производительность хоста и процесса. Вот почему Dynatrace соотносит проблемы хоста и процесса с соответствующими замедлениями в запросах на обслуживание. Например, если служба CouchDB аварийно завершает работу, Dynatrace интерпретирует этот сбой как основную причину увеличения частоты отказов в вызовах службы CouchDB. Хотя глубокий мониторинг не поддерживается для этой службы, Dynatrace все еще может обнаруживать все запросы к этой службе, отправляемые отслеживаемыми службами, и, например, вычислять соответствующее время отклика и частоту отказов.

Обратите внимание, что непрозрачные сервисы непризнанных или не поддерживаемых технологий все еще включены в Smartscape. Это обеспечивает полное представление топологии вашей инфраструктуры, даже если ваша среда включает непрозрачные сервисы.

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

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

Dynatrace: merged services

Merged service - это служба, которая объединяет несколько служб веб-запросов одной и той же группы процессов, выполняющих идентичные функции на разных узлах кластера. Слияние служб доступно только для служб веб-запросов, выполняющих одну и ту же функцию в рамках одной и той же группы процессов и поэтому фактически идентичных с точки зрения мониторинга производительности. Объединенная служба отображается в Dynatrace как единая служба, содержащая данные всех агрегированных служб.

Чтобы понимать какие из ваших служб подходят для слияния служб, Dynatrace автоматически идентифицирует для вас объединяемые службы и отображает их на странице мониторинга Для этого перейдите Settings > Server-side service monitoring > Merged service monitoring
Только эти службы могут быть объединены.

Примером может служить приложение easyTravel.
Создадим объединенную службу.

После объединения данные отдельных служб больше не могут быть различены—данные мониторинга доступны только в совокупности для всех объединенных служб.

После объединения новые агрегированные данные будут назначены новой объединенной службе и связаны с ней(определяйте имена правильно, чтобы не запутаться). А отдельные компоненты объединенной службы больше не обновляются как источники данных. Хотя исторические данные остаются доступными (например, для построения графиков).

Если вы разделяете службу от Объединенного сервиса (т. е. "размонтируете" сервис или удаляете смердженную службу), исторические данные будут доступны только для объединенного сервиса. Все вновь полученные данные будут связаны с автономной службой.

Объединять можно только службы одного типа. Например, объединяемые службы должны принадлежать к одной и той же группе процессов, совместно использовать одну и ту же базовую технологию и следовать одному и тому же шаблону именования. Несколько виртуальных узлов, корни контекста или порты прослушивания, представляющие одну и ту же логическую сущность, часто являются кандидатами на слияние служб.

Объединенная служба не может быть объединена в другую объединенную службу. Можно объединить только почти идентичные, автономные службы веб-запросов одной и той же группы процессов.

Dynatrace: services

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

Веб и мобильные приложения основаны на службах, которые обрабатывают запросы, такие как веб-запросы, вызовы веб-служб и службы обмена сообщениями. Такие "серверные службы" могут принимать форму веб-служб, веб-контейнеров, запросов баз данных, пользовательских служб и т. д. Службы, в свою очередь, могут вызывать другие службы, такие как веб-службы, удаленные службы и службы баз данных. Поскольку ландшафты служб могут стать довольно сложными, Dynatrace автоматически классифицирует службы на основе их зависимостей от других общностей:

• Точки входа(Entry points): эти службы представляют собой первый контакт транзакции с отслеживаемой серверной службой и являются начальными точками Purepath на стороне сервера. Службы точек входа обычно представляют собой службы поверх отслеживаемого веб-сервера или общедоступного API. Службы могут иметь транзакции точек входа, а также транзакции, исходящие из других отслеживаемых компонентов. 
• Используемые приложениями(Used by applications): эти службы вызываются веб-приложениями, мобильными приложениями или пользовательскими приложениями (т. е. всеми приложениями, которые отслеживаются с помощью реального мониторинга пользователей, RUM). Эти сервисы также являются службами точек входа. 
• Фоновая активность(Background activity): эти службы представляют собой запросы, выполняемые в фоновых потоках.
• Только внутренние(Internal only): эти службы вызываются только другими отслеживаемыми службами. Таким образом, эти службы не ведут себя как точки входа и не имеют никакого прямого отношения к приложениям.
• Внешние зависимости(External dependencies): эти службы представляют собой исходящие вызовы к системам, которые не отслеживаются в текущей среде Dynatrace. Существует два типа внешних зависимостей:

1. Вызовы в общедоступные сети(Calls to public networks): Эти службы представляют собой исходящие вызовы, которые разрешаются на общедоступный IP-адрес и поэтому обычно находятся вне сети вашей компании. Звонок к платежному провайдеру типа paypal.com это пример внешней зависимости.
2. Вызовы к неконтролируемым хостам(Calls to unmonitored hosts): они представляют собой вызовы, которые разрешаются на частный (внутренний) IP-адрес и обычно находятся под ответственностью вашей организации. Поэтому для получения видимости в этих частях вашей среды рекомендуется специальный мониторинг этих зависимостей с помощью OneAgent или с помощью пользовательского мониторинга устройств.

Dynatrace автоматически определяет и называет серверные службы ваших приложений на основе основных свойств развертывания и конфигурации вашего приложения.

Process groups 

Dynatrace автоматически группирует связанные процессы в группы процессов. Когда Dynatrace обнаруживает несколько групп процессов, он предполагает, что эти группы процессов представляют собой отдельные приложения или, по крайней мере, отдельные логические части одного приложения. Таким образом, группы процессов представляют собой границы для содержащихся в них служб.

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

Службы веб запросов (Web request services) обслуживают веб-приложения, которые развертываются либо через веб-сервер (например, Apache или NGINX), либо в веб-контейнерах (например, Java, Node.js, или PHP). Dynatrace рассматривает три дискретных понятия при идентификации и именовании служб: имя веб-сервера, корневой контекст и идентификатор веб-приложения.

Web server name

Существует три различных термина: виртуальный хост, серверный блок и сайт, которые представляют собой сходные понятия в различных технологиях. Виртуальный хостинг доменных имен объединяет веб-запросы от нескольких хостов, доменов и IP-адресов в единую конфигурацию на веб-сервере. Например, Apache HTTP Server позволяет настроить www.dynatrace.com, www.dynatrace.at, и www.dynatrace.us все в пределах одного виртуального хоста. NGINX использует концепцию серверного блока. В случае серверного блока необходимо настроить имя сервера. Сайт-это концепция, созданная в Microsoft IIS. В средах на базе kubernetes веб-серверы Apache и NGINX часто настраиваются только как "localhost" или просто IP-адрес. В этих случаях Dynatrace автоматически использует автоматически определяемое базовое имя модуля в качестве имени веб-сервера, чтобы обеспечить более осмысленное представление из коробки.

Context root

В любом веб контейнере вы можете иметь несколько приложений в нескольких каталогах. Например, /admin приводит к заявке администратора, а /salon - ведет в интернет- магазин. В мире Java это называется контекстным корнем. В IIS - это виртуальный каталог. Большинство веб серверов данного понятия.

Web application ID

Некоторые технологии позволяют давать веб-приложениям явные имена.

• Для сервлетов Java это делается путем определения отображаемого имени в web.xml.
• Для приложений Spring boot вы должны определить следующие параметры: spring.application.name, которые могут быть в заявке.файл свойств или приложение.файл yml.
• Для технологий Java, которые не допускают именования приложений (и обеспечивают именование приложений по умолчанию), можно определить свойство командной строки Java-Ddynatrace.application.id= < name>. это не будет переопределять параметры именования, упомянутые выше.
• Для Node.js вы можете определить имя в пакете.файл json.
• Для других технологий или для предоставления имени по умолчанию можно использовать переменную окружения DT_APPLICATION ID=<name>. 

Посмотреть данные атрибуты можно выбрав Transactions & services из навигационного меню. Далее указываете нужный сервис, и выбираете Properties and tags

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

Database services

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

Queue listener services

Службы прослушивания очередей  показывают какие очереди вы слушаете. Это облегченные службы, которые не имеют времени отклика. Эти службы сообщают вам, сколько сообщений было снято с очереди. Они ничего не говорят вам об обработке сообщений-это делают службы обмена сообщениями. Если Dynatrace автоматически обнаруживает прослушиватель сообщений на основе событий, за службой прослушивания очередей всегда следует служба обмена сообщениями, которая дает вам представление о деталях сообщений. Однако если вы просто отслеживаете очередь, а не изучаете детали сообщения, служба прослушивания очереди может существовать сама по себе.

Messaging services

Службы обмена сообщениями обрабатывают сообщения из очереди. Службе сообщений всегда предшествует служба прослушивания очереди, которая прослушивает очередь, из которой пришло сообщение. Если ваше приложение отключает сообщения в цикле занятости, Dynatrace не может автоматически определить, как эти сообщения обрабатываются. Чтобы получить представление об этом, вы можете создать пользовательскую службу для обработки сообщений.

RMI service (Remote service)

В мире Java удаленный вызов метода (Remote Method Invocation) является распространенным средством связи, используемым ява-машинами (JVM) . Поскольку в одном JVM может быть много динамически создаваемых серверов RMI, Dynatrace создает только одну службу RMI для каждой группы процессов. Это не означает, что вы теряете видимость ваших служб RMI, т.к. Dynatrace отслеживает каждый класс RMI как отдельный тип запроса.

RPC service (Remote service)

Dynatrace отслеживает удаленные вызовы процедур с помощью SDK, Akka и AWS Lambda. В отличие от RMI, Dynatrace создает отдельную службу RPC для каждого эндпоинта(endpoint) службы.

Background activity service 

Во многих случаях службы вызываются потоками, которые выполняются в фоновом режиме вашего приложения или другого приложения. Эти запросы, выполняемые в фоновых потоках, представляют собой фоновую активность отслеживаемых групп процессов, выполняющих вызовы к другим службам. Они также отслеживают исходящие сообщения в очередях.

Например, если у вас есть фоновый поток в Tomcat, который делает веб-запросы к Apache, Dynatrace представляет его как фоновую службу активности Tomcat. Вы сможете увидеть, какие запросы Tomcat делает к вашему Apache, проанализировав время отклика службы фоновой активности Tomcat.

Custom services

Кастомизированные службы позволяют вам управлять приложением, которые не построены на стандартных технологиях. Вы также можете настроить свою систему и использовать определенный метод, класс или интерфейс, который вас интересует. Вы можете создавать пользовательские службы, используя Java, .NET и PHP.

Проблемы обнаружения службы

В некоторых случаях веб-серверы не имеют четко определенных виртуальных узлов, имен серверов или сайтов. Веб-сервер может быть просто назван "localhost". Это может привести к появлению нескольких аналогичных служб, содержащих несколько экземпляров веб-сайта. Чтобы устранить такие проблемы, настройте параметры обнаружения группы процессов.

Если на HTTP-сервере Apache нет виртуального хоста, то имя веб-сервера по умолчанию соответствует имени физического хоста. В облачных средах это приводит к одному виртуальному хосту для каждого физического экземпляра хоста и, следовательно, к одному экземпляру службы. Если облачная среда запускает и останавливает хосты, то эти службы будут временными.

Чтобы исправить такие сценарии localhost, используйте переменную среды для определения имен виртуальных узлов. Просто установите 'DT_LOCALTOVIRTUALHOSTNAME' для каждого процесса веб-сервера в любое значение (например, www.dynatrace.com). Dynatrace будет подбирать имена и использовать их вместо существующих имен виртуальных хостов localhost. При таком подходе вы можете гарантировать, что несколько физических узлов (т. е. "кластер") сообщают об одном и том же виртуальном узле и таким образом получают одну службу с несколькими экземплярами, по одному экземпляру на физический узел.

Некоторые технологии не предоставляют уникальных имен приложений. В этих случаях можно определить переменную окружения с именем DT_APPLICATION ID для предоставления уникального имени. Это влияет только на службы соответствующего процесса, которые еще не имеют идентификаторов приложений. Для приложений Java можно также использовать системное свойство dynatrace.application.id

В случае, если ваша служба динамически менять порт после перезапуска, можно воспользоваться переменной окружения DT_IGNORE DYNAMIC PORT=true. Это удаляет порт из обнаружения и заменяет его на *.

Dynatrace: обнаружение проблем

Проблемы в Dynatrace представляют собой аномалии, то есть отклонения от нормального поведения или состояния. Такими аномалиями могут быть, например, медленный сервис или медленный вход пользователя в приложение. Всякий раз, когда обнаруживается проблема, Dynatrace вызывает конкретное событие проблемы(Event type), указывающее на такую аномалию.

Вновь обнаруженные аномальные события в вашей среде не обязательно приведут к немедленному возникновению новой проблемы. Поднятые проблемы всегда дают представление о лежащей в их основе первопричине. Чтобы выявить коренные причины проблем, Dynatrace следует контекстно-ориентированному подходу для обнаружения взаимозависимых событий во времени, процессах, хостах, службах, приложениях и перспективах вертикального и горизонтального топологического мониторинга. Только с помощью контекстно-ориентированного подхода можно точно определить истинные "корни" причины проблемы.

Dynatrace непрерывно измеряет уровни входящего трафика в соответствии с определенными пороговыми значениями, чтобы определить, когда обнаруженное замедление или увеличение частоты ошибок оправдывает генерацию нового события проблемы. Быстро увеличивающиеся деградации времени отклика(response-time degradations) для приложений и служб оцениваются на основе 5-минутных интервалов времени. Медленно изменяющаяся деградация оценивается на основе 15-минутных интервалов времени.

Dynatrace использует два типа определения пороговых значений:

• Автоматизированные базовые линии(Automated baselines) : Многомерная базовая линия автоматически определяет индивидуальные значения, которые адаптируются с течением времени. Автоматизированные базовые значения используются для управления динамическими изменениями в пределах времени отклика приложения или службы, частоты ошибок и нагрузки.
• Встроенные статические пороги(Built-in static thresholds): Dynatrace использует встроенные статические пороги для всех событий инфраструктуры (например, обнаружение высокой загрузки процессора, уменьшение дискового пространства или малого количества доступной памяти).

Методология, используемая для создания событий с помощью автоматизированной базовой линии, полностью отличается от методологии  используемой для статических пороговых значений. Статические пороговые значения предлагают простой и понятный подход к определению базовых показателей, который работает сразу же, не требуя периода обучения, не учитывая работу Davis'a. Наоборот, методология автоматизированной базовой линии автоматически адаптируется к изменениям в структуре трафика. Dynatrace позволяет регулировать чувствительность обнаружения проблем либо путем адаптации статических пороговых значений, либо путем отклонения от автоматизированных базовых показателей.

Событие в Dynatrace может быть определенного типа. Каждый тип события имеет определенный уровень серьезности, который указывает на значимость инцидента. Результирующие проблемы объединяют все включенные серьезности событий и оцениваются с самым высоким уровнем серьезности составляющих событий. В течение срока действия проблемы уровень ее серьезности может повышаться (например, проблема может начинаться с уровня замедления, а затем автоматически повышаться до уровня доступности при обнаружении сбоя).

Уровни серьезности событий:

1. События доступности(Availability events): указывают на серьезные инциденты в вашей среде, такие как полное отключение или недоступность серверов или процессов. Эти типы событий имеют самый высокий уровень серьезности.
2. События ошибок(Error events): информирование вас об увеличении частоты ошибок или других инцидентах, связанных с ошибками, которые мешают регулярной работе вашей среды.
3. События замедления(Slowdown events): указывают на снижение производительности в одной из ваших операционных служб или приложений. События замедления менее серьезны,чем события первых 2-х уровней. Тем не менее, они информируют вас о потенциальных проблемах с выполнением ваших услуг.
4. События ресурсов(Resource events): указывают на конфликт ресурсов. Типичными примерами являются события повышения уровня утилизации процессора, памяти и др.
5. Настраиваемые оповещения(Custom alerts): используются для включения оповещения о любых заданных пользователем пороговых значениях. Настраиваемые оповещения для определенных пользователем пороговых значений могут быть установлены для любой метрики Dynatrace. Пользовательские оповещения не коррелируются и не изменяются искусственным интеллектом, хотя они автоматически включаются.
6. Информационные события(Info events): события, запускаемые вручную, которые не приводят к созданию новой проблемы. Эти события используются для обозначения важных развертываний или изменений конфигурации, а также административных событий, таких как автоматическая миграция виртуальной машины. Информационные события не рассылаются в виде предупреждений, так как этот тип событий не указывает на ненормальную ситуацию.

Немного о том, как Davis определяет проблему.
Уровень воздействия проблемы определяет, влияет ли ненормальная ситуация на инфраструктуру (INFRASTRUCTURE), программные службы (SERVICE) или приложения(APPLICATION). Четвертый, специальный уровень воздействия (ENVIRONMENT) используется для классификации общей проблемы в среде мониторинга. Эти проблемы используются для сообщения о прерывании вашего мониторинга Dynatrace или ActiveGates.

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

Каждый объект, отображаемый на уровне узла или процесса в Smartscape, классифицируется как инфраструктура. Каждое событие, вызванное этими хостами или процессами, автоматически приводит к событию инфраструктуры и, следовательно, открывает проблему инфраструктурного типа.

Службы, которые отображаются в пределах их собственного уровня в Smartscape, автоматически приводят к событиям уровня обслуживания(service level events). В случае, если служба сообщает о замедлении или ошибке, возникает проблема уровня воздействия службы(service impact level). Веб- , мобильные или пользовательские приложения отображаются на уровне приложения(application level) в Smartscape. Любые проблемы, с которыми сталкивается реальный пользователь, приводят к проблеме уровня воздействия приложения(application impact level).

Предположим, что Dynatrace обнаружила и сообщила о скачке процессора на одном из ваших отслеживаемых хостов. Ни одна служба или любое приложение не затрагивается. В этом случае проблема сообщается на уровне воздействия инфраструктуры. Если скачок ЦП отрицательно влияет на запущенную службу с точки зрения снижения производительности или увеличения числа ошибок, то к открытой проблеме добавляется событие уровня обслуживания. Затем проблема автоматически увеличивает свой уровень воздействия до уровня обслуживания. Обратите внимание, что каждый уровень воздействия не является исключительным. Проблема может затрагивать инфраструктуру, а также объекты уровня обслуживания. Таким образом, одна и та же проблема будет классифицирована как проблема инфраструктуры, так и проблема уровня обслуживания в ленте проблем. Еще один аспект, который следует отметить, заключается в том, что проблема может повлиять на службу, не затрагивая при этом никакой базовой инфраструктуры. В таких случаях проблема классифицируется как проблема только уровня обслуживания. Эта ситуация может возникнуть в бессерверных сценариях, а также в тех случаях, когда на любой базовой инфраструктуре не может быть найдена четкая первопричина.

Dynatrace: full-stack мониторинг

Что такое dynatrace и для чего используется?
FullStack мониторинг АРМ включает в себя 4 основных характеристики, которые выделяют данный продукт:
1. Автоматическое(непрерывное) развертывание и обнаружение новых сервисов.
2. Отслеживание всех действия от реакции пользователя до уровня инфраструктуры
3. Интеллектуальное ядро, обрабатывает огромное количество зависимостей, строит взаимосвязи и анализирует поступающие данные
4. Легко масштабируемая архитектура, ролевое управление

Другими словами. Поддержка полного стэка мониторинга:

1. Уровень приложения
2. Уровень сервисов
3. Уровень процесса
4. Уровень хоста
5. Уровень дата центра

Там где закончился мониторинг классический, начался АРМ. Сложные микросервисные архитектуры, постоянные релизы приложений, привели к тому, что мониторинг перестроился. Мониторинг стал Agile DevOps: объединяя команды разработки и сопровождения, внедряя гибкий подход к работе, мониторинг показывает метрики на каждой стадии работы приложения.

АРМ осуществляет мониторинг производительности приложения начиная от уровня пользователя, продолжая уровнем выполняего процесса и заканчивает уровнем инфрастуктуры, где это приложение выполняется. В случае, когда нет возможности использовать мониторинг полного стэка, АРМ предоставляет возможность использовать инфраструктурный мониторинг.

Официальная документация заявляет ,что Dynatrace - это платформа мониторинга программного обеспечения, которая упрощает использование корпоративных облаков и ускоряет цифровую трансформацию. С помощью Davis (The Dynatrace AI causation engine) и полной автоматизации платформа Dynatrace all-in-one предоставляет весь спектр услуг мониторинга плюс данные о производительности ваших приложений, их базовой инфраструктуре и опыте ваших конечных пользователей, называется "умный мониторинг".

Основные возможности:

• Real User Monitoring. Мониторинг реальных пользователей анализирует производительность всех взаимодействий пользователя с вашими приложениями, независимо от того, происходят ли они в браузере или на мобильном устройстве. Мониторинг реальных пользователей также обеспечивает мониторинг доступности приложений, проверку корректного отображения элементов пользовательского интерфейса, анализ производительности сторонних поставщиков контента, анализ производительности серверных служб (вплоть до уровня кода) и анализ производительности всей базовой инфраструктуры.
• Mobile App Monitoring. Dynatrace также поддерживает мониторинг реальных пользователей мобильных приложений. Процесс мониторинга пользовательского опыта ваших мобильных приложений принципиально отличается от мониторинга браузерных веб-приложений. Это связано с тем, что мониторинг мобильных приложений включает в себя компиляцию, упаковку и отправку библиотеки мониторинга вместе с вашим собственным пакетом мобильных приложений. Dynatrace поддерживает как Android, так и iOS.
• Server-side service monitoring. Веб- приложения состоят из веб- страниц, обслуживаемых веб-серверами и веб- контейнерами. Веб-запросы, отправляемые на определенный сервер, например Tomcat, являются примером серверной службы. Серверные службы могут быть различных типов, таких как веб-службы, веб- контейнеры, запросы баз данных и пользовательские службы. Агент Dynatrace OneAgent может предоставить сведения о том, какие приложения или службы взаимодействуют с какими другими службами и какие службы или базы данных вызывает конкретная служба.
• Network, process & host monitoring. Dynatrace позволяет мониторить всю вашу инфраструктуру: включая хосты, процессы и сеть. Вы можете выполнять мониторинг журналов и просматривать такую информацию, как общий трафик вашей сети, загрузка ЦП ваших хостов, время отклика ваших процессов и др. Dynatrace также предоставляет подробную топологическую информацию, чтобы вы знали, например, какие процессы выполняются на каких хостах и как ваши процессы взаимосвязаны.
• Cloud & virtual machine monitoring. Агент Dynatrace OneAgent контролирует весь стек, включая частные, общедоступные и гибридные облачные среды. Независимо от того, работаете ли вы на AWS, Azure, Cloud Foundry или OpenStack, агент Dynatrace OneAgent автоматически обнаруживает все виртуализированные компоненты и следит за всеми изменениями. Dynatrace OneAgent можно интегрировать с вашей виртуализированной инфраструктурой, что позволит вам связать точки между зависимостями vCenters в вашем центре обработки данных, процессами, которые выполняются на них, и вашими приложениями.
• Container monitoring. Dynatrace легко интегрируется с существующими средами Docker и автоматически отслеживает ваши контейнерные приложения и службы. Dynatrace подключается к контейнерам и устанавливает OneAgent в контейнерные процессы. Нет необходимости изменять образы Docker, изменять команды запуска или создавать дополнительные контейнеры для включения мониторинга в Docker-контейнере. Просто установите агент Dynatrace OneAgent на хосты, обслуживающие контейнерные приложения и службы. Dynatrace автоматически обнаруживает запуск и завершение контейнеров, а также контролирует приложения и службы, выполняющиеся в этих контейнерах.
• Root-cause analysis(анализ первопричин). Ключевой особенностью Dynatrace является Davis, Dynatrace AI-driven causation engine, движок с искусственным интеллектом. Davis полагается на искусственный интеллект, чтобы постоянно отслеживать каждый аспект ваших приложений, служб и инфраструктуры, чтобы автоматически изучать базовые показатели производительности и зависимости всех этих компонентов. Dynatrace также автоматически узнает базовое время отклика и частоту отказов ключевых запросов. Обнаружение проблем и отчетность основаны на этих базовых значениях. Dynatrace определяет, например, когда обнаруженное замедление или увеличение частоты ошибок оправдывает создание нового события проблемы.

Три уникальные технологии позволяют автоматически обнаруживать, моделировать и анализировать каждый компонент и зависимость на всех уровнях приложения:

• Технология OneAgent предоставляет одного агента для сбора и унификации всех операционных и бизнес-показателей всех типов объектов в среде серверов, приложений, служб, баз данных и контейнеров.
• Технология визуализации Smartscape отображает все, что работает в вашей среде, и обнаруживает все причинно-следственные зависимости между веб-сайтами, приложениями, службами, процессами, хостами, сетями и облачной инфраструктурой.
• Запатентованная компанией Dynatrace технология PurePath фиксирует временные интервалы и контекст на уровне кода для транзакций приложений от начала до конца, во всех поддерживаемых технологиях, от облака до мэйнфрейма.