New Relic Now+ New Relic’s most transformative platform update yet with 20+ product launches.
Watch the event on-demand now.
현재 이 페이지는 영어로만 제공됩니다.

How do you ensure your web server is running smoothly when faced with security threats or unexpected slowdowns? With IIS, the solution may already be inside your log files. Internet Information Services (IIS) is a Microsoft Windows web server platform, like Apache or Nginx. Like all professional applications, IIS produces log files that document events in IIS. And like all log files, they are rich with data, including:  

  • Time and date of the event
  • Who made the request, both IP address and authenticated user (if any)
  • Particular page requested and query made
  • What agent was used  
  • Status and error codes (if any)
  • Response time

IIS logs are the go-to source that allow developers and system administrators to solve problems, optimize the user experience (UX), and monitor activities in near real-time on a  web property. These logs help them to:

Identify issues

  • Identify security breaches, distributed denial of service (DDoS) attacks, and other issues

Improve performance

  • Track response times
  • Reduce bottlenecks
  • Increase throughput
  • Locate slow SQL queries

Troubleshoot with log analysis tools

  • Identify patterns
  • Visualize to gain insight
  • Streamline data analysis

While IIS logs provide rich data, navigating them to identify specific problems can be difficult and time-consuming. Analysis tools, like New Relic’s .NET agent IIS monitoring tool, help accelerate time to determine and solve problems.

What are IIS logs and why are they important?

IIS logs are text files saved in a particular format. Administrators can choose the format, such as W3C or NCSA, using the IIS Manager application. Administrators can also select which data will be logged. The type of data saved determines the detail and complexity of the log. The more data that’s logged, the more insight administrators and developers can have at-hand.  

Logs are the go-to resource for administrators, a key resource for developers, and the main diagnostic source for understanding web property performance. These logs—especially when combined with other logs—allow teams to proactively manage issues before they escalate, improving both system performance and the UX.

Web properties are often distributed across multiple servers, which means there are multiple IIS logs across those servers. Other logs—such as network, security, and authentication logs—can contain information critical to understanding issues and web property performance. With so many log files scattered across multiple properties, analysis can quickly become complex, making it essential to have a reliable IIS monitoring tool to simplify log analysis.

IIS application monitoring

An IIS monitoring tool collects log data and measures web server performance from logged data. It provides real-time insights, helps troubleshoot potential issues, and assists with optimizing web server performance.

Other server operations and applications run alongside an IIS service. A single server typically runs these processes simultaneously, each logging data relevant to its activities. IIS and other service metrics are key to monitoring and tracking the server’s health. Here are some key resource metrics for monitoring IIS applications and server performance:

  •  Site performance
    • Availability
    • Connection
    • Response times
    • Byte transfer
  • Application resources
  • Application performance
    • Response times
    • Database transactions
    • Errors and exceptions

IIS server monitoring

IIS application monitoring and IIS server monitoring go hand-in-hand. An IIS service and its server run simultaneous processes with their own logging systems. Tracking IIS server metrics is critical to avoid server downtime. Related resource metrics include resource consumption (for example, memory and storage), application pool statistics, and response times for various resources (for example, networking).

IIS log formats

IIS logs are text files saved in a particular format. Administrators can choose the format, such as W3C or NCSA, and the properties logged using the IIS Manager application. IIS Manager allows administrators to configure websites distributed across multiple environments. The default location for IIS log files is <disk root directory>\inetpub\logs\Logfiles. However, any location can be specified using IIS Manager. IIS log formats include:

  •  IIS
  • W3C Extended
  • NCSA
  • Custom

IIS

IIS format is an ASCII format that cannot be customized, such as W3C, but IIS format records more information than NCSA. IIS format includes basic items, such as the user's IP address, username, and number of bytes received, but it also includes additional details. The items are separated by commas and the time is recorded as local time. Here’s an example of some IIS log lines: 

192.168.114.201, -, 03/20/01, 7:55:20, W3SVC2, SALES1, 172.21.13.45, 4502, 163, 3223, 200, 0, GET, /DeptLogo.gif, -,
172.16.255.255, anonymous, 03/20/01, 23:58:11, MSFTPSVC, SALES1, 172.16.255.255, 60, 275, 0, 0, 0, PASS, /Intro.htm, -, 

W3C Extended format

This is a customizable ASCII format with a variety of data. You can log properties that are most relevant to your needs and remove unwanted fields to limit log size. Spaces separate logged properties. Time is recorded as UTC (Greenwich Mean Time). Here’s an example of some NCSA log lines. Note that the lines preceded by “#” are comments.

