Data Center is our focus

We help to build, access and manage your datacenter and server rooms

Structure Cabling

We help structure your cabling, Fiber Optic, UTP, STP and Electrical.

Get ready to the #Cloud

Start your Hyper Converged Infrastructure.

Monitor your infrastructures

Monitor your hardware, software, network (ITOM), maintain your ITSM service .

Our Great People

Great team to support happy customers.

Saturday, June 21, 2014

Custom Sensor dalam PRTG



Users can create and use their own, self-written custom sensors in PRTG Network Monitor to go far beyond PRTG's standard sensor set. You can create your own sensors using Windows Management Instrumentation Query Language (WQL), visual basic scripting, PowerShell, batch scripting, and by compiling an EXE or DLL file (using any Windows software development tool).

Basics

For a general introduction, please see the sections about EXE/Script sensors and the API documentation which contains details about the necessary return format for those sensors. WMI Custom sensors allow executing WQL requests.

Custom Sensors Included in PRTG

After installing PRTG Network Monitor you will already find a selection of custom EXE/Script and WMI WQL script sensors in the PRTG program directory. Many of these are sample projects that you can edit and improve for your needs.

Custom Sensors Included in PRTG—Folder: \Custom Sensors\EXE

  • Demo Batchfile - Returns 200.bat
  • Demo Batchfile - Set sensorstate to error.bat
  • Demo Batchfile - Set sensorstate to warning.bat
  • Demo Cmd - Returns 200.cmd
  • Demo Dll - Returns a random integer.dll
  • Demo EXE - Returns a random integer.exe
  • Demo EXE - Returns number of files in folder (parameter).exe
  • Demo EXE - Returns user of process.exe
  • Demo Powershell Script - Available MB via WMI.ps1
  • Demo Powershell Script - InterruptsPerSec via WMI.ps1
  • Demo Powershell Script - Returns a fixed integer value.ps1
  • Demo Powershell Script - Returns a random integer value.ps1
  • Demo Powershell Script - Returns Random Integer and Warnings.ps1
  • Demo VBScript - InterruptsPerSec via WMI.vbs
  • Demo VBScript - Multiplies two integers(2 parameters).vbs
  • Demo VBScript - Returns a fixed float value.vbs
  • Demo VBScript - Returns a fixed integer value.vbs
  • Demo VBScript - Returns a random value.vbs
  • Demo VBScript - Returns number of svchost processes.vbs
  • Demo VBScript - Returns user of process.vbs
  • Demo VBScript - Returns warning depending on number of svchost processes.vbs
  • Demo VBScript - Timezone via WMI.vbs
  • Demo VBScript - UTCTime via WMI.vbs
  • Load_Test_CPU_1_Mio_Primes.exe
  • Load_Test_CPU_10_Mio_Primes.exe
  • Load_Test_Disk_Write_Read_1000_files.exe
  • Load_Test_Disk_Write_Read_10000_files.exe
  • Load_Test_Memory_Allocate_And_Free_400MB.exe
To create a new sensor based on one of these files, create a new EXE/Script Sensor and choose the respective file from the drop down list.

Custom Sensors Included in PRTG—Folder: \Custom Sensors\EXEXML

  • Demo Batchfile - Returns static values in four channels.bat
To create a new sensor based on one of these files, create a new EXE/Script Advanced Sensorand choose the respective file from the drop down list.

Custom Sensors Included in PRTG—Folder: \Custom Sensors\WMI WQL scripts

  • Demo WQL Script - Get Win32LogicalDiscFreeMB.wql
  • Demo WQL Script - Get Win32OsBuildnumber.wql
  • Demo WQL Script - Get Win32PercentProcessorIdleTime.wql
  • Demo WQL Script - Get Win32PercentProcessorTime.wql
To create a new sensor based on one of these files, create a new WMI Custom Sensor and choose the respective file from the drop down list.

Downloading Pre-Build Custom Sensors

A good resource is the PRTG Add-Ons website on the open source platform Google Code . There are also additional tools available.
Open Source Add-Ons for PRTG Network Monitor

More

For the other sensor types that work out-of-the-box, please see
Knowledge Base: How can I test if parameters are correctly transmitted to my script when using an EXE/Script sensor?

Dashboard menarik dengan PRTG



After three exciting months the "My PRTG Dashboard" competition has come to an end. You've sent us about 30 great and inspiring dashboards, which for our jury made it quite difficult to agree on one single winner each month—you can't imagine the heated discussions! But finally we've found three winners. All chosen dashboards add real value to the monitoring solution as the responsible IT team, and in certain cases even end customers, can see at a glance if their network or monitored systems are running smoothly.
Now, without further ado, let me present to you the three winning dashboards:

