Top 10 Container Monitoring Solutions/Tools in 2018
- Native Docker
- Heapster / Grafana
- ELK stack
Top 10 Container Monitoring Solutions/Tools in 2018
As DevOps gets more agile, infrastructure needs unit tests too. Enterprise startup ScriptRock offers cloud-hosted testing configuration tools to get you started.
mpstat reports processors statictics.
vmstat reports virtual memory statistics.
vxstat – This Utility can be used as well.
The iostat command generates two types of reports, the CPU Utilization report and the Device Utilization report. The first report generated by the iostat command is the CPU Utilization Report.
|iostat commands Table|
|iostat||Iostat without any argument displays information about the CPU usage, and I/O statistics|
|iostat -c||Display only cpu statistics|
|iostat -d||Display only disk I/O statistics|
|iostat -n||Display only network statistics (device and NFS statistics)|
|iostat -m||Display the device I/O statistics in Blocks and To change I/O data in MB/second|
|iostat –p||Display I/O statistics only for a device(data for all the disks available in the system)|
|iostat -t||By default iostat displays only the current date. To display the current time, use this option|
|iostat -x||Display extended disk I/O statistics information|
|iostat -x sda1||Display Extended status of device sda1|
|iostat 2||Execute Every 2 seconds (until you press Ctl-C)|
|iostat 2 3||To execute every 2 seconds for a total of 3 times|
|iostat -N||To display the LVM statistics use option -N as shown below.|
|iostat –V||To Display Version|
|iostat -d -x||Display only disk I/O statisticsin in extended form|
|iostat -d -x sda||Display only sda device I/O statisticsin in extended form|
|iostat -Td -xdn 5||For Solaris|
|iostat -d -x 5||For Linux|
|if Average read or write times over 50 ms, this should be consider for serious i/o problems|
The report has the following format:
%user – Show the percentage of CPU utilization that occurred while executing at the user level (application).
%nice – provides statistics on a per physical device or partition basis.
Device – This column gives the device name
tps – Indicate the number of transfers per second that were issued to the device. A transfer is an I/O request to the device.
Blk_read/s – Indicate the amount of data read from the drive expressed in a number of blocks per second.
Blk_wrtn/s – Indicate the amount of data written to the drive expressed in a number of blocks per second.
Blk_read – The total number of blocks read.
Blk_wrtn – The total number of blocks written.
kB_read/s – Indicate the amount of data read from the drive expressed in kilobytes per second.
kB_wrtn/s – Indicate the amount of data written to the drive expressed in kilobytes per second.
wrqm/s – The number of write requests merged per second that were issued to the device.
r/s – The number of read requests that were issued to the device per second.
w/s – The number of write requests that were issued to the device per second.
rsec/s – The number of sectors read from the device per second.
wsec/s – The number of sectors written to the device per second.
await – The average time (in milliseconds) for I/O requests issued to the device to be served.
svctm – The average service time (in milliseconds) for I/O requests that were issued to the device.
%util – Percentage of CPU time during which I/O requests were issued to the device.
|vmstat -a||Display active and inactive memory|
|vmstat -f||Display number of forks since last boot|
|vmstat 2||Execute Every x seconds (for y number of times)|
|vmstat -t 1 100||Display timestamp|
|vmstat -V||version info|
|vmstat -m||Display slab info|
|vmstat -s||Display statistics in a table format|
|vmstat -d||Use option -d to display the disk statistics as shown below. This displays the reads, writes, and I/O statistics of the disk.|
|vmstat 1 3||vmstat – Increase the width of the display|
|vmstat -p sdb1||Display statistics for a partition|
|vmstat -S m||Display in MB|
The report has the following format:
Procs – r: Total number of processes waiting to run
Procs – b: Total number of busy processes
Memory – swpd: Used virtual memory
Memory – free: Free virtual memory
Memory – buff: Memory used as buffers
Memory – cache: Memory used as cache.
Swap – si: Memory swapped from disk (for every second)
Swap – so: Memory swapped to disk (for every second)
IO – bi: Blocks in. i.e blocks received from device (for every second)
IO – bo: Blocks out. i.e blocks sent to the device (for every second)
System – in: Interrupts per second
System – cs: Context switches
CPU – us, sy, id, wa, st: CPU user time, system time, idle time, wait time
reports processors statictics(mpstat – Report processors related statistics and mpstat displays CPU statistics )
mpstat :- mpstat displays CPU statistics
mpstat -A :- Display all information
mpstat -P ALL :- Display CPU statistics of individual CPU (or) Core
Software development has traditionally suffered from producing end products with a definite lack of inherent quality. The symptoms of this quality lack are listed here:
As we look into the symptoms of our software development malaise, five principal issues related to software development arise.
Lack of Visibility
Software is conceptual in nature. Unlike a bridge, a building, or another physical structure, it is not easy to look at software and assess how close it is to completion. Without strong project management, “software is 90% complete 90% of the time.” Through the adoption of SCM policy and the definition of the configuration management model of the software under development, all CIs, components, and subcomponents are immediately visible for versions, releases, and product families.
Lack of Control
Because software is inherently intangible, it is also more difficult to control. Without an accurate assessment of progress, schedules slip and budgets are overrun. It is hard to assess what has been accomplished and what remains to be done. SCM provides the mechanism for controlling the project through measuring the amount of effort compared to the project management plan and estimating the future effort based on past work.
Lack of Traceability
A lack of linkage between project events contributes to project failures. The main benefit of SCM is providing the traceability among versions, releases, and product families. The value of this traceability is enormous when a problem arises in one release or product family that impacts other client releases and products. Making one change and promoting that through the entire product software base is an incredible cost savings in time, money, and client good will. A lack of linkage between project events contributes to project failures where solving one problem either exacerbates a problem in another area or fails to fix the same problem elsewhere. A traceability thread allows management to examine the chain of events that caused a project to encounter difficulty as an integral process within the auditing capability of SCM. A project becomes a year late one day at a time unless the effort reported on the schedule maps to the actual work being done and traced within the software configuration management system.
Lack of Monitoring
Without traceability and visibility, monitoring of software development projects becomes extremely difficult. Management cannot make informed decisions, and thus schedules slip further and costs continue to exceed budget.
There is no way to monitor a project when the project manager has no tools to look into the actual product development within the project. SCM provides the tools that open up the process to external monitoring. With SCM in place and a policy of traceability and visibility accepted, monitoring of software development projects becomes a simple part of the overall project management task. Management makes informed decisions avoiding schedule slips and budget excesses through the monitoring available with SCM tools and the integral workings of the CCB.
Software is very malleable; it is idea-stuff, and customers constantly have new ideas for it. People would rarely ask a bridge constructor to make the kinds of changes midproject that software customers tend to request. The impact of such changes can be just as great. All SCM tools, along with the CCB, support a mechanism for appropriate change control.
SCM Interacts with Verification and Validation
SCM is most important, and most often neglected, during V&V activities, which include software testing. It is employed in tracking which module versions are included in a particular system build, as well as which tests have been run. The results of the tests are tied directly to the modules or subcomponents being tested. Many times there are “action items” resulting from the tests. SCM tracks the action item status, so overall system status can be assessed well before final builds and releases are done.
Verification and validation testing are supported through the four basic SCM processes: identification, control, auditing, and status accounting. Let’s look at examples of V&V testing in the context of each of these components.
With all of these potential benefits of SCM, project managers must address real-world considerations. Management commitment is the real key to implementing SCM on a specific project in a given organization. By treating the implementation of SCM as a project, the project plan must start at the top to secure commitment to checks and balances. Now is the time to bring out the organization’s list of project disasters to draw on management experience with their previous software project difficulties. If there are no historic disasters in the organization, or if it is inappropriate to discuss them, refer to literature articles that provide accounts of project disasters (refer to the Web resources at the end of this chapter). Finally, after putting a notional return-on-investment financial argument in place, explain the intangible benefits of SCM.
One of the major sources intangible benefits is auditing. Auditing can be a heavy consumer of configuration management resources, and management may question the benefit of this kind of expenditure. Auditing pays for itself through the avoidance of larger, unnecessary expenses. Savings of 100:1 (large projects) or 4–6:1 (small projects) are obtained by finding and fixing problems early in the life cycle. The auditing process in SCM uncovers the areas where a little more effort or control will result in higher-quality software products and lower overall project costs.
There can be audit compromises to reduce costs. As a project manager, plan audits based on both the phases of the life cycle and the frequency of builds, versions, releases, and product families. Auditing each baseline in a project while reducing the depth of each audit maintains some traceability with loss of visibility.
Eliminating one or more audits (installation baseline, for example) maintains visibility but slightly impacts traceability.