I was reading an article today that discusses managing “mission-critical” applications. I really dislike that term. It’s trite, it’s dated – even nonsensical. It suggests that applications fall into two groups – mission-critical, and…optional? marginal? unnecessary? one step away from being voted off the island?
Here’s the fallacy with that view – people that run IT organizations are smart, and they invest in stuff that matters to the business. They don’t run apps that don’t provide value because they excel at cost-efficiency. So the notion that relatively few apps are actually worth managing is illogical. Even email, the poster child for apps at the bottom of the food chain, is essential to the operation of a 21st century organization – it’s how they stay organized.
Which is why it is surprising to note that, according to industry analysts, the majority of enterprises manage fewer than 25% of their apps. I acknowledge that not all apps are created equal – some have relatively greater value than others. But surely no one would argue that the next most important 10% to 20% of apps don’t merit being managed.
So – why invest in something because it’s important to your business, but stop short of the incremental investment needed to ensure it works well? It seems irrational. Would a trucking company not monitor the oil level in their trucks, or a grocer the temperature of their freezers? At some point intervention will be required, and when not addressed on a timely basis, small problems can become big, costly ones, and business operations can be seriously disrupted.
Sure, these are not perfect metaphors, but I think my point is obvious, and obviously valid. Generally, when assets are important to the successful operation of the business, organizations invest to ensure that they keep operating effectively.
Unless they are software applications. So while people that run IT are smart, in this respect their behavior seems irrational. Attitudes towards management have always seemed a bit wonky to me. Rather than seen as additive to app value, application management has been viewed as unwanted overhead, even deleterious. Put another way, stuff that would make apps go well has often been viewed as detracting from simply making them go.
But is the lack of APM investment irrational? On balance, service delivery is pretty darned good most of the time for most apps, or at least “good enough.” Naturally, problems occur in modern, complex IT environments. So organizations invest in management technology to minimize risk and impact for the most important apps, and handle everything else as well as humanly possible. That is the status quo that seems to work reasonably well, except when it doesn’t, sometimes with serious business impact. And, in those cases, you wrestle the problem to the ground, ask “What are the chances of THAT happening again!”, and return to the status quo until it happens again.
I believe nearly all IT professionals would say that problems are inevitable, including serious business-impacting ones. So I am back to thinking that this doesn’t make good sense. Why would you not make the incremental investment in APM (for more than 25% of your apps) to reduce the incidence and impact of these inevitable events?
I can think of a few potential reasons. It may be difficult to quantify the business risk as input to a cost-justification. It may be difficult to prioritize what applications to invest in, which impedes setting technical criteria for a solution. There may be a diverse set of stakeholders with competing priorities. Any of these challenges makes it difficult to pick a strategy and move forward with it.
But in my view, none of these is a good enough reason to settle for the current status quo. There’s a bigger picture here. Those inevitable problems are affecting your business every day. Investments in apps aren’t moving in the right direction with regard to your company’s strategic customer experience focus and commitment to digital transformation. Apps are important – managing them cannot be viewed as optional.
Dynatrace has redefined monitoring to establish a new status quo way better than “good enough” for way more than 25% of your apps, regardless of their technology, and for all your stakeholders. And that makes very good sense.
The post The myth of “mission-critical”: Irrational thinking in modern IT management appeared first on Dynatrace blog – monitoring redefined.
To read more, visit our blog at www.sonatype.org/nexus.
We’re happy to announce the beta release of Dynatrace PHP-FPM monitoring! Dynatrace PHP-FPM monitoring provides information about connections, slow requests, and processes. Now you’ll know immediately if your PHP-FPM is underperforming. And when problems occur, it’s easy to see which hosts are affected.
To view PHP-FPM monitoring insights
- Click Technologies in the navigation menu.
- Click the PHP tile.
- To view cluster metrics, expand the Details section of the PHP-FPM process group.
- Click the Process group details button.
- On the Process group details page, select the Technology-specific metrics tab.
- Select a relevant time interval from the Time frame selector in the top menu bar.
- Select a metric type from the metric drop list beneath the timeline to compare the values of all nodes in a sortable table view.
- To access node-specific metrics, select a node from the Process list at the bottom of the page.
- Click the PHP-FPM tab. Here you’ll find the number of Accepted connections (connections accepted by the pool), and the Slow requests count. Please note that the Accepted connections measure is sometimes misunderstood to represent the number of requests. This metric measures exactly what its name suggests—the number of accepted connections.
More PHP-FPM monitoring metrics are available on individual Process pages. Select the Further details tab to view these metrics.
Here you’ll find additional PHP-FPM charts for Requests, Input buffering, and Processes.
When the number of total active processes reaches the Total processes limit, new scripts are prevented from running until the problematic processes have completed. The maximum number of Waiting connections defines the maximum number of connections that will be queued. Once this limit is reached, subsequent connections are refused or ignored.PHP-FPM metrics Metric Description Accepted connections The number of connections accepted by the pool Slow requests The number of requests that have exceeded the request_slowlog_timeout value Waiting connections The number of requests in the queue of pending connections Max number of waiting connections The size of the pending connections socket queue Active processes The number of active processes Total processes The number of idle + active processes Prerequisites
- Linux OS or Windows
- PHP version 5.5.9+
- PHP-FPM Status Page must be enabled on all nodes you want to monitor.
With PHP-FPM monitoring enabled globally, Dynatrace automatically collects PHP-FPM metrics whenever a new host running PHP-FPM is detected in your environment.
To monitor more than one pool, type the URIs of the individual PHP-FPM status pages (separated by spaces) into the Status page URI field. All PHP-FPM instances must have a correct status page URI reference.
- Go to Settings > Monitoring > Monitored technologies.
- Set the PHP-FPM switch to On.
- Click the ^ button to expand the details of the PHP-FPM integration.
- Define a status page URI(s).
- Click Save.
Dynatrace provides the option of enabling PHP-FPM monitoring for specific hosts rather than globally.
- If global PHP-FPM monitoring is currently enabled, disable it by going to Settings > Monitoring > Monitored technologies and setting the PHP-FPM switch to Off.
- Select Hosts in the navigation menu.
- Select the host you want to configure.
- Click Edit.
- Set the PHP-FPM switch to On.
Your feedback about Dynatrace PHP-FPM monitoring is most welcome! Let us know what you think of the new PHP-FPM plugin by adding a comment below. Or post your questions and feedback to Dynatrace Answers.
The Dynatrace API can now be used to seamlessly integrate the process-group attributes that are discovered by Dynatrace OneAgent—for example, technology overview and topology details—into your existing reporting and operations processes. Process-group properties returned by the API can be leveraged in numerous ways depending on the needs of your DevOps teams.Leverage technology overview information
The Dynatrace Technology overview presents all of the process-group technology-related information that is detected by Dynatrace OneAgent in your environment. Process group instances are grouped into technology-specific tiles (see image below).
To access the Technology overview, click Technologies in the navigation menu. All of this information can now be fetched automatically and utilized within your existing tools and processes!
While your organization can utilize technology-overview data in any particular way that supports your existing workflows, one use-case to consider is the automatic retrieval of topology information for configuration management efforts. for example, real-time topological relationships and dependencies between the components in your environment can be retrieved automatically and used to populate an ITIL CMDB database.
Or, your DevOps teams might create scripts that automatically check and fetch the log files of all available process groups.
To query process-group information with the Dynatrace API, simply call an HTTP GET request on the following Dynatrace endpoint:
For Dynatrace Managed installations, process-group information can be retrieved using a slightly modified REST endpoint:
The resulting JSON payloads list all of the monitored process groups in your environment, as shown below:
To get started writing your own scripts and leveraging the new Dynatrace API process-group endpoint, please have a look at the Dynatrace API documentation.
The post Automatically fetch & leverage process-group attributes via Dynatrace API appeared first on Dynatrace blog – monitoring redefined.