Skip to content
This repository has been archived by the owner on Jul 22, 2020. It is now read-only.

Proxy client requests through unsee instance #190

Closed
tonobo opened this issue Nov 8, 2017 · 18 comments
Closed

Proxy client requests through unsee instance #190

tonobo opened this issue Nov 8, 2017 · 18 comments
Assignees
Milestone

Comments

@tonobo
Copy link

tonobo commented Nov 8, 2017

We've protected the alertmanager and unsee instances directly over the proxyserver.
But submitting silences will not work, because the the alertmanager is directly queried from client side.
Possibly is there any ability to proxy those requests through unsee instance to alertmanager.

@prymitive prymitive added this to the v0.9 milestone Nov 9, 2017
@prymitive
Copy link
Contributor

Similar to #182, need to start work on 0.9 release that should include a config file, since any additional complexity will be a bit tricky to express purely via ENV variables.

@prymitive prymitive self-assigned this Nov 9, 2017
@sylr
Copy link

sylr commented Nov 28, 2017

@prymitive As far as I'm concerned I would prefer that you implement this than what I proposed in #182.

Cheers.

prymitive added a commit that referenced this issue Dec 7, 2017
Fixes #190.

With this feature unsee can be configured to proxy requests to selected Alertmanager instances, if it's enabled unsee silence form will send a request via unsee rather than directly. This allows users to manage silences in environments where they have access to unsee but not to Alertmanager. Only silences endpoints on Alertmanager API are proxied.
@prymitive
Copy link
Contributor

#202 adds support for this feature, you can test it by building unsee from proxy branch and adding proxy: true to the Alertmanager instance config, example:

alertmanager:
  interval: 60s
  servers:
    - name: local
      uri: http://localhost:9093
      timeout: 10s
      proxy: true

prymitive added a commit that referenced this issue Dec 22, 2017
Fixes #190.

With this feature unsee can be configured to proxy requests to selected Alertmanager instances, if it's enabled unsee silence form will send a request via unsee rather than directly. This allows users to manage silences in environments where they have access to unsee but not to Alertmanager. Only silences endpoints on Alertmanager API are proxied.
prymitive added a commit that referenced this issue Dec 23, 2017
Fixes #190.

With this feature unsee can be configured to proxy requests to selected Alertmanager instances, if it's enabled unsee silence form will send a request via unsee rather than directly. This allows users to manage silences in environments where they have access to unsee but not to Alertmanager. Only silences endpoints on Alertmanager API are proxied.
prymitive added a commit that referenced this issue Jan 4, 2018
Fixes #190.

With this feature unsee can be configured to proxy requests to selected Alertmanager instances, if it's enabled unsee silence form will send a request via unsee rather than directly. This allows users to manage silences in environments where they have access to unsee but not to Alertmanager. Only silences endpoints on Alertmanager API are proxied.
@davidkarlsen
Copy link
Contributor

Is it possible to enable proxy through use of environment variables?

@prymitive
Copy link
Contributor

No, any setup that needs a fine tuned configuration requires a config file as it gets tricky to keep config parsing simple.
But by "fine tuned" I mostly mean multiple Alertmanager instances, for most people it's probably just one and that should be possible to configure fully with just envs. I could add and env that sets the proxy flag globally on.

@davidkarlsen
Copy link
Contributor

@prymitive It would be great if you could add that - love configuring it all through env vars (and yes, I only have one alert manager)

@prymitive
Copy link
Contributor

#214 should address that

@davidkarlsen
Copy link
Contributor

Awesome - thanks a lot!

@davidkarlsen
Copy link
Contributor

Do you have an ETA for the next release?

@prymitive
Copy link
Contributor

As soon as @terinjokes helps me with #207 and it's merged. I'll try to bribe him with some coffee today, so I think we can aim for next week.
We have auto build setup on https://hub.docker.com/r/cloudflare/unsee/tags/ so there's always master docker image if you want to try it today.

@davidkarlsen
Copy link
Contributor

Hm. I run 0.9.1 and have set the env var ALERTMANAGER_PROXY=true

docker inspect monitoring_unsee_1 |grep ALERTMANAGER_PROXY
                "ALERTMANAGER_PROXY=true",
[root@alp-aot-ccm02 ~]# 

Nevertheless I get:
Connection to the remote endpoint failed

when attempting to set a silence? (alerts are displaying fine, so it's not a connection err)

@tonobo
Copy link
Author

tonobo commented Jan 29, 2018

I use the new config format, this works great. I also pulled just a few hours ago, so the master is also working correctly with proxy option.

@prymitive
Copy link
Contributor

You should see log line like this when unsee starts

INFO[0000] [foo] Configured Alertmanager source at https://example.com (proxied: false) 
INFO[0000] [bar] Configured Alertmanager source at https://example.com (proxied: true) 

can you check if proxy is set there?

@davidkarlsen
Copy link
Contributor

davidkarlsen commented Jan 29, 2018

@prymitive not there:

Jan 29 17:56:40 alp-aot-ccm02 docker/2b4db6bcbb0a[17967]: time="2018-01-29T16:56:40Z" level=info msg="[default] Configured Alertmanager source at http://alertmanager:9093 (proxied: false)"
[et2448@alp-aot-ccm02 ~]$ 

@prymitive
Copy link
Contributor

I can't reproduce that with v0.9.1:

$ LOG_CONFIG=false ALERTMANAGER_PROXY=true ALERTMANAGER_URI=https://example.com ./unsee 
INFO[0000] Reading configuration file unsee.yaml        
INFO[0000] Using simple config with a single Alertmanager server 
INFO[0000] Version: v0.9.1                              
INFO[0000] [default] Configured Alertmanager source at https://example.com (proxied: true) 

Care to open a ticket for that with some steps to reproduce?

@davidkarlsen
Copy link
Contributor

Run the image like this (docker-compose format):

 unsee:
    image: cloudflare/unsee:v0.9.1
    restart: always
    environment: 
      - ALERTMANAGER_URIS=default:http://alertmanager:9093
      - WEB_PREFIX=/unsee/
      - SERVICE_CHECK_HTTP=/
      - ALERTMANAGER_PROXY=true
    depends_on:
     - alertmanager

@prymitive
Copy link
Contributor

That's the issue: ALERTMANAGER_URIS=default:http://alertmanager:9093
ALERTMANAGER_URIS still works for compatibility, but it's handled by legacy settings code and that one doesn't know about proxy.
Update your env to:

environment: 
      - ALERTMANAGER_URI=http://alertmanager:9093
      - WEB_PREFIX=/unsee/
      - SERVICE_CHECK_HTTP=/
      - ALERTMANAGER_PROXY=true

might want to add ALERTMANAGER_NAME=default but shouldn't be needed (can't remember what's the default name)

@davidkarlsen
Copy link
Contributor

Thanks a lot!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants