Why you should read this blog post? You need to take care of the Audit function from OEM CC even if you don’t want to use it. It’s enabled by default and needs to be managed! (more…)
this is a start of an automation series with “VMware vRealize Orchestrator”. Sometimes it is necessary to extract data of a huge number of ESXi Hosts in short time. There are multiple ways to-do so, depending on the environment and type of data, some ways are more effective than others. Next to “VMware’s PowerCLI” a great alternative is the vRO. The automation software offers workflow development, API interaction, scheduled executions of workflows and much more!
The first part of this series demonstrates how to create a workflow that is able to extract driver and firmware related information from ESXi HBAs. Once the data is collected it will be sent as an attachment via email to a distribution list. The main workflow consists out of four helper workflows that can be also used for different projects. (Enable SSH, Disable SSH, Send E-Mails)
Both utilities are rarely used – usually in case you already ran into a problem. But it’s useful to have basic knowledge because otherwise it’s hard to start with them. This blog post should give you an overview what the utilities are made for. (more…)
In my previous post i explained all needed details how to get started with the “PCAP Analyzer for Splunk”.
With this post I am going to describe the Top Talker Overview Dashboard in the application.
The main idea behind this Dashboard is to perform a top talker analysis by understanding which Conversation / Server / Protocol / VLAN / Port produced the highest traffic within the captured time period.
Sometimes it can be very helpful to understand if you suffer from problems due to an overload within your network. (more…)
Too many times we have situations we suffer from random network connection / latency problems which might be caused by a huge amount of traffic sent over the network or even a problem directly on the specific endpoints.
If you have such kind of problems, in the most of the cases it’s mandatory to capture network traffic on the affected endpoints or even better also on a network device in the middle.
The most popular tool to analyze network captures (.pcap files) is Wireshark.
There are many good tutorials in the Internet which shows good ways to understand and finding the root cause for such Incidents.
I am using Wireshark since more or less 4 years now and after that time and also after many network trace files I’ve looked in there are some features which are not included or hard to get out of Wireshark (e.g. Top Talker Conversations over time, Number of devices between the conversation endpoints).
So I started to think about a way to collect the network packet data by using Splunk. After several weeks checking which will be the best way I’ve decided to use the CSV functionality.
Wireshark includes several sub components including the tshark component which is able to convert the .pcap file to a Splunk readable CSV file.
I came up with the “PCAP Analyzer for Splunk” which can be downloaded from Splunk App page:
How to get started?
“PCAP Analyzer for Splunk” requires a full splunk instance running on *nix / Windows systems and Wireshark needs to be installed.
In summary the most important requirements are the following:
- Splunk instance with SPLUNK_HOME variable defined.
- Wireshark installed (on Windows: Wireshark needs to be located at %programfiles%)
- Confirm that your user has all administrative privileges for the folders “$SPLUNK_HOME/etc/apps/SplunkForPCAP/bin/” and for your Wireshark folder.
During an Incident I was dealing with an issue that an amount of different *nix machines were receiving / transmitting data over the wrong interface.
Since we didn’t want to check every *nix machine manually to see which interface is used I wrote a simple bash script which collects necessary network interface statistics like received / transmitted bytes for every interface configured over time.
The script writes a log to a separate file with following format:
Wed Jan 21 14:58:13 CET 2015 NIC=eth7 RXbs=2807182787 TXbs=192412352
while NIC = Interface, RXbs = Received bytes per second and TXbs = Transmitted bytes per second.
We executed the script every minute by using the crontab and we collected and analyzed the log by using Splunk.