github/karma
1
0
Fork 0
mirror of https://github.com/prymitive/karma synced 2026-05-07 03:26:52 +00:00
Code Issues Packages Projects Releases Wiki Activity

Move configuration related docs to a dedicated file and rewrite those to match new config file.

Browse Source
This commit is contained in:
Łukasz Mierzwa
2017-11-27 21:30:46 -08:00
parent a2fe18e71c
commit 5f904ec99d
8 changed files with 488 additions and 338 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
Makefile
View File

@@ -3,7 +3,7 @@ VERSION := $(shell git describe --tags --always --dirty='-dev')
# Alertmanager instance used when running locally, points to mock data
MOCK_PATH := $(CURDIR)/internal/mock/0.11.0
ALERTMANAGER_URIS := "mock:file://$(MOCK_PATH)"
ALERTMANAGER_URI := "file://$(MOCK_PATH)"
# Listen port when running locally
PORT := 8080
@@ -62,7 +62,7 @@ clean:
.PHONY: run
run: $(NAME)
ALERTMANAGER_URIS=$(ALERTMANAGER_URIS) \
ALERTMANAGER_URI=$(ALERTMANAGER_URI) \
COLOR_LABELS_UNIQUE="@receiver instance cluster" \
COLOR_LABELS_STATIC="job" \
DEBUG="$(GIN_DEBUG)" \
@@ -81,7 +81,7 @@ run-docker: docker-image
--name $(NAME) \
$(DOCKER_ARGS) \
-v $(MOCK_PATH):$(MOCK_PATH) \
-e ALERTMANAGER_URIS=$(ALERTMANAGER_URIS) \
-e ALERTMANAGER_URI=$(ALERTMANAGER_URI) \
-e COLOR_LABELS_UNIQUE="instance cluster" \
-e COLOR_LABELS_STATIC="job" \
-e DEBUG="$(GIN_DEBUG)" \

345
README.md
View File

