Report to different AppSignal apps using namespaces #17
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
To allow for different API keys per namespace, we can't memoize the metrics URL like we did before. In preparation for this, this patch moves the call to must_metrics_url_from_env to evaluate just in time.
In preparation of namespaced data, replace the existing HashSet with a HashMap, which will hold a key per namespace. For now, place all data under the "default" namespace. Then, loop over each namespace in the out variable when sending metrics to AppSignal, and send all matrics for one namespace as one request.
Update the must_metrics_url_from_env function to take a namespace as an argument, in preparation for having multiple API keys. For now, always return the URL with the default API key.
To allow for selecting a different key for a different namespace, this patch adds another environment variable that has a list namespaces and API keys. If one matches, api_key_for_namespace returns the associated key instead of the default.
Instead of hardcoding the namespace to "default", use the pod's actual namespace when looking up the metric URL.
In the deployment, get the value from the namespace-api-key-map secret and configure it as the APPSIGNAL_NAMESPACE_API_KEY_MAP.
To allow for testing the namespaced API keys, suffix the version number so an image can be pushed without having to do a proper release.
This is a branch separate from the rest of the integration, so any releases shouldn't be tagged as latest.
This comment has been minimized.
This comment has been minimized.
1 similar comment
This is a message from the daily scheduled checks. |
|
I'm keeping this as a branch for now. Although this approach works well for the current version of the Kubernetes integration, we're not sure how it'll work with the upcoming version that's on the horizon. To make sure we're not introducing a feature that we have to pull later, we'll refrain from releasing hit until we know more. I'll be sure to keep the namespace-keys branch updated. Please let us know if you're using it, so we can gauge interest for this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a work-in-progress patch to test support for reporting to multiple apps through using Kubernetes namespaces. By setting the
APPSIGNAL_NAMESPACE_API_KEY_MAPenvironment variable to hold a frontend key per namespace (namespace1=123abc,namespace2=abc123), any node metrics for that specific namespace get posted to a different app in AppSignal. All non-node metrics, as well as metrics for namespaces not listed in the new environment variable, are pushed to the default app configured through theAPPSIGNAL_API_KEYenvironment variable.Closes #16.