Dashboards as Customer Service

In February Quentin Long, a cloud solutions engineer at Fronde, surprised us with a comprehensive dashboard that helps his team to monitor cloud solutions, based on Amazon Web Services (AWS) with PRTG Network Monitor. Quentin's dashboard also enables his customers to really use the monitoring data, detailing all their customers' servers, load balancers, data feeds, and remote connectivity—one dashboard for each customer with unique logins, only allowing them to see their own environment. They all love it—and so did we!
Quentin Long: Winner in FebruaryQuentin Long: Winner in February

A Dashboard Delivering Electricity

Ricardo Fernandes of REN Servi├žos, S.A. was our winner in March. His dashboard reminded us of the real-world value monitoring offers. REN operates Portugal's National Transmission Grid (RNT), which ensures a balance between energy supply and demand. If one of the monitored high tension substations isn't working properly, an entire city could be without electricity. Other dashboards enable REN to analyze the problem by checking the primary cores of the Multiprotocol Label Switching (MPLS) network and their interconnections with each other, or help them to monitor the administrative buildings of the company. We liked most how closely Ricardo's dashboard is connected to the company's actual area of operations, which makes monitoring the underlying network structure real easy and approachable.

A Dashboard Packed with Applications

In April system and network engineer Wim Van Haver dazzled us with a dashboard that's not only monitoring 50 locations in 17 countries all over Europe, but also incorporates several other great applications. The most outstanding one is the "wear-a-tie" sensor—yes, that's right: a sensor that's telling Wim and his colleagues if they need to wear a tie! At Sonoco Alcore their boss insists on them wearing a tie if he's in the office, so they came up with an ingenious custom map object based on an ADO sensor, which is linked to the electronic in/out board at the reception desk. So as soon as the little character on top of the dashboard starts wearing a tie, also the members of Wim's IT team can open their drawers and grab their tie.
Wim Van Haver: Winner in AprilWim Van Haver: Winner in April
If you want to know more about these great dashboards, just take a look at our "My PRTG Dashboard" winners gallery—also stay tuned for our upcoming blog article on the runner-up dashboards. There's more to discover, so get inspired and start designing your own unique dashboard now!
By the way: Although the contest is over, we're still curious to see your dashboards—so don't be shy and share them with us via FacebookTwitter or Google+!

Remote dan Multiple Probe dalam PRTG



Upon installation, PRTG creates the first probe automatically, called the Local Probe . It runs on the same machine as the PRTG core server and monitors all devices from this system, using the sensors you have configured. Working with only one local probe should suffice for Local Area Network (LAN) monitoring and if you want to monitor one location only.

Scenarios Requiring Remote Probes

However, there are several situations making it necessary to work with Remote Probes in the same LAN or in remote locations. Among these situations are the following:
  • You have more than one location and you need to make sure that services are available from all locations.
  • Your network is separated in several LANs by firewalls, and the local probe cannot monitor specific services across the firewalls.
  • You need to monitor systems in a Virtual Private Network (VPN) across public or in-secure data lines.
  • You want to sniff packets on another computer.
  • You want to monitor NetFlow data on another computer.
  • You experience performance issues with CPU intensive sensors like packet sniffer or NetFlow sensors and need to distribute the load over more than one PC.
The following chart shows an example for a remote probe scenario.
Monitoring a Distrubuted Network with PRTG (Illustration Also Available as Video Tutorial)Monitoring a Distrubuted Network with PRTG (Illustration Also Available as Video Tutorial)
The PRTG core server inside the Corporate LAN (bottom right) is able to monitor:
  • Services inside the Corporate LAN using the Local Probe .
  • Services behind a firewall in the Corporate LAN using Remote Probe 1 .
  • Secured services inside the Branch Office (top left) using Remote Probe 2 .
  • Secured services on Mail Server and Web Server using Remote Probe 3 and Remote Probe 4 installed directly on these servers.
  • Public services on the internet using any of the probes.
     

How Probes Work