@@ -40,7 +40,7 @@ If you wish to deploy unsee as a read-only tool please ensure that:
## Metrics
unsee process metrics are accessible under `/metrics` path by default.
If you set the [WEB_PREFIX](#web_prefix) option a path relative to it will be
If you set the `--listen.prefix` option a path relative to it will be
used.
## Building and running
@@ -62,23 +62,25 @@ container.
## Running
`unsee` is configured via environment variables or command line flags.
Environment variable `ALERTMANAGER_URIS` or cli flag `-alertmanager.uris` is the
only option required to run. See [Environment variables](#environment-variables)
section below for the full list of supported environment variables. Examples:
`unsee` can be configured using config file, command line flags or environment
variables. Config file is the recommended method, it's also the only way to
configure unsee to use multiple Alertmanager servers for collecting alerts.
To run unsee with a single Alertmanager server set `ALERTMANAGER_URI`
environment variable or pass `--alertmanger.uri` flag on the command line, with
Alertmanager URI as argument, example:
ALERTMANAGER_URIS=default:https://alertmanager.example.com unsee
unsee -alertmanager.uris default:https://alertmanager.example.com
ALERTMANAGER_URI=https://alertmanager.example.com unsee
unsee --alertmanager.uri https://alertmanager.example.com
There is a make target which will compile and run unsee:
make run
By default it will listen on port `8080` and Alertmanager mock data will be
used, to override Alertmanager URI set `ALERTMANAGER_URIS` and/or `PORT` make
used, to override Alertmanager URI set `ALERTMANAGER_URI` and/or `PORT` make
variables. Example:
make PORT=5000 ALERTMANAGER_URIS=default:https://alertmanager.example.com run
make PORT=5000 ALERTMANAGER_URI=https://alertmanager.example.com run
## Docker
@@ -96,14 +98,14 @@ Images are built automatically for:
To start a release image run:
docker run -e ALERTMANAGER_URIS=default:https://alertmanager.example.com cloudflare/unsee:vX.Y.Z
docker run -e ALERTMANAGER_URI=https://alertmanager.example.com cloudflare/unsee:vX.Y.Z
Latest release details can be found on
[GitHub](https://github.com/cloudflare/unsee/releases).
To start docker image build from lastet master branch run:
docker run -e ALERTMANAGER_URIS=default:https://alertmanager.example.com cloudflare/unsee:latest
docker run -e ALERTMANAGER_URI=https://alertmanager.example.com cloudflare/unsee:latest
Note that latest master branch might have bugs or breaking changes. Using
release images is strongly recommended for any production use.
@@ -121,324 +123,13 @@ This will build a Docker image from sources.
Will run locally built Docker image. Same defaults and override variables
apply as with `make run`. Example:
make PORT=5000 ALERTMANAGER_URIS=default:https://alertmanager.example.com run-docker
make PORT=5000 ALERTMANAGER_URI=https://alertmanager.example.com run-docker
## Environment variables
## Configuration
#### ALERTMANAGER_TIMEOUT
Timeout for requests send to Alertmanager, accepts values in
[time.Duration](https://golang.org/pkg/time/#Duration) format. Examples:
ALERTMANAGER_TIMEOUT=10s
ALERTMANAGER_TIMEOUT=2m
This option can also be set using `-alertmanager.timeout` flag. Example:
$ unsee -alertmanager.timeout 2m
Default is `40s`.
#### ALERTMANAGER_TTL
Interval for refreshing alerts and silences, tells unsee how often pull new
data from Alertmanager, accepts values in
[time.Duration](https://golang.org/pkg/time/#Duration) format. Examples:
ALERTMANAGER_TTL=30s
ALERTMANAGER_TTL=5m
This option can also be set using `-alertmanager.ttl` flag. Example:
$ unsee -alertmanager.ttl 5m
Default is `1m`.
Note that the maximum value for this option is `15m`.
The UI has a watchdog that tracks the timestamp of the last pull. If the UI
does not receive updates for more than 15 minutes it will print an error and
reload the page.
#### ALERTMANAGER_URIS
List of Alertmanager instances URI, unsee will use it to pull alert groups and
silences from all defined instances and deduplicate all alerts.
API endpoints in use:
* ${ALERTMANAGER_URI}/api/v1/alerts/groups
* ${ALERTMANAGER_URI}/api/v1/silences
Expected syntax:
${name1}:${uri} ${name2}:{uri}
Supported URI schemes:
* http://
* https://
* file://
`file://` scheme is only useful for testing purposes, it's used for `make run`
target.
Example:
ALERTMANAGER_URIS="prod:https://prod.alertmanager.example.com staging:https://staging.alertmanager.example.com"
This option can also be set using `-alertmanager.uris` flag. Example:
$ unsee -alertmanager.uris "prod:https://prod.alertmanager.example.com staging:https://staging.alertmanager.example.com"
This variable is required and there is no default value.
#### ANNOTATIONS_DEFAULT_HIDDEN
Enabling this option will hide all annotations in the UI, except for those
that are listed in the `ANNOTATIONS_VISIBLE` option.
Examples:
ANNOTATIONS_DEFAULT_HIDDEN=true
ANNOTATIONS_DEFAULT_HIDDEN=false
This option can also be set using `-annotations.default.hidden` flag. Example:
$ unsee -annotations.default.hidden
Default is `false`, which means that all annotations are visible.
#### ANNOTATIONS_HIDDEN
List of annotation names that should be hidden in the UI. Hidden annotations
can still be accessed if needed by clicking on a zoom button that will appear
if there are any hidden annotations.
Examples:
ANNOTATIONS_HIDDEN=summary
ANNOTATIONS_HIDDEN="summary owner"
This option can also be set using `-annotations.hidden` flag. Example:
$ unsee -annotations.hidden "summary owner"
This variable is optional and default is not set (all annotations are visible),
unless user enables `ANNOTATIONS_DEFAULT_HIDDEN` option.
#### ANNOTATIONS_VISIBLE
List of annotation names that should be visible in the UI. This option is only
useful when `ANNOTATIONS_DEFAULT_HIDDEN` is set.
With `ANNOTATIONS_DEFAULT_HIDDEN` all annotations are hidden by default unless
they are present in the `ANNOTATIONS_VISIBLE` option.
If `ANNOTATIONS_DEFAULT_HIDDEN` is not enabled this option is no-op.
Examples:
ANNOTATIONS_VISIBLE=summary
ANNOTATIONS_VISIBLE="summary owner"
This option can also be set using `-annotations.visible` flag. Example:
$ unsee -annotations.visible "summary owner"
This variable is optional and default is not set.
If `ANNOTATIONS_HIDDEN` is enabled then all annotations are hidden by default.
If `ANNOTATIONS_HIDDEN` is not enabled then all annotations are visible by
default.
#### DEBUG
Will enable [gin](https://github.com/gin-gonic/gin) debug mode. This will
configure to print out more debugging information on startup and enable
[https://golang.org/pkg/net/http/pprof/](pprof) debug endpoints.
Examples:
DEBUG=true
DEBUG=false
This option can also be set using `-debug` flag. Example:
$ unsee -debug
Default is `false`.
#### COLOR_LABELS_STATIC
List of label names that will all have the same color applied (different than
the default label color). This allows to quickly spot a specific label that
can have high range of values, but it's important when reading the dashboard.
For example coloring the instance label allows to quickly learn which instance
is affected by given alert. Accepts space separated list of label names.
Examples:
COLOR_LABELS_STATIC=instance
COLOR_LABELS_STATIC="instance cluster"
This option can also be set using `-color.labels.static` flag. Example:
$ unsee -color.labels.static "instance cluster"
This variable is optional and default is not set (no label will have static
color).
#### COLOR_LABELS_UNIQUE
List of label names that should have unique colors generated in the UI. Colors
can help visually identify alerts with shared labels, for example coloring
hostname label will allow to quickly spot all alerts for the same host.
Accepts space separated list of label names. Examples:
COLOR_LABELS_UNIQUE=hostname
COLOR_LABELS_UNIQUE="cluster environment rack"
This option can also be set using `-color.labels.unique` flag. Example:
$ unsee -color.labels.unique "cluster environment rack"
This variable is optional and default is not set (no label will have unique
color).
#### FILTER_DEFAULT
Default alert filter to apply when user loads unsee UI without any filter
specified. Accepts comma separated list of filter expressions (visit /help page
in unsee for details on filters). Examples:
FILTER_DEFAULT=level=critical
FILTER_DEFAULT="cluster=prod,instance=~prod"
This option can also be set using `-filter.default` flag. Example:
$ unsee -filter.default "cluster=prod,instance=~prod"
Default is not set (no filter will be applied).
#### JIRA_REGEX
This allows to define regex rules that will be applied to silence comments.
Regex rules will be used to discover JIRA issue IDs in the comment text and
inject links to those issues, instead of rendering as plain text.
Rule syntax:
$(regex)@$(jira url)
Accepts space separated list of rules. Examples:
JIRA_REGEX="DEVOPS-[0-9]+@https://jira.example.com"
The above will match DEVOPS-123 text in the silence comment string and convert
it to `https://jira.example.com/browse/DEVOPS-123` link.
This option can also be set using `-jira.regex` flag. Example:
$ unsee -jira.regex "DEVOPS-[0-9]+@https://jira.example.com"
This variable is optional and default is not set (no rule will be applied).
#### KEEP_LABELS
List of label names to show on the UI, all other labels will be stripped.
This allows to hide all labels except selected few that are useful on the
alert dashboard. Accepts space separated list of label names. Examples:
KEEP_LABELS=instance
KEEP_LABELS="host severity"
This option can also be set using `-keep.labels` flag. Example:
$ unsee -keep.labels "host severity"
This variable is optional and default is not set (all labels will be shown).
#### PORT
HTTP port to listen on. Example:
PORT=8000
This option can also be set using `-port` flag. Example:
$ unsee -port 8000
Default is `8080`.
#### SENTRY_DSN
DSN for [Sentry](https://sentry.io) integration in Go. See
[Sentry documentation](https://docs.sentry.io/quickstart/#configure-the-dsn) for
details. Example:
SENTRY_DSN=https://<key>:<secret>@sentry.io/<project>
This option can also be set using `-sentry.dsn` flag. Example:
$ unsee -sentry.dsn "https://<key>:<secret>@sentry.io/<project>"
This variable is optional and default is not set (Sentry support is disabled for
Go errors).
#### SENTRY_PUBLIC_DSN
DSN for [Sentry](https://sentry.io) integration in javascript. See
[Sentry documentation](https://docs.sentry.io/clients/javascript/) for details.
Example:
SENTRY_PUBLIC_DSN=https://<key>@sentry.io/<project>
This option can also be set using `-sentry.public.dsn` flag. Example:
$ unsee -sentry.public.dsn "https://<key>@sentry.io/<project>"
This variable is optional and default is not set (Sentry support is disabled for
javascript errors).
#### STRIP_LABELS
List of label names that should not be shown on the UI. This allows to hide some
labels that are not needed on the alert dashboard. Accepts space separated list
of label names. Examples:
STRIP_LABELS=exporter_type
STRIP_LABELS="prometheus_instance alert_type"
This option can also be set using `-strip.labels` flag. Example:
$ unsee -strip.labels "prometheus_instance alert_type"
This variable is optional and default is not set (all labels will be shown).
#### STRIP_RECEIVERS
List of receiver names that should not be shown on the UI. This allows to hide
all alerts for receivers that are not needed on the alert dashboard. Accepts
space separated list of receiver names. Examples:
STRIP_RECEIVERS=hipchat-test
STRIP_RECEIVERS="hipchat-test blackhole"
This option can also be set using `-strip.receivers` flag. Example:
$ unsee -strip.receivers "hipchat-test blackhole"
This variable is optional and default is not set (all receivers will be shown).
#### WEB_PREFIX
URL root for unsee, you can use to if you wish to serve it from location other
than /. Examples:
WEB_PREFIX=/unsee/
This will configure unsee to serve requests from http://localhost/unsee/
instead http://localhost/.
This option can also be set using `-web.prefix` flag. Example:
$ unsee -web.prefix /unsee/
Default is `/`.
Please see [CONFIGURATION](/docs/CONFIGURATION.md) for full list of avaiable
configuration options and [example.yaml](/docs/example.yaml) for a config file
example.
## Contributing

435
docs/CONFIGURATION.md Normal file
View File

@@ -0,0 +1,435 @@
# Configuration options
## Config file
### Alertmanagers
`alertmanager` section allows setting Alertmanager servers that should be
queried for alerts.
You can configure one or more Alertmanager servers, alerts
with identical label set will be deduplicated and labeld with each Alertmanager
server they were observed at. This allows using unsee to collect alerts from a
pair of Alertmanager instances running in
[HA mode](https://prometheus.io/docs/alerting/alertmanager/#high-availability).
Syntax:
```yaml
alertmanager:
interval: duration
servers:
- name: string
uri: string
timeout: duration
```
* `interval` - how often alerts should be refreshed, a string in
[time.Duration](https://golang.org/pkg/time/#ParseDuration) format. If set to
`1m` unsee will query every Alertmanager server once a minute. This is global
setting applied to every Alertmanager server. All instances will be queried
in parallel.
Note that the maximum value for this option is `15m`.
The UI has a watchdog that tracks the timestamp of the last pull. If the UI
does not receive updates for more than 15 minutes it will print an error and
reload the page.
* `name` - name of this Alertmanager server, will be used as a label added to
every alert in the UI and for filtering alerts using `@alertmanager=NAME`
filter
* `uri` - base URI of this Alertmanager server. Supported URI schemes are
`http://`, `https://` and `file://`. `file://` scheme is only useful for
testing with JSON files, see [mock](/internal/mock/) dir for examples, files
in this directory are used for running tests and when running demo instance
of unsee with `make run`.
* `timeout` - timeout for requests send to this Alertmanager server, a string in
[time.Duration](https://golang.org/pkg/time/#ParseDuration) format.
Example:
```yaml
alertmanager:
interval: 1m
servers:
- name: production1
uri: https://alertmanager1.prod.example.com
timeout: 20s
- name: production2
uri: https://alertmanager2.prod.example.com
timeout: 20s
- name: staging
uri: https://alertmanager.staging.example.com
timeout: 30s
```
Defaults:
```yaml
alertmanager:
interval: 1m
servers: []
```
There is no default for `alertmanager.servers` and it's a required option.
### Annotations
`annotations` section allows configuring how alert annotation are displyed in
the UI.
Syntax:
```yaml
annotations:
default:
hidden: bool
hidden: list of strings
visible: list of strings
```
* `default:hidden` - bool, true if all annotations should be hidden by default.
* `hidden` - list of annotations that should be hidden by default.
* `visible` - list of annotations that should be visible by default when
`default:hidden` is set to `true`.
Example where all annotations except `summary` are hidden by default. If there
are additional annotation keys user will need to click on the `+` icon to see
them.
```yaml
annotations:
default:
hidden: true
hidden: []
visible:
- summary
```
Example where all annotations except `details` are visible by default. If
`details` annotation is present on any alert user will need to click on the `+`
icon to see it.
```yaml
annotations:
default:
hidden: false
hidden:
- details
visible: []
```
Defaults:
```yaml
annotations:
default:
hidden: false
hidden: []
visible: []
```
### Colors
`colors` section allows configuring which labels should have colors applied
to label background in the UI. Colors can help visually identify alerts
with shared labels, for example coloring hostname label will allow to quickly
spot all alerts for the same host.
Syntax:
```yaml
colors:
labels:
static: list of strings
unique: list of strings
```
* `static` - list of label names that will all have the same color applied
(different than the default label color). This allows to quickly spot a
specific label that can have high range of values, but it's important when
reading the dashboard. For example coloring the instance label allows to
quickly learn which instance is affected by given alert.
* `unique` - list of label names that should have unique colors generated in
the UI.
Example with static color for the `job` label (every `job` label will have the
same color regardless of the value) and unique color for the `@receiver` label
(every `@receiver` label will have color unique for each value).
```yaml
colors:
labels:
static:
- job
unique:
- "@receiver"
```
Defaults:
```yaml
colors:
labels:
static: []
unique: []
```
### Debug
`debug` key allows enabling [gin](https://github.com/gin-gonic/gin) debug mode.
It will also configure to print out more debugging information on startup and
enable [https://golang.org/pkg/net/http/pprof/](pprof) debug paths.
Syntax:
```yaml
debug: bool
```
Defaults:
```yaml
debug: false
```
### Filters
`filters` section allows configuring default set of filters used in the UI.
Syntax:
```yaml
filters:
default: list of strings
```
* `default` - list of filters to use by default when user navigates to unsee
web UI. Visit `/help` page in unsee for details on avaiable filters.
Note that if a string starts with `@` YAML requires to wrap it in quotes.
Example:
```yaml
filters:
default:
- "@state=active"
- severity=critical
```
Defaults:
```yaml
filters:
default: []
```
### Labels
`labels` section allows configuring which alert labels will be rendered in the
UI. All labels will be parsed when collecting alerts from Alertmanager API and
used when deduplicating alerts, this section is only used to UI rendering and
should be used to remove those alerts that are not useful to users.
Syntax:
```yaml
labels:
keep: list of strings
strip: list of strings
```
* `keep` - list of allowed labels, if empty all labels are allowed.
* `strip` - list of ignored labels.
Example where `task_id` label is ignored by unsee:
```yaml
labels:
keep: []
strip:
- task_id
```
Example where all but `instance` and `alertname` labels are alowed:
```yaml
labels:
keep:
- alertname
- instance
strip: []
```
Defaults:
```yaml
labels:
keep: []
strip: []
```
### Listen
`listen` section allows configuring unsee web server behaviour.
Syntax:
```yaml
listen:
address: string
port: integer
prefix: string
```
* `address` -
* `port` - HTTP port to listen on.
* `prefix` - URL root for unsee, you can use to if you wish to serve it from
location other than `/`. This option is mostly useful when using unsee behind
reverse proxy with other services on the same IP but different URL root.
Example where unsee would listen for HTTP requests on http://1.2.3.4:80/unsee/
```yaml
listen:
address: 1.2.3.4
port: 80
prefix: /unsee/
```
Defaults:
```yaml
listen:
address: "*"
port: 8080
prefix: /
```
### Log
`log` section allows configuring logging subsystem.
Syntax:
```yaml
log:
config: bool
level: string
```
* `config` - if set to `true` unsee will log used configuration on startup
* `level` - log level to set for unsee, possible values are debug, info,
warning, error, fatal and panic.
Defaults:
```yaml
log:
config: true
level: info
```
### JIRA
`jira` section allows specifying a list of regex rules for finding links to Jira
issues in silence comments. If a string inside a comment matches one of the
rules it will be rendered as a link.
Syntax:
```yaml
jira:
- regex: string
- uri: string
```
* `regex` - regular expression for matching Jira issue ID.
* `uri` - base URL for Jira instance, `/browse/FOO-1` will be appended to it
(where `FOO-1` is example issue ID).
Example where a string `DEVOPS-123` inside a comment would be rendered as a link
to https://jira.example.com/browse/DEVOPS-123.
```yaml
jira:
- regex: DEVOPS-[0-9]+
uri: https://jira.example.com
```
Defaults:
```yaml
jira: []
```
### Receivers
`receivers` section allows configuring how alerts from different receivers are
handled by unsee.
Syntax:
```yaml
receivers:
strip: list of strings
```
* `strip` - list of receiver names that should be ignored when collecting data
from Alertmanager API. If alerts are routed to multiple receivers they can be
duplicated in the UI, each instance will have different value for `@receiver`.
This options allows to set a list of receivers that will not be shown in the
UI.
Example where alerts that are routed to the `alertmanage2es` receiver are
ignored by unsee.
```yaml
receivers:
strip:
- alertmanage2es
```
Defaults:
```yaml
receivers:
strip: []
```
### Sentry
`sentry` section allows configuring [Sentry](https://sentry.io) integration. See
[Sentry documentation](https://docs.sentry.io/quickstart/#configure-the-dsn) for
details.
Syntax:
```yaml
sentry:
private: string
public: string
```
* `private` - Sentry DSN for Go exceptions, this value is only used by unsee
binary and never exposed to the user.
* `public` - Sentry DSN for JavaScript exceptions, this value will be exposed
to the user browser.
Example:
```yaml
sentry:
private: https://<key>:<secret>@sentry.io/<project>
public: https://<key>:<secret>@sentry.io/<project>
```
## Command line flags
Config file options are mapped to command line flags, so `alertmanager:interval`
config file key is accessible as `--alertmanager.interval` flag, run
`unsee --help` to see a full list.
Exaceptions:
* `alertmanager.servers` - this config files option is a list of maps, to
configure multiple Alertmanager servers config file needs to be used.
It's possible to pass a single Alertmanager server URI using
`--alertmanager.uri` flag or `ALERTMANAGER_URI` environment variable. If this
flag/env is used name of the Alertmanager instance will be always `default`
and the timeout will be set to `40s`, customizing those two options requires
config file.
* `jira` - this option is a list of maps and it's only avaiable when using
config file.
## Environment variables
Environment variables are mapped in a similiar way as command line flags,
`alertmanager:interval` is accessible as `ALERTMANAGER_INTERVAL` env.
Same exceptions apply as with command line flags.

12
example.yaml → docs/example.yaml
View File

@@ -1,5 +1,3 @@
# Example config file
alertmanager:
interval: 60s
servers:
@@ -17,14 +15,22 @@ colors:
static:
- job
unique:
- cluster
- instance
- "@receiver"
debug: false
filters:
default: []
default:
- "@receiver=by-cluster-service"
labels:
keep: []
strip: []
listen:
address: "*"
port: 8080
prefix: /
log:
level: info
jira:
- regex: DEVOPS-[0-9]+
uri: https://jira.example.com

15
internal/config/config.go
View File

@@ -24,6 +24,7 @@ var (
)
func init() {
pflag.String("alertmanager.uri", "", "Alertmanager server URI")
pflag.Duration("alertmanager.interval", time.Second*60,
"Interval for fetching data from Alertmanager servers")
@@ -53,12 +54,14 @@ func init() {
"List of labels to keep, all other labels will be stripped")
pflag.StringSlice("labels.strip", []string{}, "List of labels to ignore")
pflag.Bool("log.config", true, "Log used configuration to log on startup")
pflag.String("log.level", "info",
"Log level, one of: debug, info, warning, error, fatal and panic")
pflag.StringSlice("receivers.strip", []string{},
"List of receivers to not display alerts for")
pflag.String("listen.address", "*", "IP/Hostname to listen on")
pflag.Int("listen.port", 8080, "HTTP port to listen on")
pflag.String("listen.prefix", "/", "URL prefix")
@@ -116,6 +119,7 @@ func (config *configSchema) Read() {
config.Listen.Address = v.GetString("listen.address")
config.Listen.Port = v.GetInt("listen.port")
config.Listen.Prefix = v.GetString("listen.prefix")
config.Log.Config = v.GetBool("log.config")
config.Log.Level = v.GetString("log.level")
config.Receivers.Strip = v.GetStringSlice("receivers.strip")
config.Sentry.Private = v.GetString("sentry.private")
@@ -133,6 +137,17 @@ func (config *configSchema) Read() {
// populate legacy settings if needed
config.legacySettingsFallback()
// accept single Alertmanager server from flag/env if nothing is set yet
if len(config.Alertmanager.Servers) == 0 && v.GetString("alertmanager.uri") != "" {
config.Alertmanager.Servers = []alertmanagerConfig{
alertmanagerConfig{
Name: "default",
URI: v.GetString("alertmanager.uri"),
Timeout: time.Second * 40,
},
}
}
}
// LogValues will dump runtime config to logs

6
internal/config/legacy.go
View File

@@ -43,7 +43,7 @@ func (config *configSchema) legacySettingsFallback() {
Timeout: time.Second * 40,
}
if os.Getenv("ALERTMANAGER_TIMEOUT") != "" {
log.Warn("ALERTMANAGER_TIMEOUT env variable is deprecated")
log.Warn("ALERTMANAGER_TIMEOUT env variable is deprecated and will be removed in the next release")
timeout, err := time.ParseDuration(os.Getenv("ALERTMANAGER_TIMEOUT"))
if err != nil {
log.Fatalf("Invalid ALERTMANAGER_TIMEOUT: %s", err)
@@ -56,13 +56,13 @@ func (config *configSchema) legacySettingsFallback() {
// no default filters and legacy FILTER_DEFAULT is present
if len(config.Filters.Default) == 0 && os.Getenv("FILTER_DEFAULT") != "" {
log.Warn("FILTER_DEFAULT env variable is deprecated")
log.Warn("FILTER_DEFAULT env variable is deprecated and will be removed in the next release")
config.Filters.Default = strings.Split(os.Getenv("FILTER_DEFAULT"), ",")
}
// no jira rules configured and legacy JIRA_REGEX is present
if len(config.JIRA) == 0 && os.Getenv("JIRA_REGEX") != "" {
log.Warn("JIRA_REGEX env variable is deprecated")
log.Warn("JIRA_REGEX env variable is deprecated and will be removed in the next release")
rules := []jiraRule{}
for _, s := range strings.Split(os.Getenv("JIRA_REGEX"), " ") {
ss := strings.SplitN(s, "@", 2)

3
internal/config/models.go
View File

@@ -45,7 +45,8 @@ type configSchema struct {
Prefix string
}
Log struct {
Level string
Config bool
Level string
}
JIRA []jiraRule
Receivers struct {

4
main.go
View File

@@ -95,7 +95,9 @@ func main() {
}
log.Infof("Version: %s", version)
config.Config.LogValues()
if config.Config.Log.Config {
config.Config.LogValues()
}
jiraRules := []models.JiraRule{}
for _, rule := range config.Config.JIRA {