Problem

Fixes #978

The nginx_up metric currently indicates whether the last scrape was successful, not whether NGINX is actually up. This creates confusion for users who expect nginx_up=0 to mean NGINX is down, when it could just mean the scrape failed for other reasons (HTTP errors, parsing issues, etc.).

Solution

This PR introduces a clear separation between NGINX availability and scrape success for NGINX Open Source:

New Metrics Added:

• nginx_scrape_success - Indicates whether the last scrape was successful (1) or not (0)
• nginx_scrape_duration_seconds - Duration of the last scrape in seconds
• nginx_scrape_errors_total{type="..."} - Counter of scrape errors by type (network/http/parse)

Behavior Changes:

• nginx_up=1 - NGINX is reachable (even if scrape fails due to HTTP errors)
• nginx_up=0 - Only when NGINX is truly unreachable (network errors)
• nginx_scrape_success=0 - When scrape fails for any reason

Error Type Classification:

• network - Connection refused, timeouts, etc. (nginx_up=0)
• http - HTTP errors like 404, 500, etc. (nginx_up=1)
• parse - Response parsing errors (nginx_up=1)

Scope

⚠️ This fix applies only to NGINX Open Source collector. NGINX Plus collector remains unchanged. A separate issue can address NGINX Plus if needed.

Testing

• Added comprehensive unit tests for error classification logic
• Tested with various scenarios:
  • Normal operation (nginx_up=1, scrape_success=1)
  • HTTP errors (nginx_up=1, scrape_success=0)
  • Network errors (nginx_up=0, scrape_success=0)

Backward Compatibility

The existing nginx_up metric is preserved but now correctly represents NGINX availability rather than scrape success.