The sFlow protocol is adopted for the Host sFlow agent to export virtual and physics performance metrics. This agent promotes multi-vendor, scalable, and multi-operating system performance monitoring, besides having a small effect on the systems that are monitored.
What this Host sFlow project does is that it offers an open-source execution of the sFlow standard while reporting on the performance of the server. It is wise for computer vendors to simplify the setting up of sFlow by combining this agent with the products. By combining the servers’ host performance data and the network performance data from switches, users can enjoy a full view of the performance in converged environments
To explain more, this Host sFlow guide will provide a deep insight into how this tool works and what beginners need to understand. So, don’t stop reading!
sFlow
Currently, highly fragmented approaches are being adopted to monitor the performance of servers. For each operating system, server vendor, and application developer, agents and software are always reserved for performance monitoring. However, it must be stressed that none of these systems are designed to operate together.
The challenges that are related to scalable, multi-vendor network performance monitoring have been solved. In the field of networking, interoperability, and standards are of great importance. Most network equipment manufacturers allow the sFlow standard while combining different performance monitoring forms into their products. This ensures that the network administrators can choose from a wide range of open-source and commercial network management applications.
The interconnection of networks, cloud computing, and virtualization all contribute to blurring the lines that exist between network management and system management. Take, for example, a virtual software switch adopted to set up a connection between the network and virtual machines. To monitor the virtual switch, a user needs a sFlow agent that operates on the server.
For a better understanding of the performance in this environment, there is a need to keep track of both server resources and the network.
With the use of sFlow, users can get a common standard that can be used for system management and network management while minimizing the number of required tips to offer a single, end-to-end picture of performance. This is required to manage virtualized, converged, and cloud data centers.
The sFlow protocol can also be adopted for the Host sFlow agent, facilitating the export of both virtual and physical server performance information. This agent offers multi-vendor, scalable, multi-OS performance monitoring with a small impact on the monitored systems. Besides this, the Host sFlow project can contribute to the core of an ecosystem of similar projects that stretch visibility into the application layer. Examples include reporting web server response times, URLs, status codes, and many more.
Configuring Host sFlow for Windows
This section will provide insight into the configuration of the host sFlow agent, which is installed by adopting the installer hsflowd-win-<version>-x64.msi or hsflowd-win-<version>-x86.msi. Then, the installer will configure the service after demanding that the user provide the necessary configuration parameters. Yet, users can alter the configuration while setting any optional configuration parameters after installation. This can be done by adjusting the registry settings and then restarting the host sFlow service.
To send sFlow to a non-standard UDP port, append “:port” to the end of the IP address or hostname (0 port = 65535); IPv6 addresses need to be enclosed in brackets in this instance.
Set the registry entry to 10.0.0.1,10.0.0.2:6344, and [fe80::cabc:c8ff:fe97:ab14]:6344, for instance, to transmit sFlow to port 6343 on 10.0.0.1 and port 6344 on 10.0.0.2, as well as port 6344 on fe80::cabc:c8ff:fe97:ab14.
There are certain important terms that must be introduced:
- Sampling Rate This can be adopted in Windows Server 2012, which has Hyper-V Role installed. Given a random number N, a randomly selected packet from every Nth one forwarded by the virtual switch is sampled and exported. Default 400. To deactivate packet sampling, set the value to 0.
- Polling Interval This refers to the amount of time that passes between the export of counter samples. Default 30. To disable the counter export, you can set the value to 0.
- Agent Address This is an optional field. This is an IPv4 or IPv6 address, which the sFlow agent will adapt to identify itself uniquely. With hsflowd, it is possible to select an IPv4 address at random from the list of addresses that are related to the adapters. Make use of this parameter to specify the intended address if doing so leads to an unwanted address. The “off” or “on” string value for DNSSD is an optional one. When it is set at “on,” the collector settings, which are stored in the registry, will be ignored by hsflowd. Rather, it will make DNS calls to help discover the configuration.
- DNSSD Domain This is another optional field. You should adopt the use of this parameter if the system name contains no domain or if the domain is distinct from the relevant DNS-SD zone. Give the hsflowd instruction to inspect the settings for a specific zone. By default, hsflowd will attempt to make use of the system domain if a specific one is available.
Linux Configuration Using DNS Service Discovery
If it is possible to configure local DNS servers, then the best way to configure host sFlow on Linux is through DNS Service Discovery. Then, the sFlow configuration can be transferred into DNS records. From there, they can be read by the sFlow host agent. This ensures that there is a great network of hosts that can be configured easily and reconfigured.
Since the default configuration file is set for DNS-SD, no changes are needed there. All that is needed is to include the following records to your DNS servers, which are utilized by the hosts to be monitored. Then, the hosts will pick up the configuration automatically.
The following is an example configuration for DNS-SD. One TXT record should be created, with the name field _sflow._udp. This describes the overall sampling parameters for the agent. By following this, you can add an SRV record to specify the collectors that you can send sFlow.
_sflow._udp TXT “txtvers=1” “sampling=400” “polling=20”
SRV 0 0 6343 sflowtrend.inmon.com
SRV 0 0 6343 10.1.2.5.
As specified above, the sample rate is fixed at 1 in 400 and a counter-polling rate every 20 seconds. Then, there are two sFlow destinations. One of these includes a host, regarded as sflowtrend.inmon.com. The other is with the IP address 10.1.2.5. Both make use of the standard UDP 6343 sFlow port. To carry out this configuration, you should replace the SRV entries with those required for your installation.
Using the Configuration File for Linux Configuration
If you find it hard to modify your DNS servers, or you just wish to try out host sFlow by editing the configuration file on a few systems, then the following example can be helpful.
The configuration file is /etc/hsflowd.conf. Edit this file, and first change the line DNSSD to
DNSSD = off
This turns off DNS-SD; otherwise, the rest of the configuration file is neglected. The next step is to uncomment the collector section at the end of the file while modifying it to suit the installation. You can consider this for the configuration file:
sflow {
packetSamplingRate=400
counterPollingInterval=20
collector {
ip=sflowtrend.inmon.com
udpport=6343
}
collector {
ip = 10.1.2.5
udpport = 6343
}
}
Distributed Agent for sFlow on Hosts
The sFlow standard adopts the use of a distributed push model, in which each host, acting on its initiative, transmits a constant stream of performance data to a sFlow collector located in the center of the system. The push paradigm is very scalable and works extremely well in cloud-based applications.
The sFlow agents that are contained within a host are also part of the distributed architecture. The following figure illustrates how sFlow agent coordination occurs on each host to provide an all-encompassing and uniform view of performance.
Typically, a data center involves all the hosts using the same configuration settings for their systems. The Host sFlow offers a centralized point of configuration. This is a daemon that is also known as hsflowd. DNS Service Discovery is a method that is used by hsflowd by default and can be adapted to figure out the configuration values. Besides this, the configuration settings can be deployed by adopting various orchestration tools, including Chef or Puppet, which can help in changing the hsflowd configuration file, which is located at /etc/hsflowd.conf on every host. Then, you can restart the daemon.
The hsflowd daemon will save any configuration information to the /etc/hsflowd.auto file once it is received through DNS Service Discovery or via the configuration file. As changes are made to the /etc/hsflowd.auto file, other sFlow agents that are operating on the host can identify the changes automatically while applying the configuration settings.
The sFlow protocols ensure that the agents can function on their own. Besides, this also ensures that they can submit an independent stream of metrics to the sFlow collector. The removal of issues related to dependencies and synchronization, which would have increased the complexity of the agents, is made possible by the distribution of monitoring among the agents.
Each of the sFlow agents is charged with the responsibility of outputting a distinct set of metrics, as described below:
- hsflowd By running this on a Xen, XenServer, or KVM hypervisor, the Host sFlow daemon will facilitate the provision of all kinds of performance measurements for the CPU, memory, disk, and network IO. Besides this, it can also export typical information to each virtual machine. Also, monitoring traffic with iptables/LOG is allowed on various Linux platforms.
- Open vSwitch This is also regarded as the switch that is used by default in XenServer 6.0, the Xen Cloud Platform”. It supports KVM, Xen, VirtualBox, and Proxmox VE. Furthermore, it has been combined into various virtual management systems, including OpenStack, openQRM, and OpenNebula. When the built-in sFlow monitoring on the virtual switch is enabled, then it can provide the same visibility as sFlow on physical switches while offering a single end-to-end picture of network performance across the virtual and physical infrastructure.
The configuration of sFlow monitoring on the Open vSwitch is done by the ovs-vsctl command. Users can also accomplish this by offering the same visibility as sFlow on physical switches. The sflowovsd daemon also helps in achieving this. This daemon is included with Host sFlow. Similar, integrated sFlow support has also been shown for the Microsoft extensible virtual switch.
- Java Information that relates to the performance of Java threads, heap and non-heap memory, garbage collection, class loading, and compilation are exported by the Java sFlow agent.
- httpd This represents a sFlow agent, which is often combined with the web server. This is needed to export key performance measures, besides the detailed transaction data. These metrics and data can then be adopted to monitor top URLs, top Referrers, response times, and many more.
- Memcached If a user needs to monitor hotkeys, top clients, and more, there is a need for a sFlow agent, which is integrated within the Memcache server, to export performance metrics, as well as detailed information on Memcache activities. This information can then be used to monitor the Memcache server. There is an execution of sFlow for Memcached, which can be found at this time.
An integrated monitoring system is created by the agents that are operating on every host, besides the sFlow agents, which can be found within the network infrastructure. With this system, users can enjoy a single picture of the network performance, as well as the applications and storage. This can scale up to a plethora of servers.
Execution of sFlow Visualization Tools
There is a need for a host that can run Linux to install collectors. It is never a bad idea to acquaint yourself with more information about configuring sFlow. This section will provide a deep insight into monitoring, while also offering a step-by-step guide to the configuration of many sFlow visualization tools.
Acquiring Knowledge of Monitoring
With monitoring, users can enjoy significant insights into their network. A wide range of tools is available. While some of these are open source, others are commercial, and they can contribute to monitoring the performance of the switches and routers of your network. Cumulus Linux – version 2.1 and above – is capable of supporting the Host sFlow protocol.
Offering a full view of the network involves the Host sFlow collecting data on the traffic being transferred through it, as well as the counters and metrics that can be found on the switches. Besides system operating systems, a wide variety of network hardware supports sFlow. For users looking to set up sFlow successfully, there are two essential components to consider. These include:
- Placing the hosts in a position
- Setting the collection mechanisms
NVIDIA has suggested that it is good to use a separate server for a sFlow collector instead of depending on the switches. This is because switches that run Cumulus Linux are specialized. Besides, they have no storage or processing power that is needed to carry out the role of a collector.
This user guide will also instruct you on how you can configure your Cumulus Linux switch to ensure that it can act in the role of a collector. Even though the documentation that the server vendor offers can explain the configuration process of your server to become a sFlow collector, you can learn many configurations with this article.
As soon as the hsflowd daemon starts transferring monitoring traffic to your collection’s server, users will then be armed with the ability to discover certain useful data
Top sFlow Tools to Be Acquainted With
You will find a wide range of tools that are commonly used for sFlow data. With this great number of available tools, it is only imperative to make the right choice, which might be tailored to your organization’s existing infrastructure, as well as any preset goals. Since sFlow can transfer to many collectors, there is no need to be restricted to just one tool. You will find good features in sflowtool and Wireshark. If what you wish to achieve is debugging a low-bandwidth single flow, these are the right tools to use. However, they can seem not to be so human-readable.
Thanks to the large volume of communication that is moving through most switches, users often prefer human-readable formats. Besides this, you can also resort to graphs for visibility. It is never a wrong idea for companies to reserve server monitoring solutions.
A good application is Ganglia, which can ingest sFlow counter samples. While displaying switch metrics. Furthermore, Graphite is another popular tool that can be used to visualize system data. Due to sflow2graphite, a script, this tool can display sFlow data. Another good sFlow collector, which users like, is SolarWinds sFlow Collector and Analyzer. With this application, users can visualize and analyze their network thanks to its ability to sort, graph, and display data in various forms.
Conclusion
Sometimes, the network of an organization can start acting strangely. It is only natural that this happens from time to time. However, when this happens, we can all agree that there is a need to understand what is happening inside. When there are a few segments that are connected by a few routers and switches, a basic monitoring tool can help in monitoring network traffic. With Host sFlow, you can keep your network up and running while enjoying the visibility of everything that goes on. This tool has also been a popular choice among users, thanks to the fact that it can help diagnose and troubleshoot problems.