Skip to content

Commit

Permalink
Merge pull request #54 from greatestusername/otel-dashboard-gen
Browse files Browse the repository at this point in the history
OpenTelemetry Receiver to Splunk Observability dashboard generator (Terraform configs)
  • Loading branch information
billg-splunk authored Mar 11, 2024
2 parents d383995 + 16e201b commit 319570b
Show file tree
Hide file tree
Showing 79 changed files with 25,037 additions and 0 deletions.
Original file line number Diff line number Diff line change
@@ -0,0 +1,195 @@
# Byte-compiled / optimized / DLL files
__pycache__/
*.py[cod]
*$py.class

# C extensions
*.so

# Distribution / packaging
.Python
build/
develop-eggs/
dist/
downloads/
eggs/
.eggs/
lib/
lib64/
parts/
sdist/
var/
wheels/
share/python-wheels/
*.egg-info/
.installed.cfg
*.egg
MANIFEST

# PyInstaller
# Usually these files are written by a python script from a template
# before PyInstaller builds the exe, so as to inject date/other infos into it.
*.manifest
*.spec

# Installer logs
pip-log.txt
pip-delete-this-directory.txt

# Unit test / coverage reports
htmlcov/
.tox/
.nox/
.coverage
.coverage.*
.cache
nosetests.xml
coverage.xml
*.cover
*.py,cover
.hypothesis/
.pytest_cache/
cover/

# Translations
*.mo
*.pot

# Django stuff:
*.log
local_settings.py
db.sqlite3
db.sqlite3-journal

# Flask stuff:
instance/
.webassets-cache

# Scrapy stuff:
.scrapy

# Sphinx documentation
docs/_build/

# PyBuilder
.pybuilder/
target/

# Jupyter Notebook
.ipynb_checkpoints

# IPython
profile_default/
ipython_config.py

# pyenv
# For a library or package, you might want to ignore these files since the code is
# intended to run in multiple environments; otherwise, check them in:
# .python-version

# pipenv
# According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
# However, in case of collaboration, if having platform-specific dependencies or dependencies
# having no cross-platform support, pipenv may install dependencies that don't work, or not
# install all needed dependencies.
#Pipfile.lock

# poetry
# Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
# This is especially recommended for binary packages to ensure reproducibility, and is more
# commonly ignored for libraries.
# https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
#poetry.lock

# pdm
# Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
#pdm.lock
# pdm stores project-wide configurations in .pdm.toml, but it is recommended to not include it
# in version control.
# https://pdm.fming.dev/#use-with-ide
.pdm.toml

# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
__pypackages__/

# Celery stuff
celerybeat-schedule
celerybeat.pid

# SageMath parsed files
*.sage.py

# Environments
.env
.venv
env/
venv/
ENV/
env.bak/
venv.bak/

# Spyder project settings
.spyderproject
.spyproject

# Rope project settings
.ropeproject

# mkdocs documentation
/site

# mypy
.mypy_cache/
.dmypy.json
dmypy.json

# Pyre type checker
.pyre/

# pytype static type analyzer
.pytype/

# Cython debug symbols
cython_debug/

# PyCharm
# JetBrains specific template is maintained in a separate JetBrains.gitignore that can
# be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
# and can be added to the global gitignore or merged into this file. For a more nuclear
# option (not recommended) you can uncomment the following to ignore the entire idea folder.
.idea/

# Local .terraform directories
**/.terraform/*

# .tfstate files
*.tfstate
*.tfstate.*

# Crash log files
crash.log
crash.*.log

# Exclude all .tfvars files, which are likely to contain sensitive data, such as
# password, private keys, and other secrets. These should not be part of version
# control as they are data points which are potentially sensitive and subject
# to change depending on the environment.
*.tfvars
*.tfvars.json

# Ignore override files as they are usually used to override resources locally and so
# are not checked in
override.tf
override.tf.json
*_override.tf
*_override.tf.json

# Include override files you do wish to add to version control using negated pattern
# !example_override.tf

# Include tfplan files to ignore the plan output of command: terraform plan -out=tfplan
# example: *tfplan*

# Ignore CLI configuration files
.terraformrc
terraform.rc
Original file line number Diff line number Diff line change
@@ -0,0 +1,55 @@
# Generate Splunk Observability Dashboards from OpenTelemetry Receivers
These scripts help users of OpenTelemetry Receivers from the [OpenTelemetry Collector Contrib](https://github.com/open-telemetry/opentelemetry-collector-contrib/) generate Terraform configurations of Splunk Observability dashboards from OpenTelemetry Receiver `metadata.yaml` files that contain the receiver's available metrics.

## Generate dashboard for a single receiver
Install the requirements and run `otel-dashboard-o11y.py` with the `--file_path` option pointing the `metadata.yaml` file for the receiver you'd like to generate from.

Note: The Terraform configuration will print to STDOUT which can be piped to a `.tf` file.
```
pip3 install -r requirements.txt
python3 otel-dashboard-o11y.py --file_path ./metadata.yaml
```

## Generate dashboards for many receivers
If the `--file_path` argument is not used the script will look in the local directory [`./otel-receiver-yaml/`](./otel-receiver-yaml/) for available receiver `metadata.yaml` files with metrics sections. Generated Terraform configurations will be placed in the local directory [`./observability-tf-configs`](./observability-tf-configs/).

`pull-otel-yaml.py` can be used to pull down all [receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver) configs with a `metrics` section and place them in the `./otel-receiver-yaml` directory. To avoid api rate limiting during this process a Github PAT token can be provided with the environment variable `$GITHUB_PAT_TOKEN`.
```
pip3 install -r requirements.txt
python3 pull-otel-yaml.py
Metadata.yaml with 'metrics' section extracted from activedirectorydsreceiver
Metadata.yaml with 'metrics' section extracted from aerospikereceiver
...
```

## Terraform Configuration Considerations
**NOTE:** These generated dashboards are not a replacement for any of the Out Of The Box dashboards available in Splunk Observability. [A list of those dashboards is available here](https://docs.splunk.com/observability/en/data-visualization/dashboards/dashboards-list.html). Using the out of the box dashboards will most likely provide the best monitoring experience for a given technology.

Generated Terraform configurations are just that... Generated. They include a line chart per metric named for that metric in a dashboard named for the receiver.

When generating a large number of configs there may be duplicate resource names in `terraform plan` based on metrics that use the same name. In this case edit the duplicate resource name and re-run `terraform plan`

### Terraform `signalfx` Provider
All generated configs work with the [`signalfx`]() Terraform provider. You'll need to define the provider in a `.tf` file in the same directory as your generated configurations.

**Example Provider configuration:** edit to incude your `api_url` and `$SFX_AUTH_TOKEN` for your specific Observability api url and api token.
```
terraform {
required_providers {
signalfx = {
version = "~> 9.0.0"
source = "splunk-terraform/signalfx"
}
}
}
# Configure the SignalFx provider
provider "signalfx" {
auth_token = "${var.SFX_AUTH_TOKEN}"
# If your organization uses a different realm
api_url = "https://api.us1.signalfx.com"
# If your organization uses a custom URL
# custom_app_url = "https://myorg.signalfx.com"
}
```
Loading

0 comments on commit 319570b

Please sign in to comment.