#Software: Internet Information Services 6.0
#Version: 1.0
#Date: 2001-05-02 17:42:15
#Fields: time c-ip cs-method cs-uri-stem sc-status cs-version
17:42:15 172.16.255.255 GET /default.htm 200 HTTP/1.0

NCSA Common format

The National Center for Supercomputing Applications (NCSA) Common format is an ASCII format that cannot be customized. The NCSA format records basic information, including remote host name, username, date, time, request type, and more. Spaces separate logged properties, and time is recorded as local time.

172.21.13.45 - Microsoft\fred [08/Apr/2001:17:39:04 -0800] "GET /scripts/iisadmin/ism.dll?http/serv HTTP/1.0" 200 3401

What information is in an IIS log?

IIS logs are rich with data. They contain information about requests made to a server, including the date and time the request was made, client IP address, user name (if authenticated), requested URL, and HTTP method/type of request. 

For example, here are the opening log lines of a new website set up with IIS on a local Windows host, queried by the same host. The file format is W3C Extended.

#Software: Microsoft Internet Information Services 10.0
#Version: 1.0
#Date: 2024-12-10 18:00:54
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
2024-12-10 18:00:54 ::1 GET / - 80 - ::1  Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/128.0.0.0+Safari/537.36+OPR/114.0.0.0 - 200 0 0 557
2024-12-10 18:00:54 ::1 GET /iisstart.png - 80 - ::1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/128.0.0.0+Safari/537.36+OPR/114.0.0.0 http://localhost/ 200 0 0 12
2024-12-10 18:00:54 ::1 GET /favicon.ico - 80 - ::1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/128.0.0.0+Safari/537.36+OPR/114.0.0.0 http://localhost/ 404 0 2 2

The above example log is from a localhost IIS server and a request made by the same localhost. The lines preceded by # are commented lines identifying the IIS version, time and date of the configuration, and the fields that are saved in the log. 

The following chart offers a description for the different items found in the first log line of the above list.

 

Field Name Example Description
Date 2024-12-10 The date the event happened and was logged.
Time 18:00:54 The time the event happened and was logged.
s-ip ::1 The server's IP address. The example is in IPv6 for the localhost. For IPv4, it would be 127.0.0.1.
cs-method GET The HTTP method for requestiong a web page.
cs-uri-stem / What file is being requesting. "/" is the root file in the website (i.e., the homepage).
cd-uri-query - The code used to query something on the page. There was no query in this example.
s-port 80 The port used for the request. 80 is the non-encrypted, default HTTP port. If it was an encrypted request, the port would likely be 443, unless the administrator specified a different port.
cs-username - The authenticated user name. In this case, there is no authenticated user.
c-ip ::1 The requester's IP address. The example is in IPv6 for the localhost. For IPv4, it would be 127.0.0.1.
cs (user-Agent) Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/128.0.0.0+Safari/537.36+OPR/114.0.0.0 The agent the requester is using for the web content. The string includes information about the browser, rendering engine, and platform.
cs (Referrer) - There is no referrer in this case. If there was, a URL would appear here, such as www.xyzabc.com.
sc-status 200 The HTTP status for the request. In this case, the request was successful. In a later log line, a 404 error was returned, indicating a requester error for a page not found. You can find more information on status and sub-status codes here.
sc-substatus 0 The HTTP sub status of the response. In this case, the sub status is 0. You can find more information on status and sub-status codes here.
sc-win32-status 0 The Windows error code, if returned. You can learn more about these codes here. You can also find out more by using PowerShell and entering “net helpmsg Win32_Status_Code”, where Win32_Status_Code is the specific error code returned in the log. In a later log line with a 404 HTTP status, the request returned a Win32 status code of 2, which means “The system cannot find the file specified.”
time-taken 557 The time, in milliseconds, taken to return the requested content. 557 milliseconds in this case.

Each property can be useful for troubleshooting problems or optimizing the site. For instance: 

  • Date/time: This allows the administrator to pinpoint when reported problems occurred. A search limiting only selected dates allows zooming in on events during that period. Filtering by date and time also allows correlation across different logs, such as network logs, which might impact performance.
  • Server’s IP and port: With distributed sites in enterprise web systems, problems on specific servers can be filtered out of the logs. If the user tried to access an encrypted site with an unencrypted port (80), the log would show the user’s mistake, eliminating time an administrator might spend trying to identify a problem that was a user error.
  • Method, stem, and query: These allow the administrator to check that the request was made correctly or identify an issue with the query.
  • Username, IP, and agent: These properties help pinpoint issues to a particular user, the machine, and browser being used to access the content. These are useful to possibly geolocate the user, verify an authentication problem, or determine if an incompatible browser was used.
  • Bytes sent and received and time taken: These, along with network logs, can help assess bandwidth issues and requirements or track suspicious behaviors.
  • Status and error codes: These point to specific problems encountered (or successes) during the transaction and help identify if problems occur in the OS or the site.
  • Referrer: This can be useful to help customize site content.

