継続的インテリジェンスレポート

さらに詳しく

Brien Posey

Brien Posey is a Fixate IO contributor, and a 15-time Microsoft MVP with over two decades of IT experience. Prior to going freelance, Brien was CIO for a national chain of hospitals and healthcare facilities. He also served as Lead Network Engineer for the United States Department of Defense at Fort Knox. Brien has also worked as a network administrator for some of the largest insurance companies in America. In addition to his continued work in IT, Brien has spent the last three years training as a Commercial Scientist-Astronaut Candidate for a mission to study polar mesospheric clouds from space.

投稿者 Brien Posey

ブログ

Graphite Monitoring for Windows Performance Metrics

For several years now, the tool of choice for collecting performance metrics in a Linux environment has been Graphite. While it is true that other monitoring tools, such as Grafana, have gained traction in the last several years, Graphite remains the go tool monitoring tool for countless organizations. But what about those organizations that run Windows, or a mixture of Windows and Linux? Because Graphite was designed for Linux, it is easy to assume that you will need a native Win32 tool for monitoring Windows systems. After all, the Windows operating system contains a built-in performance monitor, and there are countless supplementary performance monitoring tools available, such as Microsoft System Center. While using Graphite to monitor Linux systems and a different tool to monitor Windows is certainly an option, it probably isn’t the best option. After all, using two separate monitoring tools increases cost, as well as making life a little more difficult for the administrative staff. Fortunately, there is a way to use Graphite to monitor Windows systems. Bringing Graphite to Windows As you have probably already figured out, Graphite does not natively support the monitoring of Windows systems. However, you can use a tool from GitHub to bridge the gap between Windows and Graphite. In order to understand how Graphite monitoring for Windows works, you need to know a little bit about the Graphite architecture. Graphite uses a listener to listen for inbound monitoring data, which is then written to a database called Whisper. Graphite is designed to work with two different types of metrics—host metrics and application metrics. Host metrics (or server metrics) are compiled through a component called Collectd. Application metrics, on the other hand, are compiled through something called StatsD. In the Linux world, the use of Collectd and StatsD means that there is a very clear separation between host and application metrics. In the case of Windows however, Graphite monitoring is achieved through a tool called PerfTap. PerfTap does not as cleanly differentiate between host and application monitoring. Instead, the tool is designed to be compatible with StatsD listeners. Although StatsD is normally used for application monitoring, PerfTap can be used to monitor Windows operating system-level performance data, even in the absence of Collectd. The easy way of thinking of this is that StatsD is basically treating Windows as an application. As is the case with the native Windows Performance Monitor, PerfTap is based around the use of counters. These counters are grouped into five different categories, including: System Counters – Used for monitoring hardware components such as memory and CPU Dot Net Counters – Performance counters related to the .NET framework ASP Net Counters – Counters that can be used to track requests, sessions, worker processes, and errors for ASP.NET SQL Server Counters – Most of these counters are directly related to various aspects of Microsoft SQL Server, but there is a degree of overlap with the System Counters, as they relate to SQL Server. Web Service Counters – These counters are related to the native web services (IIS), and allow the monitoring of ISAPI extension requests, current connections, total method requests, and more. PerfTap allows monitoring to be enabled through the use of a relatively simple XML file. This XML file performs four main tasks. First, it sets the sampling interval. The second task performed by the XML file is to provide the location of the counter definition file. The XML file’s third task is to list the actual counters that need to be monitored. And finally, the XML file provides connectivity information to the Graphite server by listing the hostname, port number, prefix key, and format. You can find an example of the XML file here. Graphite and Sumo Logic Although Graphite can be a handy tool for analyzing performance metrics, Graphite unfortunately has trouble maintaining its efficiency as the organization’s operations scale. One possible solution to this problem is to bring your Graphite metrics into the Sumo Logic service. Sumo Logic provides a free video of a webinar in which they demonstrate their platform’s ability to natively ingest, index, and analyze Graphite data. You can find the video at: Bring your Graphite-compatible Metrics into Sumo Logic. Conclusion Although Graphite does not natively support the monitoring of Windows systems, you can use a third-party utility to send Windows monitoring data to a Graphite server. Of course, Graphite is known to have difficulty with monitoring larger environments, so adding Windows monitoring data to your existing Graphite deployment could complicate the management of monitoring data. One way of overcoming these scalability challenges is to bring your Graphite monitoring data into Sumo Logic for analysis.

