You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The proxy will utilize the same TLS based scheme as the official Prometheus agents. Customers existing SSH key(s) (the same key(s) used for accessing instances and sdc-docker) will be used.
The details of generating a TLS key from a Triton user's SSH key need further definition from @richardkiene.
Discovery
@richardkiene can add the details of discovery of RFD27 endpoints. It's possible that the best solution here is to develop a new Telegraf input plugin that integrates RFD27 endpoint discovery on top of the existing Prometheus input plugin.
The text was updated successfully, but these errors were encountered:
I don't want to get overly prescriptive about authenticated requests until I've worked out the kinks with Alex. However, the Prometheus TLS configuration section gives the basics. Also, I believe we can re-use the key and cert we generate for users when they setup sdc-docker access.
Discovery happens via CloudAPI and then knowledge of how the CNS CNAME is created (i.e. https://(container_uuid).cm.triton.zone:9163/metrics). There is a WIP Prometheus server plugin which handles discovery for the Prometheus server. Forwarders would need to follow this same pattern/logic.
RFD27/Container Monitor integration requires two things:
Authenticated requests
The details of generating a TLS key from a Triton user's SSH key need further definition from @richardkiene.
Discovery
@richardkiene can add the details of discovery of RFD27 endpoints. It's possible that the best solution here is to develop a new Telegraf input plugin that integrates RFD27 endpoint discovery on top of the existing Prometheus input plugin.
The text was updated successfully, but these errors were encountered: