custom client option

[chou-godaddy]

Add CustomClient option to PushOptions

Problem

When pushing metrics to a VictoriaMetrics Instance that requires mutual TLS authentication with client certificates, the current implementation doesn't allow customizing the HTTP client used for requests. This creates a dilemma:

1. Modify the global HTTP DefaultTransport (affecting all HTTP clients in the application)
2. Create a custom metrics pusher implementation

Solution

Add a CustomClient field to the PushOptions struct that allows specifying a custom HTTP client. This enables users to configure TLS settings specifically for metrics pushing without affecting other parts of the application.

Why Not Use vmauth or Traefik?

While vmauth and Traefik are excellent solutions for many scenarios, there are specific use cases where a custom client approach provides significant advantages:

1. Cross-cloud deployments: When the metrics client is in one cloud provider and the VictoriaMetrics server is in another, setting up an additional proxy layer introduces unnecessary complexity and potential points of failure.

2. Network complexity: Cross-cloud communications typically traverse public internet, making embedded TLS configuration simpler and more secure than exposing and securing additional proxy services.

3. Operational simplicity: For many users, configuring the client directly eliminates the need to deploy, manage, and secure additional infrastructure components.

This implementation provides flexibility for users to choose the approach that best fits their specific infrastructure and security requirements.

Use Case

This is particularly useful in multi-cloud environments where metrics need to be pushed between services in different clouds requiring mutual TLS authentication. For example:

• Pushing metrics from services in one cloud provider to a VictoriaMetrics instance in another cloud
• Using client certificates for authentication between environments
• Configuring specific timeouts or connection parameters for metrics pushing

Changes

• Added CustomClient *http.Client field to PushOptions struct
• Modified newPushContext to use the provided client or create a default one
• Added tests to verify the custom client is used correctly with TLS configuration

The implementation maintains backward compatibility with all existing code.

Fixes #88

[Copilot]

Pull Request Overview

This PR adds a CustomClient field to the PushOptions struct to enable users to specify a custom HTTP client for metric pushing. This addresses the need for mutual TLS authentication with client certificates when pushing metrics to VictoriaMetrics instances without modifying the global HTTP DefaultTransport.

• Added CustomClient *http.Client field to PushOptions struct for custom HTTP client configuration
• Modified the client creation logic in newPushContext to use the provided custom client or fall back to default
• Added comprehensive test coverage to verify custom client functionality with TLS configurations

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
push.go	Adds CustomClient field to PushOptions and modifies newPushContext to use custom or default client
push_test.go	Adds test coverage for custom client functionality with TLS configuration scenarios

Comments suppressed due to low confidence (1)

push_test.go:290

• The test relies on string matching to verify TLS-related errors, which is brittle. Consider using error type assertions or wrapping errors to make the test more robust and specific.

	// Verify the error is TLS-related

[Copilot]

[nitpick] The comment should use 'certificates' instead of 'cert' for proper grammar.

Suggested change

	// Create a TLS configuration that accepts self-signed cert
	// Create a TLS configuration that accepts self-signed certificate

[f41gh7]

I think, it's more clear to name it just as Client and add a comment, that it's optional http client for making push requests.