ブログ

Biggest AWS Security Breaches of 2017

ブログ

Three Things You Didn’t Know About AWS Elastic Load Balancer

ブログ

Monitoring and Troubleshooting Using AWS CloudWatch Logs

AWS CloudWatch is a monitoring tool for the AWS platform. CloudWatch logs are an important resource for monitoring and helping to interpret the data in your AWS cloud. This article covers the essentials of working with AWS CloudWatch and CloudWatch Logs. What Can You Do with CloudWatch? As a tool, CloudWatch is quite versatile. IT Pros can use it for several different purposes, including tracking performance metrics, setting threshold alarms, and even taking automated action when a monitored resource exceeds a predetermined threshold. Monitor Amazon EC2 Instances One of the most common uses of AWS CloudWatch is for the monitoring of EC2 instances. The nice thing about this functionality is that it is enabled by default. AWS collects performance metrics from EC2 instances every five minutes, and stores those metrics for 15 months so that you can monitor performance changes over time. For instances that require more timely performance data, AWS does provide an option to collect performance data every minute. Doing so requires you to enable detailed monitoring for the instance, which is a simple process, but incurs an additional cost. Monitor Events Logged by CloudTrail AWS CloudWatch logs can do far more than simply monitor the performance of EC2 instances. You can also use CloudWatch to gather the events that have been monitored by AWS CloudTrail. For those who might not be familiar with CloudTrail, it is designed to be an auditing mechanism for AWS. As you are no doubt aware, AWS is made up of an extremely diverse collection of services. The one thing that all of these services have in common is that they are built around the use of APIs. Any time that you interact with an AWS service, an API is at work in the background. This holds true regardless of whether the service is accessed programmatically, through the AWS console, or through the AWS CLI. CloudTrail’s job is to capture a record of all API activity that occurs across an AWS account. A log of the activity is written to an S3 bucket, but it is also possible to deliver the logging data to CloudWatch. Kinesis Streams and AWS Lambda AWS Kinesis Streams are designed to help AWS subscribers to either process or analyze extremely high volumes of streaming data. A Kinesis stream can capture data from hundreds of thousands of sources simultaneously, and can process or analyze multiple terabytes of data every hour. Kinesis is often used in conjunction with AWS Lambda, which allows for the automatic processing of streaming data. Lambda is designed to log data through CloudWatch logs. Filtering and Searching AWS CloudWatch Logs AWS CloudWatch logs can accumulate vast amounts of data, so it is important to be able to filter the log data based on your needs. Filtering is achieved through the use of metric filters. Perhaps the most important thing to understand about metric filters is that they do not support retroactive filtering. Only events that have been logged since the time that the filter was created will be reported in the filtered results. Log entries that existed prior to the filter’s creation are not included in the filtered results. Creating a Metric Filter To create a metric filter, log into the AWS console, and choose the CloudWatch service. When the CloudWatch dashboard appears, click on the Logs option, and then click on the number of metric filters that is displayed within your log group. (The number of metric filters will initially be set at zero.) If no log groups exist, you will have to create a log group before continuing. Click the Add Metric Filter button, and you will be taken to a screen that asks you to specify a few different pieces of information. First, you will need to provide a filter pattern. A filter pattern specifies what the metric filter will look for within the log. (For instance, entering the word Error will cause the filter to look for occurrences of the word Error.) Next, you will need to select the log data that you plan to test. Once you have made your selection, click the Test Pattern button to make sure that the results are what you expect, and then click on the Assign Metric button. The resulting screen requires you to enter a filter name. The filter name is just a friendly name used to identify the metric filter within the log group. You will also need to specify a metric namespace. A metric namespace is nothing more than a group that contains related metrics. By default, AWS uses LogMetrics as the metric namespace name. Finally, you will have to specify a metric name. The metric name is the name of the CloudWatch metric where the log information will be published. AWS also gives you the optional ability to write a metric value to the log when a pattern match occurs. When you are done, click the Create Filter button, and the metric filter will be created. You can monitor your metrics from the CloudWatch Metrics dashboard.