As soon as a probe is started, it automatically connects to its core server, downloads the sensor configuration, and begins its monitoring tasks. The core server sends new configuration data to a probe as soon as the monitoring configuration is changed by the user. Probes monitor autonomously and send the monitoring results back to the core server for each check they have performed.
If the connections between core and probe fails for any reason (for example, a reboot of the computer running the core server) the probe continues its monitoring and stores the results. During a connection loss a buffer stores a maximum of 500,000 sensor results in RAM memory of the remote probe system (up to 50 - 200 MB). This means that for 100 sensors with one minute interval the monitoring results of up to 3 days can be buffered (or 52 minutes for 10,000 sensors with one minute interval). The probe automatically reconnects to the core as soon as it is available again and transmits all monitoring results gathered during the connection loss.
The connection between probe and core is initiated by the probe, secured using Secure Sockets Layer (SSL). This means that the data sent back and forth between core and probe is not visible to someone capturing data packets. The core server provides an open TCP/IP port and waits for connection attempts from probes. If a new probe connects for the first time, the administrator will receive a ToDo ticket and will then see the new probe in the device tree.
As a security precaution, the probe must be manually acknowledged by the administrator in the device tree before any sensors can be created and monitored. The administrator can also deny a probe which will then be disconnected. No further connection attempts will be accepted and the probe IP is added to the Deny IPs list in the probes system settings (see System Administration—Core & Probes section). This ensures that unauthorized probes cannot connect to a core server.
Because the probe initiates the connection, you must ensure that a connection can be established from the outside world onto your core server. For example, you may need to open any necessary ports in your firewall and you may need to specify a Network Address Translation (NAT) rule for your network. The process is the same as if you wanted to allow access to the web server provided by the PRTG core server via port 443, for example. Usually it is sufficient to open or forward TCP port 23560 (default) on the machine that runs the core server; on probe side it is notnecessary to open any port in most cases.

Automatic Probe Update

Whenever a new version of PRTG is installed on the core server, all remote probes will automatically download and install the updated version of the probe as soon as they reconnect to the updated core installation.
The local probe has already been updated during the core installation. All remote probes are automatically downloading the new binaries using the SSL-secured probe/core connection. The download of the 4 MB file takes between a few seconds (in a LAN) and a few minutes (via internet connections), depending on the available bandwidth. As soon as the update has been downloaded the probe disconnects, installs the update and reconnects to the core server. This takes between 20 and 100 seconds. Please note that during the update phase the monitoring of the local probe can be affected due to the bandwidth required for the downloads.

More

Video Tutorial: There is a video available on the Paessler video tutorials page.

Private Cloud akan tetap jadi pilihan utama



Private cloud is here to stay: Cisco

Summary: Cisco believes as regulatory pressures to keep data in-country heightens, more businesses will look at the private cloud as the solution.
Cisco Systems is confident that Australia will be the global market leader to take up its big cloud play that has been dubbed Intercloud. 
Speaking to a room of media this week, Cisco development and sales president Robert Lloyd said Intercloud — which the company initially announced in March as part of its US$1 billion investmentto secure its position in the cloud computing market — is an "enterprise response to the multiple uses of cloud technology that is expected to unfold in the next decade".
"We have heard for a year or two about the construct of the market, and how it has been trying to respond to the complexity that has emerged in networking ... [but] command line interface network units that's expected to lead to the agility and flexibility that customers are looking for today isn't going to be the answer," he said.
Lloyd believes Cisco's Intercloud solution and ecosystem will be "more vibrant" in Australia because "private cloud is not going away", especially as regulatory pressures to keep data in-country heightens. Recent information released by Wikileaks has shown that 50 countries including Australia may be signing away rights to ensure sensitive customer data remains in its country of origin, as part of negotiations for new financial services rules for operating between participating countries.
"It will be here first, so it will be interesting to watch it play out. We have a very vibrant Amazon, a very impactful Azure and Microsoft cloud, we have a lot of successful private cloud deployments because private cloud is at the heart of what we see to be the true vision of Intercloud," he said.
So far, Cisco has signed Telstra as its first global customer where Telstra will launch cloud services based on Cisco's Intercloud platform by the end of 2014. As part of the deal Cisco will be operating and controlling the telco's cloud platform in its datacentre and using Telstra's mobile network in Australia.
Cisco has also signed with Dimension Data for help on laying the building blocks for the hybrid cloud infrastructure and reaching emerging markets.
Lloyd anticipates globally there will be eight to 10 Intercloud global providers that will embrace all of its Intercloud building blocks, including ACI, OpenStack, Hyper-V, and vSphere.
"We will see a world of many clouds. Our intention is to demonstrate the network and the cloud will come together in a very important way."
Cisco ANZ vice president Ken Boal also commented that Intercloud will help drive productivity and remove complexities that exists when it comes to "moving parts of an infrastructure into a vanilla platform".
"The selling point for Intercloud is just that it offers choice and flexibility of combing private and public across multiple platforms and hyervisors," he said.
But Cisco is not alone in this approach to the cloud. Towards the end of last year, IBM cooked up its version of  InterCloud, a cloud-of-clouds approach designed to tie services together and avoid vendor lock-in.