I'm looking for practical monitoring advice for a public .NET e-commerce platform built with ASP.NET Core MVC, Angular, SQL Server, Elasticsearch with roughly 10 million products, RabbitMQ, and IIS. The system serves multiple public domains and receives substantial traffic from search crawlers and unknown bots.
We've found that CPU, memory, and disk usage alone don't explain every outage. We've had incidents where infrastructure looked healthy while requests were slow, the server was reachable but users experienced downtime, TCP exhaustion caused failures, Elasticsearch degraded search performance, bots generated excessive traffic, and slow application requests were difficult to identify.
I'm considering monitoring application metrics such as request rate, p50/p95/p99 latency, HTTP 4xx and 5xx rates, slow endpoints, exceptions, thread-pool starvation, garbage-collection pauses, runtime counters, and allocation rates. For IIS, I'm interested in connections, request queues, worker-process health, application-pool recycling, failed requests, and connection errors.
For the network, I'd like to track TCP connections, TIME_WAIT counts, connection failures, bandwidth, top clients, suspicious user agents, and possible connection-tracking limits. For Elasticsearch, useful signals may include cluster health, JVM memory pressure, heap usage, search latency, query failures, slow queries, unassigned shards, and disk capacity. SQL Server monitoring could include blocking, deadlocks, query duration, connection-pool utilization, wait statistics, and resource usage. RabbitMQ should probably include queue depth, consumer counts, processing time, dead-letter messages, and memory usage.
I'd also like to detect suspicious paths such as /.env, /.git, and wp-admin, along with bot volume, high-frequency clients, and rate-limit violations.
If you operated a system like this, which dashboards and alerts would you consider mandatory? Which metrics turned out to be especially valuable only after a production incident? I'm most interested in practical experience and alerting processes that avoid creating excessive noise.
4 Answers
The right network and infrastructure checks depend heavily on whether this is on-premises or cloud-hosted. In a cloud environment, also watch load-balancer health, connection limits, network throughput, and storage-specific limits such as burst balance or IOPS. Configure the load balancer deliberately for failure behavior—decide whether it should fail open or fail closed—and shed load when the application is unhealthy instead of allowing queues to grow indefinitely.
For a public service, I’d also separate normal crawler traffic from abusive or malfunctioning bots. Monitor request volume by client, user agent, route, and status code, then apply rate limits or filtering before that traffic reaches the application. This is especially useful for expensive search endpoints, where a small number of clients can consume a large share of Elasticsearch capacity.
Start with external synthetic checks and the signals that represent user impact: request rate, latency percentiles, 4xx/5xx rates, failed health checks, and load-balancer response time. Then add the basic host and dependency metrics such as disk throughput and IOPS, database resource usage, process health, and connection counts.
If those look normal while the application is still failing, the next step is usually application logs and tracing rather than adding more generic infrastructure alerts. Track which endpoints are slow, correlate requests across SQL Server, Elasticsearch, and RabbitMQ, and keep enough structured context to identify the failing dependency. Alerts should be tied to service-level objectives where possible, otherwise they quickly become noise.
The operational process matters just as much as the dashboard: perform a root-cause review after every incident, test fixes in staging, deploy them consistently through infrastructure-as-code or an equivalent process, and document the result in a troubleshooting guide.
Don’t overlook connection-tracking and socket limits. Linux exposes these through conntrack, and Windows has comparable TCP and networking counters. Track active connections, ephemeral-port usage, failed connection attempts, and TIME_WAIT growth. A server can have plenty of CPU and RAM left but still be unable to accept new connections because a network or port limit has been reached.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures