Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify promtail config #1012

Closed
rfratto opened this issue Sep 12, 2019 · 1 comment
Closed

Simplify promtail config #1012

rfratto opened this issue Sep 12, 2019 · 1 comment
Labels
stale A stale issue or PR that will automatically be closed. type/enhancement Something existing could be improved

Comments

@rfratto
Copy link
Member

rfratto commented Sep 12, 2019

Today, the promtail config that is exposed to the user requires knowledge about how Prometheus is configured. This is due to the fact that promtail's service discovery uses the same service discovery code as Prometheus.

While this is good for code re-use, it doesn't account for how the Prometheus service discovery can discover other machines, while promtail only supports reading from the current host. This leaves filtering out the other machines as an exercise to the operator in the relabel_configs section of the scrape_config.

The following would make it easier to configure promtail and understand:

  1. Expose only the subset of service discovery methods that work with Promtail. static_config, kubernetes_sd_config, and file_sd_config are the only service discovery mechanisms that I believe work today.
  2. When appropriate (i.e., kubernetes_sd_config), wrap the underlying Prometheus service discovery mechanism with a filter to remove any node that is not the same host that promtail is running on.

This should be implemented in a backwards-compatible way: any existing relabel_config that adds the __host__ label to the Kubernetes SD discovery should continue to work.

I'm not aware of any at the moment, but other boilerplate that all users need to do for kubernetes_sd_config to work should be abstracted out and removed as a requirement.

Related to #820.

@rfratto rfratto added type/enhancement Something existing could be improved keepalive An issue or PR that will be kept alive and never marked as stale. labels Sep 12, 2019
@slim-bean slim-bean removed the keepalive An issue or PR that will be kept alive and never marked as stale. label Feb 28, 2020
@stale
Copy link

stale bot commented Mar 29, 2020

This issue has been automatically marked as stale because it has not had any activity in the past 30 days. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale A stale issue or PR that will automatically be closed. label Mar 29, 2020
@stale stale bot closed this as completed Apr 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale A stale issue or PR that will automatically be closed. type/enhancement Something existing could be improved
Projects
None yet
Development

No branches or pull requests

2 participants