Whats New In 2.2.0 - Web Server Monitoring

Via Microsoft IIS Administration API 2.2.0

If you are unfamiliar with the API, check out our earlier post for an introduction.

The IIS team has been working on making the IIS Administration API more than just a tool for configuring IIS. The latest release enables users to collect web server health and performance data that is integral to keeping web servers running. This new data source opens up possibilities for IIS data reporting, management suite integration, and live monitoring systems. 

Health and Performance Monitoring

An important aspect of running a web server is being able to measure whether the server is healthy, and this requires collecting a wide array of data. In the 2.2.0 release of the IIS Administration API, monitoring endpoints have been added that provide the data necessary to ensure that the web server is performing as expected. These new endpoints provide metrics that are considered the most relevant for web servers including network, cpu, memory, disk, and HTTP requests. Data can be retrieved for the web server as a whole or individually for web sites and application pools. With these new endpoints the IIS Administration API can serve the dual purpose of configuration and monitoring.

The data from the monitoring endpoints is focused on the web server rather than the entire machine. For instance, the web server endpoint returns the number of web server processes running on the machine, but it does not include any unrelated processes. This means web server administrators can measure resource usage that comes solely from the web server.

Documentation for these new endpoints is available at https://docs.microsoft.com/en-us/IIS-Administration/api/monitoring.

Web Server Monitoring (/api/webserver/monitoring)

The web server monitoring resource has fields that represent different categories of performance data including network, HTTP requests, memory, CPU, disk, and web server cache. This endpoint can be polled on a one second interval to obtain live aggregated usage data of the web server. 

The snippet below is an example of the webserver monitoring resource.

{
    "id": "{id}",
    "network": {
        "bytes_sent_sec": "1201162",
        "bytes_recv_sec": "278429",
        "connection_attempts_sec": "0",
        "total_bytes_sent": "7722036030",
        "total_bytes_recv": "1789971361",
        "total_connection_attempts": "99",
        "current_connections": "99"
    },
    "requests": {
        "active": "0",
        "per_sec": "2870",
        "total": "18453312"
    },
    "memory": {
        "handles": "35343",
        "private_bytes": "721608704",
        "private_working_set": "614633472",
        "system_in_use": "3359817728",
        "installed": "10642575360"
    },
    "cpu": {
        "threads": "2382",
        "processes": "99",
        "percent_usage": "3",
        "system_percent_usage": "31"
    },
    "disk": {
        "io_write_operations_sec": "0",
        "io_read_operations_sec": "0",
        "page_faults_sec": "0"
    },
    "cache": {
        "file_cache_count": "198",
        "file_cache_memory_usage": "1962",
        "file_cache_hits": "36906658",
        "file_cache_misses": "55360241",
        "total_files_cached": "199",
        "output_cache_count": "0",
        "output_cache_memory_usage": "0",
        "output_cache_hits": "0",
        "output_cache_misses": "36906759",
        "uri_cache_count": "198",
        "uri_cache_hits": "36906359",
        "uri_cache_misses": "400",
        "total_uris_cached": "200"
    }
}

Web Site Monitoring (/api/webserver/websites/monitoring/{id})


The web site monitoring endpoint provides data for individual web sites. This is useful for drilling in and seeing how each web site is contributing to the total usage of the web server. Specifying the id of a web site in the URL limits the API's response to the web site with that id, however if no id is specified the endpoint can be used to query all web sites at once.

Note: Some performance data obtained from the web site endpoint may not be accurate if more than one web site is configured to run in the same application pool.

The API also exposes application pool monitoring data that is available from the /api/webserver/application-pools/monitoring/{id} endpoint. This resources behaves in the same manner as the web site monitoring resource.

Monitoring UI

Along with the introduction of monitoring endpoints, the web management tool at https://manage.iis.net has been updated to provide a live monitoring experience.

9 Comments

  • Great update, but the upgrade script needs some work:

    1. 2.1.0 ran off netcore 1.0.5, and this one installed 1.0.7. Add logic to uninstall old netcore versions.
    2. It doesn't respect the existing port or SSL certificate, and creates a new port + SSL binding, relevant logs: https://pastebin.com/raw/QC8cJNLP

  • Also, interestingly, it also changed my 55539 binding. It changed the SSL cert to the generated one. So, by the end of the install, there's a 55539 and 55540 binding.

  • @EZ

    Thanks for the feedback.

    Regarding #1: You are right that we left behind the 1.0.5 runtime. We did not remove it on upgrade as we could not be sure that there were not others on the system depending on exactly that version. We have a change that we are going to implement in our next release of the installer that will check for any existing .NET Core 1.0.* version that we are compatible with and use it if it exists. So this shouldn't happen again.

    For #2: The upgrade creates a temporary side by side installation and confirms that the service has been installed correctly. It then migrates this new service to use the previously used binding (55539) and application settings and removes the old service. If the new binding is sticking around after the upgrade then that certainly could be cleaned up. In the end the new service should be using the same port as the old despite the fact it was originally created on a temporary port.

    Regarding the fact that your binding stayed on the temporary upgrade port (55540), that looks like a bug. Was the previous installation done through the MSI?

    We haven't reproduced this issue. Have you done anything special to your installation such as using a custom port or a custom certificate for the service?

    Assuming the 55539 cert binding is still around you should be able to go into the appsettings.json file and change the "urls" property to "https://*:55539"

  • @jimmyca Thanks for the reply.

    The very first install on this server was 2.1.0, installed via msi. I made a few changes to the json setting files, and those were migrated over without issue.
    I did indeed replace the SSL cert with my own in 2.1.0. I left the port 55539, though. Upon upgrading, there are 2 bindings - 55539 and 55540, both with the SSL cert that the installer generated, and not mine. Interestingly, 55539 still worked fine after the upgrade. I did not notice the bug until I reviewed everything and noticed the new SSL certificate in my store.

    I also do not have a "urls" property in my appsettings.json.

  • @EZ

    If there is no "urls" property in the appsettings.json then the service must be running on the default 55539 port in which case the upgrade succeeded and your cert is still in use. The issue here would be that the 55540 binding is still sticking around. I'll look into the script and make sure we don't leave around a binding on 55540.

    Thanks for the feedback. Let us know if there's anything else.

  • @jimmyca The upgrade succeeded, but no, my cert was NOT still in use. It looks like the 55539 binding was recreated with the generated cert, in addition to adding a new 55540. I can tell because there's another thing. The cert store name was set to "MY", but I corrected it after setting up 2.1.0 to "My" (lowercase y) to be consistent with the other bindings netsh showed. Upgrading to 2.2.0 changed that back to "MY", so the upgrade definitely tampered with it. That's another thing you should maybe change - MY to My, since that's what other bindings display.

    I can probably give you instructions how to reproduce if you can't find the issue. Let me know.

  • @EZ

    Thanks for clarifying that the 55539 binding used the newly generated cert. That shouldn't happen and we will get it fixed.

    The "MY" to "My" change isn't so clear cut. Not all bindings use "My" in fact, all the bindings on my current machine use "MY".

  • Great

  • Web Platform Installer anytime soon?

    msi for general consumption for non VS users?

    Can someone upload an msi and post link here so I can play with this on win10 pro 64bit. Thanks

Comments have been disabled for this content.