Challenges of analyzing IIS logs

One of the biggest challenges of analyzing IIS logs—or any log—is the sheer amount of data presented in a somewhat cryptic text format. Traditionally, analyzing logs uses text filtering and searching tools to pinpoint when a problem occurred and what might have caused it.

However, IIS logs alone don’t always tell the whole story of why an issue with a website occurred. Network issues are reported in network logs. Authentication and security issues are reported in individual logs and they can be distributed across multiple servers or even physical sites. In modern web properties, the complexity of traditional log analysis can quickly escalate due to distributed systems and the impact of other system services on websites.

Modern log analysis tools, such as New Relic’s .NET agent IIS monitoring tool, centralize your IIS logs and other service data (such as network and authentication logs) into a single resource. Whether you’re troubleshooting or optimizing systems, the New Relic IIS monitoring tool interprets the data and provides visualizations and easy-to-understand information to help identify problems quickly.

What are the benefits of using IIS log analysis tools?

IIS logs—and other logs—provide essential data needed to isolate and solve problems, as well as improve system efficiency and customer experiences. 

The New Relic IIS monitoring tool makes it quicker and easier to understand the data in IIS (and other) logs. This solution helps teams stay proactive by offering real-time data, alerting, and visualization features, giving you the information needed to solve problems faster and improve site performance and customer experiences more efficiently.

Additionally, the New Relic IIS monitoring tool provides multiple dashboards, bringing decentralized data together into a single resource. Interactive visualizations let you easily explore your data, understand context, and resolve problems quickly. Dashboards and alerts track essential metrics like Application Performance Index (Apdex) score, memory usage, and transaction errors, simplifying performance monitoring and detecting issues before they affect users.

Interactive visualizations for faster insights

The New Relic .NET agent IIS monitoring tool parses log data and builds interactive visualizations for fast insight into your web properties’ performance. Real-time alerts let you know when issues arise. Graphs and charts simplify the complexity of all data contained in logs to reveal critical insights.

These interactive visualizations allow teams to quickly explore and understand trends in their IIS log data. Easy-to-read charts show the most popular incoming requests, helping you identify content interests and needs. Slowest response time, transaction time, and memory usage reveal how your system is performing across your pipeline.

Monitoring Apdex scores for performance optimization in real time

Apdex is an industry standard used to measure users’ satisfaction with the response time of web applications and services. An Apdex score helps you quantify how satisfied users are with your app. This score is a number between 0 and 1 (1 being the best score). It serves as a ratio of the number of “satisfied” and “tolerating” requests to the total requests made using a response time threshold you set (such as 500 ms).

The New Relic IIS monitoring tool provides real-time assessment of Apdex scores, alerting administrators of less-than-acceptable performance when the Apdex score dips at or below 0.5 for more than five minutes. This short timeframe helps ensure teams can quickly address user issues to maintain a high user satisfaction.

Learn more about Apdex scoring

Detecting transaction errors 

Transaction errors, top five slowest transactions, slowest average response time, and web transaction time are critically important metrics for understanding both web performance and its impact on user satisfaction. With the New Relic IIS monitoring tool, a transaction alert is triggered when transactions fail more than 10 percent of the time in five minutes. This real-time alerting of transaction throughput helps teams quickly detect and troubleshoot issues.

Simplifying IIS setup with installation documentation

New Relic’s step-by-step documentation makes it fast and easy to start analyzing IIS logs. New Relic provides an application performance monitoring (APM) agent for the .NET environment that accelerates your introduction to IIS log analysis on the New Relic Intelligent Observability Platform

Learn more about .NET monitoring and installation.

Boost IIS performance with New Relic

New Relic Intelligent Observability takes the complexity out of performance monitoring, maintaining, troubleshooting, securing, and optimizing of IIS sites. The New Relic IIS monitoring tool helps teams perform a more efficient analysis with log centralization, visualization, and real-time alerts for monitoring IIS performance. Combined with other resources in the New Relic platform, administrators have a comprehensive suite of tools applicable across a fleet of servers, operating environments, and services.