Hyper-V monitoring: Here’s some tips!

Posted by on Sep 26, 2017 in Capacity Management, Nagios, Nagios-Plugins, NetEye | 0 comments

Network traffic monitoring is traditionally based on SNMP queries. This protocol generates statistics on the transmission of data across one or more network interfaces.

While network device queries still run through SNMP, using Microsoft Hyper-V monitoring requires the adoption of other approaches. One of the reasons is the network connection configuration itself: for example, many physical network interfaces of a Hyper-V device belong to a logical interface that can also distribute network traffic to multiple network devices, such as multiple switches. Another reason for using an alternative approach is that Microsoft has abandoned the maintenance of SNMP services on their operating systems.

Consider a physical network with the following configuration: a physical Hyper-V host has two active physical network connections that are connected to the network via two switches.

Esempio di cablaggio di una rete fisica

Example of a physical network

Read More

Why does my local network latency increase during working hours?

Posted by on Sep 22, 2016 in Capacity Management, NetEye, Network Traffic Monitoring, Real User Experience Monitoring | 0 comments

Sometimes you get a higher network latency during certain periods of the day.

Network section of a datacenter (1 Gigabit Ethernet) with normal, constant latency throughout the day

Network section of a datacenter (1 Gigabit Ethernet) with normal, constant latency throughout the day. Please consider that the typical latency for 1 Gigabit Ethernet connections is minor than 5ms.


Network section of a datacenter (1 Gigabit Ethernet) with increased latency during working hours

Network section of a datacenter (1 Gigabit Ethernet) with increased latency during working hours. Please consider that the typical latency for 1 Gigabit Ethernet connections is minor than 5ms.

Read More

Capacity View on Microsoft Exchange for German OS 2K3

Posted by on Oct 19, 2011 in Capacity Management | 0 comments

The previous Blog article ( http://www.neteye-blog.it/?p=1502 ) on how to implement a capacity view on the e-mail exchange on Microsoft Exchange servers works fine for international English servers. Due to the fact that the template makes use of system counters for the data backend, the remote system calls have to be adjusted for hosts installed in regional languages.

During my latest customer visits in Germany I experienced 2003 Servers installed in language and I took the occasion to translate the template for German counter objects. Due to the 2003 specific deeply-build in language specifications there arise some problems in simply translating the counter names for the check_nt call.

Due tue many special, non standard ASCII characters the check_nt call from remote does not succeed from our non Unicode system and I opted for the implementation of the counter call within the remote Microsoft system by calling it via NRPE.

Here comes the configuration for the NSClient++ we are using on the MS side. Edit the NSC.ini and add in the [NRPE Handlers] section those command definitions:

check_exch_submittedmsg=inject checkCounter “\MSExchangeIS Postfach(_Total)\Übermittelte Nachrichten” ShowAll
check_exch_sentmsg=inject checkCounter “\MSExchangeIS Postfach(_Total)\Gesendete Nachrichten” ShowAll
check_exch_deliveredmsg=inject checkCounter “\MSExchangeIS Postfach(_Total)\Übergebene Nachrichten” ShowAll
check_exch_sendqueuesize=inject checkCounter “\MSExchangeIS Postfach(_Total)\Größe der Sendewarteschlange” ShowAll
check_exch_deliveryqueuesize=inject checkCounter “\MSExchangeIS Postfach(_Total)\Größe der Empfangswarteschlange” ShowAll

For your convenience we have prepared a NSC.ini file already usable. Make sure to maintain the Unicode encoding and to reload the NSClient++ service !

Well, now we’re almost done. Copy the exchange07_de Perl script into your “scripts” folder of Cacti and then load the Host template for Microsoft Exchange DE cacti_host_template_exchange_de into Cacti and define your Device using this template. Enjoy !

Read More

Monitoring Nagios Performance Graphs

Posted by on Jan 4, 2011 in Capacity Management, Nagios | 0 comments

This post introduces a check strategy to monitor the freshness of Nagios performance graphs.

When the feature is enabled Nagios is generating performance graphs, that are updated automatically with the execution of a single check. Such a check result delivers also the so called “performance data”, content interpreted by dedicated listeners behind the Nagios process. The results are stored and maintained within RRD databases.

Read More

Capacity View: Exchange 2007

Posted by on Aug 13, 2010 in Capacity Management | 7 comments

For the capacity management it is of interest to monitor the development of performance values over a longer time distance within graphs.

Today we will offer the community a collection of templates to monitor the load of a Microsoft Exchange 2007 server infrastructure.

This template is made up of an data import file for Cacti version 0.8.x importable directly from the web front-end. The other file ( exchange07.pl ) has to be placed in your cacti home in the folder scripts/

Advice: Don’t forget to edit the path to your local check_nt binary and the path for the comunication!

Graphs for number of connections and mail exchange statistics:

Graphs for RPC statistics and SMTP queues:

Graphs for the optional SPAM filter service activity:

Cacti importable host “Exchange 2007” template and script: Exchange07_CactiTempl_01

Import the XML vai Import feature from web
Copy the Perl script to ./cacti/scripts/exchange07.pl

Read More

Gli allarmi sul traffico di rete IP

Posted by on Mar 18, 2010 in Capacity Management, Nagios, NetEye, Network Traffic Monitoring | 0 comments

Una interessante funzionalita’ di NetEye che abbiamo utilizzato per risolvere un problema concreto di un nostro cliente sono gli allarmi che vengono innescati sull’ analisi del traffico “live” di Nfsen.

Il problema che avevamo era legato all’ utilizzo massiccio di un protocollo che andava a degradare le performance di alcuni servizi, grazie alle nuove funzionalita’ di Ntop integrate in NetEye avevamo identificato la causa del degrado, quello che ci mancava era di avere l’ informazione in “tempo reale”  di quando veniva utilizzato il protocollo in modo massivo.

La soluzione e’ stata l’ utilizzo degli allarmi di Nfsen che permettono di eseguire delle azioni (allarmi o attivazione di plugin) in base al  raggiungimento di determinate condizioni sul traffico.

tramite l’ utilizzo dei filtri e la definizione delle condizioni che vedete elencate nelle immagini e’ possibile ottenere una ottima granularita’ dell’ informazione.

Quello che abbiamo fatto e’  stato di configurare un allarme che si attiva se l’ utilizzo medio del protocollo in questione (RDP) su di una specifica WAN supera la soglia dei 100 Kbps per un periodo di 10 minuti. L’ utilizzo delle medie su di un periodo ci permette di avere delle segnalazioni puntuali nel caso ci sia un vero disservizio evitando nel contempo segnalazioni inutili (falsi positivi) nel caso di brevi picchi di utilizzo.

Nell’ immagine seguente, l’ esempio del controllo che ci notifica i raggiungimenti delle soglie definite e che ci permette di avere la visualizzazione grafica delle medie delle ultime 24 ore

Read More