Sunday, May 3, 2015

Monitoring Business Processes dengan PRTG



For most of today's companies a smoothly running IT infrastructure is essential and a critical business requirement. There is hardly any business which does not rely on IT services like email, websites, databases, or online shops within their business process portfolio.
In most cases, the IT infrastructure will be handled by people with a deep technical knowledge, the company's IT support. These people and the management need to communicate proactively all the time to ensure that the infrastructure has no critical issues, fits the business needs, and is suited for the future development of your company. Usually, the management continuously receives reports from the IT department which show recent events in the IT system of the company.
On the one hand, this approach is fine to examine the current overall status and to plan future developments, on the other hand it might be inconvenient for the management to prioritize short-term actions on actual impacts to the overall business process if one of the IT services fails. Moreover, other non-technical staff needs only to know about outages that affect their daily work (for example, if the email system stops working).

Different Devices - One Overall Status

For example, networks in general operate with a substantial margin of safety so that when a small number of devices, providers, or the like fail, it does not cause total system failure. Consider a load balancer that might fan out traffic to five switches with each operating at 60% of its rated capacity. The failure of any one switch would result in each of the remaining four switches going to 75% of its rated capacity. So one device is in an error status but the system as a whole still runs stably-it is important for the system admins to get a notification about the failure, but management or non-technical colleagues of the admin team most probably will not notice this outage of a single switch.

Assuming your company shows its current network status on a dashboard so that everyone can see if there is a system affecting issue, there is no need to show a red status icon to non-admins in this case, alerting of something that is not really of interest for them. Everything still works as expected, for example, emails still come in and go out, so a big green OK icon for the overall system status would be fine while the IT team is investigating the failed switch. A yellow status (consider it as a "warning") helps a lot because everybody can see that the systems might be a bit slower, for example, but the overall functionality is still assured.

Cumulated Real-Time View

With the capabilities of PRTG, your company's IT department is able to provide a cumulated real-time view of all the system components which are needed to ensure a working network, as well as the status of particular processes. In the case of a single failing switch, business processes like emails or online shop orders still work and so an OK status can be shown. For the non-technical staff with a surface point of view, nothing more is important-they do not need to know about any issues of internal system components which do not affect their daily work and won't be interested in the "invisible" failing switch.
But how to sum up the states of several network devices or business process stages into one overall status? And how to set the according status? The solution is included as a feature of PRTG: the Sensor Factory. You just have to add the Sensor Factory sensor to PRTG like a common sensor, provide the desired source channels, and define when it would show an alert. With this powerful tool your IT department has the ability to cumulate a summary status based on the states of "source" sensors or even with individual logical formulas.

Combining Several Business Process Steps Into One Overall Process Status

Assuming you run an online shop. Then the corresponding "business process" might be the whole process from the first visit of your shop's website until the ordered packet is delivered to the customer by your logistics partner. In order to monitor this process appropriately, you have to consider several underlying components.

  • You have to ensure the availability of your shop's webpage, suitable loading times, and a properly working web server.
  • The database of your shop has to be connected, running with an acceptable performance, and it must process requests correctly.
  • Your email server has to be able to deliver and receive emails of (potential) customers.
  • The inventory control system service has to run to ensure that every order is booked correctly. 
  • You may also check the system of your logistics partner and see via their web service how many of your packets are still on their way.

You can monitor all these single points with the according sensors, having an eye on every part of the process. But this will result in potentially dozens of fine-grained sensors. With PRTG's Sensor Factory you can combine them to get only one status for the whole course of related events: Your business process "online shop" is OK-or not.
This is what matters to the management, selling things works without any issues. Non-admins rather won't care if the buffer cache hit ratio value of the database is a little bit low-it's in the admin's interest though to have an eye on those "internal" things: PRTG's solution fits to all these different needs.


You can find a detailed technical description of this sensor type in our manual. Furthermore, we provide a step-by-step tutorial for creating a basic Sensor Factory for the "business process" email in our Knowledge Base. Just adapt this approach to your specific use cases and see the overall status of any process at a glance!

Try out PRTG for free if you don't use PRTG Network Monitor and cannot monitor your business processes so far!

Solusi monitoring respon HTTP dari cloud.



Today's business relies very much on the internet. This is true not only for vendors with big web shops, but also for companies, which present their product portfolio, or provide their services online. Downtime will actually mean revenue loss. As business is becoming more global, it isn't enough to monitor the availability of a web server from one single location—and that's where our brand-new Cloud HTTP sensor comes into play...

The Cloud HTTP sensor keeps a close eye on your web server from various locations, which are distributed over five continents around the globe. Just enter the URL the sensor should connect to. This could either be a URL leading to a webpage, for example, to measure the loading time of the page's source code. Or you could enter the URL of a page asset, for example, an image to measure its availability and loading time. Currently, all measurements are performed from the following locations:
  • Asia Pacific: Singapore
  • Asia Pacific: Sydney
  • Asia Pacific: Tokyo
  • EU Central: Frankfurt
  • EU West: Ireland
  • South America: Sao Paulo
  • US East: Northern Virginia
  • US West: Northern California
  • US West: Oregon
The sensor also shows you the global average response time. Pretty great, isn't it?
For more detailed information on the Cloud HTTP sensor, its requirements, and settings please have a look at the PRTG manual. Because this sensor type is currently in a beta status, we would really appreciate your feedback on your experience with it—just let us know! Please note that currently you can only use 5 sensors of this type at the same time.

Solusi monitoring hasil Script SSH Anda



A few months ago, we've featured the SSH Script sensor, which allows you to use your own scripts to customize your Linux monitoring. The SSH Script Advanced sensor takes the customization potential even further as it enables you to show values returned by an executable script located on the target system in multiple channels. This really comes in handy if you want to monitor multiple processes and return the result of each process in a separate channel.

In order to set up the SSH Script Advanced sensor, select a script from the /var/prtg/scriptsxml directory on the target Linux/Unix system. Please note that the script files stored in this folder must return valid XML in order for the sensor to show the expected values. If set up correctly, the sensor can show the following:
  • Execution time, and
  • Values returned by the script in multiple channels.
The areas of application for the SSH Script Advanced sensor are virtually infinite. You can use it to monitor, for example, multiple processes of your web shop and return the results of each check in a separate channel:
  • The number of new orders in the last 24 hours,
  • The number of registered users, and
  • The number of new customer tickets.
This allows you to keep a detailed overview of your running processes—all within one sensor. If you set limits in PRTG for the monitored values, you can also set up notifications to get alerted if these values are exceeded and go into error state.
For more detailed information on the SSH Script Advanced sensor, please have a look at the PRTG manual. For deeper insights into your Linux systems also take a look at the Python Mini Probe, which enables you to run a mini probe directly on the Linux target system.

Map Security needs to DevSecOps tools in SDLC.

  Map Security needs to DevSecOps tools in SDLC. Implementing DevSecOps effectively into the SDLC involves adopting the right tools, adaptin...