OneAgent log analytics now supports the Docker logging framework, making it possible to access all Docker container log data related to specific applications (i.e., process groups). Log files for processes that write to standard input/output errors and that run in containers that use the default Docker json-logging driver are also available for analysis in the Dynatrace Log viewer. Docker container logs can now be downloaded from the Log files tab on related Process pages. Container image names and IDs, as well as output types, are available with each log entry. All Log Analytics functionality—including searching, grouping, bookmarking, and event detection—is now fully supported within Docker environments.
Improved reporting of technologies used by monitored .NET processes.
ASP.NET Core services now report application IDs and context roots.
Queue support for IBM MQSeries.
Support for OpenResty Nginx builds.
Fixed handling of OneAgent requests (Dynatrace Managed only).
OneAgent for iOS and Android
Dynatrace OneAgent for iOS and Android release 6.5.5 introduces some changes to Gradle and CocoaPods support…. – Read the whole story.
With the introduction of OneAgent version 107 it’s now possible to access Docker container log files related to specific applications (i.e., process groups).
Different approaches to gathering log data
The Application Performance Management market has matured over the past few years. There are now a number of intelligent, automated approaches available for managing application lifecycle. Still, most applications continue to rely on logging as a foundation for diagnostics and tracing. While this may not be bad practice, it does create some challenges. For example, writing logs in dynamic, microservices-based environments involves the problem of diagnostics data persistence. Physical disks often aren’t available, containers are volatile, and saving logs as local disk files isn’t an option because such files disappear when the containers they reside in are shut down…. – Read the whole story.
Processes crash for a multitude of reasons and it’s often difficult to understand the root causes that contribute to such crashes. This is why Dynatrace is proud to announce the availability of crash analysis for processes.
As before, when a monitored process crashes, you’ll see a Process crash entry in the Events section of each affected Process and Host page. The example process below has some availability problems (shown in red on the timeline). By selecting the affected timeframe in the timeline, the Events section shows you the number of process crashes that occurred during that timeframe (3 crashes in this example). This functionality isn’t new. What’s new is the Process crash details button…. – Read the whole story.
Following the release of version 108, here are the latest enhancements that we’ve introduced to the Dynatrace Managed deployment option.
New Security Gateway page
To enable you to see the resource usage and availability of your public Security Gateways, we’ve overhauled the Security Gateway page. The page now provides a chart that shows you the resource consumption of your Security Gateways. We’ve also added an indicator that shows you when your Security Gateways were offline…. – Read the whole story.
Ensuring the worldwide availability of your web application is key to your business success. This is why we’ve made it possible to now check your application’s accessibility to the IP addresses that Dynatrace uses to deliver availability web checks…. – Read the whole story.
You can now configure Dynatrace to proactively alert you if any process within a specific process group goes offline or crashes. Dynatrace has also long been able to recognize the unavailability of specific processes as the root cause of certain response-time issues and other problems. However, until now, active availability monitoring and alerting was only available at the application level—made possible via web checks and real user monitoring…. – Read the whole story.
A long awaited Dynatrace feature—the ability to view the history of detected problems in your environment within custom time frames—is finally here!
To date, the Problems feed and the Problems dashboard tile have provided a rolling 72-hour history of open/closed problems in your environment. We selected 72 hours as the default time frame because this gives DevOps teams adequate time to analyze detected problems, even when they occur on weekends. As always, quick response to detected problems is considered best practice. However, there are instances when custom time frame analysis of detected problems can be valuable…. – Read the whole story.
The new problem comments feed enables your team members to collect team knowledge, discuss AI-detected root causes of detected problems, and evaluate appropriate remediation actions related to problems detected by Dynatrace.
AI-driven team collaboration
The term “ChatOps” suggests team collaboration and conversation-driven problem analysis that ultimately leads to effective remedial actions. As today’s web-application environments are often huge, service clusters are dynamic, and immediate response time is critical to maintaining customer satisfaction, AI-supported problem- and root-cause analysis is the next logical and necessary step in improving upon traditional application-performance monitoring tools. Nevertheless, team collaboration and communication remain essential to successful implementation of AI-supported problem- and root-cause analysis…. – Read the whole story.
Dynatrace has long provided monitoring visibility into Nginx modules via the response time hotspots listing on each Nginx service page. Now you can access this hotspot data within the global CPU profiler where it is now correlated with Nginx CPU-consumption metrics…. – Read the whole story.
Copyright 2016 Dynatrace LLC